Simulación de cohetes

ÍNDICE DE CONTENIDO
1. GENERALIDADES ........................................................................................... 1
INTRODUCCIÓN.............................................................................................. 1
ANTECEDENTES ............................................................................................ 3
PLANTEAMIENTO DEL PROBLEMA ............................................................ 10
Identificación del Problema ........................................................................... 10
1.3.1.1. Identificación de la Situación Problemática .................................................... 10
1.3.1.2. Identificación de las causas ............................................................................ 10
Formulación del Problema .............................................................................. 11
Análisis Causa-Efecto .................................................................................... 11
1.3.3.1. Causa ............................................................................................................. 11
1.3.3.2. Efecto ............................................................................................................. 11
OBJETIVOS Y ACCIONES ............................................................................ 11
Objetivo General............................................................................................. 11
Objetivos Específicos y Acciones ................................................................... 12
JUSTIFICACIÓN ............................................................................................ 16
Justificación Técnica ...................................................................................... 16
Justificación Económica ................................................................................. 16
Justificación Operativa .................................................................................. 16
ALCANCE ...................................................................................................... 16
i
Alcance Temático ........................................................................................... 16
Alcance Temporal........................................................................................... 17
Alcance institucional ....................................................................................... 17
Alcance Funcional .......................................................................................... 17
HIPÓTESIS .................................................................................................... 17
Análisis de Variables ...................................................................................... 18
1.7.1.1. Variable Independiente................................................................................... 18
1.7.1.2. Variable Dependiente ..................................................................................... 18
Definición Conceptual..................................................................................... 18
1.7.2.1. Variable Independiente................................................................................... 18
1.7.2.2. Variable Dependiente ..................................................................................... 18
Operativización de Variables .......................................................................... 19
MATRIZ DE CONSISTENCIA ........................................................................ 20
2. MARCO TEÓRICO ......................................................................................... 21
TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN ................................... 21
Entrevistas ...................................................................................................... 21
Análisis de documentos .................................................................................. 22
INGENIERÍA DE SOFTWARE........................................................................ 23
Modelos de desarrollo ágil .............................................................................. 24
2.2.1.1. Programación Extrema (XP) ........................................................................... 24
2.2.1.2. Scrum ............................................................................................................. 26
ii
2.2.1.3. Desarrollo rápido de aplicaciones(RAD)......................................................... 30
Pruebas de Software ...................................................................................... 32
2.2.2.1. Tipos de Prueba ............................................................................................. 33
SIMULACIÓN DE SISTEMAS ........................................................................ 34
Etapas para elaboración de un simulador ...................................................... 34
2.3.1.1. Herramientas de modelación .......................................................................... 35
2.3.1.2. Métodos de validación .................................................................................... 45
MODELAMIENTO EN 3D ............................................................................... 46
Herramientas de modelado en 3D .................................................................. 47
2.4.1.1. Blender ........................................................................................................... 47
2.4.1.2. AutoDesk 3DS Max ........................................................................................ 49
TECNOLOGÍAS DE DESARROLLO .............................................................. 50
Lenguaje de Programación ............................................................................ 50
2.5.1.1. Java ................................................................................................................ 50
2.5.1.2. Python ............................................................................................................ 53
Arquitectura de Software ................................................................................ 55
2.5.2.1. Patrones de Arquitectura ................................................................................ 55
Base de Datos ................................................................................................ 61
2.5.3.1. Tipos de Bases de Datos ............................................................................... 62
2.5.3.2. Software de Gestión de Bases de Datos ........................................................ 68
3. MARCO PRÁCTICO....................................................................................... 74
iii
ANÁLISIS DEL PROCESO ACTUAL DE DESARROLLO DE NUEVOS
PROTOTIPOS DE COHETES ........................................................................ 74
Análisis del proceso actual de desarrollo de prototipos .................................. 74
3.1.1.1. Planificación de Diseño de Prototipo .............................................................. 75
3.1.1.2. Fabricación del Propelente y las Pastillas ...................................................... 75
3.1.1.3. Construcción las piezas del motor de cohete ................................................. 77
3.1.1.4. Pruebas de Validación en Banco de Pruebas ................................................ 78
3.1.1.5. Planificación del Diseño de Fuselaje del Prototipo ......................................... 79
3.1.1.6. Pruebas de Validación del diseño del Prototipo ............................................. 80
3.1.1.7. Pruebas de Campo del Prototipo ................................................................... 80
Falencias del software de simulación ............................................................. 81
Definición del sistema propuesto .................................................................... 83
3.1.3.1. Requerimientos y estimaciones sobre el sistema a desarrollar ...................... 83
3.1.3.2. Definición de Variables ................................................................................... 84
3.1.3.3. Elaboración del modelo propuesto para el sistema ........................................ 90
FORMULACIÓN DE LOS MODELOS DE SIMULACIÓN PARA

REPRESENTAR LA IMPLEMENTACIÓN DE LOS DISEÑOS DE LOS
COHETES ...................................................................................................... 91
Modelos Matemáticos..................................................................................... 91
3.2.1.1. Modelo de motor de combustible sólido. ........................................................ 91
Modelo de las piezas de fuselaje para cohetes. ........................................... 101
Modelo del ambiente y otros factores que afecten al cohete. ....................... 102
iv
Colección de datos ....................................................................................... 105
3.2.4.1. Datos de Variables ....................................................................................... 106
IMPLEMENTACIÓN DE LOS MODELOS DE LOS COHETES

BASÁNDOSE EN LA INFORMACIÓN RECOPILADA ................................. 113
Metodología de desarrollo de software para el proyecto. ............................. 113
3.3.1.1. Aplicación de Patrón de Arquitectura ........................................................... 124
Selección de tecnologías de desarrollo para su implementación ................. 126
Desarrollo de Primer Sprint .......................................................................... 128
3.3.3.1. Historias de Usuario ..................................................................................... 128
3.3.3.2. Codificación de la interfaz de salida y entrada de datos............................... 131
3.3.3.3. Elaboración de la Base de Datos ................................................................. 132
3.3.3.4. Codificar el módulo del motor de combustible sólido.................................... 138
3.3.3.5. Patrón de Arquitectura.................................................................................. 147
3.3.3.6. Pruebas para Primer Sprint .......................................................................... 148
Desarrollo de Segundo Sprint ...................................................................... 154
3.3.4.2. Codificación de los cálculos de rendimiento de Motor .................................. 157
3.3.4.4. Pruebas de segundo sprint ........................................................................... 162
Desarrollo de tercer sprint ............................................................................ 165
3.3.5.1. Historias de usuario ...................................................................................... 165
v
3.3.5.2. Desarrollo de fuselajes ................................................................................. 169
3.3.5.4. Pruebas de tercer sprint ............................................................................... 172
Desarrollo de cuarto sprint ........................................................................... 175
3.3.6.2. Desarrollo de vuelo de prototipo ................................................................... 179
3.3.6.4. Pruebas de cuarto sprint .............................................................................. 180
EXPERIMENTACIÓN CON EL MODELO DE SIMULACIÓN E

INTERPRETACIÓN DE LOS RESULTADOS OBTENIDOS. ....................... 182
Validación de Modelos mediante comparación con datos previos ............... 182
Experimentación con datos .......................................................................... 188
3.4.2.1. Experimentación con datos de propelente ................................................... 188
3.4.2.2. Datos de Prueba de las Maniobras en Patacamaya .................................... 191
3.4.2.3. Experimentación con datos físicos en Patacamaya ..................................... 195
DEMOSTRACIÓN DE LA HIPÓTESIS ......................................................... 198
Demostración de la Primera Variable Dependiente ...................................... 198
Demostración de la Segunda Variable Dependiente .................................... 200
Demostración de la Hipótesis de Variable Independiente ............................ 203
3.4.5.1. Planteamiento de la hipótesis ....................................................................... 204
3.4.5.2. Calculo estadístico “T” .................................................................................. 205
vi
4. ANÁLISIS DE VIABILIDAD........................................................................... 208
VIABILIDAD TÉCNICA ................................................................................. 208
VIABILIDAD ECONÓMICA ........................................................................... 209
Justificación de los valores de conductores de costo ................................... 216
VIABILIDAD OPERATIVA ............................................................................ 222
5. CONCLUSIONES Y RECOMENDACIONES ............................................... 224
CONCLUSIONES ......................................................................................... 224
RECOMENDACIONES ................................................................................ 226
BIBLIOGRAFÍA
vii
ANEXOS
ANEXO A: DIAGRAMA DE ISHIKAWA
ANEXO B: ENTREVISTA A ING. HAROLD PÉREZ (1)
ANEXO C: ENTREVISTA A ING. HAROLD PÉREZ (2)
ANEXO D: TABLAS TERMODINÁMICA DE CO2
ANEXO E: TABLA TERMODINÁMICA DE CO
ANEXO F: TABLA TERMODINÁMICA DE H2O
ANEXO G: TABLA TERMODINÁMICA DE H2
ANEXO H: TABLA TERMODINÁMICA DE N2
ANEXO I: TABLA TERMODINÁMICA DE K2CO3
ANEXO J: TABLA TERMODINÁMICA DE KOH
ANEXO K: CLASIFICACIÓN DE MOTORES
ANEXO L: MATERIALES DE CONSTRUCCIÓN
ANEXO M: ENTREVISTA A ING. HAROLD PÉREZ (3)
ANEXO N: DIAGRAMA DE CASOS DE USO
ANEXO O: DIAGRAMAS DE COLABORACIÓN
ANEXO P: ENTREVISTA A ING. HAROLD PÉREZ (4)
ANEXO R: COTIZACIÓN PARA UNA UNIDAD DESARROLLADA POR EL PROGRAMA

AEROESPACIAL.
ANEXO S: DATOS DE PRUEBA.
viii
INDICE DE FIGURAS
Figura 1: Soldado chino preparándose a disparar un NH-5. .......................................... 3
Figura 2: Emblema del programa aeroespacial. ............................................................. 4
Figura 3: Diagrama de motor de combustible sólido ...................................................... 6
Figura 4: Comparación de datos reales con datos del simulador. .................................. 9
Figura 5: Matriz de Consistencia. ................................................................................. 20
Figura 6: Ejemplo de Diagrama de Secuencias. .......................................................... 37
Figura 7: Elementos de Diagrama de Casos de Uso. .................................................. 42
Figura 8: Diagrama de Modelo Vista-Controlador ........................................................ 56
Figura 9: Diagrama de Modelo Vista-Presentador. ...................................................... 57
Figura 10: Diagrama de Modelo Vista-Vista Modelo .................................................... 59
Figura 11: Modelado del proceso actual ...................................................................... 74
Figura 12: Modelo propuesto del sistema. ................................................................... 90
Figura 13: Interfaz de elaboración de propelente. ...................................................... 131
Figura 14: Diagrama de base de datos ...................................................................... 133
Figura 15: Forma tradicional del grano del propelente. .............................................. 146
Figura 16: Pastillas terminadas. ................................................................................. 147
Figura 17: Banco de Pruebas ..................................................................................... 157
Figura 18: Gráficos MatPlotLib ................................................................................... 158
Figura 19: Tabla de datos estadísticos....................................................................... 158
Figura 20: Áreas de la tobera ..................................................................................... 159
ix
Figura 21: Tipos de narices ........................................................................................ 170
Figura 22: Tabla de Fisher. ........................................................................................ 185
Figura 23: Grafico de Fisher I. .................................................................................... 185
Figura 25: Grafico de Fisher II. ................................................................................... 187
Figura 26: Lanzamiento a 45 grados .......................................................................... 196
Figura 27: Lanzamiento a 35 grados .......................................................................... 197
Figura 30: Grafico de Fisher III. .................................................................................. 199
Figura 31: Realización de prueba en banco de pruebas. ........................................... 200
Figura 32: Gráfico de gauss para la hipótesis ............................................................ 207
x
INDICE DE TABLAS
Tabla 1: Objetivos Específicos y Acciones ................................................................... 12
Tabla 2: Operativización de Variables .......................................................................... 19
Tabla 3: Ventajas y desventajas de Programación Extrema ........................................ 26
Tabla 4: Ventajas y desventajas de Scrum................................................................... 29
Tabla 5: Ventajas y desventajas de RAD. .................................................................... 31
Tabla 6: Elementos de Diagrama de Secuencias. ........................................................ 38
Tabla 7: Ventajas y desventajas del Diagrama de Secuencias .................................... 41
Tabla 8: Ventajas y desventajas del Diagrama de Casos de Uso. ............................... 44
Tabla 9: Métodos de validación para modelo de simulación. ....................................... 45
Tabla 10: Ventajas y desventajas de Blender ............................................................... 48
Tabla 11: Ventajas y desventajas de AutoDesk ........................................................... 50
Tabla 12: Ventajas y desventajas de Java. .................................................................. 52
Tabla 13: Ventajas y desventajas de Python. ............................................................... 54
Tabla 14: Ventajas y desventajas de MVC ................................................................... 57
Tabla 15: Ventajas y desventajas de MVP ................................................................... 58
Tabla 16: Ventajas y desventajas de MVVM ................................................................ 60
Tabla 17: Ventajas y desventajas de Bases de Datos Relacionales ............................ 63
Tabla 18: Ventajas y desventajas de Bases de Datos NoSQL ..................................... 66
Tabla 19: Ventajas y desventajas de MySQL. .............................................................. 69
Tabla 20: Ventajas y desventajas de SQL Server. ....................................................... 71
xi
Tabla 21: Ventajas y desventajas de PostgreSQL ....................................................... 73
Tabla 22: Experimentación Impulso ISP e Impulso Especifico ..................................... 78
Tabla 23: Condiciones ambientales en Bolivia. ............................................................ 82
Tabla 24: Variables de Entrada. ................................................................................... 84
Tabla 25: Variables de Proceso. ................................................................................... 86
Tabla 26: Variables de Salida. ...................................................................................... 87
Tabla 27: Datos de Variables de Entrada ................................................................... 106
Tabla 28: Datos de Variables de Salida...................................................................... 108
Tabla 29: Datos de Impulso Específico ...................................................................... 112
Tabla 30: Comparación de ventajas de modelos de metodología ágil........................ 114
Tabla 31: Comparación de desventajas de modelos de metodología ágil. ................. 115
Tabla 32: Asignación de roles de Scrum. ................................................................... 117
Tabla 33: Historias de Usuario ................................................................................... 118
Tabla 34: Planificación de Sprint. ............................................................................... 122
Tabla 35: Sprint e historias de usuario de cada objetivo. ........................................... 123
Tabla 36: Implementación de MVC............................................................................. 126
Tabla 37: Historia de Usuario #1 ................................................................................ 128
Tabla 41: Diccionario de datos ................................................................................... 134
Tabla 42: Productos de la reacción. ........................................................................... 139
xii
Tabla 43: Estados de compuestos de la reacción. ..................................................... 140
Tabla 38: Balanceo de reacción química .................................................................... 141
Tabla 44: Datos de moles y masas ............................................................................ 142
Tabla 45: Comparación con datos de JANAF ............................................................. 144
Tabla 47: Pruebas funcionales del primer sprint #1 .................................................... 148
Tabla 50: Tabla de resultados de las pruebas de Primer Sprint ................................. 152
Tabla 51: Retrospectiva del primer sprint. .................................................................. 152
Tabla 56: Prueba funcional del segundo sprint #1 ...................................................... 162
Tabla 57: Tabla de resultados de las pruebas de Segundo Sprint ............................. 164
Tabla 58: Retrospectiva del segundo sprint. ............................................................... 164
Tabla 59: Historia de usuario #7 ................................................................................. 165
Tabla 62: Historia de usuario #10 ............................................................................... 168
xiii
Tabla 64: Prueba funcional del tercer sprint ............................................................... 172
Tabla 65: Tabla de resultados de las pruebas de Tercer Sprint ................................. 174
Tabla 66: Retrospectiva del tercer sprint. ................................................................... 174
Tabla 72: Prueba funcional del cuarto sprint .............................................................. 180
Tabla 73: Tabla de resultados de las pruebas de Cuarto Sprint ................................. 181
Tabla 74: Retrospectiva del cuarto sprint. .................................................................. 182
Tabla 75: Experimentación con Datos de Impulso (ISP) ............................................ 191
Tabla 76: Experimentación con Datos de Impulso (Impulso Específico) .................... 193
Tabla 76: Comparación de tiempos con sistema actual y sistema propuesto. ........... 201
Tabla 77: Tabla comparativa de beneficios ................................................................ 204
Tabla 78: Requerimientos mínimos e ideales de Hardware. ...................................... 208
Tabla 79: Requerimientos mínimos e ideales de Software ......................................... 209
Tabla 80: Costo de requerimientos. ............................................................................ 210
Tabla 81: Valores de coeficientes de COCOMO. ....................................................... 212
Tabla 82: Factores de costo en COCOMO ................................................................. 213
xiv
Tabla 83: Costo mínimo estimado. ............................................................................. 219
Tabla 84: Costo ideal estimado. ................................................................................. 219
Tabla 85: Tabla de costos con y sin sistema. ............................................................. 220
xv
1. GENERALIDADES
INTRODUCCIÓN
Durante la historia de la humanidad, hasta llegar a la actualidad, la tecnología militar se

constituye en el instrumento crucial para el dominio planetario referente al aspecto
económico y político de las grandes potencias mundiales sobre los países en vías de
desarrollo y sub desarrollados. La constante renovación del arsenal militar, terrestre y
aéreo de los países vecinos de Sud América, se constituye en una amenaza permanente
para la soberanía del territorio boliviano, obligando a tomar acciones reales, de esta
manera surge la necesidad en las FF.AA. de desarrollar ciencia y tecnología militar en el
ámbito de seguridad y defensa nacional. Habiéndose establecido este primordial
requerimiento de tecnología militar en las FF.AA. de Bolivia, se están desarrollando a
partir del año 2005, diferentes prototipos de aeronaves (Fuerza Aérea Boliviana),
embarcaciones (Armada Boliviana) y cohetes balísticos (Ejercito de Bolivia). Una de las
condiciones fundamentales para que las FF.AA. desarrollen tecnología militar “moderna”
es la utilización o desarrollo de equipos electrónicos para alcanzar a todos los niveles y
modalidades posibles de combate que actualmente emplean las potencias mundiales.
De acuerdo a este contexto, en el Ejército de Bolivia surge la primordial necesidad para

desarrollar tecnología que pueda implementarse en los diferentes prototipos de “cohetes
balísticos” mencionados, el cual es el objetivo del programa aeroespacial de la Escuela
Militar de Ingeniería. En la actualidad, los cohetes misiles son considerados en muchos
aspectos una de las principales armas de largo alcance, usada prácticamente a nivel
general por todos los países del mundo, usualmente los misiles tienen una o más
cabezas de guerra explosivas, pueden ser empleados de acuerdo a las características
de la táctica y estrategia militar: Misión, Velocidad y Alcance. Por misión se refiere al tipo
de medios que tendrá que atravesar el misil (tierra, aire y agua o submarino), velocidad
comúnmente toma en cuenta el lugar que ocupa en relación al sonido en unidades mach
(un mach es igual a 1234.8 kilómetros por hora) y alcance se refiere a los kilómetros que
pueda alcanzar el misil durante su vuelo. El sistema de guía de un misil es un diseño
físico y lógico que mediante un conjunto de componentes electrónicos, proporcionaban
1 - 236
datos al sistema de control del misil, para que este a su vez lo maniobre para interceptar
al objetivo (en general moviendo las aletas de guía del misil o variando el ángulo de su
chorro de escape), las ordenes electrónicas impuestas por el sistema de guía pueden
ser generadas dentro del mismo misil, o recibirse de una fuente externa, aunque en
general el localizador o buscador se encuentra en la cabeza del misil por lo que recibe el
nombre de “guía inteligente”, “cabeza buscadora”, entre otros para llevar adelante un
eficiente proceso de investigación y experimentación las grandes industrias
armamentistas utilizan un “simulador de vuelo”. (Encyclopedia Britannica, 2017).
Se puede definir a una simulación como una representación de la realidad, en otras

palabras, la representación de un objeto o situación dentro de la realidad. La importancia
de un sistema de simulación para la elaboración de cohetes entra en su capacidad de
poner a prueba los distintos diseños, materiales de construcción y otros elementos
empleados en los mismos, para poder medir como afectan al rendimiento del cohete, sin
tener que someter prototipos a condiciones de la vida real. Sin embargo no está de más
el recordar que la simulación es sólo una aproximación de la realidad, y por lo tanto sólo
tan preciso como el propio procedimiento de recrear las condiciones del mundo físico,
cosa que los desarrolladores, como los del programa aeroespacial, deben tener gran
cuidado de evitar. Es decir, si se realiza una simulación con datos o modelos que no se
adhieran lo suficiente a la realidad, se corre riesgo de que los resultados estén alejados
de la calidad esperada. (Bu, 1993, p. 12).
A pesar de esto, un simulador desarrollado con el cuidado apropiado a la codificación de

cada una de sus partes, podrá potencialmente llegar a ser una herramienta fundamental
para la simulación de propulsión de cohetes, esto permitirá realizar diseños de prototipos
con datos más precisos como apoyo, aumentando la calidad de nuestro producto final,
ya que los simuladores existentes en la actualidad no generan resultados apropiados
para la realidad del entorno, el cual es analizado por el programa aeroespacial. (Banks,
1998, p. 13).
2 - 236
ANTECEDENTES
Bolivia desde el gobierno del Dr. Víctor Paz Estensoro en la década de los sesenta, el
ejército empezó el proceso de adquisición de armamento y munición, comúnmente de
China. Esta práctica continuaría en las décadas siguientes, a través de los distintos
gobiernos que tomaban lugar en el país. Los primeros modelos a ser adquiridos fueron
los misiles chinos NH-5 de tipo MANPAD (“Man-portable air-defense system”, que
traducido quiere decir “Sistema de Defensa Aérea Portátil”), cuya apariencia es ilustrada
en la figura 1. El Comando General del Ejército (COMANEJTO), mediante su centro de
investigación de ciencia y tecnología, fue desarrollado de forma experimental a partir de
2005 diferentes prototipos de “cohetes balísticos”, con fines militares de seguridad y
defensa.
Figura 1: Soldado chino preparándose a disparar un NH-5.
Fuente: (weaponsystems, 2016).
Durante la gestión de 2015, la Escuela Militar de Ingeniería (EMI), instituyó como parte
del Departamento de Investigación de Ciencia y Tecnología (DICyT), el “Programa de
Desarrollo en Tecnología Aeroespacial” (PDTA-EMI), en la unidad académica
Cochabamba, habiendo conformado un equipo multidisciplinario formado por docentes y
estudiantes, el cual actualmente se encuentra en proceso de desarrollar e incorporar
3 - 236
sistemas electrónicos para los mencionados cohetes. El logo establecido para el
Programa Aeroespacial se muestra en la Figura 2. (Bozo, 2016, p. 2, 3, 4).
Figura 2: Emblema del programa aeroespacial.
Fuente: (Programa aeroespacial, 2016).
En el día de hoy, es prácticamente imposible encontrar a una persona que no esté

familiarizada con el concepto de un cohete. Su fama es producto de su implementación
extensa, desde como objeto de pasatiempo para aficionados hasta pieza de armamento
militar o equipo espacial. Un cohete es un vehículo, aeronave o nave espacial que sigue
una trayectoria definida por el ángulo de lanzamiento, que obtiene su empuje por la
reacción de la expulsión rápida de gases de combustión, desde un motor diseñado para
ser utilizado por un combustible determinado. El crédito de la invención de los primeros
tipos de cohetes se le atribuye al ingenio de la antigua China del siglo XIII, periodo
durante el cual se les conoció como “Flechas de Fuego”. Como fue mencionado antes,
un cohete puede ser diseñado para servir a una extensa variedad de propósitos, en
ocasiones recibiendo una nueva denominación con este, como por ejemplo el caso de
los misiles. El misil es aquel cohete de uso militar con capacidad de ser dirigido,
manejado o guiado durante toda o parte de su trayectoria para alcanzar un objetivo. Un
cohete puede emplear varios tipos de combustibles o propelentes. Estos han
4 - 236
evolucionado desde los días más primitivos de los cohetes, época donde la pólvora negra
era el material principal, hasta la era moderna donde se usan diferentes sustancias
químicas usando sus reacciones al momento de la combustión, para impulsar el cohete
en su lanzamiento y transcurso de su vuelo. Entre los tipos de combustible para cohetes
existentes, se puede encontrar sólidos y líquidos, aunque en ocasiones más reducidas
también se suele usar combustibles en forma de gas y de gel. Durante gran parte de la
historia de los cohetes, los combustibles sólidos han sido la principal fuente de propulsión
para los cohetes. Como su nombre lo indica, se refiere a varias formas de material sólido
que pueden ser quemadas para liberar energía, a través del proceso de combustión.
Actualmente los combustibles sólidos son los propelentes más económicos y fáciles de
conseguir. Una característica importante de estos es su capacidad de permanecer un
extenso periodo de tiempo en almacenamiento, además de necesitar de un periodo de
preparación corto para ponerse en uso al instante. Estos dos factores, son la razón por
la que este tipo de propelente es popular con los misiles. (Dinesh, Shishira & Shravya,
2016, p. 1).
Para su implementación en aparatos más complejos, por ejemplo misiles militares, los
combustibles sólidos usados suelen ser mezclas distintas de elementos químicos.
Compuestos como el Zinc, Magnesio, Azufre y otros, son los más comunes, estos son
pulverizados y mezclados para luego ser introducidos en los cohetes. Las combinaciones
de elementos que se pueden utilizar son variadas y se elaboran a base de los
requerimientos que tiene el cohete que se esté diseñando. En el caso de un motor que
funciona con combustible sólido, se puede decir que tiene un diseño bastante simple de
entender, la estructura de este se encuentra ilustrada en la figura 3, señalando todas sus
partes. El motor está básicamente compuesto de tres partes visibles: la cámara de
combustión (básicamente un tubo dentro del cual se deposita el combustible o
propelente), la tobera (es el cono que se acostumbra ver en el extremo inferior del cohete)
y la tapa de la cámara de combustión (ocupa el rol que su propio nombre indica, sellando
la cámara). A su vez dentro de la cámara de combustión misma se puede hallar, como
fue mencionado antes, el combustible a usar, que llena casi completamente el tubo, a
5 - 236
excepción de un espacio al centro donde se coloca al “ignitor” que se utiliza para
encender la cámara de combustible. (Davenas, 2012, p. 2 - 8).
Al encender el combustible dentro de un motor como este, se generan gases de alta

presión, que al no tener más que una salida, pasan forzosamente por la tobera que esta
diseñada con una forma que hace que los gases salientes pasen con mayor velocidad
hacia afuera de lo que harían normalmente, aumentando el impulso del motor. (Kuo,
1984, p. 4).
Figura 3: Diagrama de motor de combustible sólido
Fuente: Elaboración Propia, 2017.
El proceso para la elaboración de un cohete se puede organizar en seis pasos a seguir:
 Diseño del Motor según requerimientos del cohete: Es el nivel más básico del cohete,
donde se establecen cuáles serán las características del motor y se empieza a
diseñar un prototipo. No se puede diseñar ninguna parte del cohete si no se ha
completado y verificado el motor, este es el corazón del cohete. Si este no funciona
apropiadamente no se puede proceder con el fuselaje. (Davenas, 2012, p. 19).
 Pruebas en Bancos de Pruebas: Se prueba el empuje que tiene el cohete al
encenderlo, colocándolo en una contracción que sostiene el motor de forma vertical,
6 - 236
equipado con sensores que convierten la fuerza aplicada en ellas en una señal
electrónica. Estos miden la fuerza de empuje, y envían la información que registra a
una computadora donde se elabora una gráfica que compara empuje y tiempo.
También se mide el impulso total del cohete, el cual sirve para clasificar el motor
según su rendimiento. Existe unas normas creadas por diferentes agencias y
fabricantes de cohetes, que establecen una serie de categorías para motores de
cohete que mayormente toman el nombre de letras del abecedario, donde cada una
tiene asignada un rango de impulso. Para aplicar estas normas, se debe buscar la
categoría donde el impulso del motor se encuentre dentro del rango establecido de
esta, por lo que se le designa la letra correspondiente a la categoría. La tabla de
clasificación se encuentra en el Anexo K. Es en esta etapa donde se verifica si el
motor diseñado logra satisfacer las condiciones por las que fue creado. La cámara de
combustión tiene que ser capaz de soportar la reacción del propelente dentro de ella
y contenerla hasta un punto determinado de temperatura. Si este aspecto se
descuida, el motor puede llegar a estallar o sufrir otras averías que afecten al cohete.
(Desrochers, Olsen, & Hudson, 2001, p. 50-55).
 Diseño de Fuselaje: Con el diseño de motor verificado, el siguiente paso es diseñar
el fuselaje o la capa externa alrededor del motor. Es aquí cuando se pueden integrar
al diseño del cohete características más familiares, como aletas y la nariz en forma
de cono. El motor ocupa un lugar en la base del cohete, es decir la parte inferior de
esta, sobre la cual se le agrega otra sección en forma de tubo que servirá para llevar
la carga del cohete, y en el final la nariz de cono. Es importante recordar que el
fuselaje solo puede diseñarse a partir del motor, nunca antes de tenerlo definido.
(NASA, 2017).
 Probar Estabilidad: Tras haber obtenido la forma final del cohete, con el diseño de las
aletas y ojiva en el fuselaje, ahora se tiene que probar la estabilidad en vuelo,
tomando en cuenta el centro de masa y el centro de presión que suelen estar en dos
puntos diferentes en el largo del cohete, puesto que la estabilidad del cohete depende
de un equilibro entre ambos. (NASA, 2017).
7 - 236
 Construcción de la Unidad: Aquí es donde se empieza a construir una versión física
del cohete, hasta donde se encuentre detallado en este punto. Después de completar
el cohete físico, se lo somete a una prueba de túnel de viento, para verificar si el
diseño es lo suficientemente aerodinámico, como para soportar flujo laminar y
turbulento del aire. (Milligan, 2013, p. 2).
 Pruebas de Campo: Por último se realizan pruebas del modelo al aire abierto para
poder verificar si son cohetes viables. Cabe destacar que usualmente se necesitan
de 50 unidades como mínimo para hacer validar el diseño de un cohete.
(PlanetDestiny, 2015).
Durante la elaboración de un prototipo de cohete, se suele implementar software de

simulación de cohetes para perfeccionar el diseño. Para lograr esto se hace uso de
programas especiales para recrear el lanzamiento de un cohete. Entre los software para
simulación de cohetes más comunes se pueden destacar dos en particular los cuales
son empleados en el desarrollo de prototipos: RockSim y SpaceCAD. Ninguno de ellos
es gratuito, pero existen versiones de prueba que los posibles usuarios interesados
puedan probar familiarizarse con el software. Los programas están desarrollados usando
datos de condiciones ambientales propias de su país de origen, tanto RockSim como
SpaceCAD son programas amateur. Es decir, que ninguno de ellos fue desarrollado para
la elaboración de diseños más avanzados de cohetes. Esto afecta directamente la
precisión de resultados que devuelve tras cada prueba realizada, esto se puede
presentar en distintas partes de la información, desde la fuerza de empuje hasta el tiempo
de vuelo del cohete. Además el software que existe actualmente en el mercado, basa
sus cálculos en condiciones ambientales ajenas a Bolivia. (Science Learning Hub, 2011).
En pruebas realizadas en el pasado con los miembros del Programa Aeroespacial, se
mostró en más de una ocasión que el software de simulación llegaba a obtener en varias
ocasiones resultados que se salían del 5% de margen de error aceptable, según
entrevistas realizadas a sus miembros (Ver Anexo C).
Para el Programa Aeroespacial, el desarrollar un prototipo puede tomar meses enteros

antes de que se puede estar listos para realizar las pruebas. Según entrevistas, puede
8 - 236
tomar un buen tiempo antes de que este listo para ser probado, sin mencionar que en
caso de encontrar imperfecciones esto significa rehacer partes del diseño y volver a
comisionar todo para realizar otra prueba. (Ver Anexo M).
Como un ejemplo de las falencias que contiene el software existente se tiene la siguiente
situación: El Programa Aeroespacial desarrollo el prototipo de cohete B1M1, empleando
una mezcla de propelente KNSU. Es decir, Nitrato de Potasio y Sucrosa. Para el proceso
de elaboración, se empleó RockSim para la elaboración de la unidad. Como resultado
de este proceso se obtuvieron los datos usuales, incluyendo el empuje generado por el
motor que se muestra en el lado izquierdo de la figura 4:
Figura 4: Comparación de datos reales con datos del simulador.
Fuente: (Programa aeroespacial, 2016).
Sin embargo, durante el proceso de elaborar una unidad física, al realizar la prueba de
banco de pruebas, se encontró la gráfica de empuje de la derecha de la figura 4. A simple
vista, se puede ver que los datos generados por el software son diferentes a los
registrados en la vida real. Existe una diferencia de casi 500 Newtons en el empuje del
motor. Este tipo de diferencia radical de lo indicado por el software hace que los
resultados del mismo no puedan ser adecuados para llevar a cabo el desarrollo de futuros
prototipos. Los desarrolladores del Programa Aeroespacial, tuvieron que retroceder y
9 - 236
realizar cambios al diseño del propelente y del motor, causando que todo el tiempo
invertido en el motor anterior se convierta en perdida. Situaciones similares han ocurrido
al realizar no solo pruebas de banco de pruebas, sino en pruebas de campo.
PLANTEAMIENTO DEL PROBLEMA
Identificación del Problema
1.3.1.1. Identificación de la Situación Problemática
 Los resultados devueltos por los simuladores, según las entrevistas al programa
aeroespacial, son inconsistentes provocando una inconsistencia en la apreciación
y aproximación de los datos usados para la construcción de cohetes.
 El tiempo empleado en la elaboración y diseño de cohetes usando software de
simulación existente en el mercado, inadecuados a la realidad geográfica depende
de los resultados obtenidos con este, provocando que aumente la pérdida de
tiempo de forma proporcional al número de imperfecciones detectadas en un
diseño, la seriedad de estas y el número de pruebas a realizar hasta que se
verifique que se arreglaron todos los problemas.
 El software existente no toma en cuenta las diferencias de ciertas variables
presentes en Bolivia comparadas a las de su país de origen (Altura Sobre el Nivel
del Mar, etc.) provoca pérdida de tiempo en la recolección de datos técnicos que
sirvan para ubicar y corregir imperfecciones en los prototipos.
1.3.1.2. Identificación de las causas
 Los resultados devueltos por los simuladores, según las entrevistas al programa
aeroespacial, son inconsistentes.
 El tiempo empleado en la elaboración y diseño de cohetes usando software de
simulación existente en el mercado, inadecuados a la realidad geográfica.
 El software existente no toma en cuenta las diferencias de ciertas variables
presentes en Bolivia comparadas a las de su país de origen (Altura Sobre el Nivel
del Mar, etc.).
10 - 236
Formulación del Problema
El proceso de simulación de propulsión de cohetes de combustible sólido realizado por

el programa aeroespacial mediante software de procedencia internacional, basado en
condiciones ambientales de sus países de origen y desarrollado por entidades
interesadas en el campo de los cohetes a modelo, provoca inconsistencia en la
apreciación y aproximación de los datos usados para la construcción de cohetes, cosa
que a su vez crea una pérdida de tiempo en la recolección de datos técnicos que sirvan
para ubicar y corregir imperfecciones en los prototipos.
Análisis Causa-Efecto
1.3.3.1. Causa
El proceso de simulación de propulsión de cohetes de combustible sólido realizado por

el programa aeroespacial mediante software de procedencia internacional, basado en
condiciones ambientales de sus países de origen y desarrollado por entidades
interesadas en el campo de los cohetes a modelo.
1.3.3.2. Efecto
 Inconsistencia en la apreciación y aproximación de los datos usados para la

construcción de cohetes.
 Pérdida de tiempo en la recolección de datos técnicos que sirvan para ubicar y
corregir imperfecciones en los prototipos.
OBJETIVOS Y ACCIONES
Objetivo General
Desarrollar un simulador de un sistema de propulsión de cohetes de combustible sólido

y verificación del rendimiento de la cámara de combustión, para obtener resultados más
claros y fáciles de procesar, colaborando al desarrollo de prototipos más eficientes.
11 - 236
Objetivos Específicos y Acciones
 Analizar el proceso actual de desarrollo de nuevos prototipos de cohetes.

 Formular los modelos de simulación para representar la implementación de los
diseños de los cohetes.
 Implementar los modelos de los cohetes basándose en la información recopilada.
 Experimentar con el modelo de simulación y realizar la interpretación de los
resultados obtenidos.
Tabla 1: Objetivos Específicos y Acciones
Objetivos Específicos Acciones
Analizar el proceso actual de desarrollo de  Recopilar y analizar información del

nuevos prototipos de cohetes. proceso actual de desarrollo de
prototipos en base a entrevistas a
miembros del programa aeroespacial.
 Analizar y seleccionar cuales fueron
las más grandes falencias del software
de simulación usado hasta ahora.
 Analizar cuáles son las capacidades y
limitaciones de un motor de
combustible sólido.
 Investigar sobre las piezas de fuselaje
que se pueden usar en un cohete y
como estas podrían afectar su
rendimiento.
 Analizar cuáles son los efectos que
tendrían las condiciones atmosféricas
12 - 236
comunes del país en el vuelo de los

cohetes.
 Recopilar información de cuáles son
los requerimientos y estimaciones que
se esperan lograr con el sistema a
desarrollar.
Formular los modelos de simulación para  Seleccionar las características que se

representar la implementación de los utilizaran como variables para la
diseños de los cohetes. elaboración de un modelo.
 Entrevistar a miembros del programa
aeroespacial y recopilar información
sobre los tipos de combustible sólido a
usarse.
 Recolectar información sobre el diseño
y funcionamiento de un motor a
 Recolectar información sobre las
condiciones ambientales que afecten
al cohete.
 Recolectar información sobre las
diferentes piezas de fuselaje que
puedan usarse en el cohete y como se
relacionan con los flujos de aire a su
alrededor.
13 - 236
 Modelar las características de un

motor de combustible sólido usando la
información previa.
 Modelar las características de las
piezas de fuselaje que puedan usarse
en el cohete con los datos previos.
 Modelar las características del
ambiente, considerando flujos de aire
y otros factores que afecten al cohete.
Implementar los modelos de los cohetes  Seleccionar la metodología de

basándose en la información recopilada. desarrollo de software más apropiada
para el proyecto.
 Seleccionar las tecnologías de
desarrollo para la implementación,
incluyendo el lenguaje de
programación a usar, tomando en
cuenta que el sistema debe ser
multiplataforma.
 Diseñar y codificar la interfaz de salida
y entrada de datos.
 Codificar el módulo del motor de
 Codificar el módulo de las condiciones
del ambiente.
 Codificar el módulo de las piezas de
fuselaje.
14 - 236
 Codificar las funciones y

procedimientos que serán usados por
un agente inteligente para la
simulación.
 Realizar validación del modelo
mediante la predicción de datos
históricos y la opinión de los miembros
más relevantes del programa sobre el
desarrollo de cohetes.
Experimentar con el modelo de  Seleccionar distintos casos de prueba

simulación y realizar la interpretación de para realizar el ensayo del simulador,
los resultados obtenidos. a partir de datos históricos.
 Realizar el ensayo de las distintas
situaciones de casos de prueba
establecidos previamente.
 Documentar el modo que funciona el
simulador para que pueda ser usado
por otros usuarios, tanto de modo
simple como técnico.
15 - 236
JUSTIFICACIÓN
Justificación Técnica
En el aspecto técnico, el simulador de cohetes a combustible sólido hará posible el

recrear los diversos tipos de prototipos de cohetes así como las condiciones a las que
puedan afectar el rendimiento del diseño, utilizando modelos de simulación elaborados
poniendo el cuidado necesario a la precisión y cercanía a la realidad de los resultados
que genere al poner a prueba el diseño y los elementos empleados en el cohete.
Justificación Económica
El simulador permitirá reducir la cantidad de dinero invertido en crear unidades físicas de

prototipos fallidos al predecir qué tan efectivo es el diseño en el mundo real, detectando
fallas potenciales e imperfecciones.
Justificación Operativa
Una vez sea terminado, el simulador de cohetes permitirá que los usuarios sean capaces
de utilizarlo como herramienta para el desarrollo y perfeccionamiento de diseños de
nuevos prototipos de cohetes, particularmente de cohetes misiles, tomando el cuidado
necesario al diseño del motor, el fuselaje, combustible empleado entre otros factores que
puedan afectar al rendimiento de la cámara de combustión y por extensión, al tiempo de
vuelo, velocidad máxima, temperatura máxima y otras capacidades que pueda cumplir
el cohete.
ALCANCE
Alcance Temático
El simulador estará implementando el área de sistemas de simulación, Ingeniería de

Software, Análisis y Diseño de sistemas, técnicas de recopilación de información,
Tecnologías de Desarrollo.
16 - 236
Alcance Temporal
El simulador de sistema de propulsión de cohetes será desarrollado en la gestión 2017,

y se tiene una proyección de vida útil de unos cinco años hasta que se solicite una
actualización al sistema.
Alcance institucional
Con el desarrollo del simulador se espera lograr que los miembros del programa
aeroespacial sean capaces de desarrollar mejores diseños de cohetes con el menor
tiempo posible y facilidad de obtener los datos que necesiten.
Alcance Funcional
Con el simulador de cohetes de combustible sólido, elaborado con apoyo del programa
aeroespacial mediante pruebas de prototipos reales y entrevistas a miembros del
programa, se espera lograr que se pueda desarrollar diseños de cohetes perfeccionados,
poniendo a prueba todos los puntos que sean de interés para los desarrolladores
responsables, haciendo uso de un agente inteligente para el manejo de los modelos y
con soporte para el diseño de nuevos prototipos desde las primeras fases hasta el
momento de construir una unidad física, momento para el cual se debería tener un buen
nivel de certeza de las capacidades del cohete.
HIPÓTESIS
El simulador de un sistema de propulsión de cohetes de combustible sólido y verificación

del rendimiento de la cámara de combustión permitirá realizar un análisis estadístico de
comparación de datos técnicos del cohete y reducir la cantidad de tiempo empleado en
la producción de prototipos perfeccionados.
17 - 236
Análisis de Variables
1.7.1.1. Variable Independiente
 El simulador de sistema de propulsión de cohetes a combustible sólido para

verificar el rendimiento de la cámara de combustión.
1.7.1.2. Variable Dependiente
Para poder proseguir se toman en cuenta las siguientes variables:
 Análisis estadístico de comparación de datos técnicos, usando desviación

estándar para comparar temperatura de cámara y velocidad característica.
 Cantidad de tiempo empleado para la producción de prototipos perfeccionados.
Definición Conceptual
1.7.2.1. Variable Independiente
 El simulador de sistema de propulsión de cohetes a combustible sólido para

verificar el rendimiento de la cámara de combustión: Sistema de simulación de
propulsión de cohetes de combustible sólido para el desarrollo de mejores
prototipos de dispositivos aeroespaciales.
1.7.2.2. Variable Dependiente
 Análisis estadístico de comparación de datos técnicos del cohete: Comparación

de datos técnicos entre los resultados obtenidos con pruebas pasadas realizadas
por el programa y los que serán obtenidos por la implementación del programa.
 Cantidad de tiempo empleado para la producción de prototipos perfeccionados:
Es el tiempo usado para corregir los errores e imperfecciones encontradas en el
diseño de los prototipos de cohetes y crear versiones más eficientes.
18 - 236
Operativización de Variables
Tabla 2: Operativización de Variables
Variable Dimensión Indicador

Variable Independiente
El simulador de sistema Sistema de simulación Comparación de

de propulsión de desarrollado y beneficios de la
cohetes a combustible verificado. implementación
sólido para verificar el sistema y sin la
rendimiento de la implementación del
cámara de combustión mismo.
Análisis estadístico de Proceso de Pruebas estadísticas de

comparación de los construcción y f de Fisher empleando
datos técnicos del lanzamiento del cohete. para comparar la
cohete. temperatura de cámara,
Variables Dependientes
impulsos específicos y
vacíos.
Cantidad de tiempo Verificación de errores Tiempo empleado para

empleado para la en producción del la producción de
producción de prototipo. prototipos
prototipos (semanas/dias).
perfeccionados.
19 - 236
MATRIZ DE CONSISTENCIA
Figura 5: Matriz de Consistencia.
Fuente: Elaboración propia, 2017.
20 - 236
2. MARCO TEÓRICO
TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN
Como primer paso para el desarrollo de cualquier proyecto, se necesita recopilar y

analizar la información que sea requerida para poder cumplir con los objetivos
establecidos. Esto quiere decir que es necesario saber todo lo posible sobre la necesidad
que se alimentara al haber completado el proyecto. Esta tarea involucra el realizar un
proceso formal de recopilación de datos, de forma que los datos recogidos se encuentren
con un nivel adecuado de definición y precisión. Es en base a esta información que se
basaran las decisiones posteriores para el desarrollo del proyecto. Existen diferentes
tipos de técnicas para recopilación de información, cada uno con sus capacidades y
limitaciones propias (Universidad de Minesota, 2016):
 Entrevistas
 Cuestionarios y encuestas
 Observaciones
 Grupos de enfoque
 Etnografías, Historia Oral y Casos de Estudio
 Documentos y registros
De entre estos, los métodos más conocidos, en los que el investigador debe recopilar
información mediante contacto con el objeto de interés, son las Entrevistas,
Cuestionarios y Observaciones.
Entrevistas
La entrevista es una técnica que sirve para recabar información en forma verbal. Se
puede usar para obtener información acerca de las necesidades de los usuarios y la
manera de satisfacerlas. Las entrevistas pueden llevarse a cabo a través de medios de
comunicación, como por teléfono o en persona. Una entrevista está compuesta por
preguntas, que usualmente buscan producir un estímulo en la mente del interrogado para
que se pueda conseguir una respuesta o un conjunto de respuestas que proporcionen
21 - 236
información lo más cercana posible a la realidad. Hacer preguntas y obtener respuestas
es una tarea mucho más difícil de lo que pudiese parecer al principio. La palabra escrita
o hablada siempre tiene un residuo de ambigüedad, sin importar que tan cuidadosamente
se elaboren las preguntas o las respuestas. A pesar de esto, la entrevista es uno de los
medios más comunes y más poderosos por los cuales se trata de entender a otros
humanos. (Fontana y Prokos, 2016, p. 9).
Existen dos tipos grandes de entrevistas que se puedan distinguir: las entrevistas
estructuradas y las no estructuradas (Entrevista de Trabajo.Org, 2017).
 Entrevista Estructurada: En este tipo, el investigador elabora previamente las

preguntas que se vayan a realizar a los entrevistados. Se suelen realizar de forma
que se puedan repetir en el mismo orden y con las mismas palabras a cada persona
que se desee entrevistar. Cabe destacar que una vez se hayan establecido las
preguntas no es recomendable realizar otras nuevas durante la entrevista que no
aporten a aclarar el tema junto con las demás preguntas establecidas previamente.
 Entrevista No Estructurada: En una entrevista no estructurada, el investigador no
predetermina cuáles serán las preguntas que serán realizadas durante la entrevista.
Esto se hace para garantizar la espontaneidad de las respuestas de los entrevistados,
pero puede afectar la calidad de la información recolectada. Estas preguntas se
formulan durante la ejecución de la entrevista, razón por la que puede que no se
realicen las mismas preguntas a todas las personas entrevistadas o que sus
respuestas contengan los datos que requiere la investigación para el proyecto.
Análisis de documentos
El análisis de documentos es una técnica de recopilación de información en la que los

documentos son interpretados por el investigador para dar voz y significado en torno a
un tema de evaluación. Como su nombre lo indica, esta técnica analiza comúnmente
documentos existentes que a menudo que están disponibles al público, aunque también
se puede usar documentos privados dependiendo de la naturaleza de la información que
se necesite recolectar.
22 - 236
Consiste en examinar los datos existentes en forma de bases de datos, actas de
reuniones, informes, registros de asistencia, registros financieros y boletines informativos
entre otros. Esta puede ser una forma barata de recopilar información, pero puede ser
una fuente de datos incompleta. (Universidad de Minesota, 2016)
Es casi siempre la primera técnica que una persona aprende a usar, debido a que durante
el tiempo que uno pasa en el colegio, tiene que emplear libros textos para avanzar las
clases. Es un método popular debido a que permite al investigador obtener información
en las palabras propias del participante y puede accederse en cualquier momento se lo
necesite. Cabe mencionar también, que los documentos con los que trabaja esta técnica
pueden estar desactualizados o de carácter restringido al público.
INGENIERÍA DE SOFTWARE
El uso de los diferentes medios y herramientas ofrecidas por la tecnología moderna,

particularmente del software, se ha incrustado profundamente en casi todos los aspectos
de nuestra vida cotidiana y, como consecuencia, el número de personas que comparten
interés en el funcionamiento interno de una aplicación de software ha crecido en forma
notable. Con el creciente interés e importancia del software, la rama de la ingeniería que
se encarga del desarrollo del mismo ha crecido para cubrir las implementaciones que la
sociedad le da al software en la vida real. La profesión de ingeniería de software incluye
todos los aspectos de concebimiento, comunicación, especificación, diseño elaboración,
testeo y mantenimiento de sistemas de software. Las actividades que incluyen todo lo
que tenga que ver con la producción de los elementos relacionados con ingeniería de
software como documentación y herramientas respectivas. (Laplante, 2007, p. 2).
La ingeniería de software es el establecimiento y uso de principios fundamentales de con

objeto de desarrollar en forma económica software que sea confiable y que trabaje con
eficiencia en máquinas reales. Cuando se necesita crear una aplicación o sistema nuevo,
se tiene muchas opiniones acerca de como alcanzar el objetivo que buscan. En más de
una ocasión, de entre las diferentes opiniones se puede presentar una idea relativamente
distinta acerca de que características y funciones debiera tener el software, que
23 - 236
potencialmente pueda beneficiar el producto final. Esta más que claro que para poder
dar buenas sugerencias se deben hacer esfuerzos para entender el problema o
necesidad que se busca satisfacer antes de desarrollar una aplicación de software. Los
requerimientos de la tecnología que demandan los individuos, negocios y gobiernos se
hacen más complejos con cada año que pasa. En la actualidad, grandes equipos de
personas son formados para crear programas que antes eran elaborados por grupos más
pequeños o por un solo individuo. La complejidad de los nuevos sistemas y productos
basados en computadora actuales demandan mayor atención a las interacciones de
todos los elementos y componentes del sistema, razón por la cual los ingenieros de
software deben constantemente buscar cuál de las opciones es más eficaz para el
proyecto en el que trabajen. El producto final de este proceso es el conjunto de
programas, información y otros productos terminados que consiguen utilizando software
de computadora. (IEE, 1991, p. 32).
Modelos de desarrollo ágil
Según (Collier, 2011, p. 121):
El desarrollo de software ágil describe un conjunto de principios para el desarrollo

de software bajo el cual los requisitos y las soluciones evolucionan a través del
esfuerzo colaborativo de equipos que se organizan a sí mismos y trabajan entre
ellos.
El desarrollo de software, como se mencionó anteriormente, ha pasado a requerir cada

vez grupos más grandes de desarrolladores que trabajen en la elaboración de un
programa. Las metodologías ágiles, buscan el facilitar el trabajo entre los miembros de
estos equipos y por extensión, la calidad del producto final. (Aha! Labs Inc., 2017).
2.2.1.1. Programación Extrema (XP)
La programación extrema (XP) es un modelo de desarrollo de software que busca

mejorar la calidad del software y la capacidad de respuesta a las necesidades
cambiantes de los clientes. Toma su nombre de la idea de que los elementos
24 - 236
beneficiosos de las prácticas tradicionales de ingeniería de software se llevan a niveles
"extremos". Como ejemplo, las revisiones de código se consideran una práctica
beneficiosa; llevado al extremo, el código se puede repasar continuamente sin límite de
tiempo para encontrar defectos que serían más difíciles de encontrar si se realiza una
menor cantidad de pruebas. La Programación Extrema enfatiza el trabajo en equipo. Los
gerentes, clientes y desarrolladores son socios iguales en un equipo de colaboración.
(Wells, 2017).
XP es una disciplina de desarrollo de software. Es una disciplina porque hay ciertas cosas
que tienes que hacer para poder implementar XP. No se puede elegir si va a realizar
pruebas o no, si no se las realiza, no se está llegando al extremo. XP está diseñado para
trabajar con proyectos que pueden ser elaborados por equipos de dos a diez
programadores, que no están fuertemente limitados por el entorno informático existente,
y donde un trabajo razonable como ejecutar pruebas se puede hacer en una fracción de
día. XP asusta o frustra a algunas personas que lo encuentran por primera vez. Sin
embargo, ninguna de las ideas de XP son nuevas. La mayoría son tan viejas como la
programación misma. Hay un sentido en el que XP es conservador, todas sus técnicas
han sido probadas durante décadas o siglos. (Beck y Andres, 2004, p. XVII).
a) Ciclo de Vida
XP describe cuatro fases dentro del proceso de desarrollo de software: codificación,

pruebas, escucha y diseño (TutorialsPoint, 2017):
 Planeación: Es toda actividad para recabar información para entender los

requerimientos que se tienen para el proyecto.
 Diseño: El diseño se refiere a la implementación de una historia de usuario, o
requerimiento del sistema dentro del diseño mismo del sistema. Se desalienta el
diseño de funcionalidad adicional porque el desarrollador supone que se requerirá
realizar modificaciones después.
 Codificación: Como su nombre lo indica, aquí se busca realizar la codificación
necesaria para el proyecto y cada una de las funciones requeridas.
25 - 236
 Prueba o Testeo: Una vez terminado el programa se pasa a realizar pruebas para
validar si este satisface los requerimientos que fueron establecidos.
 Escucha: La base de la programación extrema es un mecanismo continuo de
participación del cliente a través de comentarios y reseñas durante la fase de
desarrollo. Aparte del cliente, también se recibe retroalimentación del encargado del
proyecto.
b) Ventajas y Desventajas
Tabla 3: Ventajas y desventajas de Programación Extrema
Ventajas Desventajas
 Se centra en el código en lugar de en el

 Permite a las empresas de desarrollo
diseño.
de software ahorrar costos y tiempo
 La documentación de defectos no
necesario para la realización del
siempre es buena.
proyecto.
 No mide el aseguramiento de la calidad
 Se centra en la entrega de productos
del código. Puede causar defectos en el
finales.
código inicial.
 No emplea mucha documentación.
 Emplea un código sencillo de entender
que se puede mejorar en cualquier
momento.
Fuente: (Pierce, 2016)
2.2.1.2. Scrum
Scrum es un framework ágil de gestión de proyectos cuyo objetivo primordial es elevar

al máximo la productividad de un equipo y obtener el mejor resultado posible de un
proyecto. Un principio clave de Scrum es el reconocimiento de que durante el desarrollo
26 - 236
del producto, los clientes pueden cambiar su opinión sobre lo que quieren y necesitan, y
que impredecibles desafíos no pueden ser fácilmente abordados de una manera
tradicional predictiva o planificada. Como tal, Scrum adopta un enfoque empírico basado
en la evidencia, aceptando que el problema no puede ser totalmente comprendido o
definido, centrándose en cambio en maximizar la capacidad del equipo para entregar
rápidamente, responder a las necesidades emergentes y adaptarse a las tecnologías en
evolución y cambios en las condiciones del mercado. Los principios Scrum son
congruentes con el manifiesto ágil y se utilizan para guiar actividades de desarrollo dentro
de un proceso de análisis que incorpora las siguientes actividades estructurales:
requerimientos, análisis, diseño, evolución y entrega. Dentro de cada actividad
estructural, las tareas del trabajo ocurren con un patrón del proceso (que se estudia en
el párrafo siguiente) llamado sprint. El trabajo realizado dentro de un sprint (el número
de éstos que requiere cada actividad estructural variará en función de la complejidad y
tamaño del producto) se adapta al problema en cuestión y se define, y con frecuencia se
modifica, en tiempo real por parte del equipo Scrum. (Pressman, 1997, p. 69).
a) Ciclo de Vida
El ciclo de vida contiene las siguientes fases (Gurendo, 2005):
 Crear Product Backlog.

 Planificación de Sprints y Creación del Sprint Backlog.
 Trabajar en los Sprints o Scrum Meetings.
 Pruebas y Demostración de Productos.
 Retrospectiva y Planificación del siguiente Sprint.
Estas fases para el desarrollo de un proyecto mediante metodología Scrum se pueden

describir de forma más detallada en los siguientes puntos:
 Crear Product Backlog: El Backlog del producto es una lista que consiste en
características que deben implementarse durante el proceso de desarrollo. Se ordena
por prioridad y cada elemento se llama una historia de usuario.
27 - 236
 Planificación de Sprints y Creación del Sprint Backlog: En primer lugar, se deben
determinar cuáles serán la duración de los sprint, es decir el tiempo entre entregas
del proyecto, esto se define mediante que tan frecuentemente se desee recibir
retroalimentación del cliente. Como regla, un sprint dura alrededor de 2 semanas. Lo
que es más importante en esta fase es la cooperación entre las partes interesadas y
los miembros del equipo, para decidir que tareas deben realizarse primero. El backlog
de Sprint debería crearse a continuación. Consiste en historias de usuarios que se
completarán durante el sprint actual. La cantidad de estas historias depende de su
duración en los puntos de historia asignados a cada historia durante la etapa de
evaluación. El equipo debe ser capaz de terminar todas estas historias a tiempo.
 Trabajar en los Sprints o Scrum Meetings: Una vez definidas que historias de usuario
se trabajaran, se empieza el proceso de desarrollo. El trabajo del sprint se mide
durante las reuniones cotidianas del equipo. El objetivo principal de estas reuniones
es obtener información el estado actual del proyecto. Durante estas reuniones, cada
miembro del equipo debe informar cada tarea terminada.
 Pruebas y Demostración de Productos: Dado que el resultado ideal de cada sprint es
un producto de trabajo, el proceso completo de pruebas de ciclo de vida es muy
importante. El resultado de cada sprint es la demostración del producto. El equipo de
Scrum crea una reseña y demuestra los resultados de su trabajo. Sobre esta base,
las partes interesadas toman una decisión sobre nuevos cambios en el proyecto.
 Retrospectiva y Planificación del siguiente Sprint: El objetivo principal de la
retrospectiva es discutir los resultados y determinar cómo mejorar el proceso de
desarrollo en el próximo paso. El equipo debe concluir lo que salió bien durante el
proceso de trabajo y lo que se puede hacer mejor durante la futura iteración. Cuando
se definen las maneras de mejorar, el equipo puede concentrarse en la siguiente
planificación de sprint.
28 - 236
Tabla 4: Ventajas y desventajas de Scrum.
 Scrum a menudo carece de una fecha

 Scrum asegura un uso efectivo de
de finalización definitiva para el
tiempo y dinero.
proyecto, haciendo difícil estimar
 Los grandes proyectos se dividen en
cuando se finalizara el desarrollo.
Sprints fácilmente manejables.
 Las posibilidades de fracaso del
 Los avances del desarrollo son
proyecto son altas si los miembros del
codificados y probados durante la
equipo no están comprometidas al
revisión sprint.
trabajo o no son cooperativas.
 El equipo tiene una impresión más
 La implementación de Scrum en
clara del avance a través de reuniones
equipos grandes es una tarea
los Scrum Meetings.
complicada.
 Scrum, siendo ágil, toma en cuenta la
 Las reuniones diarias a veces frustran
retroalimentación de clientes y otras
a los miembros del equipo.
entidades interesadas.
 Si algún miembro del equipo deja el
 Los Sprints cortos permiten cambios
proyecto a mitad de desarrollo de un
basados en la retroalimentación
proyecto, puede tener un enorme
mucho más fácilmente.
impacto negativo.
 El esfuerzo individual de cada
 La calidad es difícil de verificar, hasta
miembro del equipo es visible durante
que el equipo pueda realizar pruebas
las reuniones diarias.
exhaustivas.
Fuente: (Chandana, 2013)
29 - 236
2.2.1.3. Desarrollo rápido de aplicaciones(RAD)
El Desarrollo rápido de aplicaciones es un modelo de desarrollo de software que resta

importancia a la planificación a favor del enfocarse en desarrollar prototipos a un ritmo
rápido. En general, los enfoques RAD para el desarrollo de software ponen menos
énfasis en la planificación y más énfasis en el proceso.
En contraste con metodologías como el modelo de cascada, que requiere que se

establezcan especificaciones rigurosamente definidas antes de entrar en la fase de
desarrollo, los enfoques RAD enfatizan la adaptabilidad y la necesidad de ajustar los
requisitos en respuesta a la información adquirida a medida que se avanza el proyecto.
Para algunas personas, el desarrollo rápido consiste en la aplicación de una sola
herramienta o método. Para el hacker, el rápido desarrollo es la codificación de 36 horas
en un tramo. Para el ingeniero de información, es RAD, una combinación de
herramientas CASE, participación intensiva del usuario, y timeboxes apretados.
(McConnell, 1996, p. 2).
a) Ciclo de Vida
El enfoque de James Martin para RAD divide el proceso en cuatro fases distintas
(Software Testing, 2014):
 Fase de planificación de necesidades: Los usuarios, los gerentes y los miembros del
personal discuten y acuerdan las necesidades del negocio, el alcance del proyecto,
las restricciones y los requisitos del sistema. Finaliza cuando el equipo está de
acuerdo en las cuestiones clave y obtiene la autorización de la administración para
continuar.
 Fase de diseño del usuario: Durante esta fase, los usuarios interactúan con los
analistas de sistemas contribuyen desarrollan modelos y prototipos que representan
todos los procesos del sistema, entradas y salidas.
 Fase de construcción: Se centra en la tarea de desarrollo de programas y
aplicaciones. En RAD, los usuarios pueden sugerir cambios. Las tareas de esta fase
30 - 236
son la programación y desarrollo de aplicaciones, codificación, integración de
unidades y pruebas del sistema.
 Fase de corte: En comparación con los métodos tradicionales, todo el proceso,
aunque similar a otros procesos de implementación incluyendo la conversión de
datos, pruebas, cambio al nuevo sistema, y la instrucción del usuario, se comprime.
Como resultado, el nuevo sistema se desarrolla, se entrega y se pone en
funcionamiento en menos tiempo.
Tabla 5: Ventajas y desventajas de RAD.
 Este método puede no ser útil para

 El tiempo requerido para desarrollar el
proyectos grandes, únicos o muy
software se reduce drásticamente
complejos
debido a la reducción de tiempo de
 Este método no puede tener éxito si el
análisis de requerimientos y
equipo no está suficientemente
planificación del proyecto.
motivado o si es incapaz de trabajar
 Todos los prototipos de software
cohesivamente juntos.
producidos pueden guardarse en un
 El éxito depende de las habilidades
repositorio para uso futuro. La
técnicas de los desarrolladores.
reutilización de los componentes
 Hay momentos en los que el equipo
también aumenta la rapidez del
ignora los parámetros de calidad
proceso de desarrollo de software.
necesarios para elaborar la mayor
 Es mucho más fácil para un gerente de
cantidad de prototipos.
proyecto ser preciso en la estimación
de los costos del proyecto.
 Si un componente se almacena en el
repositorio, ya está probado y, por lo
31 - 236
tanto, no necesita ser probado de

nuevo.
 Los requisitos de gestión de proyectos
se recogen de manera dinámica. Cada
vez que hay un prototipo listo, los
requisitos son estudiados y
emparejados.
 Existe una fuerte y continua
participación del patrocinador del
proyecto que sigue dando
retroalimentación en todo el proceso.
 Promueve una mejor documentación a
través de casos de prueba escritos.
Fuente: (Sousa, 2009)
Pruebas de Software
Las pruebas de software son una investigación llevada a cabo para proporcionar a los
interesados información sobre la calidad del producto o servicio de un software sometido
a prueba, para examinar que fallas se puedan presentar. Estas también pueden
proporcionar una visión objetiva e independiente del software para permitir al negocio
apreciar y comprender los riesgos de la implementación del software. A fin de cuentas,
se elabora una prueba con intención de encontrar errores de software y verificar que el
producto de software es apto para el uso. Las pruebas de software implican la ejecución
de un componente de software o componente del sistema para evaluar una o más
propiedades de interés. En general, estas propiedades indican hasta qué punto el
componente o sistema bajo prueba debe cumplir los requisitos establecidos durante su
diseño y desarrollo, responde correctamente a los datos de entrada que se le otorguen,
tiene un tiempo aceptable para la realización de sus funciones, es suficientemente
32 - 236
utilizable, puede instalarse y ejecutarse en los entornos previstos y cumple con el
resultado general que era esperado. Como la cantidad de pruebas posibles para
componentes de software simples incluso es prácticamente infinita, todas las pruebas de
software utilizan alguna estrategia para seleccionar pruebas que son viables para el
tiempo y los recursos disponibles. (Tilley & Floss, 2014, p. 1).
2.2.2.1. Tipos de Prueba
Existen los siguientes tipos o niveles de prueba (TutorialsPoint, 2017):
 Pruebas de Unidad: Las pruebas unitarias se refieren a pruebas que verifican la

funcionalidad de una sección específica de código, normalmente a nivel de
función. En un entorno orientado a objetos, esto suele ser a nivel de clase, y las
pruebas unitarias mínimas incluyen los constructores y los destructores.
 Pruebas de Integración: Las pruebas de integración son cualquier tipo de pruebas de
software que buscan verificar las interfaces entre componentes contra un diseño de
software. Los componentes de software pueden integrarse de forma iterativa o en
conjunto. Normalmente, el primero se considera una mejor práctica ya que permite
que los problemas de interfaz se ubiquen más rápidamente y de forma más fija.
 Prueba de interfaz de componentes: La práctica de la prueba de interfaz de
componentes puede utilizarse para comprobar el manejo de datos pasados entre
varias unidades o componentes del subsistema, más allá de las pruebas de
integración completa entre esas unidades.
 Prueba del sistema: Las pruebas del sistema prueban un sistema completamente
integrado para verificar que el sistema cumple con sus requisitos.
 Prueba de aceptación operacional: Es un tipo común de pruebas de software no
funcionales, utilizadas principalmente en proyectos de desarrollo de software y
mantenimiento de software. Este tipo de pruebas se centra en la disponibilidad
operativa del sistema para ser apoyado y/o convertirse en parte del entorno de
producción.
33 - 236
SIMULACIÓN DE SISTEMAS
(Banks, Carson, Nelson, y Nicol, 2010, p. 3) Sostiene que:
Una simulación es una representación de un objeto que existe en la vida real, en

otras palabras, es la imitación de la operación de un proceso o sistema del mundo
real.
Una simulación suele depender de modelos para realizar las operaciones necesarias. Un
modelo de simulación es un modelo matemático que calcula el impacto de las decisiones
que tomadas en base a los resultados, como ganancias y pérdidas, retornos de inversión,
consecuencias ambientales y similares, dependiendo de que sistema se desea simular.
Una simulación por computadora, es una simulación que se ejecuta en una o más
computadoras, estas varían desde programas de computadora que se ejecutan casi
instantáneamente en dispositivos pequeños, a grupos de equipos basados en red que
funcionan durante horas hasta simulaciones en curso que se ejecutan durante días. La
escala de eventos simulados por simulaciones por ordenador ha superado con creces
todo lo posible utilizando el modelo matemático tradicional de papel y lápiz. La simulación
por computadora se desarrolló al mismo ritmo que el crecimiento de la computadora,
después de su primer despliegue a gran escala durante el Proyecto Manhattan en la
Segunda Guerra Mundial para modelar el proceso de detonación nuclear. Hay muchos
tipos de simulaciones por computadora; El rasgo común de los simuladores es el intento
de generar una muestra de escenarios representativos para un modelo en el que una
enumeración completa de todos los estados posibles del modelo sería prohibitiva o
imposible, porque estas permiten realizar todo tipo de procesos, bajo condiciones que
serían difíciles, sino imposibles, de recrear en un entorno físico. (Encyclopedia
Britannica, 2017).
Etapas para elaboración de un simulador
La simulación de sistemas se puede realizar mediante un proceso que involucra ocho

diferentes etapas (Bu, 1993, pp. 5,6,7):
34 - 236
 Definición del sistema: Se necesita definir y analizar el sistema, es necesario hacer
primeramente un análisis sobre la situación u objeto que se desee simular.
 Formulación del modelo: En la formulación, como lo indica su nombre, consiste en
establecer como se elaboraran todos los modelos, para lo cual es necesario definir
todas las variables que irán a formar parte del mismo.
 Colección de Datos: Para ejecutar una simulación, se necesita información específica
para el funcionamiento adecuado del modelo, y por extensión, en el rendimiento del
simulador.
 Implementación del modelo: Con el modelo definido, se pasa a elaborar el sistema
en computadora, implementando las tecnologías que ofrezcan más beneficios.
 Validación: Se procede a validar los resultados que devuelvan los modelos, para que
se verifique con certeza que está retornando los datos necesarios
 Experimentación: Se realizan distintas pruebas, donde se establece que datos se
desea adquirir y se realizan estas operaciones con los modelos.
 Interpretación: Se interpretan los distintos datos que arroja el simulador y se plantea
si se pueden tomar decisiones en base a estos.
 Documentación: Se realiza la documentación necesaria, una de tipo técnico y otra de
manejo cotidiano para usuarios comunes.
2.3.1.1. Herramientas de modelación
El modelado de simulación es el proceso de crear y analizar un prototipo digital de un

modelo físico para predecir su rendimiento en el mundo real. El modelado es usado para
ayudar a diseñadores e ingenieros a comprender si, en qué condiciones y de qué manera
una pieza podría fallar y qué carga puede soportar. (Frontline Systems Inc, 2017).
El modelo del sistema bajo estudio es una abstracción, cosa que significa que solo
representa características y funciones seleccionadas mientras que usualmente no
considera conjuntos más amplios de los mismos. (Wehrle, Günes, y Gross, 2010, p. 6).
El modelado de simulación permite evitar la construcción repetida de múltiples prototipos

físicos para analizar diseños de piezas nuevas o existentes. Antes de crear el prototipo
35 - 236
físico, los usuarios pueden investigar virtualmente muchos prototipos digitales, mediante
lo cual pueden (AnyLogic, 2017):
 Optimizar la geometría para el peso y la fuerza

 Seleccione materiales que cumplan con los requisitos de peso, resistencia y
presupuesto necesarios.
 Simular el fallo de las piezas e identificar las condiciones que las causan
 Evaluar las condiciones ambientales extremas o las cargas que no puedan ser
probadas fácilmente en medios físicos.
 Verificar cálculos manuales
 Validar la probable seguridad y supervivencia de un prototipo físico
Para el modelado de forma apropiada de un proceso de simulación se puede hacer uso

de herramientas como el Modelo Entidad-Relación y el Diagrama UML.
a) Diagrama UML de Clases
El lenguaje de modelado unificado (UML) es un lenguaje de propósito general, de

desarrollo y de modelado en el campo de la ingeniería de software, que pretende
proporcionar una forma estándar de visualizar el diseño de un sistema.
El lenguaje de modelado unificado es sólo un idioma. No es una forma de diseñar un

sistema, pero es una forma de modelar un sistema. Para utilizar UML, debe aplicar un
método a él. Hay una serie de métodos que han sido diseñados, pero el más popular, y
probablemente el primero en tratar con UML, es Rational Unified Process (RUP), también
llamado Proceso Unificado. (Roff, 2003, p. 5).
 Diagrama UML de Secuencias
El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre

objetos en un sistema según UML. Dentro de esta se muestra las interacciones de los
objetos dispuestas en secuencia temporal. Representa los objetos y las clases
involucradas en el escenario y la secuencia de mensajes intercambiados entre los
36 - 236
objetos necesarios para llevar a cabo la funcionalidad del escenario. Un diagrama de
secuencia muestra, como líneas verticales paralelas (líneas de vida), diferentes procesos
u objetos que viven simultáneamente y, como flechas horizontales, los mensajes
intercambiados entre ellos, en el orden en que ocurren. (UML-Diagrams.Org, 2017).
En la figura 5, se muestra el ejemplo de un diagrama de secuencias de emisión de

pedidos de un restaurante. Donde el cliente llega al establecimiento con hambre, y hace
un pedido al cajero o encargado del menú. El pedido debe incluir todos los platos que el
cliente desee incluir del menú. Con cada nuevo plato del pedido, el encargado debe
comprobar la disponibilidad del mismo. Si se encuentra que el plato aun esta disponible,
se lo agrega a la lista del pedido, en caso de que no esté disponible el plato, simplemente
se lo excluye de la lista. Una vez que se complete el pedido, se debe calcular el monto a
cobrar y el que es notificado al cliente. El pago del pedido debe ser realizado en su
enteridad antes de que el pedido sea almacenado en la cola de espera.
Figura 6: Ejemplo de Diagrama de Secuencias.
Fuente: (Microsoft, 2017).
37 - 236
En el diagrama de la figura 5, toda este ejemplo se fabricó empleando una amplia gama
de elementos para cada una de las secuencias necesarias para este ejemplo, en la tabla
inferior se explican cada uno de los elementos de los diagramas de secuencia, así como
los roles o funciones que estos cumplen.
Tabla 6: Elementos de Diagrama de Secuencias.
FORMA ELEMENTO DESCRIPCIÓN
1 Lifeline Línea vertical que representa la secuencia de eventos que

se producen en un participante durante una interacción,
mientras el tiempo avanza por la línea. Este participante
puede ser una instancia de una clase, un componente o
un actor.
2 Actor Participante externo al sistema que está desarrollando.

Para que aparezca un símbolo de actor al principio de una
línea de vida, establezca la propiedad Actor.
3 Mensaje El remitente espera una respuesta a un mensaje

sincrónico sincrónico antes de continuar. El diagrama muestra la
llamada y la devolución. Los mensajes sincrónicos se usan
para representar llamadas de función ordinarias dentro de
un programa, así como otros tipos de mensaje que se
comportan de la misma manera.
4 Mensaje Mensaje que no requiere una respuesta para que el

asincrónico remitente continúe. Un mensaje asincrónico muestra solo
una llamada del remitente. Se usa para representar la
38 - 236
comunicación entre subprocesos diferentes o la creación

de un nuevo subproceso.
5 Ocurrencia de Rectángulo sombreado vertical que aparece en la línea de

ejecución vida de un participante y representa el período en el que
el participante ejecuta una operación.
La ejecución empieza cuando el participante recibe un

mensaje. Si el mensaje de inicio es un mensaje sincrónico,
la ejecución finalizará con una flecha de retorno al
remitente.
6 Mensaje de Mensaje que se devuelve a un participante que espera la

devolución de devolución de una llamada anterior. La ocurrencia de
llamada ejecución resultante aparece encima de la que ya existe.
7 Mensaje propio Mensaje de un participante a sí mismo. La ocurrencia de

ejecución resultante aparece encima de la ejecución de
envío.
8 Mensaje de Mensaje que crea un participante. Si un participante recibe

creación un mensaje de creación, este debe ser el primero que
reciba.
9 Mensaje Mensaje asincrónico de un participante desconocido o no

encontrado especificado.
39 - 236
10 Mensaje Mensaje asincrónico a un participante desconocido o no

perdido especificado.
11 Comentario Se puede asociar un comentario a cualquier punto de una

línea de vida.
12 Interaction Use Contiene una secuencia de mensajes definidos en otro

diagrama.
Para crear un uso de interacción, haga clic en la

herramienta y, después, arrastre el mouse por las líneas
de vida que quiere incluir.
13 Fragmento Colección de fragmentos. Cada fragmento puede incluir

combinado uno o varios mensajes. Hay varios tipos de fragmentos
combinados. Para más información, vea Describir el flujo
de control con fragmentos de diagramas de secuencia de
UML.
Para crear un fragmento, haga clic con el botón derecho

en un mensaje, seleccione Delimitar con y, después, haga
clic en un tipo de fragmento.
14 Restricción de Se puede usar para indicar una condición sobre si tendrá

fragmentos lugar el fragmento.
40 - 236
Para establecer la restricción, seleccione un fragmento y,

después, seleccione la restricción y escriba un valor.
Los elementos de un diagrama de secuencias se encuentran listados en la tabla y la

figura superior, en cada caso explicando el rol que estas asumen. Entre sus
características se pueden listar (Universidad ICESI, 2017):
o Se muestran los objetos que interactúan

o Se muestra el tiempo de vida de un objeto
o Se muestran los mensajes que se envían los objetos
o Se muestra el tiempo durante el cual un objeto se encuentra activo (completando el
llamado del mensaje).
o Se muestra el envío y retorno de información de un mensaje.
o Se muestra el flujo de control de los mensajes.
Tabla 7: Ventajas y desventajas del Diagrama de Secuencias
VENTAJAS DESVENTAJAS
 Una representación de un diagrama de

 Da la posibilidad de representar los
secuencia demasiado largo, puede ser
mensajes en función del tiempo.
difícilmente entendido por alguien
 La separación de los mensajes no
ajeno al Sistema.
indica intervalos o cantidades de
tiempo, solo ordenación temporal.
 Es posible añadir restricciones
temporales.
Fuente: (Candillo J., Gil E., Alvarez E. & Rios M., 2012).
41 - 236
 Diagrama UML de Casos de Uso
El Diagrama de Casos de Usos es una representación de la interacción de un usuario

con el sistema que muestra la relación entre el usuario y los diferentes casos de uso en
los que el usuario está involucrado. Un diagrama de casos de uso puede identificar los
diferentes tipos de usuarios de un sistema y los diferentes casos de uso, y a menudo
también irá acompañado de otros tipos de diagramas. Si bien un caso de uso en sí mismo
puede profundizar en muchos detalles sobre cada posibilidad, un diagrama de casos de
usos puede ayudar a proporcionar una vista de mayor nivel del sistema. Se ha dicho
anteriormente que "los diagramas de casos de uso son los planos para su sistema",
Debido a su naturaleza simplista, los diagramas de casos de uso puede ser una buena
herramienta de comunicación para las partes interesadas. Los dibujos intentan imitar el
mundo real y proporcionan una vista para que el interesado entienda cómo se diseñará
el sistema. (UML-Diagrams.Org, 2017).
En la figura 6, se desarrolla un ejemplo similar al aplicado en la figura 5, tomando lugar

en un restaurante. Se tiene un cliente que desea realizar un pedido y un encargado que
toma nota del mismo, con lo que este diagrama debe incluir dos actores. El encargado
debe ser capaz de proporcionar menú, mientras que el cliente debe ser capaz de pedirlo.
Al momento de entregar menú, el cliente debe dar todos los platos que desee incluir en
su pedido y el encargado debe crear un pedido para agregar a la cola. Igual que con la
figura 5, los elementos que participan en el diagrama se explican en la tabla inferior.
Figura 7: Elementos de Diagrama de Casos de Uso.
42 - 236
Tabla 8: Elementos de un Diagrama de Casos de Uso.
FORMA ELEMENTO DESCRIPCIÓN Y PROPIEDADES PRINCIPALES
Actor Representa un usuario, organización o sistema externo que

1 interactúa con la aplicación o el sistema. Un actor es una
clase de tipo.
Caso de uso Representa las acciones realizadas por uno o varios actores
2 para conseguir un objetivo determinado. Un caso de uso es
una clase de tipo.
3 Asociación Indica que un actor forma parte de un caso de uso.
Los elementos de un diagrama de secuencias se encuentran listados en la tabla y la

figura superior, en cada caso explicando el rol que estas asumen. Las características de
un diagrama de casos de uso incluyen (Rouse, 2017):
o Organiza requisitos funcionales

o Modela los objetivos de las interacciones sistema / actor (usuario)
o Registra rutas (llamadas escenarios) desde los eventos desencadenantes hasta los
objetivos
o Describe un flujo principal de eventos (también llamado un curso básico de acción),
y posiblemente otros, llamados flujos de eventos excepcionales (también llamados
cursos de acción alternativos)
o Es multinivel, por lo que un caso de uso puede usar la funcionalidad de otro.
43 - 236
Tabla 8: Ventajas y desventajas del Diagrama de Casos de Uso.
 No establecen los requisitos

 Expresar la intención que tiene el actor
funcionales.
(usuario)
 Tampoco permiten establecer los
 Extraer los requerimientos del usuario
requisitos no funcionales.
y del sistema
 Centrar al analista en las tareas
principales de usuario (describiendo
los casos de mayor importancia).
 Tener en cuenta todos los usuarios
evitando que las personas
especializadas en informática dirijan la
funcionalidad del nuevo sistema
basándose solamente en criterios
tecnológicos.
Fuente: (Administración de Requerimientos, 2014).
b) Modelo Entidad-Relación
Un modelo entidad-relación (modelo ER) describe cosas interrelacionadas de interés en

un dominio específico. Un modelo ER se compone de tipos de entidad y especifica que
relaciones pueden existir entre instancias de esos tipos de entidades. En la ingeniería de
software un modelo de ER se forma comúnmente para representar cosas que se necesita
recordar para realizar procesos específicos. En consecuencia, el modelo ER se convierte
en un modelo de datos abstracto que define una estructura de datos o información que
puede implementarse en una base de datos. El modelo de ER fue primero una ayuda de
diseño estructural pero más tarde se propusieron varios lenguajes de datos para ello.
También puede utilizarse como un esquema conceptual de alto nivel y puede convertirse
44 - 236
en otros esquemas, incluyendo el esquema relacional. El modelo es fácil de usar y
comprender y es pictórico, es decir, gráfico. Muestra claramente todos los tipos de
abstracciones conceptuales, varias relaciones y restricciones de mapeo. (Thalheim,
2013, p. 30).
2.3.1.2. Métodos de validación
La validación es el proceso de determinar el grado al que un modelo de simulación y sus

datos asociados son una representación exacta del mundo real desde la perspectiva de
los usos previstos del modelo. Se utilizan diversos métodos para validar modelos de
simulación, desde la comparación con otros modelos hasta el uso de datos generados
por el propio sistema. (MITRE Corporation, 2012, p. 462).
Tabla 9: Métodos de validación para modelo de simulación.
Método de validación del modelo Descripción
Comparación con otros modelos Varios resultados del modelo de

simulación que se está validando se
comparan con los resultados de otros
modelos.
Validez aparente Pedir a personas conocedoras sobre el

tema de la simulación si el modelo y/o su
comportamiento son razonables.
Validación de datos históricos Si existen datos históricos, parte de los

datos se usan para construir el modelo y
los datos restantes se usan para
determinar si el modelo se comporta como
lo requiere el sistema.
45 - 236
Método de validación del modelo Descripción
Variabilidad del parámetro/Análisis de Esta técnica consiste en cambiar los

sensibilidad valores de la entrada y los parámetros
internos de un modelo para determinar el
efecto sobre los datos de salida. Las
reacciones deben ser las mismas tanto en
el modelo como en el sistema real.
Validación Predictiva El modelo se utiliza para predecir el

comportamiento del sistema, y luego se
compara el comportamiento del sistema y
el pronóstico del modelo para determinar
si son iguales.
Fuente: (MITRE Corporation, 2012, p. 462)
MODELAMIENTO EN 3D
Aquellos objetos que tienen altura, ancho y profundidad, como cualquier objeto en el
mundo real pueden ser considerados como un objeto en 3D. El modelado 3D es el
proceso de desarrollar una representación matemática de cualquier superficie
tridimensional de un objeto sea inanimado o vivo a través de software especializado. El
producto final se denomina modelo 3D.
Normalmente, la representación de un objeto se efectúa bidimensionalmente, aunque el

original del que se parte sea un objeto tridimensional, por lo que muchas veces estas
representaciones no representan la imagen perfecta de dicho objeto, sino que hay que
realizar un dibujo en perspectiva que muestre dicho objeto con su verdadera forma
espacial. (Gómez, 2011, p. 1).
46 - 236
Hoy en día, los modelos 3D se utilizan en una amplia variedad de campos. La industria
médica utiliza modelos detallados de órganos; Estos pueden ser creados con múltiples
rebanadas de imágenes en 2-D de una resonancia magnética o tomografía
computarizada. La industria cinematográfica los utiliza como personajes y objetos para
las películas animadas y de la vida real. La industria de videojuegos los utiliza como
activos para videojuegos y computadoras. El sector de la ciencia los utiliza como modelos
altamente detallados de compuestos químicos. La industria de la arquitectura los utiliza
para demostrar los edificios y los paisajes propuestos en vez de los modelos
arquitectónicos tradicionales, físicos. La comunidad de ingenieros los usa como diseños
de nuevos dispositivos, vehículos y estructuras, así como una serie de otros usos.
(SmartGeoMetrics, 2014).
Herramientas de modelado en 3D
A medida que la edad moderna sigue su progreso ante nuestros ojos, el modelado en
3D ha aumentado en popularidad, y con ello se han creado herramientas que faciliten la
creación de estos modelos. Esto se puede ver más que todo en los distintos programas
de software para diseño en 3D que existen. Entre estos los más conocidos están
(Lacoma, 2017):
 Blender
 AutoDesk 3DS Max
2.4.1.1. Blender
Blender es un software de diseño 3D gratuita y de código abierto. Soporta la totalidad de

la tubería 3D de modelado, aparejo, animación, simulación, renderizado, composición y
seguimiento de movimiento, incluso la edición de vídeo y creación de juegos. Blender
funciona igualmente bien en ordenadores Linux, Windows y Macintosh.
Blender es un software de diseño 3D gratuito y de código abierto. Soporta la totalidad de

la tubería 3D de modelado, aparejo, animación, simulación, renderizado, composición y
seguimiento de movimiento, incluso la edición de vídeo y creación de juegos. Los
47 - 236
usuarios avanzados utilizan la API de Blender para scripts de Python para personalizar
la aplicación y escribir herramientas especializadas; A menudo estos se incluyen en
futuras versiones de Blender. Blender está bien adaptado a individuos y pequeños
estudios que se benefician de su proceso de desarrollo. (Blender, 2017).
Blender ofrece una cantidad considerable de características propias como:
 Rendimiento fotorrealista
 Modelado Rápido
 Materiales Realistas
 Aparejo rápido
 Conjunto de herramientas de animación
 Escultura 3D
 Desmoldeo UV rápido
 Compositor completo
 Simulaciones asombrosas
 Seguimiento de cámara y objetos
 Biblioteca de Extensiones
 Formatos de archivo
 Interfaz flexible
Tabla 10: Ventajas y desventajas de Blender
 Una de los mayores tropiezos al

 Es compatible con Linux, Windows,
momento de aprender Blender es su
Mac OS X, Solaris, IRIX y FreeBSD.
interfaz extraña para cualquier artista.
 Utiliza muy poco espacio en el disco:
Esto es debido a que fue creado como
Solamente pesa 22 MB la última
un software In-House, desarrollado por
versión del Blender 2.5 beta.
programadores y artistas que lo
48 - 236
 Se carga increíblemente rápido: el fabricaron para ser eficiente según las

tiempo en que Blender se carga puede necesidades de la empresa y no para
ser veinte o treinta veces más rápido tener una interfaz estándar y libre para
de lo que se carga el 3d max y el Maya. ser modificada. Es por eso que para
 Posee un motor de Juegos interno. alguien que no está familiarizado con
 Posee un compositor de imágenes de otros programas de 3D le será muy
textura y post producción incorporado. complicado entenderlo, y la curva de
 Las últimas versiones han aprendizaje será larga y compleja.

implementado un prometedor sistema
de simulaciones.
 Se puede programar en Python, un
poderoso lenguaje no tan complejo de
entender.
Fuente: (Gamez, 2014).
2.4.1.2. AutoDesk 3DS Max
Autodesk 3ds Max, anteriormente 3D Studio, 3D Studio Max es un programa profesional

de gráficos 3D para hacer animaciones en 3D, modelos, juegos e imágenes. Es
desarrollado y producido por Autodesk Media and Entertainment. Tiene capacidades de
modelado y una arquitectura de complemento flexible y se puede utilizar en la plataforma
Microsoft Windows. Es utilizado con frecuencia por los desarrolladores de videojuegos,
muchos estudios comerciales de televisión y estudios de visualización arquitectónica.
También se utiliza para efectos de películas y pre-visualización de películas. Para sus
herramientas de modelado y animación, la última versión de 3ds Max también ofrece
shaders (como oclusión ambiental y dispersión subsuperficial), simulación dinámica,
sistemas de partículas, radiosidad, creación y representación normales de mapas,
iluminación global, interfaz de usuario personalizable, nuevos iconos , Y su propio
49 - 236
lenguaje de scripting. Este software presenta cuatro características principales
(AutoDesk, 2017):
 Compatibilidad con otros software

 Disponibilidad en otros lenguajes
 Extensiones mediante un numero de API para automatización y personalización
 Integración con otros software de AutoDesk
Tabla 11: Ventajas y desventajas de AutoDesk
 Muy complicado de usar

 Opciones muy desarrolladas.
 Kinematica Inversa.
 Render mejorado
 Muy complicado de usar
Fuente: (Gamez, 2014).
TECNOLOGÍAS DE DESARROLLO
Lenguaje de Programación
2.5.1.1. Java
El lenguaje de programación Java es un lenguaje de propósito general, concurrente,

basado en clases y orientado a objetos. Está diseñado para ser lo suficientemente simple
como para que muchos programadores logren fluidez en el lenguaje. El lenguaje de
programación Java está relacionado con C y C ++, pero está organizado de manera
diferente, con varios aspectos de C y C ++ omitidos y algunas ideas de otros lenguajes
incluidos. Se pretende que sea un lenguaje de producción, no un lenguaje de
investigación, por lo que, como sugirió C. A. R. Hoare en su trabajo clásico sobre el
50 - 236
diseño del lenguaje, el diseño ha evitado incluir rasgos nuevos y no comprobados.
(Gosling, Joy, Steele, Bracha, y Buckley, 2015).
De acuerdo a (CodeJava, 2015) entre sus características principales se encuentra:
 Sencillo: El lenguaje Java es fácil de aprender. El código Java es fácil de leer y

escribir.
 Orientado a objetos: A diferencia de C ++ que es semi orientado a objetos, Java es
un lenguaje de programación totalmente orientado a objetos. Tiene todas las
características como abstracción, encapsulación, herencia y polimorfismo.
 Plataforma independiente: El código Java se compila en un formato intermedio
(bytecode), que puede ejecutarse en cualquier sistema para el que se porta la
máquina virtual Java. Esto significa que puede escribir un programa Java una vez y
ejecutarlo en Windows, Mac, Linux o Solaris sin volver a compilar.
 Asegurado: La plataforma Java está diseñada con funciones de seguridad integradas
en el sistema de lenguaje y tiempo de ejecución, lo que le permite crear aplicaciones
que no pueden ser invadidas desde fuera.
 Robusto: Con colección automática de basura y un modelo simple de administración
de memoria, además de otras características de lenguaje Java guía al programador
hacia hábitos de programación confiables para crear aplicaciones altamente
confiables.
 Alto rendimiento: El código Java se compila en bytecode altamente optimizado por el
compilador Java, de modo que la máquina virtual Java (JVM) puede ejecutar
aplicaciones Java a toda velocidad.
 Multiproceso: La plataforma Java está diseñada con capacidades multithreading
incorporadas al lenguaje. Esto significa que puede crear aplicaciones con muchos
hilos de actividad concurrentes, lo que resulta en aplicaciones altamente interactivas
y sensibles.
51 - 236
a) Ventajas y Desventajas
Tabla 12: Ventajas y desventajas de Java.
 Rendimiento: Es mucho más lenta y

 Simple: Java fue diseñado para ser
consume más memoria que los
fácil de usar, escribir, compilar,
lenguajes compilados nativamente,
depurar y aprender que otros
como C o C ++.
lenguajes de programación. Java es
 Aspecto y apariencia: El aspecto y la
mucho más simple que C ++ porque
apariencia predeterminados de las
Java utiliza asignación automática de
aplicaciones GUI escritas en Java con
memoria y recolección de basura.
el kit de herramientas Swing es muy
 Orientado a objetos: le permite crear
diferente de las aplicaciones nativas.
programas modulares y código
 Lenguaje de un solo paradigma: La
reutilizable.
adición de importaciones estáticas en
 Independiente de la plataforma:
Java 5.0, el paradigma procedimental,
Capacidad de moverse fácilmente de
está mejor acomodado que en
un sistema de computadora a otro.
versiones anteriores de Java.
 Distribuido: Diseñado para facilitar el
uso de la computación distribuida con
la capacidad de red que se integra de
forma inherente al mismo.
 Seguro: El lenguaje Java, el
compilador, el intérprete y el entorno
de ejecución se desarrollaron cada
uno con la seguridad en mente.
 Asignación: Java tiene la característica
de sistema de asignación de pila.
52 - 236
Ayuda a almacenar los datos y puede

restaurarse fácilmente.
 Multiproceso: La capacidad de un
programa para realizar varias tareas
simultáneamente dentro de un
programa.
Fuente: (MindsMapped, 2015).
2.5.1.2. Python
Python es un lenguaje de programación de ampliamente utilizado, creado por Guido van

Rossum en 1991. Python es un lenguaje orientado a objetos claro y potente, comparable
a Perl, Ruby o Java.
Python es la maravillosa criatura de Guido Van Rossum, un científico de computación y

matemático holandés quien decidió regalar al mundo un proyecto en el que estaba
trabajando desde la navidad del año 1989. El lenguaje apareció al público alrededor de
1991, y desde entonces ha evolucionado en uno de los lenguajes de programación
líderes usados a nivel mundial. (Romano, 2015, p. 4).
Entre las características más destacables de Python se puede nombrar las siguientes
según (Python, 2016):
 Utiliza una sintaxis elegante, haciendo que los programas sean más fáciles de leer
para el programador.
 Es un lenguaje fácil de usar que facilita el funcionamiento del programa. Esto hace
que Python sea ideal para el desarrollo de prototipos sin comprometer la
mantenibilidad del mismo.
53 - 236
 Viene con una gran biblioteca estándar que soporta muchas tareas de programación
comunes, como la conexión a servidores web, buscar texto con expresiones
regulares, leer y modificar archivos.
 El modo interactivo de Python facilita la comprobación de fragmentos cortos de
código. También hay un entorno de desarrollo incluido llamado IDLE.
 Se amplía fácilmente añadiendo nuevos módulos implementados en un lenguaje
compilado como C o C ++.
 También se puede integrar en una aplicación para proporcionar una interfaz
programable.
 Se ejecuta en cualquier lugar, incluido Mac OS X, Windows, Linux y Unix.
 Es el software libre en dos sentidos. No cuesta nada descargar o usar Python, o
incluirlo en su aplicación. Python también puede ser libremente modificado y re-
distribuido, porque mientras que el idioma está protegido por derechos de autor está
disponible bajo una licencia de código abierto.
a) Ventajas y Desventajas
Tabla 13: Ventajas y desventajas de Python.
Desventajas
Ventajas
 Pequeño grupo de desarrolladores de
 Disponibilidad gratuita (como Perl,
Python en comparación con otros
Python es de código abierto).
idiomas, como Java
 Estabilidad (Python está en la versión
 Falta de soporte multiprocesador
2.2 en este punto y, como ya he dicho
verdadero
antes, es más antiguo que Java).
 La ausencia de un punto de apoyo
 Buen soporte para objetos, módulos y
comercial, incluso para un proyecto
otros mecanismos de reutilización.
Open Source (aunque esta situación
 Fácil integración y extensibilidad con C
está cambiando)
y Java.
54 - 236
Desventajas
Ventajas
 Rendimiento de software (aunque los
benchmarks demuestran
repetidamente que Python es
comparable a Java en la mayoría de
las aplicaciones)
Fuente: (Shafer, 2002)
Arquitectura de Software
Arquitectura de software se refiere a las estructuras fundamentales de un sistema de

software, la disciplina de la creación de tales estructuras, y la documentación de estas
estructuras. Estas estructuras son necesarias para razonar sobre el sistema de software.
Cada estructura comprende elementos de software, relaciones entre ellos, y propiedades
tanto de elementos como de relaciones, junto con razones para la introducción y
configuración de cada elemento.
La arquitectura de software de un sistema es el conjunto de estructuras necesitadas para

el razonamiento del sistema, lo cual compromete elementos de software, las relaciones
entre estos y las propiedades de ambos. (Bass, Clements, y Kazman, 2012, p. 4).
2.5.2.1. Patrones de Arquitectura
Un patrón arquitectónico es una solución general, reutilizable a un problema común que

ocurre en la arquitectura del software dentro de un contexto dado. Los patrones
arquitectónicos son similares al patrón de diseño de software pero tienen un alcance más
amplio. Los principales patrones son: Modelo Vista-Controlador, Modelo Vista-
Presentador y Modelo Vista-Vista Modelo.
55 - 236
a) Modelo Vista-Controlador
Es un patrón arquitectónico para implementar interfaces de usuario en equipos. Este

divide una aplicación dada en tres partes interconectadas con el fin de separar las
representaciones internas de la información de las formas en que la información es
presentada y aceptada por el usuario, la figura 7 se puede observar una ilustración de
este modelo. (Apple Inc., 2015)
Figura 8: Diagrama de Modelo Vista-Controlador
Fuente: (Apple Inc., 2015)
Los componentes que forman parte de un modelo Vista-Controlador son los siguientes:
 Modelos: Los modelos contienen información de datos. No llama o no usa el

Controlador y la Vista. Contiene la lógica y formas de representar datos.
 Controlador: Actúa como la conexión entre la vista y el modelo. Básicamente, informa
al modelo y/o la vista que cambie según corresponda.
 Ver: Es la parte encargada de la parte de la interfaz de usuario. Interactúa con el
usuario.
Sus características principales son (Cuevas, 2016):
 El modelo, las vistas y los controladores se tratan como entidades separadas.

 Se utilizan en aplicaciones con interfaces sofisticadas
 Maneja gran cantidad de datos y transacciones complejas.
56 - 236
Tabla 14: Ventajas y desventajas de MVC
 El tiempo de desarrollo de una

 Las aplicaciones están implementadas
aplicación que implementa MVC es
modularmente.
mayor, al menos de las primeras
 Crea independencia de
etapas, que aplicaciones que usan
funcionamiento.
otros diseños.
 Las modificaciones a las vistas no
 La curva de aprendizaje del patrón es
afectan en absoluto a los otros
mas alta que usando otros modelos.
módulos de la aplicación.
 MVC requiere la existencia de una
 Sus vistas muestran información
arquitectura inicial para construir
actualizada.
clases e interfaces para modificar y
comunicar los módulos.
Fuente: (Cuevas, 2016).
b) Modelo Vista-Presentador
Figura 9: Diagrama de Modelo Vista-Presentador.
Fuente: (Microsoft, 2017)
57 - 236
El MVP es una derivación del patrón arquitectónico del modelo-vista-controlador (MVC),
y se utiliza principalmente para crear interfaces de usuario. La figura 9 muestra una
ilustración de este modelo. En MVP el presentador asume la funcionalidad del "middle-
man". En MVP, el presentador se ocupa de trabajar con el modelo y decidir qué
información se necesitará para formar algún tipo de visualización. (Microsoft, 2017).
Un modelo MVP se puede dividir en:
 Modelo: Es una interfaz que define los datos que se mostrarán o que se actuarán en
la interfaz de usuario.
 Presentador: Actúa sobre el modelo y la vista. Recupera los datos de los
repositorios (el modelo) y los formatea para su visualización en la vista.
 Vista: Es una interfaz pasiva que muestra los datos (el modelo) y dirige los
comandos del usuario (eventos) al presentador para que actúe sobre esos datos.
Sus características principales son (Mary Dz, 2014):
 La vista no conoce el modelo.

 El presentador es independiente de la tecnología de interfaz de usuario.
 La vista y el presentador son testeables puesto que esta basada en un contrato.
 El patrón MVP, es un patrón que no puede ser implementado sin haber hecho un
análisis previo que determine que miembros deben formar parte del contrato de cada
vista.
Tabla 15: Ventajas y desventajas de MVP
 Este patrón de diseño es perfecto para  Requiere una gran cantidad de código
aplicaciones basadas en Windows. que no vale la pena hacer en proyectos
 El código de la vistas es relativamente fáciles y simples
sencillo y la vista hacen muy pocas
58 - 236
cosas, así cumpliendo objetivo de  Consume bastante memoria porque

sencillez y rapidez. depende de los atributos y por todo
 La vista puede ser trabajada incluso crea un atributo.
por una persona diferente  Dependencia de la clase Presentador.
 La vista y el modelo pueden cambiar y  La Interfaz de nuestra aplicación sea
ser muy diferentes sin que eso afecte muy pesada (muchos métodos) y el
demasiado el sistema mapeo entre propiedades y controles
puede llegar a ser tedioso.
Fuente: (Mary Dz, 2014).
c) Modelo Vista-Vista Modelo
Modelo vista-vista modelo (MVVM) es un modelo de arquitectura de software. El patrón

Model-View-ViewModel se puede utilizar en todas las plataformas XAML. La figura 9
muestra como se organiza el modelo. Su intención es proporcionar una separación clara
entre los controles de la interfaz de usuario y su lógica. (Microsoft, 2017)
Figura 10: Diagrama de Modelo Vista-Vista Modelo
Fuente: (Microsoft, 2017)
59 - 236
Dentro de este modelo hay tres componentes principales en el patrón MVVM: el modelo,
la vista y el modelo de vista. Cada uno desempeña un papel distinto y separado. La
siguiente ilustración muestra las relaciones entre los tres componentes:
 Modelo: Representa el modelo de datos que consume la aplicación.

 Ver: Una aplicación normalmente está compuesta de varias páginas de interfaz de
usuario. Cada aplicación usualmente al usuario es una vista en terminología MVVM.
Los datos del modelo se muestran al usuario, y es el trabajo de ViewModel para
alimentar la interfaz de usuario de estos datos basados en el estado actual de la
aplicación.
 ViewModel: El ViewModel vincula el modelo de datos, o simplemente el modelo, a la
UI o interfaz de la aplicación. Contiene la lógica con la que administrar los datos del
modelo y expone los datos como un conjunto de propiedades a las que se pueden
enlazar.
Sus características principales son (SOFTPEI, 2013):
 Encaja muy bien cuando se desea que los equipos de diseño de las vistas y de los
viewmodel trabajen en paralelo. Solo se debe definir el contrato respecto a la
información a intercambiar y listo. Cada uno trabaja por su parte.
 Presenta un bajo acoplamiento con la lista, ya que los viewmodel no conocen nada
acerca de la vista con la cual son enlazados.
Tabla 16: Ventajas y desventajas de MVVM
 Algunas personas piensan que para

 Una separación limpia de diferentes
interfaces de usuario sencilla, MVVM
tipos de código debería hacer más fácil
puede ser excesiva.
para entrar en una o varias de las
partes más detalladas y específicas y
60 - 236
hacer cambios sin tener que  Del mismo modo, en los casos más
preocuparse. grandes, puede ser difícil de diseñar el
 Esto significa que puede mantener su modelo de vista.
agilidad y mantenerse en movimiento a  Depuración sería poco difícil cuando
las nuevas versiones de forma rápida. tenemos enlaces de datos complejos.
Fuente: (W3i, 2017).
Base de Datos
Una base de datos es una colección organizada de datos. Esto incluye todo tipo de
esquemas, tablas, consultas, informes, vistas y otros objetos. Los datos suelen ser
organizados para modelar aspectos de la realidad de una manera que son fáciles de
accesar cuando se requiere información. Casi todo el software que se utiliza en la
actualidad depende de una base de datos a un nivel fundamental para funcionar
correctamente. Todo software debe ser capaz de manejar datos, y por lo tanto también
debe ser capaz de guardarlos en alguna parte. Un sistema de gestión de base de datos
consiste de una colección de datos interrelacionados y un conjunto de programas para
accesar a dichos datos. Su principal propósito es el de proveer un ambiente que es
conveniente y eficiente para la recolección y almacenamiento de información de base
de datos. (Kedar, 2009, p. 1).
Es con el propósito de facilitar el trabajo de los desarrolladores que se elaboraron los

llamados sistemas gestores de bases de datos. Un gestor de bases de datos es una
aplicación informática que interactúa con el usuario, otras aplicaciones y la propia base
de datos para capturar y analizar datos. Sirve de intermediario para realizar operaciones
con la información de las tablas, que se pueden simplificar en cuatro funciones: Registrar
datos, extraer datos, modificar datos y eliminar datos. Los sistemas de gestión de bases
de datos suelen clasificarse de acuerdo con el modelo de base de datos que manejan.
Es decir, relacional o no relacional.
61 - 236
2.5.3.1. Tipos de Bases de Datos
a) Base de datos relacional
Una base de datos relacional es una base de datos digital cuya organización se basa en
el modelo relacional de datos. Dentro de esta base de datos se tiene distintos tipos de
tablas que tiene relaciones entre sus distintos datos y cómo interactúan entre sí.
Por ejemplo, se tiene una base de datos con tablas que guardan información de
“Estudiantes” y “Clases”. Cada tabla puede tener distintas columnas o atributos, los
“Estudiantes” pueden tener datos como “Nombre” y “Código de Est.” mientras que las
“Clases” deberían guardar “ID de Clase”, “Nombre de la Materia”, “Docente” y “Aula”
entre otros. Cada tabla debe tener una clave primaria, una columna que tenga un valor
único por cada fila. Para relacionar estas dos tablas se puede formar una tercera tabla,
donde se guarde los valores “Código de Est.” y “ID de Clase”, emparejándolos según que
clases toma cada estudiante.
Si el estudiante “1” toma dos clases, se introducen dos filas con el mismo estudiante y
con el “ID” correspondiente a la clase. De esta forma si se desea saber que estudiantes
toman una clase solo se tiene que buscar las filas en la tercera tabla que contengan el
“ID” respectivo, y con los “Códigos” que se encuentren se puede acceder a toda la
información de cada estudiante de la clase. Algunos ejemplos conocidos de sistemas de
gestión de base de datos son: MySQL, Microsoft SQL Server y PostgreSQL.
Las características de una Base de Datos Relacional incluyen (ToolBox.Com, 2008):
 Los datos en la base de datos relacional se deben representar en tablas, con valores
en columnas dentro de las filas.
 Los datos dentro de una columna deben ser accesibles especificando la tabla, el
nombre de la columna y el valor de la clave principal de la fila.
 El DBMS debe admitir información faltante e inaplicable de forma sistemática, distinta
de los valores normales e independientes del tipo de datos.
 El DBMS debe admitir un catálogo activo en línea.
62 - 236
 El DBMS debe admitir al menos un idioma que se puede usar de forma independiente
y dentro de los programas, y admite operaciones de definición de datos, manipulación
de datos, restricciones y gestión de transacciones.
 Las vistas deben ser actualizadas por el sistema.
 El DBMS debe admitir operaciones de inserción, actualización y eliminación en
conjuntos.
 El DBMS debe admitir independencia de datos lógicos.
 El DBMS debe admitir independencia de datos físicos.
 Las restricciones de integridad deben almacenarse dentro del catálogo, separadas
de la aplicación.
 El DBMS debe ser compatible con la independencia de la distribución. La aplicación
existente debería ejecutarse cuando los datos existentes se redistribuyen o cuando
se redistribuye el DBMS.
 Si el DBMS proporciona una interfaz de bajo nivel (fila a la vez), esa interfaz no puede
eludir las restricciones de integridad
Tabla 17: Ventajas y desventajas de Bases de Datos Relacionales
 Una desventaja de las bases de datos

 El formato de la tabla es simple y fácil
relacionales es el costo de configurar y
de entender y usar para los usuarios
mantener el sistema de base de datos.
de la base de datos.
Para configurar una base de datos
 Los RDBMS permiten que múltiples
relacional, generalmente necesita
usuarios de bases de datos accedan a
comprar un software especial. Si no es
una base de datos simultáneamente.
un programador, puede usar cualquier
 Las funciones de autorización y control
cantidad de productos para configurar
de privilegios en un RDBMS permiten
una base de datos relacional. Lleva
al administrador de la base de datos
63 - 236
restringir el acceso a usuarios tiempo ingresar toda la información y

autorizados y otorgar privilegios a configurar el programa.
usuarios individuales en función de los  Los avances en la complejidad de la
tipos de tareas de base de datos que información causan otro inconveniente
necesitan realizar. a las bases de datos relacionales.
 Los RDBMS brindan acceso a la base  Algunas bases de datos relacionales
de datos a través de un daemon de tienen límites en la longitud de los
servidor, un programa de software campos
especializado que escucha solicitudes  Los sistemas complejos de bases de
en una red, y permite a los clientes de datos relacionales pueden hacer que
la base de datos conectarse y usar la estas bases de datos se conviertan en
base de datos. "islas de información" donde la
 Los RDBMS incluyen utilidades de información no se puede compartir
mantenimiento que brindan a los fácilmente de un sistema grande a
administradores de bases de datos otro.
herramientas para mantener, probar,
reparar y hacer copias de seguridad de
las bases de datos alojadas en el
sistema.
 Los RDBMS son compatibles con un
lenguaje genérico llamado "Structured
Query Language" (SQL). La sintaxis de
SQL es simple, y el lenguaje utiliza
palabras clave y fraseología estándar
en inglés, lo que lo hace bastante
intuitivo y fácil de aprender.
Fuente: (Lee & Martin, 2017).
64 - 236
b) NoSQL
Un NoSQL, también conocido como base de datos no relacional es una base de datos
cuya característica principal es el no implementar relaciones entre sus tablas. El NoSQL
surgió como respuesta al uso amplio de bases de datos relacionales por empresas
grandes como Google y Amazon que usan bases de datos enormes. (Garling, 2012).
Cuando se usa bases de datos relacionales para manejar una enorme magnitud de
volumen de datos el sistema empieza a perder velocidad en el tiempo de reacción.
Aunque existen medidas que puedan contrarrestar esto, existe suficiente inconformidad
para sacar adelante el NoSQL, que se enfoca más en el manejo de grandes volúmenes
de información. Las motivaciones para este enfoque incluyen: simplicidad de diseño,
escalado "horizontal" más simple a grupos de y control más fino de la disponibilidad. Las
estructuras de datos utilizadas son diferentes de las utilizadas por defecto en las bases
de datos relacionales, lo que hace que algunas operaciones sean más rápidas en
NoSQL. (Leavitt, 2010).
Cuando se ingresan datos a una tabla relacional, se necesita verificar que los datos sean
compatibles con la estructura de la misma, tiene que tener su columna a la cual ser
asignada. Cuando no se cumple esta condición se deben realizar modificaciones
complejas a la base de datos para hacer lugar a esta información.
Por otro lado NoSQl, no requiere esto. Si se tiene datos que no encajan en la estructura
aún se las pudiese ingresar a la tabla, y posteriormente se las puede asignar una
columna existente o una nueva.
Las características más comunes de NoSQL son (Fowler, 2017):
 Esquema independiente: un esquema de base de datos es la descripción de todas

las posibles estructuras de datos y datos en una base de datos relacional. Con una
base de datos NoSQL, no se requiere un esquema, que le da la libertad de almacenar
información sin hacer un diseño de esquema inicial.
65 - 236
 No relacional: las relaciones en una base de datos establecen conexiones entre
tablas de datos. Por ejemplo, una lista de detalles de la transacción se puede conectar
a una lista separada de detalles de la entrega. Con una base de datos NoSQL, esta
información se almacena como un agregado, un registro único con todo lo relacionado
con la transacción, incluida la dirección de entrega.
 Hardware básico: algunas bases de datos están diseñadas para funcionar mejor (o
solo) con hardware especializado de almacenamiento y procesamiento. Con una
base de datos NoSQL, se pueden usar servidores baratos y listos para usar. Agregar
más de estos servidores baratos permite que las bases de datos NoSQL se escalen
para manejar más datos.
 Altamente distribuible: las bases de datos distribuidas pueden almacenar y procesar
un conjunto de información en más de un dispositivo. Con una base de datos NoSQL,
se puede usar un clúster de servidores para mantener una sola base de datos grande.
Tabla 18: Ventajas y desventajas de Bases de Datos NoSQL
 Los RDBMS han existido mucho más

 Los RDBMS no son tan fáciles de
tiempo que las bases de datos NoSQL.
escalar en clusters de productos,
La mayoría de las alternativas de
mientras que las bases de datos
bases de datos NoSQL apenas han
NoSQL están hechas para una
salido de las etapas de preproducción,
expansión transparente,
y hay muchas características
aprovechando los nuevos nodos.
importantes que aún no se han
Estas bases de datos están diseñadas
implementado.
para su uso con hardware básico de
 Las bases de datos NoSQL tienden a
bajo costo. En un mundo en el que la
ser de código abierto, con solo una o
escalabilidad ascendente está siendo
dos empresas que manejan el ángulo
reemplazada por una escalabilidad
de soporte. Muchos de ellos han sido
desarrollados por startups más
66 - 236
externa, las bases de datos NoSQL se pequeñas que carecen de los recursos
adaptan mejor. para financiar el soporte a escala
 Dado que las tasas de transacción global, y también por la credibilidad
están creciendo a partir del que disfrutan los proveedores de
reconocimiento, es necesario RDBMS establecidos como Oracle,
almacenar volúmenes masivos de IBM y Microsoft.
datos. Si bien los RDBMS han crecido  Las bases de datos NoSQL se crearon
para satisfacer las crecientes teniendo en cuenta las demandas de
necesidades, es difícil utilizar un las aplicaciones web actuales de la
RDBMS de manera realista para Web 2.0. Como tal, la mayoría de las
administrar dichos volúmenes de funciones están dirigidas a satisfacer
datos. Sin embargo, estos volúmenes estas demandas. Cuando las
son manejados fácilmente por las demandas de una aplicación de datos
bases de datos NoSQL. se extienden más allá del ciclo
 Los mejores RDBMS requieren los característico "insertar-leer-actualizar-
servicios de administradores caros borrar" de una aplicación web típica,
para diseñar, instalar y mantener los estas bases de datos ofrecen pocas
sistemas. Por otro lado, las bases de funciones para el análisis y la consulta
datos NoSQL requieren mucha menos ad-hoc. Las consultas simples
administración práctica, con requieren algunos conocimientos de
distribución de datos y capacidades de programación, y las herramientas de
reparación automática, modelos de inteligencia de negocios más comunes
datos simplificados y menos requisitos en las que muchas empresas confían
de ajuste y administración. Sin no ofrecen conectividad a bases de
embargo, en la práctica, siempre se datos NoSQL. Sin embargo, esto
necesitará a alguien para cuidar el puede resolverse a tiempo, dado que
rendimiento y la disponibilidad de las algunas herramientas se han creado
bases de datos. para ofrecer una funcionalidad de
67 - 236
 Los RDBMS requieren la instalación consulta ad-hoc para bases de datos

de costosos sistemas de NoSQL.
almacenamiento y servidores  El objetivo final para el diseño de la
propietarios, mientras que las bases base de datos NoSQL era ofrecer una
de datos NoSQL pueden instalarse solución que no requiriera
fácilmente en clusters baratos de administración, pero la realidad sobre
hardware básico a medida que el terreno es muy diferente. Las bases
aumentan los volúmenes de de datos NoSQL todavía demandan
transacciones y datos. Esto significa mucha habilidad técnica con la
que puede procesar y almacenar más instalación y el mantenimiento.
datos a un costo mucho menor.  Debido a que las bases de datos
NoSQL aún son nuevas,
prácticamente todos los
desarrolladores de NoSQL todavía
están aprendiendo las reglas.
Fuente: (Richards, 2015).
2.5.3.2. Software de Gestión de Bases de Datos
a) MySQL
MySQL es un sistema de gestión de base de datos relacional de código abierto (RDBMS).

El proyecto de desarrollo de MySQL ha hecho disponible su código fuente bajo los
términos de la Licencia Pública General GNU, así como bajo una variedad de acuerdos
propietarios. MySQL fue creado y patrocinado por una empresa con fines de lucro, la
compañía sueca MySQL AB.
MySQL es muy diferente de otros servidores de bases de datos, y sus características

arquitectónicas lo hacen útil para una amplia gama de propósitos, así como lo convierten
68 - 236
en una mala elección para otros. MySQL no es perfecto, pero es lo suficientemente
flexible como para funcionar bien en entornos muy exigentes, como aplicaciones web. Al
mismo tiempo, MySQL puede alimentar aplicaciones embebidas, data warehouses,
software de indexación y entrega de contenidos, sistemas redundantes altamente
disponibles, procesamiento de transacciones en línea (OLTP) y mucho más. (Schwartz,
2012, p. 1).
Las características principales de MySQL son (Oracle, 2017):
 Alto rendimiento y escalabilidad para satisfacer las demandas de cargas de datos y

usuarios que crecen exponencialmente.
 Clústeres de replicación de auto-recuperación para mejorar la escalabilidad, el
rendimiento y la disponibilidad.
 Cambio de esquema en línea para cumplir con los requisitos cambiantes del negocio.
 Esquema de rendimiento para supervisar el rendimiento de usuarios y aplicaciones y
el consumo de recursos.
 SQL y NoSQL Access para realizar consultas complejas y operaciones de valor de
claves simples y rápidas.
 Independencia de la plataforma que le da la flexibilidad para desarrollar y desplegar
en múltiples sistemas operativos.
 Interoperabilidad de Big Data utilizando MySQL como almacén de datos operativos
para Hadoop y Cassandra.
Tabla 19: Ventajas y desventajas de MySQL.
 Tiene algunos problemas de

 Fácil de instalar, crear bases de datos
estabilidad.
y trabajar con tablas.
 Sufre de relativamente pobre
 Ayuda al cliente está siempre
desempeño escalado
disponible para cuando sea necesaria
69 - 236
 Es un software de fuente abierta.  El desarrollo de actualizaciones no

 Cuando se necesita pagar por él, su suele implementar soluciones
precio es increíblemente barato propuestas por la comunidad de
 Es extremadamente popular y aficionados.
ampliamente usado.  Su funcionalidad tiende a ser
dependiente a Add-ons.
 Algunos desarrolladores pueden
encontrar a sus limitaciones muy
frustrantes.
Fuente: (Mack, 2014)
b) Microsoft SQL Server
Microsoft SQL Server es un sistema de gestión de bases de datos relacional desarrollado

por Microsoft. Como servidor de base de datos, es un producto de software con la función
principal de almacenar y recuperar datos según lo soliciten otras aplicaciones de
software, que pueden ejecutarse en el mismo equipo o en otro equipo a través de una
red.
Microsoft comercializa al menos una docena de ediciones diferentes de Microsoft SQL

Server, dirigidas a diferentes audiencias y para cargas de trabajo que van desde
pequeñas aplicaciones de una sola máquina hasta grandes aplicaciones orientadas a
Internet con muchos usuarios simultáneos.
Según (Microsoft, 2016), las principales características que ofrece SQL Server son:
 Soporta la mayoría de las tareas administrativas de SQL Server.

 Un único entorno integrado para la administración y la creación del motor de base de
datos de SQL Server.
70 - 236
 Diálogos para administrar objetos en el motor de base de datos de SQL Server,
Analysis Services y Reporting Services, que le permite ejecutar sus acciones
inmediatamente, enviarlas a un Editor de código o guiarlas para su ejecución
posterior.
 Los diálogos no modales y redimensionables permiten el acceso a múltiples
herramientas mientras se abre un diálogo.
 Un diálogo de programación común que le permite realizar una acción de los cuadros
de diálogo de administración en un momento posterior.
 Exportar e importar el registro de servidor de SQL Server Management Studio de un
entorno de Management Studio a otro.
 Guarde o imprima archivos XML Showplan o Deadlock generados por SQL Server
Profiler, reviselos más tarde o envíelos a los administradores para su análisis.
 Un nuevo cuadro de mensaje de error y información que presenta mucha más
información, le permite enviar a Microsoft un comentario sobre los mensajes, le
permite copiar mensajes al portapapeles y le permite enviar mensajes fácilmente a
su equipo de soporte.
 Un navegador web integrado para navegar rápidamente en MSDN o ayuda en línea.
 Integración de la Ayuda de las comunidades en línea.
 Un tutorial sobre SQL Server Management Studio para ayudarlo a aprovechar las
muchas nuevas características y ser más productivo de inmediato.
 Un nuevo monitor de actividad con filtrado y actualización automática.
 Interfaces integradas del correo de base de datos.
Tabla 20: Ventajas y desventajas de SQL Server.
 Costo elevado de la licencia para su

 Software de Gestión digno de
uso.
considerarse de nivel de empresa.
71 - 236
 Nivel excelente de ayuda de  Compatibilidad limitada a servidores

recuperación de datos. que se ejecuten utilizando el sistema
operativo Windows.
Fuente: (Moufarrege, 2016)
c) PostgreSQL
PostgreSQL, a menudo llamado simplemente Postgres, es una base de datos relacional

de objetos (ORDBMS), es decir, un RDBMS con características adicionales de "objeto",
con énfasis en la extensibilidad y cumplimiento de estándares. Como servidor de base
de datos, sus funciones principales son almacenar datos de forma segura y devolverlos
en respuesta a solicitudes de otras aplicaciones de software. Cabe de destacar que este
software cuenta con un modo “No Relacional” para implementar bases de datos de este
tipo.
PostgreSQL es un descendiente de código abierto de este código original de Berkeley.

Soporta una gran parte del estándar SQL y ofrece muchas características modernas.
(The PostgreSQL Global Development Group, 2017).
Sus características principales incluyen (Mary Dz, 2014):
 Consultas complejas
 llaves extranjeras
 Disparadores
 Vistas actualizables
 Integridad transaccional
 Control de concurrencia
72 - 236
Tabla 21: Ventajas y desventajas de PostgreSQL
 Considerablemente más lento que

 Inmunidad ante el exceso de
MySQL.
despliegue
 No soporta el mismo nivel de estándar
 Mejor soporte que los vendedores
que MySql.
propietarios
 Tiene una comunidad mucho más
 Ahorro significativo en costos de
reducida que otros gestores.
personal
 Legendaria fiabilidad y estabilidad
 Plataforma Extensible y Cruzada
 Diseñado para entornos de alto
volumen
 Herramientas de diseño y
administración de bases de datos GUI
Fuente: (The PostgreSQL Global Development Group, 2017) .
73 - 236
3. MARCO PRÁCTICO
ANÁLISIS DEL PROCESO ACTUAL DE DESARROLLO DE NUEVOS

PROTOTIPOS DE COHETES
Análisis del proceso actual de desarrollo de prototipos
El programa aeroespacial es encargado de saciar la necesidad del ejército de armamento

al crear unidades de defensas de corto alcance. El proceso actual para llevar a cabo el
desarrollo de nuevos prototipos de cohetes se divide en las siguientes etapas:
 Planificación de Diseño de Prototipo

 Fabricación del Propelente y las Pastillas
 Construcción de las piezas del motor de cohete
 Pruebas de Validación en Banco de Pruebas
 Planificación del Diseño de Fuselaje del Prototipo
 Pruebas de Validación del diseño del Prototipo
 Pruebas de Campo del Prototipo
Figura 11: Modelado del proceso actual
74 - 236
3.1.1.1. Planificación de Diseño de Prototipo
Cuando se desea empezar a diseñar un cohete nuevo, este viene con una serie de
requerimientos que la unidad final deberá cumplir. Los desarrolladores empiezan el
proceso por considerar o proponer diferentes ingredientes, materiales o modelos de
partes que puedan ser empleados en el diseño del prototipo, en una serie de reuniones
para discutir a fondo estos detalles. Los requerimientos dados inicialmente para el
cohete, permiten establecer factores o variables importantes que determinaran el
rendimiento esperado del mismo. Es con es con el fin de influir positivamente sobre estos
factores que se debe escoger los componentes que pasaran a formar parte del diseño.
Comúnmente los componentes principales que se deben definir incluyen:
 Ingredientes de Propelente.
 Medidas de las pastillas de grano empleadas,
 Material de construcción del fuselaje
 Tipos de aletas y ojiva para el fuselaje
 Carga que se deba llevar en el cohete.
Para realizar todo este proceso de toma de decisiones, se emplea el software de

simulación existente para predecir como ciertos componentes favorecerían al diseño y si
deberían ser incluidos en el diseño para la fabricación de una unidad física.
3.1.1.2. Fabricación del Propelente y las Pastillas
La fabricación del propelente para el cohete empieza por seleccionar los elementos
químicos que se desean usar. Los requisitos para seleccionar estos pueden ser influidos
por conveniencia económica, volatilidad esperada de la reacción, acceso a herramientas
de trabajo necesarias entre otras condiciones. Los ingredientes para propelentes sólidos
suelen tomar dos roles dentro de la mezcla: El oxidante y combustible:
 Oxidante: Funciona como el pegamento del propelente. Se mezcla con los demás
ingredientes y permite que tomen forma de masa, la cual puede ser dado forma según
lo que los desarrolladores planeen.
75 - 236
 Combustible: Son la parte que le da al propelente su capacidad de combustión al
momento que se exponen a una chispa.
Teniendo en cuenta estos roles las mezclas de propelente se dividen de acuerdo al

método en que estos son moldeados en forma de las pastillas:
 Por Frio: Son mezclas que se moldean sin necesidad de aplicar calor para que sus
ingredientes puedan ser dados forma. El oxidante usualmente viene en forma de
resina que puede solidificarse tras mezclarse con los demás ingredientes.
 Por Calor: Son mezclas que necesitan de calor para poder ser moldeados juntos. El
oxidante necesita ser derretido para llegar a un estado donde se pueda mezclar con
el combustible y solidificarse en la forma deseada.
Tras haber definido los ingredientes, se necesita todos deben estar en polvo, a excepción
de los usados para el oxidante de ser necesario. Para asegurarse que no haya grumos
en la mezcla, tras juntar los ingredientes se los introduce en un molino de bolas para
triturar y desmenuzar todo. Este aparato es básicamente un barril lleno de pequeñas
bolas de cerámica que es colocado horizontalmente sobre un motor que hace que este
gire horizontalmente, de forma que las bolas pulverizan los grumos dentro de la mezcla.
La mezcla de polvo es luego, apartada en porciones con la masa deseada para la pastilla.
Si es fabricada con calor, estas porciones son colocadas una a una en una olla para ser
cocinada. Esta es usualmente puesta en un recipiente con aceite hirviendo, se usa aceite
a motor para esta tarea debido a que es fácil mantener este a una temperatura específica,
lo que evita riesgo de que el calor no se esparza uniformemente en la olla. La mezcla se
remueve constantemente para que se cocine bien y no se pegue a las paredes de la olla
hasta que la mezcla llega a una temperatura de alrededor de los 160 °C.
Una vez lista, la mezcla es colocada en moldes especiales para las pastillas. Dichos
moldes fueron previamente preparados con una capa de aceite cubriendo toda superficie
que entre en contacto con el propelente para facilitar su extracción del mismo. Se debe
tener cuidado de introducir toda la cantidad posible de masa antes de que esta se
endurezca y sea malgastada. Al final, cuando esta termino de solidificarse, se lo saca del
76 - 236
molde manualmente con herramientas distintas como martillo y cincel. Se repite este
mismo proceso para cada porción de la mezcla. Las pastillas elaboradas no deben tener
ningún tipo de grieta o deformidad, y deben ser almacenadas en un ambiente seco sin
mucha exposición a la luz.
3.1.1.3. Construcción las piezas del motor de cohete
Los motores de las unidades de cohetes tienen diferentes componentes, los cuales se
listan a continuación:
 Cámara de Combustión: Es donde se almacena el combustible y dentro del cual se
lo enciende. Sus dimensiones dependen del número de pastillas que se planee que
empleara la unidad y el diámetro externo de estas.
 Tobera: Es una parte importante porque es donde salen los gases de combustión
liberados por la ignición del propelente a alta velocidad y enfrentando altas
temperaturas.
 Tapa de la Cámara de Combustión: Como su nombre indica, es la tapa que sella la
cámara de la salida opuesta a la tobera. Es la parte más sencilla del motor de cohete.
 Sistema de Ignición: Es el mecanismo que, como su nombre lo indica, inicia toda la
secuencia de lanzamiento de la unidad. Usualmente está compuesta por dos cables
extendiéndose dentro del cohete, aprovechando el agujero de las pastillas, hasta el
final de la cámara de combustión, donde se deposita una carga minúscula de pólvora.
Todas estas partes son las primeras en ser desarrolladas en el proceso de elaboración
de prototipos, no se puede diseñar las demás piezas si no se tiene los datos o la certeza
de veracidad de los mismos de las piezas más pequeñas. Se pueden fabricar con
distintas aleaciones de metales, según lo vean necesarios los desarrolladores.
Usualmente las piezas del motor deben ser comisionadas a una tornería, dando las
especificaciones del motor para elaborar la cámara de combustión, tobera y tapa. El
sistema de ignición es desarrollado por los desarrolladores mismos.
77 - 236
3.1.1.4. Pruebas de Validación en Banco de Pruebas
La primera prueba, la prueba en Banco de Pruebas se enfoca en medir el impulso del

motor desarrollado, que se puede medir gracias al mencionado “Banco de Pruebas”. Esta
es una maquina en forma de banco que posee una placa de presión sobre la cual se
ubica el motor cabeza abajo.
Para realizar la prueba, se enciende el motor y se espera a que termine de consumirse

el combustible. La placa del banco mide la presión generada por el motor de cohete
durante la combustión del propelente y envía los datos a una computadora con un
software grafica el empuje del motor en relación al tiempo que tarda en consumirse el
propelente.
Al terminar todo, el software genera una gráfica que recibe el nombre de “Curva de
Empuje”, que mide el empuje que tendrá el motor durante el vuelo. Es con los datos
recuperados de esta prueba que se puede clasificar el motor según la clasificación
establecida para cohetes, además de que los desarrolladores son capaces de verificar
si el cohete es lo suficientemente potente para las metas del diseño.
Tabla 22: Experimentación Impulso ISP e Impulso Especifico
EXPERIMENTACIÓN EN CAMPO EXPERIMENTACIÓN EN CAMPO
ISP IMPULSO ESPECÍFICO
100 120,4
123 110,1
105,2 170
95,9 100,7
78 - 236
EXPERIMENTACIÓN EN CAMPO EXPERIMENTACIÓN EN CAMPO
ISP IMPULSO ESPECÍFICO
92,7 99,4
98,3 110,7
91,4 119,4
101,5 120,9
99,5 124,7
89,8 116,7
Para calcular el Impulso, la fórmula es la siguiente:
𝑘2−1
1 𝑅 𝑘2 𝑃𝑒 𝑘2
𝐼𝑒 = √2𝑇 ( ) ( ) [1 − ( ) ]
𝑔 𝑀 𝑘2 − 1 𝑃𝐶
Dentro de la cual R es el constante universal de gases, T es la temperatura de

combustión, M es el peso molecular, Pe y Pc son las presiones de exhauste y de la
cámara respectivamente y k2 es la relación de calores específicos de dos fases.
3.1.1.5. Planificación del Diseño de Fuselaje del Prototipo
Por otro lado se tiene el diseño del fuselaje o capa externa que tiene el cohete. Este
puede ser dividido en las siguientes partes para su diseño y desarrollo:
79 - 236
 Cámara de Motor: Es aquella parte del fuselaje que cubre la parte que almacena el
motor de la unidad, dentro de esta parte del cohete se puede emplear partes que
puedan guiar el cohete durante su vuelo, como aletas y otros componentes.
 Cámara de Carga: Esta es la parte media del cohete, que se encuentra hueca para
poder colocar la carga útil que fuese a cargar la unidad. Cabe mencionar que es
clave que se preste atención a esta parte porque su peso puede causar variaciones
al arco de vuelo.
 Ojiva de Cohete: Es la punta del cohete, que es la primera parte que enfrenta
resistencia del aire, razón por la cual tiene su característica forma de cono.
Esta es la parte de cohete que requiere menos trabajo porque no requiere mucho material
para fabricarse, al ser básicamente una carcasa hueca, que solo adquiere relevancia al
introducir el motor y la carga útil dentro del mismo. Sin embargo, el material en si, puede
ser difícil de conseguir, y necesariamente tiene que ser comisionado a una tornillera
externa al Programa Aeroespacial.
3.1.1.6. Pruebas de Validación del diseño del Prototipo
Por otro lado se tiene la prueba por túnel de viento, que busca medir como el fuselaje
externo creado para el cohete reacciona ante diferentes tipos de flujos de aire y si este
es capaz de reducir lo más posible la resistencia creada por el mismo. Para esto se
comprueba si el modelo de fuselaje tiene la resistencia de aire y fractura necesaria para
permanecer en vuelo.
3.1.1.7. Pruebas de Campo del Prototipo
Las pruebas en campo de la unidad involucran realizar el lanzamiento de una unidad en

un campo abierto, y medir los datos técnicos necesarios para evaluar el rendimiento del
cohete. Los datos a extraer incluyen entre otros:
 Velocidad Máxima
 Altura Máxima
 Tiempo Para Altura Máxima
80 - 236
Para realizar estas pruebas se tiene que buscar un terreno extenso y sin edificaciones,
preferiblemente con poco viento, en condiciones templadas y clima calmado.
Falencias del software de simulación
Como ejemplo de la vida real acerca de las deficiencias que existen en el software de
simulación disponible en la actualidad para el Programa Aeroespacial se puede
referenciar las pruebas realizadas para el diseño de un prototipo de cohete B1M1. El
desarrollo del cohete B1M1 fue llevado a cabo utilizando software de simulación
SpaceCAD y RockSim. Mediante estas herramientas se pudo determinar distintos datos
que sean de interés para el desarrollador. Una vez el diseño del modelo virtual hubiese
llegado a satisfacer las necesidades del desarrollador, se empezó a elaborar un prototipo
físico para corroborar su rendimiento en la realidad. Dicho modelo físico atravesó todo el
proceso descrito anteriormente. (Programa aeroespacial, 2016).
Pero sin embargo, a medida que se fueron desarrollando las pruebas de Banco de
Pruebas fueron surgiendo errores en el diseño que fueron obligando al equipo de
desarrolladores a retroceder para retroceder para rehacer algunos pasos o volver a
realizar comisiones con diferentes especificaciones a la tornillera. Un ejemplo de la
falencia ocasionada por el software es mostrado en la figura 4. En este caso, se
comparan dos Curvas de Empuje, una sacada con RockSim y la otra con el Banco de
Pruebas. Los datos obtenidos con el software muestran que el empuje llega hasta
alrededor de los 465 N, mientras que los datos de la prueba indican que el empuje llega
hasta la medida de los 1000 N, cosa que deja casi 500 N de falencia por parte del
software. (Programa aeroespacial, 2016).
Otras pruebas arrojan datos similares, incluyendo las pruebas de campo. Entre las
causas para este tipo de falencias en el software de simulación, se puede apuntar a las
siguientes causas:
 Cálculos de Propelente con datos desactualizados: Los datos termo dinámicos son
clave para determinar el rendimiento del propelente. Es con estos datos que se
determina indicios clave para el diseño, como la temperatura máxima de la cámara
81 - 236
de combustión después de la ignición. Estos datos son obtenidos mediante
instituciones como la NIST o el Instituto Nacional de Estándares y Tecnología, entidad
que publica las tablas de termo dinámicas de JANAF. Son con estos datos que
muchos software basan sus funciones. Sin embargo NIST ha lanzado muchas
ediciones nuevas desde la elaboración de estos programas. Actualmente existen
programas que aun utilizan datos que fueron establecidos en ediciones de alrededor
de 1974. Año desde el cual muchos de los datos que menciona han sido actualizados.
 Software inadecuado para las condiciones atmosféricas: Entre los factores que
afectan al cohete, condiciones climáticas como viento y lluvia son los obstáculos más
comunes a enfrentar en el diseño de un prototipo. Bolivia está ubicada en la zona
central de América del Sur, con un área de 1.098.581 kilómetros cuadrados y
extendiéndose desde los Andes Centrales a través de parte del Gran Chaco hasta el
Amazonas. El clima de Bolivia varía drásticamente de una región a otra, desde los
trópicos en los llanos orientales hasta un clima polar en los Andes occidentales. Los
veranos son cálidos, húmedos en el este y secos en el oeste, con lluvias que a
menudo modifican temperaturas, humedad, vientos, presión atmosférica y
evaporación, produciendo climas muy diferentes en diferentes áreas. Los inviernos
son muy fríos en el oeste, y nieva en las cordilleras, mientras que en las regiones
occidentales, los días ventosos son más comunes. El otoño es seco en las regiones
no tropicales.
Tabla 23: Condiciones ambientales en Bolivia.
ALTURA SOBRE EL CONDICIONES

UBICACIÓN
NIVEL DEL MAR CLIMÁTICAS
Cochabamba 2570 m Semi Árido
La Paz 3,640 m Oceánico
82 - 236
ALTURA SOBRE EL CONDICIONES
UBICACIÓN
NIVEL DEL MAR CLIMÁTICAS
Santa Cruz de la Sierra 416 m Sabana Tropical
Todo esto puede afectar significativamente al cohete, sobretodo cambios en el clima.

Viento y lluvia puede llegar a generar más resistencia de la esperada en un día con
condiciones apacibles, cosa que podría reducir el tiempo de vuelo y velocidad del cohete,
al viajar este en contra el flujo de este. Además se la diferente altura a nivel del mar es
capaz de causar problemas, debido a que una altura diferente también puede significar
una diferente densidad del aire, presión del aire y demás datos que afectan el vuelo de
la unidad.
Definición del sistema propuesto
3.1.3.1. Requerimientos y estimaciones sobre el sistema a desarrollar
El simulador de sistema de propulsión de cohetes, debe ser capaz de tomar en cuenta

ciertos aspectos funcionales necesarios para facilitar el proceso de desarrollo de
prototipos:
 Multiplataforma: El software a desarrollar debe ser capaz de correr sin dificultades

significativas en Windows, Linux y Mac, de modo que no afecte negativamente su
rendimiento.
 Interfaz Rediseñada: La interfaz del software debe tener en cuenta que los usuarios
que lo empleen seguramente harán uso del idioma español solo una cantidad
reducida sabe usar el inglés.
 Margen de Error Menor o igual a 5%: Los resultados obtenidos con el software se
espera que no sobrepasen el rango del 5% de error.
83 - 236
3.1.3.2. Definición de Variables
a) Variables de Entrada
Tabla 24: Variables de Entrada.
VARIABLES DE ENTRADA
Datos para el Propelente
Mp Masa del propelente a usar
T Temperatura de la Cámara
Pe Presión de Exhauste
Pc Presión de Cámara
Datos de Grano
De Diámetro Externo
Di Diámetro Interno
Ls Longitud de Segmento
Cs Cantidad de Segmentos
Datos del Motor
84 - 236
Dmi Diámetro interno del motor
Lm Largo del Motor
Rei Relación inicial de área de quemado
K Relación de calor especifico, mezcla
k2 Relación de calor especifico, dos fases
Eg Erosión de la garganta
Datos de Presión
Ec Eficiencia de la combustión
Datos de Rendimiento
Et Eficiencia de la tobera
Rt Relación de expansión de la Tobera
Datos de Fuselaje
Ltb Longitud de Fuselaje
Dtb Diámetro Externo de Fuselaje
85 - 236
Estb Espesor de tubo
b) Variables de Proceso
Tabla 25: Variables de Proceso.
VARIABLES DE PROCESO
El estado de elemento
E Entalpia
Cp Calor especifico
Dn Densidad del elemento
Ce cambio de entalpia
Tr Temperatura de Rango
E Espesor del material
Dm Densidad del Material
P Presión del aire
86 - 236
VARIABLES DE PROCESO
Da Densidad del Aire
Ta Temperatura del Aire
c) Variables de Salida
Tabla 26: Variables de Salida.
VARIABLES DE SALIDA
Den Densidad Ideal
Vc Velocidad Característica
Pv CP/CV de la cámara
Ie Impulso especifico
M Peso Molecular
Tc Temperatura de Cámara
Lgr Largo del Grano
Vg Volumen del Grano
87 - 236
VARIABLES DE SALIDA
Drg Densidad real del Grano
Mg Masa total del Grano
Ai Area initial de End Burning y Core Burning
Aeq Área Exterior de Quemado
Atq Área Total de Quemado inicial
Vc Volumen de la Cámara
Fv Factor de llenado Volumétrico
Ag Área inicial de Garganta
Dif Diámetro inicial y final de garganta
Rq Relación de área de quemado
Ast Área de salida de la tobera
Dst Diámetro de salida de la tobera
Rep Relación de expansión óptima para la presión máxima
Reo Relación de expansión optima promedio
88 - 236
VARIABLES DE SALIDA
Ft Fracción de tela
Cm Coeficiente de empuje máximo
Em Empuje máximo
It Impulso total
Ies Impulso especifico suministrado
C Clasificación del motor
Vmax Velocidad Máxima
Tem Tiempo de Empuje
A* Aceleración
Amax Altura máxima
Mpro Masa promedio
T_max Tiempo para altura máxima
Re Constante Especifica de los Gases
Tcr Temperatura de Combustible Real
89 - 236
VARIABLES DE SALIDA
Rs Resistencia a Fracturas
Pu Presión de rotura
3.1.3.3. Elaboración del modelo propuesto para el sistema
Figura 12: Modelo propuesto del sistema.
90 - 236
FORMULACIÓN DE LOS MODELOS DE SIMULACIÓN PARA
REPRESENTAR LA IMPLEMENTACIÓN DE LOS DISEÑOS DE LOS
COHETES
Modelos Matemáticos
3.2.1.1. Modelo de motor de combustible sólido.
Como fue mencionado antes, el motor es lo primero que debe modelar el software. Debe
empezar desde el nivel más básico, la elaboración de la mezcla del propelente que
implementará, y debe llegar a comprobar tanto la efectividad del mismo así como si el
material del que está hecho el cohete pueda soportar la combustión del propelente
elaborado. Este modelo emplea las siguientes ecuaciones:
a) Modelado de Propelente
 Densidad Ideal
1
𝐷𝑒𝑛 =
𝑓𝑎 𝑓𝑛
+ ⋯ +
𝜌𝑎 𝜌𝑛
Donde:
𝑓𝑎 = Fracción de masa de compuesto reactante.
𝜌𝑎 = Densidad de compuesto reactante. (gr/m3).
 Impulso Especifico
𝑘2−1
1 𝑅 𝑘2 𝑃𝑒 𝑘2
𝐼𝑒 = √2𝑇𝑐 ( ) ( ) [1 − ( ) ]
𝑔 𝑀 𝑘2 − 1 𝑃𝐶
91 - 236
Donde:
𝑔 = Constante de gravedad. Valor de 9.806 m/Seg.
𝑇𝑐 = Temperatura de Cámara de Combustión. (K)
𝑅 = Constante Universal de Gases. Valor de 8314 J/Kmol-K.
𝑃𝑒 = Presión de exhausto. (atm)
𝑃𝐶 = Presión de Cámara (atm)
𝑀 = Peso molecular. (g/mol)
𝑘2 = Exponente isentrópico de la fase 2.
 Velocidad Característica
𝑅 ⁄𝑀 𝑇
𝑉𝑐 = 𝑘+1
√
2 𝑘−1
𝑘( )
𝑘+1
Donde:
𝑅 = Constante universal de gases.(J/kmol-K)
𝑀 = Peso molecular.(g/mol)
𝑇 = Temperatura de cámara. (K)
92 - 236
𝑘 = Exponente isentrópico de mezcla.
 Cp/Cv de Cámara
Donde:
𝐶𝑝𝑔𝑎𝑠 = Calor específico para los gases de la mezcla.
𝐶𝑝𝑚𝑒𝑧𝑐𝑙𝑎 = Calor específico para todos los componentes de la mezcla.
𝐶𝑝𝑠 = Calor específico de los elementos condensados de la mezcla.
Suma de los valores de calor específico de todos los componentes de la

𝐶𝑠 =
mezcla.
𝑘′ = Exponente isentrópico de los componentes gaseosos de la mezcla.
93 - 236
𝑋 = Fracción de masa de partículas en el escape.
𝑛 = Número de moles de componentes.
𝑅 = Constante universal de gases
𝑀𝑠 = Peso molecular de elementos condensados.
𝑀𝑇𝑜𝑡𝑎𝑙 = Masa total de la mezcla.
 Peso Molecular
𝑀𝑝
𝑀=
𝑁𝑀𝑔𝑎𝑠
Donde:
𝑀 = Peso molecular
𝑀𝑝 = Masa de mezcla
𝑁𝑀𝑔𝑎𝑠 = Número de moles de gas
 Temperatura de Llama Adiabática o Temperatura de Cámara de Combustión
∑ 𝑛𝑖 [𝐸 + ∆ℎ]𝑖 = ∑ 𝑛𝑒 [𝐸 + ∆ℎ]𝑒
𝑅 𝑃
94 - 236
Donde:
𝑛 = Número de moles
∆ℎ = Cambio de entalpia
𝐸 = Entalpia de formación
b) Modelado de grano o pastilla

 Volumen Total de Grano
𝜋
𝑉𝑔 = (𝐷𝑒 2 − 𝐷𝑖 2 )𝐿𝑠
4
Donde:
𝐷𝑒 = Diámetro externo (mm)
𝐷𝑖 = Diámetro interno (mm)
𝐿𝑠 = Longitud (mm)
 Largo total de Grano
𝐿𝑚𝑖 = 𝐿𝑠 ∗ 𝐶𝑠
Donde:
𝐶𝑠 = Número de segmentos
𝐿𝑠 = Longitud de segmentos (mm)
95 - 236
 Área inicial de "End burning"
𝐶𝑠 ∗ 2 ∗ 𝑒𝑖 ∗ π
𝐴𝑖𝑒 =
4 ∗ (𝐷𝑒 2 − 𝐷𝑖 2 )
Donde:
Cs = Cantidad de Segmentos
ei = Puntas o Coronas
De = Diámetro Externo
Di = Diámetro Interno
 Área inicial de "Core burning"
𝐴𝑖𝑐 = 𝐶𝑠 ∗ 𝑐𝑖 ∗ 𝜋 ∗ 𝐷𝑖 ∗ 𝐿𝑠
Donde:
Ci = Ánima o alma
Di = Diámetro Interno
Ls = Longitud de Segmentos
 Área exterior de Quemado inicial
𝐴𝑒𝑞 = 𝐶𝑠 ∗ 𝑜𝑠𝑖 ∗ 𝜋 ∗ 𝐷𝑒 ∗ 𝐿𝑠
96 - 236
Donde:
osi = Superficie expuesta
De = Diámetro Externo
Ls = Longitud de Segmentos
 Área total de quemado inicial
𝐴𝑡𝑞 = 𝐴𝑖𝑒 + 𝐴𝑖𝑐 + 𝐴𝑒𝑞
Donde:
Aie = Area inicial de “End Burning”
Aic = Area incial de “Core Burning”
Aeq = Area externa de Quemado Inicial
c) Modelado de Cámara de Combustión y Tobera

 Volumen de Cámara
𝜋
𝑉𝑐 = ∗ 𝐷𝑚𝑖 2 ∗ 𝐿𝑚𝑖
4
Donde:
Dmi = Diámetro interno de Cámara de Combustión
97 - 236
Lmi = Largo de Cámara de Combustión
 Área Inicial de Garganta
𝐴𝑏𝑜
𝐴𝑡𝑜 =
𝑅𝑒𝑖
Donde:
Abo = Área total de quemado inicial
Rei = Relación inicial de área de quemado /

superficie de la garganta de la tobera
 Diámetro inicial de Garganta
4 ∗ 𝐴𝑡𝑜
𝐷𝑖𝑔 = √
𝜋
Donde:
Ato = Área inicial de garganta
 Diámetro final de Garganta
4 ∗ 𝐴𝑡𝑜
𝐷𝑖𝑓 = √ + 𝐸𝑔
𝜋
Donde:
Ato = Área Inicial de garganta
98 - 236
Eg = Erosión en la garganta de la Tobera
d) Modelado de Presión de Cámara

 Constante específico de los gases
𝑅
𝑅𝑒 =
𝑀
Donde:
R = Constante Universal de los Gases
M = Peso específico molecular de los productos
 Temperatura de Combustión Real
𝑇𝑐𝑟 = 𝑇𝑐 ∗ 𝐸𝑐
Donde:
Tc = Temperatura de combustión ideal
Ec = Eficiencia en la Combustión
 Velocidad de salida de los Gases
𝑅 ⁄𝑀 𝑇
𝑉𝑐 = 𝑘+1
√
2 𝑘−1
𝑘( )
𝑘+1
99 - 236
Donde:
𝑅 = Constante universal de gases.(J/kmol-K)
𝑀 = Peso molecular.(g/mol)
𝑇 = Temperatura de cámara. (K)
𝑘 = Exponente isentrópico de mezcla.
e) Modelado de Rendimiento de Motor

 Diámetro de Salida de la Tobera
𝐴𝑡𝑜
𝐷𝑠𝑡 = √4 ∗
𝜋
Donde:
𝐴𝑡𝑜 = Constante universal de gases.(J/kmol-K)
 Fracción de Tela
1
𝐹𝑡 = 2 ∗ 𝑟𝑎𝑣𝑔 ∗ 𝑡𝑏𝑜𝑢𝑡 ∗
𝐷𝑒
Donde:
𝑟𝑎𝑣𝑔 = Constante universal de gases.(J/kmol-K)
𝑡𝑏𝑜𝑢𝑡 = Peso molecular.(g/mol)
100 - 236
𝐷𝑒 = Temperatura de cámara. (K)
 Impulso Específico Suministrado
𝑖𝑡
𝐼𝑒𝑠 = 9.806
𝑚𝑝
Donde:
𝑖𝑡 = Constante universal de gases.(J/kmol-K)
𝑀𝑝 = Peso molecular.(g/mol)
Modelo de las piezas de fuselaje para cohetes.
Una vez se logra comprobar la efectividad del diseño del motor y del propelente, se debe
elaborar el cuerpo del cohete, que a su vez está construido alrededor del mismo y
además debe llevar la carga que el usuario tenga en mente para el cohete. Debe incluir
las distintas piezas con las que el usuario pueda trabajar, así como su capacidad
aerodinámica en distintos flujos de aire. Las fórmulas que aplica este modelo son:
 Resistencia a Fracturas
𝐿𝑡𝑏
𝑅𝑠 =
𝐷𝑡𝑏
Donde:
𝐷tb = Diámetro externo
𝐿𝑡𝑏 = Longitud
101 - 236
 Presión de Rotura
𝑡 ∗ 𝐹𝑡𝑦
𝑃𝑢 = 2 ∗ ∗𝐵
𝐷0
𝐵 = 𝐶𝑎 ∗ 𝛽 4 + 𝐶𝑏 ∗ 𝛽 3 + 𝐶𝑐 ∗ 𝛽 2 + 𝐶𝑑 ∗ 𝛽 + 𝐶𝑒
𝐹𝑡𝑦
𝛽=
𝐹𝑡𝑢
Donde:
𝐵 = Factor de Rotura
𝐶𝑎, … , 𝐶𝑒 = Coeficientes polinomiales
𝐹𝑡𝑦 = Límite de espesor
𝐹𝑡𝑢 = Fuerza final
Modelo del ambiente y otros factores que afecten al cohete.
El software debe incluir la simulación de condiciones de clima que enfrente el cohete,

desde presión atmosférica hasta resistencia de viento, lluvia, entre otros. Especialmente
debe tomar en cuenta los flujos de aire de turbulencia o fluidos que afecten al cohete e
interactúan con el diseño aerodinámico establecido. Las fórmulas para el ambiente y el
vuelo, incluyen:
 Velocidad máxima
𝐴𝑙𝑡𝐴𝑔𝑜𝑡𝑒
𝑉𝑀𝑎𝑥 = √2 ∗ ∗ (𝐹 − 𝑀𝑎𝑠𝑎𝑉𝑢𝑒𝑙𝑜 ∗ 𝑔)
𝑀𝑎𝑠𝑎𝑉𝑢𝑒𝑙𝑜
102 - 236
1 𝐹
𝐴𝑙𝑡𝐴𝑔𝑜𝑡𝑒 = ∗( − 𝑔) ∗ 𝑡 2
2 𝑀𝑎𝑠𝑎𝑉𝑢𝑒𝑙𝑜
𝑀𝑎𝑠𝑎𝑐𝑜ℎ𝑒𝑡𝑒 + 𝑀𝑎𝑠𝑎𝑝𝑟𝑜𝑝𝑒𝑙𝑒𝑛𝑡𝑒
𝑀𝑎𝑠𝑎𝑉𝑢𝑒𝑙𝑜 =
2
Donde:
𝐴𝑙𝑡𝐴𝑔𝑜𝑡𝑒 = Altura de agote (m)
𝐹 = Empuje promedio (N)
𝑀𝑎𝑠𝑎𝑉𝑢𝑒𝑙𝑜 = Masa promedio de cohete en vuelo (kg)
𝑔 = Gravedad. Valor de 9.808.
𝑡 = Tiempo de empuje (seg)
𝑀𝑎𝑠𝑎𝑐𝑜ℎ𝑒𝑡𝑒 = Masa de cohete si propelente (kg)
𝑀𝑎𝑠𝑎𝑝𝑟𝑜𝑝𝑒𝑙𝑒𝑛𝑡𝑒 = Masa de propelente (kg)
 Altura máxima
𝐴𝑙𝑡𝐴𝑔𝑜𝑡𝑒
𝐴𝑙𝑡𝑀𝑎𝑥 =𝐹∗
𝑔
Donde:
𝐴𝑙𝑡𝑀𝑎𝑥 = Altura máxima (m)
103 - 236
 Aceleración
𝐹
𝐴𝑐 = −𝑔
Donde:
𝐴𝑐 = Aceleración (m/s2)
 Tiempo para altura máxima
𝐴𝑙𝑡𝑀𝑎𝑥 − 𝐴𝑙𝑡𝐴𝑔𝑜𝑡𝑒
𝑇𝐴𝑙𝑡𝑀𝑎𝑥 = 𝑡 + √2 ∗
𝑔
Donde:
𝑇𝐴𝑙𝑡𝑀𝑎𝑥 = Tiempo para altura máxima (seg)
𝑡 = Tiempo de empuje (seg)
104 - 236
𝐴𝑙𝑡𝑀𝑎𝑥 = Altura máxima (m)
 Tiempo de empuje
𝑖𝑡
𝑡=
𝐹
Donde:
it = Impulso Total
F = Empuje Promedio
Colección de datos
Para realizar todos estos procesos y cálculos, se debe almacenar una serie de datos
estadísticos en una base de datos, base de datos. Estos datos deben incluir elementos
como:
 Datos de tablas termodinámicas para cálculos de la cámara de combustión

 Materiales de construcción para el fuselaje
 Datos particulares acerca de los ingredientes de la mezcla
 Datos particulares de los posibles productos de una reacción química
Entre otros tipos de datos de información que podrían ser útiles para el diseño del
prototipo.
105 - 236
3.2.4.1. Datos de Variables
Tabla 27: Datos de Variables de Entrada
Datos para el Propelente Descripción
Mp Masa del propelente a usar Densidad ideal (Den)
T Temperatura de la Cámara Temperatura de Cámara
Pe Presión de Exhauste Impulso Especifico
Pc Presión de Cámara Impulso Especifico
Datos de Grano
De Diámetro Externo Volumen de Grano
Di Diámetro Interno Volumen de Grano
Ls Longitud de Segmento Largo de Grano
Cs Cantidad de Segmentos Largo de Grano
Datos del Motor
Dmi Diámetro interno del motor Velocidad característica
106 - 236
Lm Largo del Motor Velocidad característica
Rei Relación inicial de área de quemado Área inicial de la garganta
K Relación de calor especifico, mezcla Velocidad característica
k2 Relación de calor especifico, dos fases Velocidad característica
Diámetro inicia y final de

Eg Erosión de la garganta la garganta
Datos de Presión
Temperatura de
Ec Eficiencia de la combustión combustión real
Datos de Rendimiento
Coeficiente de empuje
Et Eficiencia de la tobera
Área de salida de la
Rt Relación de expansión de la Tobera tobera
Datos de Fuselaje
Ltb Longitud de Fuselaje Resistencia de fractura
107 - 236
Resistencia de fractura
Dtb Diámetro Externo de Fuselaje Presión de rotura
Presión de rotura
Estb Espesor de tubo
Tabla 28: Datos de Variables de Salida.
VARIABLES DE SALIDA DESCRIPCIÓN
Comparativa para la
Den Densidad Ideal
eficiencia
Velocidad a que se
Vc Velocidad Característica
liberan los gases
Relación de calores
Pv CP/CV de la cámara
específicos
Medir el potencial del

Ie Impulso especifico
rendimiento
Masa de una compuesto

M Peso Molecular
químico
108 - 236
Material de fabricación
Tc Temperatura de Cámara
de fuselaje
Lgr Largo del Grano Cantidad de segmentos
Vg Volumen del Grano Volumen de pastilla
Comparativa para la
Drg Densidad real del Grano
eficiencia
Mg Masa total del Grano Volumen de pastilla
Ai Area initial de End Burning y Core Burning Datos de la garganta
Aeq Área Exterior de Quemado Cantidad de segmentos
Área expuesta a los

Atq Área Total de Quemado inicial
gases
Capacidad de pastillas
Vc Volumen de la Cámara
que aloja a pastillas

Ag Área inicial de Garganta
gases
Dif Diámetro inicial y final de garganta Expulsión de los gases
109 - 236
Relacion entre la área de

Rq Relación de área de quemado quemado y área de la
garganta

Ast Área de salida de la tobera
gases
Dst Diámetro de salida de la tobera Expulsión de los gases
Relación de expansión óptima para la presión Relación de expansión

Rep
máxima de la tobera
Relación de expansión
Reo Relación de expansión optima promedio
de la tobera
Relación entre radio y el

Ft Fracción de tela
quemado de propelente
Cm Coeficiente de empuje máximo Eficiencia de la tobera
Máximo que alcance del

Em Empuje máximo
empuje del motor
Suma generado durante

It Impulso total
el vuelo
Ies Impulso especifico suministrado Impulso de propelente
110 - 236
Categoría de motor
C Clasificación del motor
según norma americana
Velocidad a la q alcanza
Vmax Velocidad Máxima
Tiempo de consumido de
Tem Tiempo de Empuje
propelente
Reacción de unidad para

A* Aceleración
salir
Altura que alcanza la

Amax Altura máxima
unidad
Mpro Masa promedio Masa de la unidad
Tiempo q tarda en
T_max Tiempo para altura máxima
alcanzar la altura max
Valor de constante de los

Re Constante Especifica de los Gases
gases
Tcr Temperatura de Combustible Real Eficiencia de combustión
111 - 236
Valor de fractura del

Rs Resistencia a Fracturas
material de la unidad
Presión de rotura de
Pu Presión de rotura
material de la unidad
Tabla 29: Datos de Impulso Específico
IMPULSO
PROPELENTE TEMPERATURA ISP
ESPECÍFICO
KNSU 766,85 132,3 104,4
KNSU 819,85 154,2 114,9
KNSU 897,85 142,2 111,2
KNSU 840,85 132,9 102,9
KNSU 826,85 136,2 108,7
KNSU 807,85 136,9 106,9
KNSU 723,85 137,3 108,9
112 - 236
IMPULSO
PROPELENTE TEMPERATURA ISP
ESPECÍFICO
KNSU 985,85 139,3 108,4
KNSU 1346,85 136,6 107,5
KNSU 711,85 135 104,7
KNSU 845,2 143,11 100,2
KNSU 928,7 139,4 105,4
IMPLEMENTACIÓN DE LOS MODELOS DE LOS COHETES BASÁNDOSE

EN LA INFORMACIÓN RECOPILADA
Para la ejecución de este proyecto se eligió una metodología de gestión, a continuación

un análisis de las opciones seleccionadas.
Metodología de desarrollo de software para el proyecto.
Para poder seleccionar que metodología de desarrollo emplear en el proyecto, se

procede a repasar las diferentes ventajas y desventajas que cada uno de estos trae
consigo. A continuación se detalla una lista de los mismos por cada opción de
metodología de las que se puede escoger (Scrum, XP, RAD).
113 - 236
Tabla 30: Comparación de ventajas de modelos de metodología ágil.
SCRUM XP RAD
Uso efectivo de tiempo y Permite ahorrar costos y El tiempo requerido para

dinero. tiempo en la realización del desarrollar el software se
proyecto. reduce
Los grandes proyectos se Se centra en la entrega de Todos los prototipos de

dividen en Sprints productos finales. software producidos
fácilmente manejables. pueden guardarse
Los avances son No emplea mucha Es más fácil para un

codificados y probados en documentación. gerente de proyecto ser
la revisión. preciso en los costos del
proyecto.
El equipo tiene una Emplea un código sencillo Cualquier componente del

impresión más clara del de entender. almacena está probado
avance.
Toma en cuenta la Los requisitos de gestión

retroalimentación de -- de proyectos se recogen de
interesados. manera dinámica.
114 - 236
SCRUM XP RAD
Los Sprints cortos permiten Existe una fuerte y continua

cambios más fácilmente. -- participación del
patrocinador.
El esfuerzo individual es Promueve una mejor

--
visible. documentación.
Tabla 31: Comparación de desventajas de modelos de metodología ágil.
SCRUM XP RAD
Carece de una fecha de Se centra en el código en Este método puede no ser

finalización definitiva lugar de en el diseño. útil para proyectos
grandes, únicos o muy
complejos
Las posibilidades de La documentación de No puede tener éxito si el

fracaso son altas si los defectos no siempre es equipo no está
miembros del equipo no buena suficientemente motivado.
están comprometidos.
La implementación en .No mide el aseguramiento El éxito depende de las

equipos grandes es de la calidad del código. habilidades técnicas de los
complicada. desarrolladores.
115 - 236
SCRUM XP RAD
Las reuniones diarias El equipo puede ignorar

--
pueden ser frustrantes. los parámetros de calidad.
Si un miembro del equipo

deja el proyecto puede -- --
tener un impacto negativo.
La calidad es difícil de
-- --
verificar.
Después de analizar las opciones disponibles, se escogió planear el avance del proyecto
mediante metodología ágil bajo los siguientes puntos:
 El proyecto será desarrollado bajo el modelo Scrum. Scrum fue elegida debido a que
para desarrollar de manera apropiada los modelos, se tiene que ir elaborando desde
los componentes más básicos hasta los más complejos, por ejemplo si el cálculo de
la temperatura de la cámara de combustión esta erróneo, puede que el material usado
para fabricar la cámara de combustión no sea capaz de soportar el calor y llegue
incluso a explotar. Para evitar esto se realizaran entregas regulares sobre las distintas
partes del software que este en desarrollo.
 El desarrollo rápido de aplicaciones, otra de las opciones de metodología
consideradas, no es apropiado para este punto debido a que se necesita enfocarse a
que el prototipo funcione apropiadamente, en lugar de lanzar la mayor cantidad
posible de entregas.
 Por otro lado los requerimientos impuestos del cliente están bien definidos y no varían
en ningún nivel considerable desde la entrega inicial de los mismos, lo que coloca a
116 - 236
Scrum por encima de la Programación Extrema, otra de las metodologías
consideradas.
Para la realización e implementación de Scrum dentro del proyecto, se decidió asignar

los roles necesarios de la siguiente manera:
Tabla 32: Asignación de roles de Scrum.
N° ROL DESCRIPCIÓN ASIGNACIÓN
Conoce la lógica del proyecto,

sus requisitos y otros detalles
 Ing. Harold
1 Product Owner particulares. Sirve de Mediador
Pérez Pozo
entre el equipo de trabajo y el
cliente.
Se encarga de hacer cumplir el

 Cesar Augusto
2 Scrum Master proceso de la metodología
Calvi Lujan
SCRUM.
 Cesar Augusto
Miembros del
Responsable de la construcción Calvi Lujan
3 equipo de
y calidad del proyecto.  Jacobo Ángel
desarrollo
Nogales Ortiz
Para facilitar la implementación y manejo de las historias de usuario, se empleó una

herramienta para ayudar a este proceso, conocido como Trello, una aplicación de gestión
de proyectos basada en la web hecha originalmente por Fog Creek Software en 2011.
Trello tiene una variedad de funciones y usos, incluyendo áreas como la gestión de
117 - 236
bienes raíces, gestión de proyectos de software, tablones de anuncios, planificación de
lecciones y gestión de casos de la oficina de abogados.
En este caso, se empleara para mantener un control de las distintas historias de usuario
a desarrollar para las entregas de software. Existen varias etapas en que se elige las
tecnologías de desarrollo para la implementación, incluyendo el lenguaje de
programación a usar, tomando en cuenta que el sistema debe ser multiplataforma.
Aquí la selección de tecnologías de desarrollo está en proceso, es donde se tiene las

historias que se dieron por terminado con la selección de tecnologías de desarrollo. Una
vez terminada esta etapa lo que sigue es empezar a codificar el módulo del motor de
combustible sólido este paso es uno de los más importantes y por lo cual se lo toma
en primer lugar a desarrollar lo más pronto posible.
Las historias de usuario fueron establecidas con apoyo de los miembros del Programa
Aeroespacial. Las historias que fueron definidas están listadas a continuación:
Tabla 33: Historias de Usuario
NÚMERO
SPRINT PRIORIDAD COMO NECESITO PARA
HISTORIA
Product Elaborar un Simular el

Owner modelo que desarrollo de
recree el prototipos
1 Media 1 proceso de desde el nivel
fabricación de más básico.
propelente
1 Media 2 Equipo Implementar Manejar los

tablas datos químicos
118 - 236
NÚMERO
HISTORIA
termodinámicas requeridos por

en los cálculos el cliente.
ejecutados por
el código.
Product Realizar con Garantizar la

Owner precisión todos calidad de los
los cálculos resultados.
1 Media 3
requeridos en la
fabricación del
propelente.
Product Elaborar un Garantizar que

Owner modelo para el motor
simular la actuará de
elaboración de manera
2 Alta 4
un motor de adecuada.
cohete en base
a datos del
propelente.
Usuario Incluir los Ofrecer una

distintos variedad amplia
2 Alta 5 materiales que de opciones de
se puedan material de
construcción.
119 - 236
NÚMERO
HISTORIA
utilizar para el
motor.
Product Recrear la Simular casos

Owner implementación en que se
de material necesita alentar
retardante y la combustión o
2 Media 6 protección a la evitar el
pastilla contacto directo
de las paredes
de la cámara
con la pastilla
Product Implementar Recrear el

Owner recreaciones de proceso de
todas las piezas ensamblado de
3 Alta 7 de fuselaje que la capa externa.
se puedan
necesitar en un
cohete.
Product Analizar y Garantizar la

Owner recrear el implementación
3 Alta 8 comportamiento de la capacidad
de los flujos de aerodinámica
aire sobre cada de las piezas.
120 - 236
NÚMERO
HISTORIA
pieza de
fuselaje.
Equipo Validar que el Simular las

fuselaje pruebas en
implementado túnel de viento
en la unidad, que se realizan
tenga en la realidad.
3 Media 9
capacidad
aerodinámica
mediante
evaluación de
los flujos de aire
Equipo Recrear los Los resultados

distintos climas tomen en
4 Alta 10 a los que se cuenta la
pueda enfrentar resistencia que
el cohete puedan ofrecer.
Equipo Implementar Recrear las

inteligencia distintas
artificial condiciones del
4 Media 11
ambiente que
enfrentaría el
cohete
121 - 236
NÚMERO
HISTORIA
Usuario Implementar Ilustrar el

gráficos 3D proceso de
elaboración y
4 Media 12
proporcionar
una vista previa
del prototipo.
Equipo Validar que los Garantizar la

resultados calidad de los
devueltos resultados
4 Media 13 tengan un finales.
margen de error
de cinco por
ciento.
Fuente: (Elaboración propia, 2017)
Tabla 34: Planificación de Sprint.
FECHA DE FECHA DE FECHA DE

SPRINT FUNCIONALIDAD
INICIO FINALIZACIÓN REVISION
Diseñar y codificar
la interfaz de
1 20-MAR-17 19-JUL-17 31-JUL-17
salida y entrada de
datos.
122 - 236
FECHA DE FECHA DE FECHA DE
SPRINT FUNCIONALIDAD
INICIO FINALIZACIÓN REVISION
Codificar el
módulo del motor
2 20-MAR-17 19-JUL-17 31-JUL-17
de combustible
sólido
Codificar el
módulo de las
3 30-JUN-17 23-JUL-17 31-JUL-17
piezas de
fuselaje.
Codificar el
módulo de las
4 30-JUN-17 30-JUL-17 31-JUL-17
condiciones del
ambiente,
Fuente: (Elaboración propia, 2017).
Tabla 35: Sprint e historias de usuario de cada objetivo.
NÚMERO DE
OBJETIVO SPRINT
HISTORIA
Diseñar y codificar la interfaz de salida y entrada 1

de datos. 1
2
123 - 236
NÚMERO DE
OBJETIVO SPRINT
HISTORIA
Codificar el módulo del motor de combustible 4

sólido
5
.
2
3
Codificar el módulo de las piezas de fuselaje. 7
3 8
Codificar el módulo de las condiciones del 10

ambiente,
4
11
12
13
3.3.1.1. Aplicación de Patrón de Arquitectura
La arquitectura escogida para el programa es el Modelo Vista Controlador o MVC, debido

a su diseño se enfoca en separar las responsabilidades o funciones dentro de la misma
124 - 236
aplicación. Es decir, es bastante fácil acceder a la parte del programa que se desee
modificar debido a que está dividido en tres partes que contienen procesos específicos
para el software. El MVP y el MVVM también tienen sus ventajas pero al ser menos
conocidos existe un mayor riesgo de cometer errores al tratar de aplicarlos, sin
mencionar que de todos MVC, es el que tiene una división más fácil de entender. El
patrón de arquitectura MVC es aplicado en el proyecto mediante la división del mismo en
las siguientes partes:
 Interface: Es la parte de la vista, aquí se manejan todas las funciones referentes a las
ventanas que usa el programa y la apariencia de estas.
 Procesos: Es el controlador, todas las funciones que realizan cálculos y otro tipo de
operaciones para el programa se encuentran en esta sección.
 Data: El modelo, aquí es donde se hace la conexión con la base de datos y se sacan
todos los datos de JANAF, entre otras fuentes necesarias para que corra el programa.
Todas estas se encuentran guardadas en diferentes directorios, desde los cuales se

puede importar sus funciones debido a que contienen un archivo “__init__.py” que
aunque esta en blanco, nos sirve para que Python los trate como si fueran paquetes o
módulos del mismo lenguaje, lo que permite llamarlos como si fueran otra librería
cualquiera. El programa será ejecutado desde un archivo “main.pyw” fuera de los tres
directorios que permitirá utilizar todas las funciones. En interface se tiene un archivo
“_interface.py”, donde se tienen guardadas todas las interfaces generadas con Qt
Designer:
 Interfaz de Fuselaje
 Interfaz de Vuelo
 Interfaz de Propelente
 Interfaz de Motor
 Interfaz de Tasa de Quemado
Cada una de estas interfazes puede ser llamada según se requieran en la ejecución del
programa. Tambien cuenta con el archivo “QtTools.py” que contiene funciones de apoyo,
125 - 236
es decir, funciones que crean un widget para una interfaz automáticamente. Por otro lado
en data, se tiene un archivo “_mongo.py”, que realiza todas las consultas con PyMongo.
Tabla 36: Implementación de MVC.
MODELO VISTA CONTROLADOR
“_mongo.py” hace las consultas a la base de datos, mientras que “_collections.py”, extrae
los datos de la misma y los guarda como atributos, haciendo las conversiones
necesarias. Por ejemplo si hay un dato de presión que se encuentre en unidades de PSI,
este es convertido a Pa, antes de ser guardado en “_collections.py”.
Selección de tecnologías de desarrollo para su implementación
Dentro de las etapas iniciales de este proyecto se tomaron en cuenta diferentes

lenguajes de programación y otro software adicional que pueda ayudar a lograr la mayor
eficiencia al ejecutar el código dentro de distintas plataformas. Durante las etapas de
planeamiento iniciales fue establecido que el software debe ser capaz de correr sin
problemas en Windows, Mac y Linux, en otras palabras, debe tener capacidad
multiplataforma. Con el fin de cumplir con este requisito, se escogió el lenguaje de
programación Python. El motivo detrás de escoger Python sobre otros lenguajes distintos
126 - 236
que también tienen capacidad multiplataforma, es que este lenguaje es mucho más
dinámico que otros más conocidos en el mercado. Python tiene librerías que ayudan a
desarrollar proyectos que implementan inteligencia artificial, como scikit-learn. Los
comandos de este además permiten reducir enormemente la cantidad de líneas de
código necesarias para escribir una función, reduciendo enormemente el tamaño del
archivo y su tiempo de ejecución. Además las librerías de Python tienen otras utilidades,
por ejemplo el modelado 3d de gráficos, que también será necesario para el software a
desarrollar. Como se señala en anteriores ocasiones, el proyecto necesita de modelado
3d, en especial para el diseño de la pastilla del propelente y el fuselaje del cohete. Es
con este motivo que se implementa la capacidad de las librerías de Python para esta
tarea. Comparado a otros lenguajes, esta capacidad es relativamente limitada, pero las
librearías son mucho más mutables de lo que uno esperaría. Existen diferentes
alternativas para esto, entre las que se encuentran OpenGL, Pandas3D y en cierta
capacidad Matplotlib. Para esto se planea utilizar principalmente la librería Panda3D y
modelos desarrollados con Blender para esta tarea. Blender es un software para
modelado 3d con compatibilidad con Python y es uno de los que tienen mayor calidad de
diseño para sus modelos. Por otro lado Pandas3D es una librería usada para la creación
de videojuegos por lo que tiene sus propios méritos y a diferencia de OpenGL que
comparte varios de sus atributos, es mucho más fácil de manejar e implementar dentro
del proyecto. A pesar de esto no se descarta OpenGL, debido a su posición como una
de las principales librerías disponibles para modelado en 3d. Por otro lado, el programa
necesita almacenar grandes cantidades de datos para llevar a cabo los distintos cálculos
termodinámicos para calcular el rendimiento del motor. Con este punto en mente, se
planea implementar la base de datos en MongoDB, más que todo para garantizar la
velocidad de respuesta del software y facilitar el ingreso de datos de las tablas de JANAF
y demás fuentes para implementarse en la ejecución del programa.
127 - 236
Desarrollo de Primer Sprint
3.3.3.1. Historias de Usuario
Tabla 37: Historia de Usuario #1
HISTORIA DE USUARIO #1
Prioridad Media Complejidad 3
Usuario Product Owner
Nombre de Historia Fabricación de Propelente
Descripción Como Product Owner necesito elaborar

un modelo que recree el proceso de
fabricación de propelente para simular el
desarrollo de prototipos desde el nivel
más básico.
Criterios de Aceptación Debe realizar todos los cálculos químicos

necesarios para poder simular la mezcla
de ingredientes.
Debe contar con una lista de los

ingredientes y productos de la combustión
posibles.
128 - 236
Usuario Equipo
Nombre de Historia Tablas Termodinámicas
Descripción Como equipo necesito implementar tablas

termodinámicas en los cálculos
ejecutados por el código para manejar los
datos químicos requeridos por el cliente.
Criterios de Aceptación Debe guardarse una tabla por cada

posible producto que pueda formarse
como resultado de la combustión de
propelente.
Se deben guardar datos como la

capacidad de calor, entalpia, temperatura
a la que corresponde y la diferencia de
entalpia entre dichas temperaturas.
129 - 236
Nombre de Historia Precisión de datos de propelente
Descripción Como Product Owner necesito realizar

con precisión todos los cálculos
requeridos en la fabricación del propelente
para garantizar la calidad de los
resultados.
Criterios de Aceptación Todos los resultados deben estar dentro

de los márgenes posibles o aceptables de
error
Los resultados deben seguir los patrones

esperados de los cálculos de los que se
producen.
130 - 236
3.3.3.2. Codificación de la interfaz de salida y entrada de datos.
Para el diseño de la interfaz de usuario, se utilizó el software Qt es un framework

multiplataforma que se utiliza para desarrollar software que utiliza interfaces de usuario.
Sin embargo también se pueden usar para desarrollar programas que no usen dichas
interfaces. Fue desarrollado como un software libre y de código abierto, donde participa
tanto la comunidad, como desarrolladores. Qt tiene compatibilidad con otros lenguajes
de programación, principalmente Python y C++. Se puede diseñar la interfaz mediante
Qt Designer, una herramienta de este software que permite diseñar visualmente el mismo
y después se lo puede importar como un script de Python o del lenguaje a elección del
usuario.
Figura 40: Interfaz de elaboración de propelente.
Fuente: Elaboración Propia.
131 - 236
La interfaz de elaboración de propelente que se muestra en la figura 19, tiene la tarea de
recibir los datos de entrada que incluyen el ingrediente a agregar a la mezcla y la masa
del mismo dentro de esta. Después permite visualizar los resultados obtenidos tras los
cálculos de rendimiento del propelente. Es decir la temperatura adiabática o de cámara,
impulso especifico, entre otros.
La interfaz de cálculo de grano por otro lado, busca realizar la parte referente a la pastilla
de propelente. Toma los resultados de la elaboración de propelente, que muestra en la
parte superior izquierda, como datos de entrada. Utiliza estos datos para calcular
diferentes datos como las dimensiones de la cámara de combustión, grano de la pastilla
y dimensiones de la tobera.
3.3.3.3. Elaboración de la Base de Datos
Para facilitar el acceso a los datos y por extensión la velocidad de reacción de nuestro
programa, se elabora la base de datos dentro de MongoDB bajo el nombre de
“simcohetes”. Dentro de esta base de datos se almacenan distintas colecciones de datos
que juegan un papel importante en la ejecución de los cálculos del programa:
 Tablap: Esta tabla, como su nombre parece indicar, contiene todos los datos que uno
esperaría de una tabla periódica, con todos y cada uno de los elementos existentes.
 Ingrediente: Contiene los datos de todos los posibles ingredientes solidos que puedan
usarse dentro de un propelente, así como algunos datos químicos que útiles para los
cálculos a realizar.
 Motores: Aquí se almacena la escala de motores que se usa para clasificarlos
mediante el empuje que estos generan. Se encuentra también adjunta como Anexo
K.
 Material: Contiene los datos de resistencia de los distintos materiales que puedan
usarse para la construcción del fuselaje.
 Jnflst: Contiene una lista o índice de todos los productos posibles para la reacción,
de entre los cuales se deben escoger los más adecuados según los ingredientes
usados.
132 - 236
 Jnftab: Esta tabla contiene los valores de la tabla termodinámica de cada compuesto
en Jnflst. Se puede ubicar los valores específicos de un compuesto mediante los
campos “Tabla” en Jnflst y “Nombre” en Jnftab.
Figura 14: Diagrama de base de datos
133 - 236
Tabla 41: Diccionario de datos
Campo Tipo de Dato Descripción
Ingrediente
_id Object Código de identificación del documento.
Entalpia Number Valor de entalpia de formación de cada reactante.
Números String Cadena de valores que guarda los coeficientes de

la fórmula del compuesto, separados por “;”.
Densidad Number Densidad del compuesto en condiciones estándar.
Nombre String Nombre en español del compuesto.
Elementos String Cadena de valores que guarda los símbolos

químicos de la fórmula del compuesto, separados
por “;”.
Jnflst
Números String Cadena que guarda los coeficientes de la formula

química, separados por “;”.
134 - 236
Nombre String Nombre en español del compuesto.
Formula String Formula química del compuesto
Estado String Cadena que guarda todos los valores de los

estados del producto, separados por “,”.
Tabla String Cadena que sirve para ubicar los valores

termodinámicos del compuesto dentro de “jnftab”,
dependiendo si este coincide con un valor en el
campo “Nombre”.
Elementos String Cadena que guarda los símbolos químicos de la

fórmula del compuesto.
Jnftab
Nombre String Cadena que ayuda a ubicar los valores

termodinámicos de un compuesto de “jnflst”
dependiendo de si su valor coincide con el campo
“Tabla”.
Tmp String Cadena que guarda las temperaturas de la tabla

termodinámica de un compuesto, separados por “;”.
135 - 236
Cp String Cadena que guarda los calores específicos de la
tabla termodinámica de un compuesto, separados
por “;”.
h_h String Cadena que guarda los valores de la diferencia de

entalpia de la tabla termodinámica de un
compuesto, separados por “;”.
Dh String Cadena que guarda las entalpias de la tabla

termodinámica de un compuesto, separados por “;”.
Tablap
Categoría String Tipo de grupo al que pertenece el elemento dentro

de la tabla periódica. (Ejm.: Halógenos)
Tipo String Tipo de metal al que pertenece el elemento. Puede

ser Metal, No metal y Metaloide.
Masa Number Masa atómica del elemento dentro de la tabla

periódica.
Estado String Estado de los elementos en condiciones normales.
NumAtomico Number Número atómico del elemento dentro de la tabla

periódica.
136 - 236
Carga String Cargas atómicas de los elementos, guardadas en
una cadena y separados por “;”.
Nombre String Nombre del elemento en español.
Símbolo String Símbolo químico del elemento en la tabla periódica.
Material
Nombre String Nombre del material en español.
Kc String Resistencia a fractura del material o factor crítico.
Of String Tensión de fluencia del material.
Esp String Espesor mínimo de material.
Rad String Radio mínimo de material para grieta.
Motores
Categoría String Símbolo de categoría dentro de la escala de

motores.
137 - 236
Min Number Valor mínimo de empuje para calificar a la categoría
de motor.
Max Number Valor máximo de empuje para calificar a la

categoría de motor.
3.3.3.4. Codificar el módulo del motor de combustible sólido.
a) Codificar el proceso para la elaboración de la mezcla del propelente
Para iniciar con el desarrollo y codificación de nuestro software, se enfoca primero en la

parte más simple del cohete, es decir el motor y su propelente. Se parte de la primera
fase, la interfaz para la mezcla de ingredientes que den por resultado un propelente que
se pueda usar como combustible. Para este propósito se tiene una lista de ingredientes
distintos que se pueden combinar según las necesidades del usuario.
Esta lista comprende de ingredientes como Nitrato de Potasio (KNO3) y sacarosa o

azúcar de mesa (C12H22O11). Con cada diferente ingrediente que se agrega a la mezcla
se necesita especificar además las diferentes masas de dichos ingredientes que se
introducen a la mezcla. La interfaz de usuario cuenta con una tabla que muestra los
ingredientes en uso para el propelente, junto con su masa en gramos y su porcentaje
dentro del propelente.
Una vez se tiene definida la lista de ingredientes para la mezcla, con sus respectivas
masas, se puede pasar a desarrollar los cálculos para la reacción química que tomaría
lugar al entrar en combustión. Los productos son definidos a partir de una lista de las
diferentes tablas termodinámicas almacenadas en la base de datos. Solo se emplean
como productos aquellos compuestos que cumplan con las siguientes condiciones:
 Deben estar compuesto solamente de elementos que estén presentes en los

ingredientes escogidos.
138 - 236
 Se debe escoger compuestos que estén en estado gaseoso, si no existe una tabla
del compuesto en dicho estado, se emplea un líquido.
Como resultado de la búsqueda se obtienen los siguientes resultados:
Tabla 42: Productos de la reacción.
ELEMENTO FÓRMULA ESTADO
Dióxido de Carbono CO2 Gas
Monóxido de Carbono CO Gas
Vapor de Agua H2O Gas
Hidrógeno H2 Gas
Nitrógeno N2 Gas
Carbonato de Potasio K2CO3 Liquido
Hidróxido de Potasio KOH Liquido
Esta sería específicamente una reacción exotérmica, donde los productos están
definidos a partir de los elementos presentes en los reactantes pero que como toda
reacción de combustión, deben tener a CO2 y H2O entre ellos en forma de gas. Para
llevar a cabo los cálculos necesarios para este motor se deben implementar las formulas
en la tabla 25.
139 - 236
Por ejemplo en una reacción de combustión de una mezcla entre Nitrato de Potasio y
Azúcar de Mesa, podría resultar en la siguiente fórmula de reacción química.
𝐶12 𝐻22 𝑂11 + 𝐾𝑁𝑂3 → 𝐶𝑂2 + 𝐶𝑂 + 𝐻2 𝑂 + 𝐻2 + 𝑁2 + 𝐾2 𝐶𝑂3 + 𝐾𝑂𝐻
Cabe destacar acá que la selección de productos posibles es la parte más complicada
del desarrollo de prototipos, debido a que es difícil definir todos los componentes que
puedan tomar parte en la reacción química. Los productos son seleccionados mediante
un proceso que verifica que compuestos de la base de datos cumplen una serie de
condiciones específicas.
Por ejemplo, los productos deben tener carga iónica neutra, los compuestos que
contengan solo elementos no metales deben venir en forma de gas, mientras que los
que contengan elementos metales deben ser compuestos condensados o líquidos. Como
es de esperarse un compuesto debe estar presente una sola vez en un determinado
estado de materia. En el caso de la fórmula de la reacción, los elementos están presentes
de la siguiente forma:
Tabla 43: Estados de compuestos de la reacción.
Sacarosa C12H22O11 Solido
Nitrato de Potasio KNO3 Solido
Dióxido de Carbono CO2 Gas
Monóxido de Carbono CO Gas
Vapor de Agua H2O Gas
140 - 236
Hidrógeno H2 Gas
Nitrógeno N2 Gas
Carbonato de Potasio K2CO3 Liquido
Hidróxido de Potasio KOH Liquido
Después de haber determinado la lista de los productos, el siguiente paso a desarrollar

es el de balanceo de la fórmula, de modo que los elementos de cada lado de la fórmula
tengan el mismo número de moléculas, mediante modificar los números de moles de
cada producto y reactante. La fórmula que se tiene como resultado tras el balanceo es
la siguiente:
𝐶12𝐻22𝑂11 + 6,288 𝐾𝑁𝑂3

→ 3,796 𝐶𝑂2 + 5,205 𝐶𝑂 + 7,794 𝐻2𝑂 + 3,065 𝐻2 + 3,143 𝑁2
+ 2,998 𝐾2𝐶𝑂3 + 0,274 𝐾𝑂𝐻
Donde el número de moles de átomos en los reactivos y productos se encuentra exhibido

en la tabla 25.
Tabla 38: Balanceo de reacción química
ELEMENTO REACTIVOS PRODUCTOS
C 12 12
141 - 236
ELEMENTO REACTIVOS PRODUCTOS
H 22 22
O 29,87 29,87
K 6,288 6,28
N 6,288 6,28
Una vez se obtiene el balanceo de la fórmula química, se puede empezar a calcular datos
como el peso molecular, número de moles, masa de producto y entre otros datos que
ayudarán más adelante.
Tabla 44: Datos de moles y masas
PESO NÚMERO FRACCIÓN MASA EN FRACCIÓN

MOLECULAR DE MOLES MOLAR SISTEMA DE MASA
CO2 44,01 3,796 0,145 167,062 0,171
CO 28,01 5,205 0,198 145,792 0,149
H2O 18,02 7,794 0,297 140,448 0,144
H2 2,02 3,065 0,117 6,191 0,063
N2 28,02 3,143 0,120 88,067 0,090
142 - 236
K2CO3 138,21 2,998 0,113 414,354 0,424
KOH 56,11 0,274 0,010 15,374 0,016
Total 26,275 1,0 977,288 1,0
Total de gases 23,003 0,877 547,56 0,56
Total de Comp.
3,272 0,123 429,728 0,44
Condensados
Para empezar a calcular los datos específicos que se quiere que se visualizan en el
programa como dato de salida se calcula datos como la Temperatura de la Llama
Adiabática que se encuentra en la cámara de combustión. La fórmula para calcular
dicho dato emplea las entalpias formación de los distintos productos y reactantes, que
se colocan en la fórmula 6 de la tabla 25.
Es aquí donde entra en juego una herramienta útil para calcular el resto de los datos: Las
tablas termodinámicas de JANAF, que contiene tablas para cada uno de los elementos
listados como producto, que pueden encontrarse en los Anexos D hasta J.
El primer paso para empezar a calcular la tempera es introducir las diferentes entalpias
de formación tanto como para reactivos como productos. Se reemplaza estos datos en
la fórmula junto con los moles del compuesto y el cambio de entalpia. Cabe mencionar
acá que el cambio de entalpia del lado de los reactivos es igual a cero excepto por
situaciones particulares. Esto deja los cambios de entalpia del lado de los productos
como los únicos interrogantes:
143 - 236
1 (−2222,10 + 0) + 6,288(−494,63 + 0)
= 3,796(−393,52 + 𝛥ℎ𝐶𝑂2) + 5,205(−110,53 + 𝛥ℎ𝐶𝑂)
+ 7,794(−241,83 + 𝛥ℎ𝐻2𝑂) + 3,065(0 + 𝛥ℎ𝐻2) + 3,143 (0 + 𝛥ℎ𝑁2)
+ 2,998 (−1150,18 + 𝛥ℎ𝐾2𝐶𝑂3) + 0,274 (−424,72 + 𝛥ℎ𝐾𝑂𝐻)
Tras haber despejado las incógnitas, queda la formula siguiente:
2186,2 = 3,796 ∗ 𝛥ℎ𝐶𝑂2 + 5,205 ∗ 𝛥ℎ𝐶𝑂 + 7,794 ∗ 𝛥ℎ𝐻2𝑂 + 3,065 ∗ 𝛥ℎ𝐻2

+ 3,143 ∗ 𝛥ℎ𝑁2 + 2,998 ∗ 𝛥ℎ𝐾2𝐶𝑂3 + 0,274 ∗ 𝛥ℎ𝐾𝑂𝐻
El resultado de los datos del lado de los reactivos devuelve un número que se toma como
punto de referencia para encontrar la temperatura. Se recorre cada fila de las tablas de
JANAF correspondientes para cada compuesto, probando los cambios de entalpia dentro
de la fórmula, y se compara el resultado con el de los reactivos.
Hasta que se llegue a encontrar un caso en el que el valor entre dos filas forma un rango
en el que nuestro dato de referencia encaja.
Por ejemplo se tiene 2186,2 como resultado de la ecuación, donde las entalpias de 1700
K y 1800 K retorna como resultado 2114,5 y 2280,6 respectivamente. Lo que significa
que la temperatura que se está buscando se encuentra entre 1700 K y 1800 K.
Tabla 45: Comparación con datos de JANAF
T CO2 CO H2O H2 N2 K2CO3 KOH
1700 K 73,480 45,945 57,758 42,835 45,429 280,275 116,505
1800 K 79,431 49,526 62,693 46,169 48,978 301,195 124,815
3,796 (73,480) + 5,205 (45,945) + 7,905 (57,758) + 3,065 (42,835)

+ 3,143 (45,429) + 2,998 (280,275) + 0,274 (116,505) = 2114,5
144 - 236
3,796 (79,431) + 5,205 (49,526) + 7,794 (62,693) + 3,065 (46,169)
+ 3,143 (48,978) + 2,998 (301,195) + 0,274 (124,815) = 2280,6
Una vez que se tiene una idea de en qué rango se encuentra la temperatura ahora solo
es cuestión de sacar su número exacto, cosa que es posible mediante interpolación
lineal:
2186,2 − 2114,5
𝑇𝐴𝐹𝑇 = (1800 − 1700) + 1700 = 1743 𝐾
2280,6 − 2114,5
De esta forma se puede decir a ciencia cierta que la temperatura de la cámara de

combustión es 1743 K.
Tras sacar la temperatura, se procede a empezar a calcular otros datos, usando el calor
especifico de cada uno de los elementos y calcular el valor para el producto en su
totalidad y tomando en cuenta solo los elementos gases. Por ejemplo:
 Densidad ideal
1 𝑔𝑟
𝜌𝑃 = = 1.889
0.65 0.35 𝑐𝑚3
+
2.123 1.569
 Impulso Especifico
1.044−1
1 8314 1.044 68.046 1.044
𝐼𝑠𝑝 = √2(1720) ( )( ) [1 − ( ) ] = 166 𝑆𝑒𝑔𝑠.
9.806 41.98 1.044 − 1 1
 Velocidad Característica
8314⁄41.98 ∗ 1720 𝑀
𝑐∗ = 1.133+1 = 919
√ 𝑆𝑒𝑔𝑠
2 1.133−1
1.133 (1.133 + 1)
145 - 236
a) Codificación del proceso de cálculo del “grano” del propelente
Sin importar la composición del propelente, todos son procesados en una forma
geométrica similar, a la que se denomina como “grano” de propelente, aunque también
reciben el nombre de pastilla de propelente, la apariencia que tienen estos. Como regla,
los granos propelentes son de forma cilíndrica para encajar perfectamente dentro del
motor cohete. El grano puede consistir de un solo segmento o puede consistir de varios
segmentos. Se suele dejar un agujero en el centro, que lo atraviesa de un extremo a otro,
dentro del cual se realizara la combustión del propelente de adentro hacia afuera.
Dependiendo de la elección del desarrollador, se le puede dar distintas formas a este
agujero o núcleo. Cabe destacar que la forma de este llega a afectar directamente al
impulso que se mide dentro de las pruebas de Banco de Pruebas.
Figura 15: Forma tradicional del grano del propelente.
El cálculo de la pastilla se caracteriza por ser básicamente cálculos geométricos, como

por ejemplo el volumen, que se puede fácilmente calcular con solo tres datos de entrada:
Diámetro externo, diámetro interno y longitud. Después se aplica la fórmula de volumen
de cilindro al grano y se le resta el volumen del núcleo, de la que después es posible
sacar la densidad real del grano.
146 - 236
Figura 16: Pastillas terminadas.
3.3.3.5. Patrón de Arquitectura
Tal como se citó en la página 131, el modelo MVC es aplicado para este caso. Dentro el
patrón de arquitectura MVC, todas las funciones del controlador son manejadas por el
archivo “_propcess.py”, que actúa como un cuello de botella y permite el acceso a las
demás funciones y clases que se encuentren almacenadas en esta unidad.
147 - 236
Cada otro archivo dentro del directorio “Procesos” contiene las funciones usadas para
realizar los cálculos de una etapa del software. En este caso, los archivos “QBalance.py”
y “CGrano.py” contienen las funciones para la elaboración de propelente y las pastillas
para el motor.
3.3.3.6. Pruebas para Primer Sprint
Tabla 47: Pruebas funcionales del primer sprint #1
PRIMER SPRINT
HISTORIA DE USUARIO #1 – CASO DE PRUEBA #1
Titulo Verificar el correcto procedimiento para la

fabricación de propelentes
Pre-requisitos Haber declarado terminado de elaborar

todas las funciones necesarias para la
elaboración de propelente, tomando en
cuenta los conocimientos químicos
apropiados.
Haber creado los medios de salida de

datos necesarios para verificar que todos
los resultados que se quiere verificar sean
visibles.
Pasos Determinar una lista de ingredientes con

sus masas respectivas.
Ingresar los datos en el programa en

ejecución.
148 - 236
Ejecutar el cálculo químico.
Datos de prueba Lista de ingredientes de una mezcla

básica de propelente
Resultado esperado Cada uno de los resultados devueltos de

los cálculos químicos mostrará los
detalles específicos que se buscan
encontrar
Resultado obtenido Los datos de salida coinciden con los

datos que se esperaba recibir con las
funciones creadas.
Estado Aprobado
PRIMER SPRINT
Titulo Verificar el acceso a las tablas de JANAF
Pre-requisitos Haber registrado en la base de datos

previamente las tablas necesarias del libro
de termodinámica de JANAF
149 - 236

ejecución.

Resultado esperado El programa creará una lista de productos

posibles, de los cuales irá sacando
temperaturas, entalpia y demás datos de
las tablas JANAF, para el cálculo de la
temperatura máxima de la cámara de
combustión.
Resultado obtenido Los datos de salida del programa,

muestran como se busca entre los
diferentes rangos de la tabla
termodinámica, durante el cálculo de la
temperatura.
Estado Aprobado
150 - 236
PRIMER SPRINT
Titulo Verificar la precisión de datos
Pre-requisitos Haber comprobado el funcionamiento

correcto de las funciones que llevan a
cabo los cálculos necesarios


ejecución.

Resultado esperado El programa devolverá una serie de

resultados que deben ser comparados a
un ejemplo de la vida real, donde la
diferencia debe ser la más mínima
posible.
Resultado obtenido Los resultados obtenidos muestran poca

diferencia con los datos de prueba real.
151 - 236
Estado Aprobado
Tabla 50: Tabla de resultados de las pruebas de Primer Sprint
PRUEBA TITULO DE PRUEBA CALIFICACION
Verificar el correcto
1 procedimiento para la Aprobado
fabricación de propelentes
Verificar el acceso a las

2 Aprobado
tablas de JANAF
Verificar la precisión de
3 Aprobado
datos
Tabla 51: Retrospectiva del primer sprint.
PRIMER SPRINT
QUE SE DEBE
QUE SE HIZO MAL QUE SE HIZO BIEN
CONSIDERAR
Las interfaces de usuario

Hubo más dificultades de Detallar mejor la
fueron fáciles de generar
las esperadas en la documentación necesaria
gracias a herramientas
152 - 236
PRIMER SPRINT
QUE SE DEBE
CONSIDERAR
realización de las historias proporcionada por la propia para los cálculos

de usuario. librería. realizados.
Se debió hacer una Se logró obtener una

investigación a profundidad comprensión más a fondo
para hallar las fórmulas del tema.
necesarias para realizar los
cálculos.
153 - 236
Desarrollo de Segundo Sprint
Prioridad Alta Complejidad 3
Nombre de Historia Modelación de motor en base a datos

previos
Descripción Product Owner necesito elaborar un

modelo para simular la elaboración de un
motor de cohete en base a datos del
propelente para garantizar que el motor
actuará de manera adecuada.
Criterios de Aceptación Todos los resultados deben estar dentro

de los márgenes posibles o aceptables de
error
Los datos de propelente generados en la

fabricación del mismo deben pasarse de
manera fácil.
154 - 236
Nombre de Historia Materiales de motor
Descripción Como usuario necesito incluir los distintos

materiales que se puedan utilizar para el
motor para ofrecer una variedad amplia de
opciones de material de construcción.
Criterios de Aceptación Se deben considerar los datos generados

por el propelente para seleccionar el
material con la mayor resistencia posible
Debe mantenerse dentro de los límites de

adquisición para los desarrolladores.
155 - 236
Nombre de Historia Implementación de material retardante
Descripción Product Owner necesito recrear la

implementación de material retardante y
protección a la pastilla para simular casos
en que se necesita alentar la combustión
o evitar el contacto directo de las paredes
de la cámara con la pastilla
Criterios de Aceptación Implementar el uso de material en todos

las partes de la pastilla que se puedan
aplicar
Los resultados deben seguir los patrones

esperados de los cálculos de los que se
producen.
156 - 236
3.3.4.2. Codificación de los cálculos de rendimiento de Motor
Los datos de la pastilla y el propelente incluyen aspectos básicos e indispensables para

el cálculo de los datos del motor. Es en base a estos que se puede modelar la tobera del
motor, su cámara de combustión entre otros datos que puedan servir. En particular su
elaboración requiera que se apliquen gráficos que permitan juzgar de forma apropiada el
rendimiento del prototipo. Una de estos gráficos es el de Empuje del prototipo a razón
del tiempo. Este es uno de los principales datos alrededor del cual se interpreta si el
motor de cohete tiene un rendimiento satisfactorio. Este es el tipo de datos que se busca
extraer al realizar las denominadas Pruebas en Bancos de Pruebas. La figura inferior
muestra la apariencia de este mismo banco.
Figura 17: Banco de Pruebas
El Banco de pruebas es básicamente una mesa especial con equipo de medición dentro
de la misma, en ella se coloca el motor de cohete fabricado cabeza abajo, tras lo cual se
lo enciente y la mesa mide el empuje de este contra su superficie, que luego es usado
para crear la gráfica mencionada.
La interfaz de usuario será equipada con gráficos de MatPlotLib y tablas que contengan
los datos estadísticos necesarios para graficar la información requerida, como en las
figuras a continuación:
157 - 236
Figura 18: Gráficos MatPlotLib
Figura 19: Tabla de datos estadísticos
Para realizar el cálculo de los datos del motor, primero se deben ejecutar una serie de
cálculos, que involucran datos como área inicial de la tobera, entre otros. La forma en
158 - 236
que se planea realizar la codificación del motor es dividirlo en sus partes, particularmente
Cámara de Combustión y la Tobera.
La cámara de combustión es fácil de implementar debido a que solo se necesita

establecer su diámetro, longitud y volumen dentro del cual se alojaría las pastillas de
propelente. La tobera, por otro lado es mucho más complicada.
La tobera es quizás la parte del motor que requiere mayor esfuerzo en su diseño, debido
a que su tarea principal es canalizar y acelerar los gases producto de la combustión
dentro de la cámara. Sus partes son ilustradas en la figura 19. La geometría que se
aplique en esta puede terminar afectando el paso del flujo del fluido, es decir los gases
de escape y las partículas condensadas. Para esto se debe tomar en cuenta que tiene
tres áreas principales a las que se debe tomar en cuenta:
Figura 20: Áreas de la tobera
La elaboración de la tobera empieza con distinguir estas áreas. Para lo cual se necesitará
la relación inicial de área de quemado con la superficie de tobera, y la erosión en la
garganta. De lo cual se puede conseguir el área inicial de la garganta, su diámetro inicial
y su diámetro final, tras haber realizado la combustión.
El objetivo durante la elaboración de la tobera es maximizar y acelerar la salida de los

fluidos. Se necesita calcular datos como la velocidad de salida e impulso total.
Para llevar a cabo el desarrollo del programa, se dividió la interfaz del motor en diferentes
pestañas, para facilitar su manejo. Estas se dividen de la siguiente forma:
159 - 236
 Datos de Grano: En esta pestaña es donde se ingresan todos los datos de entrada
para los cálculos del motor. Incluye datos de la tobera, la cámara de combustión y
demás.
 Datos de Oxidante y Combustible: Son datos del área quemada inicial de la tobera,
es decir el área que está expuesta a la combustión del propelente.
o Tabla de Datos
o Gráficos
 Presiones: Son datos sobre la presión que experimenta el motor con la combustión
de propelente dentro de la cámara, maneja datos relacionados a la tasa de quemado
del mismo.
o Tabla de Presiones
o Gráficos
 Rendimiento: Aquí se determina el empuje total del motor y propelente, como su
nombre indica, es aquí donde se mide cuan efectivo es el motor.
o Tabla de Rendimiento
o Gráficos
 Modelo 3d de Pastilla: Es un modelo 3d de la pastilla de propelente, donde toma
datos de la parte de Datos de Grano para dar una vista previa a como luciría la pastilla
tras fabricarla en la vida real.
Cabe mencionar acá que todas las pestañas a excepción de Datos de Grano solo
muestran tablas con los datos a medida que se quema y reduce el propelente durante la
combustión y un gráfico mostrando el mismo efecto.
Para esto se tienen tablas que guardan los datos de presión, empuje y demás datos que
cambian conforme se reduce el propelente por consecuencia de la combustión. Muchos
de estos datos dependen de la tasa de quemado de un propelente, el cual tiene que ser
medido en laboratorio mediante pruebas de Strand Burner, que básicamente requerían
crear piezas del propelente y quemarlos en condiciones controladas. Mediante estas
pruebas se buscan adquirir tres datos en particular:
160 - 236
 Presión (MPa)
 Coeficiente de Tasa de Quemado
 Exponente de Presión.
Datos que tras ser introducidos en la fórmula de la Ley de Saint Robert:
𝑟 = 𝑟𝑜 + 𝑎𝑃𝑛
Donde r es la tasa de combustión, r es una constante (usualmente tomado como cero),

a es el coeficiente de la tasa de combustión, y n es el exponente de la presión. Los
valores de ay se determinan empíricamente para una formulación propulsora particular,
y no se pueden predecir teóricamente.
Con ayuda de estos valores y con datos del propelente sacados durante la etapa de
fabricación del mismo, se puede estimar la fuerza de empuje de dicho motor a razón del
tiempo. Dos datos que se pueden sacar con ayuda de la tasa de quemado. Los datos del
propelente usados además de la tasa de quemado incluyen:
 Densidad Ideal
 Relación de Calores Específicos
 Peso Molecular
 Temperatura de Cámara
El impulso final, hallado tras haber terminado todos los cálculos adquiridos, será el dato
que se usará para clasificar nuestro motor, de acuerdo a la escala dada en el Anexo K.
Tal como se citó en la página 131, el modelo MVC es aplicado para este caso. De manera
similar al caso anterior explicado en cuanto al propelente y a las pastillas, los cálculos
para la elaboración del motor se encuentran almacenados dentro de un archivo en
particular, “ClMotor.py”. El cual puede ser accedido desde el controlador principal
“_process.py” en caso de ser necesitado.
161 - 236
3.3.4.4. Pruebas de segundo sprint
Tabla 56: Prueba funcional del segundo sprint #1
SEGUNDO SPRINT
Titulo Verificar la modelación de motor en base

a datos previos
Pre-requisitos Haber terminado exitosamente la

producción de un propelente que pueda
ponerse en uso en un cohete, habiendo
calculado los datos necesarios.
162 - 236
Pasos Determinar una lista de dimensiones y
medidas que poner como datos de
entrada al software
Ejecutar el cálculo con el botón “Calcular”.
Datos de prueba Datos extraídos de la elaboración de

propelente, incluyendo densidad ideal,
etc.

posible.

Estado Aprobado
163 - 236
Tabla 57: Tabla de resultados de las pruebas de Segundo Sprint
Verificar la modelación de
1 motor en base a datos Aprobado
previos
Tabla 58: Retrospectiva del segundo sprint.
SEGUNDO SPRINT
QUE SE DEBE
CONSIDERAR
Hubo más dificultades de

las esperadas en la Las tablas de valores
realización de los gráficos estadísticos fueron
más La capacidad responsiva
3d. fáciles de completar tras de las interfaces de usuario
haber encontrado las requiere más atención al
Hubo que buscar formas de
fórmulas correctas detalle.
integrar graficos de
MatPlotLib dentro de la
interfaz qt.
164 - 236
Desarrollo de tercer sprint
3.3.5.1. Historias de usuario
Tabla 59: Historia de usuario #7
Nombre de Historia Recreación de piezas de fuselaje.
Descripción Como Product Owner necesito

implementar recreaciones de todas las
piezas de fuselaje que se puedan
necesitar en un cohete para recrear el
proceso de ensamblado de la capa
externa.
Criterios de Aceptación
Todas las partes del cohete deben poder

ser modificadas dentro del software.
Se deben asignar dimensiones diferentes

a las distintas partes.
165 - 236
Nombre de Historia Recreación efectos del aire sobre el

fuselaje
Descripción Como Product Owner necesito analizar y

recrear el comportamiento de los flujos de
aire sobre cada pieza de fuselaje para
garantizar la implementación de la
capacidad aerodinámica de las piezas.
Todas las partes del cohete deben tomar

en cuenta las diferentes formas que su
geometría pueda variar.
Tomar en cuenta como cada variación en

su geometría afecta la resistencia de los
flujos de aire.
166 - 236
Usuario Equipo
Nombre de Historia Validación de capacidad aerodinámica.
Descripción Como equipo se necesita validar que el

fuselaje implementado en la unidad tenga
capacidad aerodinámica mediante
evaluación de los flujos de aire, para
simular las pruebas en túnel de viento que
se realizan en la realidad.

ejercer un nivel de eficiencia diferente en
el vuelo.
Los valores de eficiencia deben ser lo más

cercanos posible a la realidad.
167 - 236
Usuario Equipo
Nombre de Historia Validación de capacidad aerodinámica.
Descripción Como equipo se necesita validar que el

fuselaje implementado en la unidad tenga
capacidad aerodinámica mediante
evaluación de los flujos de aire, para
simular las pruebas en túnel de viento que
se realizan en la realidad.

ejercer un nivel de eficiencia diferente en
el vuelo.
Los valores de eficiencia deben ser lo más

cercanos posible a la realidad.
168 - 236
3.3.5.2. Desarrollo de fuselajes
En este sprint se deben desarrollar todos los medios para simular el fuselaje de un
cohete. Para esto se deben tomar en cuenta distintas variables, empezando por el
material seleccionado, dimensión de las distintas partes y demás.
a) Material
El material con el que se construirá el fuselaje que rodee al motor de cohete. Para esto
el software cuenta con una lista de todos los posibles materiales para aplicar en el diseño
de prototipos. Es posible construir fuselajes de PVC o aluminio, debido a su bajo peso y
su resistencia. El material es completamente dependiente de las decisiones y recursos
de los desarrolladores. Una lista de posibles materiales se encuentra en el Anexo L.
b) Partes de fuselaje de un cohete

 Tubo o cuerpo
Esta es la parte más simple del fuselaje del cohete, como su nombre lo indica es el
cuerpo del cohete en sí. Su forma geométrica es sencilla, donde básicamente solo se
necesitan especificar tres datos:
o Diámetro externo de tubo: Diámetro que toma el cuerpo del cohete en toda su
extensión.
o Espesor de tubo: Espesor o diferencia entre diámetro externo y diámetro interno.
o Longitud total: Extensión total del tubo.
 Nariz
Existen distintos tipos de nariz que puedan usarse en un fuselaje. Entre estas se pueden
mencionar dos tipos en particular, ilustradas en la figura 20: Ojivas y elípticas.
169 - 236
Figura 21: Tipos de narices
Cada nariz tiene distinta resistencia al aire, que se atribuye a sus dimensiones. Las
cuales se pueden listar en las siguientes variables:
o Longitud de nariz: Largo total de la nariz desde la base hasta la punta.

o Diámetro de base: Diámetro de la base de la nariz, donde se une al tubo.
o Longitud de hombro: Largo de la nariz que se extiende dentro del tubo al ser
enroscada.
o Distancia de curva: Largo desde el punto en que la nariz empieza a curvarse hasta
llegar a la punta.
 Aletas
Las aletas son las encargadas de proporcionar estabilidad al cohete variando el centro
de presiones y facilitándole un desempeño aerodinámico en vuelo. En un cohete se
pueden ubicar 3, 4 o más aletas.
Entre mayor sea el número de aletas, menor la altura que alcanzará, porque al tener
mayor superficie, la resistencia del aire al paso del mismo será mayor a la de un cohete
con menor superficie.
170 - 236
En caso que el cohete esté diseñado para alcanzar grandes aceleraciones, velocidades
y alturas, es recomendable el uso de cuatro o más para estabilizarlo. Las dimensiones
que se deben tomar en cuenta para formar una aleta son las siguientes:
o Cantidad de aletas: Numero de aletas que se incorpora al diseño de fuselaje.

o Longitud de Base: Longitud de la aleta donde se une al cuerpo del cohete.
o Longitud de punta: Largo de la aleta al en el extremo opuesto a donde se une al
cohete.
o Longitud de aleta: Distancia entre la base y punta de la aleta.
o Angulo de aleta: Angulo de inclinación entre la base y la punta
c) Medición de resistencia a fracturas
Una vez se haya creado los medios para modelar o establecer las dimensiones de las
partes del fuselaje, se deben realizar pruebas para saber que tan efectivo es nuestro
diseño. Esto se logra mediante el cálculo de los siguientes datos:
 Resistencia a Fractura
Según la fórmula 1 de la tabla 46, se divide la longitud del tubo por el diámetro externo
del mismo. Si el resultado es menor a un constante determinado, quiere decir que nuestro
fuselaje no corre riesgo de fractura. Esta constante es el espesor mínimo del material
que se escogió para la elaboración del cohete.
 Presión de rotura y factor de rotura
La Presión de Ráfaga o Rotura es la presión de la cámara a la cual es probable que la

caja falle catastróficamente.
El Factor de Seguridad de Rotura se da como la relación de la Presión de Rotura a la

Presión de Diseño (un motor debe estar equipado con un dispositivo de limitación de
presión, tal como pasadores de cizallamiento para retener la boquilla o cabeza, o un
tapón de ráfaga, cuyo propósito es proporcionar una liberación controlada de presión
antes de que alcance este valor crítico).
171 - 236
Tal como se citó en la pagina 131, el modelo MVC es aplicado para este caso. Las
funciones para el cálculo de las piezas del fuselaje, están incluidas dentro de los archivos
“CnFuselage.py”, donde estos pueden ser ejecutados desde fuera del directorio con
ayuda de “_process.py”.
3.3.5.4. Pruebas de tercer sprint
Tabla 64: Prueba funcional del tercer sprint
TERCER SPRINT
Titulo Verificar la recreación de las piezas de

fuselaje
172 - 236
Pre-requisitos Haber terminado exitosamente los medios
para extraer los datos necesarios de los
materiales a usar
Pasos Determinar una lista de dimensiones y

para cada una de las piezas requeridas.

fuselaje, como la presión de rotura.

posible.

Estado Aprobado
173 - 236
Tabla 65: Tabla de resultados de las pruebas de Tercer Sprint
Verificar la recreación de
1 Aprobado
las piezas de fuselaje
Tabla 66: Retrospectiva del tercer sprint.
TERCER SPRINT
QUE SE DEBE
CONSIDERAR
Hubo más dificultades de

las esperadas en la
realización de los gráficos La investigación de
Se requiere más atención a
3d. distintas fuentes que
la hora de integrar los
eventualmente llevaron a
Se creo algo de confusión encontrar las distintos resultados de los
fórmulas
en como modelar las requeridas cálculos.
dimensiones de las
distintas piezas
174 - 236
Desarrollo de cuarto sprint
Usuario Equipo
Nombre de Historia Recreación de los efectos del clima
Descripción Como equipo necesito recrear los distintos

climas a los que se pueda enfrentar el
cohete para que los resultados tomen en
cuenta la resistencia que puedan ofrecer.
Tomar en cuenta las diferencias de

resistencia que se presenten con cada
variación del clima
175 - 236
Usuario Equipo
Nombre de Historia Implementación de Inteligencia artificial
Descripción Como equipo necesito implementar

inteligencia artificial para recrear las
distintas condiciones del ambiente que
enfrentaría el cohete.
Se deben recrear los efectos de las

condiciones especificadas como el clima
que enfrenta el cohete en su vuelo.
176 - 236
Usuario Usuario
Nombre de Historia Apoyo de gráficos 3D.
Descripción Como equipo necesito implementar

gráficos 3D para ilustrar el proceso de
elaboración y proporcionar una vista
previa del prototipo.
Se deben integrar graficos que reflejen

como va tomando forma nuestro diseño
de prototipo.
177 - 236
Usuario Equipo
Nombre de Historia Veracidad de resultados.
Descripción Como equipo necesito validar que los

resultados devueltos tengan un margen
de error de cinco por ciento para
garantizar la calidad de los resultados.
La comparación de resultados reales y

resultados obtenidos del software debe
resultar en un una diferencia mínima de
0.05.
178 - 236
3.3.6.2. Desarrollo de vuelo de prototipo
Para poder modelar el vuelo de un cohete, se deben centrar nuestros esfuerzos

principalmente en conseguir datos específicos que puedan indicar que tan eficiente ha
sido el prototipo. Estos datos incluyen:
 Velocidad Máxima: Como su nombre lo indica, esta sería la mayor velocidad que
alcanza el cohete durante toda la duración del vuelo. Es uno de los datos más
relevantes para medir el rendimiento del cohete.
 Altura Máxima: Igualmente claro en su nombre, este dato es la mayor distancia del
suelo que es lograda durante el vuelo.
 Aceleración: Es el aumento de velocidad del cohete durante su ascenso hasta
alcanzar su velocidad máxima.
 Tiempo para altura máxima: La cantidad de tiempo que transcurre hasta que se
alcance la altura máxima desde el momento de la ignición.
 Tiempo de empuje: Es el tiempo para alcanzar su mayor capacidad de empuje.
Las formulas usadas para calcular todos estos datos están presentes en la tabla 56.
3.3.6.3. Patrón de Arquitectura.
Tal como se citó en la pagina 131, el modelo MVC es aplicado para este caso. En este
caso, las funciones de vuelo en su totalidad, se pueden acceder desde el archivo
“_process.py”. Cabe destacar acá que todas las funciones son sin arrastre.
Todo calculo que sea necesario para simular el lanzamiento de una unidad, se encuentra
almacenado dentro de “flight.py”.
Pero como todos los demás archivos puede ser llamado por el cuello de botella que
enlaza todas las funciones del directorio.
179 - 236
3.3.6.4. Pruebas de cuarto sprint
Tabla 72: Prueba funcional del cuarto sprint
CUARTO SPRINT
Titulo Verificar la veracidad de resultados
Pre-requisitos Haber terminado de implementar todas las

formulas necesarias para tomar los datos
de propelente y fuselaje.
180 - 236
Pasos Crear una lista de datos de fuselaje y
motor para poner a prueba.

fuselaje, como la presión de rotura.

posible.

Estado Aprobado
Tabla 73: Tabla de resultados de las pruebas de Cuarto Sprint
Verificar la veracidad de
1 Aprobado
resultados
181 - 236
Tabla 74: Retrospectiva del cuarto sprint.
TERCER SPRINT
QUE SE DEBE
CONSIDERAR
Se creó confusión al La investigación de datos Se requiere más

establecer que fórmulas necesarios fue facilitada introspección y reflexión en
ayudaran a calcular el por la abundancia de las mejorar los módulos del
vuelo del prototipo. fuentes en internet. software.
EXPERIMENTACIÓN CON EL MODELO DE SIMULACIÓN E

INTERPRETACIÓN DE LOS RESULTADOS OBTENIDOS.
Validación de Modelos mediante comparación con datos previos
Para realizar la validación de los modelos, se toma como referencia las pruebas
realizadas en campo, para más información ver la página 79. En el proceso de validación
aplicamos la prueba de F de Fisher mediante igualdad de varianzas. Dicha prueba
empieza por calcular las varianzas de las muestras obtenidas mediante las siguientes
formulas:
(𝑋0 + ⋯ + 𝑋𝑛 ) ((𝑋0 − 𝑀𝑒𝑑𝑖𝑎)2 + ⋯ + (𝑋𝑛 − 𝑀𝑒𝑑𝑖𝑎)2 )

𝑀𝑒𝑑𝑖𝑎 = 𝜎=
𝑛 𝑛−1
Donde:
𝑋𝑖 = 𝐷𝑎𝑡𝑜 𝑑𝑒 𝑙𝑎 𝑀𝑢𝑒𝑠𝑡𝑟𝑎
𝑛 = 𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑑𝑎𝑡𝑜𝑠 𝑒𝑛 𝑙𝑎 𝑀𝑢𝑒𝑠𝑡𝑟𝑎
182 - 236
Tomando en cuenta los dos tipos de muestra que serán empleados en la prueba, fueron
asignados las siguientes variables a sus respectivas varianzas:
σ1 = Varianza de la muestra uno, con datos de las maniobras realizadas en Patacamaya
σ2 = Varianza de la muestra dos, con datos sacados el software de simulación.
Una vez que se tenga estos valores, se puede seleccionar la hipótesis para esta prueba.
 Hipótesis Nula (Ho).
La hipótesis nula afirma que las varianzas son iguales en ambos procesos.
𝐻0 → 𝜎1 = 𝜎2
 Hipótesis Alterna (Hi)
La hipótesis alterna afirma que las varianzas son diferentes en ambos procesos.
𝐻𝑖 → 𝜎1 ǂ 𝜎2
A partir de lo cual se puede pasar a determinar el valor crítico para determinar el éxito de
la prueba, dependiendo de los datos de las tablas de Fisher. Donde se selecciona la
tabla de valores que corresponda al nivel de significancia que hemos seleccionado, en
este caso 0.10. Para ubicar el valor que se empleara dentro de la tabla, calculamos Gl
para ambas varianzas que se obtiene mediante la siguiente formula:
𝐺𝑙 = 𝑛 − 1
El valor obtenido entonces es usado para escoger el número de columna y fila, donde el
Gl de la varianza uno es la fila y el de la varianza dos es la comuna. El valor encontrado
en la intersección de ambas será el valor crítico para nuestra prueba. Tras haber hecho
esto solo calculamos F de la siguiente forma:
𝑉𝑎𝑟𝑖𝑎𝑛𝑧𝑎 𝑀𝑎𝑦𝑜𝑟
𝐹=
𝑉𝑎𝑟𝑖𝑎𝑛𝑧𝑎 𝑀𝑒𝑛𝑜𝑟
183 - 236
El resultado debe caer dentro del rango del valor critico con su opuesto negativo. En caso
de cumplirse esto puede decirse que la prueba fue exitosa.
Para la prueba en si tomamos en cuenta dos tipos de datos: Impulso especifico e impulso
vacío.
Para impulso especifico ideal:
1) Primer paso
𝑀𝑒𝑑𝑖𝑎1 = 138,29 𝑀𝑒𝑑𝑖𝑎2 = 138,95
σ1= (132,3 – 138,29)2 + (154,2 – 138,29)2 + (142,2 – 138,29)2 + (132,9 – 138,29)2 + (139,2
– 138,29)2 + (136,9 – 138,29)2 + (137,3– 138,29)2 + (139,3– 138,29)2 + (136,6 – 138,29)2 +
(135– 138,29)2 /n-1= 39,481
σ2= (134.1 – 138,95)2 + (154,7 – 138,95)2 + (143,5 – 138,95)2 + (133,4 – 138,95)2 +

(135,9 – 138,95)2 + (138,1 – 138,95)2 + (138,2 – 138,95)2 + (139,8 – 138,95)2 + (136,4 –
138,95)2 + (135,4 – 138,95)2 /n-1= 39,278333
𝜎1 = 39,481 𝜎2 = 39,278333
𝑁. 𝑆 = 0.10
2) Segundo paso
𝐺𝑙 1 = 𝑛1 – 1 = 10 – 1 = 9
𝐺𝑙 2 = 𝑛2 − 1 = 10 – 1 = 9
Seleccionar en la tabla de Fisher de acuerdo a los grados de libertad los datos para el
grafico que en este caso son 3.18 como se muestra en la siguiente figura:
184 - 236
Figura 22: Tabla de Fisher.
3) Tercer paso
El resultado final se muestra en la figura 23:
σ1 39,481
F= = 39,278333 =1,00516
σ2
Figura 23: Gráfico de Fisher I.
Por lo tanto, a partir de los cálculos y estudios realizados con anterioridad para realizar
la validación del modelo propuesto, se puede llegar a la conclusión de que el nivel de
185 - 236
significancia en todos y cada una de los impulsos específicos son mayores al 0.05 por lo
tanto se acepta la hipótesis nula, desechando así la hipótesis alternativa.
Impulso vacío:
1) Primer paso
Media1 = 107,48
Media2 = 107,85
σ1 = (103- 107.48)2 + (115.2- 107.48)2 + (110.8- 107.48)2 + (103.5- 107.48)2 + (1106.5-

107.48)2 + (107.1- 107.48)2 + (107.5- 107.48)2 + (109- 107.48)2 + (106.9- 107.48)2 +
(105.3- 107.48)2 /n-1 = 12, 7817778
σ2 = (104.4-107.85)2 + (114.9-107.85)2 + (111.2-107.85)2 + (102.9.4-107.85)2 + (108.7-

107.85)2 + (106.9-107.85)2 + (108.9-107.85)2 + (108.4-107.85)2 + (107.5-107.85)2 +
(104.7-107.85)2 /n-1 = 12.2672
σ1 = 12, 7817778 σ2 = 12, 2672
N.S = 0.10
2) Segundo paso
Gl 1= n1 – 1 = 10 – 1 = 9
Gl 2= n2 - 1 = 10 – 1 = 9
grafico que en este caso son 3.18 como en la figura 23.
186 - 236
3) Tercer paso
El resultado final se grafica en la figura 25:
σ1 12,7817778
F= = =1,0419
σ2 12,2672
Figura 25: Gráfico de Fisher II.
la validación del modelo propuesto (sistema), se puede llegar a la conclusión de que el
187 - 236
nivel de significancia en todos y cada una de los impulsos vacios son mayores al 0.05
por lo tanto se acepta la hipótesis nula, desechando asi la hipótesis alternativa.
Experimentación con datos
3.4.2.1. Experimentación con datos de propelente
Para llevar a cabo la experimentación del software dentro con datos de un modelo similar
al utilizado en la fabricación a un cohete B1M1. Empezando desde el propelente utilizado,
para el cual se han mezclado dos ingredientes:
 Nitrato de Potasio (KNO3)

 Sacarosa (C12H22O11)
Para los cuales se tiene preparada dos mezclas para usar en la experimentación,
detallados a continuación:
 Mezcla A:
o Nitrato de Potasio: 65 gramos
o Azúcar de Mesa: 35 gramos
 Mezcla B:
o Nitrato de Potasio: 75 gramos
o Azúcar de Mesa: 55 gramos
Estos datos se calculan con condiciones estándar, es decir a 298.15 K de temperatura

ambiente, 1 atm de presión de cámara y 68.046 atm de presión de exhauste. Como
resultado se obtuvo los siguientes resultados.
 Mezcla A:
o Impulso Especifico: 166,828.
o Velocidad Característica: 919,219.
o Densidad Ideal: 1,8995.
o Peso Molecular: 41,980.
o CP/CV de Cámara: 1,133.
188 - 236
o Temperatura de Cámara: 1720,277.
 Mezcla B:
o Impulso Especifico: 160,554.
o Velocidad Característica: 774,496.
o Densidad Ideal: 1,778.
o Peso Molecular: 49,973.
o CP/CV de Cámara: 1,195.
o Temperatura de Cámara: 1747,274.
Después, con los datos obtenidos de ambos propelentes se ejecutó el modelado del
grano o pastilla de propelente. Con los siguientes datos:
 Diámetro externo de 34 mm
 Diámetro interno de 14 mm
 Longitud de Segmentos 100 mm
 5 segmentos de grano
 Relación de densidad de 0.95
 Con anima y puntas
 Largo total de 500 mm
 Volumen total de 75398 mm3
Como resultado de los datos de motor, con el software se devuelven los siguientes datos:
 Mezcla A:
o Masa del Grano: 0.677 kg
o Impulso Total: 2612.620 N-Seg
o Empuje promedio: 1595.619 N
o Tiempo de empuje: 1.637 seg
o Clasificación de motor: L
 Mezcla B:
o Masa del Grano: 1.734 kg
o Impulso Total: 2903.423 N-Seg
189 - 236
o Empuje promedio: 1701.037 N
o Tiempo de empuje: 1.805 Seg.
o Clasificación de motor: L
Se tiene las siguientes dimensiones de fuselaje, fabricados con Aluminio 7075 – T7351:
 Tubo
o Diámetro Externo: 40
o Espesor: 0.7
o Longitud: 580
 Nariz
o Tipo: Ojiva
o Longitud de nariz: 150
o Diámetro de base: 40
o Longitud de Hombro: 3
 Aletas
o Cantidad de aetas: 3
o Longitud de Base 100
o Longitud de aleta: 50
o Angulo de aleta: 45
Con los datos de resistencia de:
 Resistencia a fractura: 7,265

 Presión de rotura: 2693,102
 Factor de Rotura: 1,231
Finalmente los resultados de vuelo obtenidos con el software son:
 Mezcla A:
o Tiempo de empuje : 1,637
o Altitud Max.: 755695,013
o Velocidad Max: 3842,138
190 - 236
o Aceleración: 3144,790
o Tiempo para Altitud Max: 393,372
 Mezcla B:
o Tiempo de empuje : 1.805
o Altitud Max.: 784305,704
o Velocidad Max: 3920,415
o Aceleración: 3180,072
o Tiempo para Altitud Max: 402,220
3.4.2.2. Datos de Prueba de las Maniobras en Patacamaya
Tabla 75: Experimentación con Datos de Impulso (ISP)
RESULTADOS EXPERIMENTACIÓN
VALORES DE EN CAMPO VALORES % DE
OBTENIDOS
PROPELENTE SIMULADOR ERROR
EN MESA ISP
-Nitrato de
Potasio (65%) 100 104,4 103 2%
-Sucrosa(35)
Nitrato de
Potasio (65%) 123 114,9 115,2 1%
-Sucrosa(35)
Nitrato de
Potasio (65%) 105,2 111,2 110,8 1%
-Sucrosa(35)
191 - 236
OBTENIDOS
EN MESA ISP
Nitrato de
Potasio (65%)
95,9 102,9 103,5 2%
-Sucrosa(35)
Nitrato de
Potasio (65%) 92,7 108,7 106,5 2%
-Sucrosa(35)
Nitrato de
Potasio (65%) 98,3 106,9 107,5 2%
-Sucrosa(35)
Nitrato de
Potasio (65%) 91,4 108,9 107,5 2%
-Sucrosa(35)
Nitrato de
Potasio (65%) 101,5 108,4 109 1%
-Sucrosa(35)
192 - 236
OBTENIDOS
EN MESA ISP
Nitrato de
Potasio (65%) 99,5 107,5 106,9 1%
-Sucrosa(35)
Nitrato de
Potasio (65%) 89,8 104,7 105,3 3%
-Sucrosa(35)
Tabla 76: Experimentación con Datos de Impulso (Impulso Específico)
EXPERIMENTACIÓN
RESULTADOS EN CAMPO
VALORES DE VALORES
OBTENIDOS % DE
PROPELENTE IMPULSO SIMULADOR
EN MESA ERROR
ESPECIFICO
-Nitrato de
Potasio (65%) 120,4 132,3 134,1 1%
-Sucrosa(35)
Nitrato de
110,1 154,2 154,7 1%
Potasio (65%)
193 - 236
EXPERIMENTACIÓN
RESULTADOS EN CAMPO
VALORES DE VALORES
OBTENIDOS % DE
EN MESA ERROR
ESPECIFICO
-Sucrosa(35)
Nitrato de
Potasio (65%) 170 142,2 143,5 1%
-Sucrosa(35)
Nitrato de
2%
Potasio (65%) 100,7 132,9 133,4
-Sucrosa(35)
Nitrato de
Potasio (65%) 99,4 132,2 135,9 1%
-Sucrosa(35)
Nitrato de
Potasio (65%) 110,7 136,9 138,1 2%
-Sucrosa(35)
Nitrato de
Potasio (65%) 119,4 137,3 138,2 2%
-Sucrosa(35)
194 - 236
EXPERIMENTACIÓN
RESULTADOS EN CAMPO
VALORES DE VALORES
OBTENIDOS % DE
EN MESA ERROR
ESPECIFICO
Nitrato de
Potasio (65%) 120,9 139,3 139,8 1%
-Sucrosa(35)
Nitrato de
Potasio (65%) 124,7 136,6 136,4 1%
-Sucrosa(35)
Nitrato de
Potasio (65%) 116,7 135 135,4 1%
-Sucrosa(35)
Tras realizar experimentos con el software empleando diferentes mezclas, se puede

concluir en que mientras más cantidad de combustible sea agregada, la velocidad, altura
máxima y otros datos resultantes de la simulación, mostraran un mayor alcance o
rendimiento.
3.4.2.3. Experimentación con datos físicos en Patacamaya
En las maniobras conjuntas del ejército se realizaron las pruebas de las unidades con
las mezclas A y B, como se muestra en las figuras 25 y 26. Los datos que se obtuvo de
ese proceso fue el siguiente, empezando por la Mezcla A:
195 - 236
Para el Angulo a 45 grados:
 Angulo de lanzamiento 45
 Distancia horizontal alcanzado 11900 mts
 Tiempo de empuje 1,180 seg
 Altura total alcanzado 2500 mts
Figura 26: Lanzamiento a 45 grados
Fuente: Elaboración propia, 2017
Los datos que se logró obtuvo del lanzamiento a 45 grados fueron los que se menciona
anteriormente
Para el ángulo a 35 grados:
 Ángulo de lanzamiento 35
 Distancia horizontal alcanzado 9500 mts
 Tiempo de empuje 1.170 seg
 Altura máxima 1800 mts
196 - 236
Los datos que se logró obtuvo del lanzamiento a 35 grados fueron los que se menciona
anteriormente y se logra observar que hay una variación en la altura máxima, y Distancia
horizontal alcanzado ya que el Angulo que se emplea son distintas
En las pruebas que se realizaron se notó que el ángulo de lanzamiento es muy

importante porque se nota que el que las distancias varían de acuerdo al Angulo también
hacer mucho en lugar donde se hacen los lanzamientos ya que influirá la presión
atmosférica en las tres regiones de nuestro país (altiplano, llano, valles).
Figura 27: Lanzamiento a 35 grados
Fuente: Elaboracion Propia, 2017
Los datos más relevantes en el momento de poner a prueba son:
 Angulo de lanzamiento
 Presión atmosférica del ambiente
Tras realizar experimentos con el software empleando diferentes mezclas, se puede

concluir en que mientras más cantidad de combustible sea agregada, la velocidad, altura
máxima y otros datos resultantes de la simulación, mostraran un mayor alcance o
rendimiento.
197 - 236
DEMOSTRACIÓN DE LA HIPÓTESIS
Demostración de la Primera Variable Dependiente
Análisis estadístico de comparación de datos técnicos. Hace referencia a todos los datos
que el software de simulación ya existente devuelve como resultado del procedimiento
de cálculo.
1) Primer Paso:
𝜎1 = (773.85 − 876.75)2 + (819.85 − 876.75)2 + (912.85 − 876.75)2

+ (840.85 − 876.75)2 + (826.85 − 876.75)2 + (807.85 − 876.75)2
+ (724.85 − 876.75)2 + (985.85 − 876.75)2 + (1362.85 − 876.75)2
+ (711.85 − 876.75)2 /n − 1 = 35790,7667
𝜎2 = (766.85 − 872.85)2 + (819.85 − 872.85)2 + (897.85 − 872.85)2

+ (840.85 − 872.85)2 + (826.85 − 872.85)2 + (807.85 − 872.85)2
+ (723.85 − 872.85)2 + (985.85 − 872.85)2 + (1346.85 − 872.85)2
+ (711.85 − 872.85)2 /n − 1 = 34178,0
𝜎1 = 35790,7667 𝜎2 = 34178,0
𝑁. 𝑆 = 0.10
2) Segundo Paso
𝑁. 𝑆 = 0.10/2 = 0.05
𝐺𝑙 1 = 𝑛1 – 1 = 10 – 1 = 9
𝐺𝑙 2 = 𝑛2 − 1 = 10 – 1 = 9
grafico que en este caso son 3.18 como en la figura 27.
198 - 236
3) Tercer paso
El resultado final se puede observar en la figura 29.
σ1 35790,7667
F= = =1,04718727
σ2 34178
Figura 30: Gráfico de Fisher III.
199 - 236
la validación del modelo propuesto (sistema), se puede llegar a la conclusión de que el
nivel de significancia en todos y cada una de las temperaturas son mayores al 0.05 por
lo tanto se acepta la hipótesis nula, desechando asi la hipótesis alternativa.
Demostración de la Segunda Variable Dependiente
Los tiempos para la utilización de equipo suele ser una cuestión de tiempo disponible del
equipo de desarrollo, la disponibilidad del equipo y demás. Si bien la fabricación del
propelente puede realizarse relativamente pronto, el llevar a cabo fases como la prueba
en banco de pruebas puede requerir meses de espera, dependiendo si el equipo está
reservado para uso de otras personas o si se necesita que llegue nuevas partes o un
nuevo banco para llevar a cabo las pruebas.
Con el software, esto se resolvería, debido a que los cálculos son llevados a cabo
inmediatamente y sin tener que esperar por equipo nuevo, o lidiar con cualquiera de los
preparativos necesarios para una prueba física. En la figura 29, se puede ver una prueba
en el mencionado banco de pruebas. Los relojes de la imagen indican que las pruebas
llegan a tomar minutos enteros, cosa que es fácilmente superada por la ejecución de un
software.
Figura 31: Realización de prueba en banco de pruebas.
200 - 236
En la siguiente tabla, se tiene la comparación de los tiempos obtenidos del proceso de
elaboración de una unidad, uno del sistema propuesto, y otro con el proceso actual.
Tabla 76: Comparación de tiempos con sistema actual y sistema propuesto.
TIEMPO TIEMPO
SIN CON
PROCESO SIN SISTEMA SISTEMA CON SISTEMA SISTEMA
(MINUTOS) (MINUTOS)
INTRODUCIR
DATOS DE
PESADO DE 2 1
TIEMPO DE ELABORACION DE PASTILLAS
LOS QUÍMICOS MEZCLA DE

PROPELENTE
DEFINIR LAS
MEZCLADO DE
30 DIMENCIONES 1
LOS QUÍMICOS
DE LA PASTILLA
CONDICIONES
COCINADO DE DE
12
LOS QUÍMICOS CONSTITUCIÓN 1
DE LA PASTILLA
201 - 236
TIEMPO TIEMPO
SIN CON
(MINUTOS) (MINUTOS)
MOLDEAR LA
MEZCLA 10 -- --
COCIDA
TIEMPO DE FABRICACIÓN DE LA CÁMARA DE COMBUSTIÓN
FABRICACIO 1440 DEFINIR 1

N DE LA DIMENCIONES
CAMARA DE DE LA CAMARA
COMBUSTIO DE COMBUSTION
N
FUSELAJE Y ALERONES
FABRICACION 960 DEFINIR 1

DE LA TOBERA RELACION DEL
AREA DE
QUEMADO
202 - 236
TIEMPO TIEMPO
SIN CON
(MINUTOS) (MINUTOS)
DEFINIR
DIMENCIONES Y
FABRICACION MATERIAL DEL
1920 2
DEL FUSELAJE FULAJE
TOTAL DE 4374 TOTAL DE 7 MINUTOS

MINUTOS MINUTOS MINUTOS
Con la comparación mostrada en la tabla, podemos ver que el tiempo empleado en la

elaboración de una unidad desciende radicalmente al emplear el software desarrollado
en el proyecto. El tiempo resultante llega a ser un 0.16 % del tiempo que originalmente
solía demorarse.
Demostración de la Hipótesis de Variable Independiente
El simulador de sistema de propulsión de cohetes a combustible sólido Para verificar el

rendimiento de la cámara de combustión. Esta variable hace referencia a todo nuestro
software en general, para la simulación de propulsión de cohetes y rendimiento de la
cámara de combustión.
Para la demostración de la misma se emplea una comparación de beneficios entre el

proceso actual, y el proceso con ayuda del software desarrollado.
203 - 236
Tabla 77: Tabla comparativa de beneficios
PROCESO PROCESO
NRO: FACTORES TOMADOS EN CUENTA CON EL
MANUAL
FACTOR COMO BENEFICIO SISTEMA
(ANTES) (AHORA)
1 Toma en cuenta todos los posibles SI Si

ingredientes para propelente
2 Tiene una interfaz de usuario fácil de No Si

comprender y navegar
3 Todas las herramientas están en idioma No Si

español
4 Fácil traspaso de datos de una tabla otra No Si
5 Permite al usuario a hacer los cálculos de No Si

manera más exacta (los calículos o realizan
la computadora )
TOTAL DE BENEFICIOS 1(5) 5(5)
3.4.5.1. Planteamiento de la hipótesis
Para medir de forma apropiada el nivel de éxito de nuestra variable independiente, se

necesita medir la probabilidad sacada de los beneficios especificados en la tabla 41.
P1 = Los procesos manuales empleados en el planeamiento de operaciones.
204 - 236
P2 = El sistema de modelación del terreno empleado en la planeación de operaciones
militares.
P1 = 1/5 = 0.2
P2 = 5/5 =1
El planeamiento de la prueba de hipótesis es:
 Hipótesis Nula (Ho).
La hipótesis nula afirma que los factores de éxito son iguales en ambos procesos.
P1 = P2
 Hipótesis Alterna (HA)
La hipótesis alterna afirma que los factores de éxito son diferentes en ambos procesos.
P1 ≠ P2
Así que, la hipótesis nula es rechazada y se acepta la hipótesis alterna que presenta dos
casos posibles para el cumplimiento de la misma, los cuales se desarrollan a
continuación. Aquí se tiene dos opciones:
o P1 > P2
o P1 < P2
Si se toma en cuenta que P1 = 0.2 y P2 = 1.0, se puede afirmar que en nuestra hipótesis,
P2 es mayor a P1.
3.4.5.2. Calculo estadístico “T”
El cálculo estadístico “T”, permite conocer la aceptación de la hipótesis, teniendo en

cuenta que existe un rango de aceptación. Luego con el dato encontrado con las
probabilidades se ubica si está dentro del rango de aceptación o rechazo.
205 - 236
Para realizar el cálculo se utilizan las siguientes formulas, el resultado final se muestra
en la figura 30:
𝑋𝑛
𝑃𝑛 =
𝑛
𝑄𝑛 = 1 − 𝑃𝑛
𝑔𝑙 = 𝑛 − 1
𝑃1 − 𝑃2
𝑡=
√𝑃1 ∗ 𝑄1 + 𝑃2 ∗ 𝑄2
𝑛1 𝑛2
Donde:
Pn = Probabilidad de ocurrencia de uno de los casos.
X = Número de aciertos en la muestra de la probabilidad Pn.
N = Número de muestras (beneficios analizados).
Qn=Probabilidad de ocurrencia de uno de los casos.
α/2=Grado de error.
gl = Grado de libertad.
t = Valor estadístico para la aceptación o rechazo de la hipótesis.
Llevando a cabo los cálculos se tiene:
gl = n – 1
gl =5-1 = 4
gl = 4
Q = 0.025
206 - 236
Q1 = 1 – 0.2 = 0.8
Q2 = 1 – 5/5 =0
𝟎. 𝟐 − 𝟏
𝒕=
√𝟎. 𝟐 ∗ 𝟎. 𝟖 + 𝟏 ∗ 𝟎
𝟓 𝟓
T = --4.472135955
Figura 32: Gráfico de gauss para la hipótesis
Fuente: Elaboracion propia, 2017.
Después de haber realizado el análisis del cálculo del T-Student, se puede observar que
el valor obtenido se encuentra en el rango de la hipótesis alternativa HA, específicamente
en el caso donde se establece que P1 < P2 la cual indica que: “El proceso actual para la
simulación de propulsión de cohetes de combustible sólido y verificación del rendimiento
de la cámara de combustión tiene menores beneficios que el software desarrollado. Por
lo que queda demostrado que el software propuesto generara mayores beneficios para
el programa aeroespacial.
207 - 236
4. ANÁLISIS DE VIABILIDAD
VIABILIDAD TÉCNICA
A continuación se detallan los requerimientos mininos e ideales en cuanto a hardware y

software para el funcionamiento adecuado del proyecto, tomando en cuenta las
necesidades establecidas por el Programa Aeroespacial en los Anexos P y R.
Tabla 78: Requerimientos mínimos e ideales de Hardware.
REQUERIMIENTO
HARDWARE REQUERIMIENTO IDEAL
MINIMO
Equipo de Escritorio
Procesador Intel Core i5 Intel Core i7
RAM 4 Gb 16 Gb
Disco Duro 20 Gb 500 Gb
Tipo de Sistema 32 bits 32 y 64 bits
Equipo Portátil o Laptop
Procesador Intel Core i5 Intel Core i7
RAM 8 Gb 16 Gb
Disco Duro 905 Gb 905 Gb
208 - 236
REQUERIMIENTO
HARDWARE REQUERIMIENTO IDEAL
MINIMO
Tipo de Sistema 32 bits 64 bits
Tabla 79: Requerimientos mínimos e ideales de Software
REQUERIMIENTO
SOFTWARE REQUERIMIENTO IDEAL
MINIMO
Sistema Operativo Windows 7 Windows 8
Gestor de Base de Datos MongoDB 2.0.0 MongoDB 3.4.4
Lenguaje Python 2.7 Python 2.7.
Tras haber revisado los requerimientos de hardware y software, se puede decir que el
simulador cumple con las condiciones establecidas previamente. Este cuenta con la
capacidad de funcionar bajo las expectativas mencionadas, y los miembros del programa
aeroespacial han encontrado aceptable la adquisición del equipo para los requerimientos
de software y hardware.
VIABILIDAD ECONÓMICA
Buena parte de las herramientas usadas para la elaboración del simulador son de libre
distribución o de licencia gratuita. Esto significa que los gastos del proyecto se reducen
significativamente a los que se tendría en caso de emplear otras de licencia menos
209 - 236
accesible. Este proyecto al ser un simulador, es constituido prácticamente por código en
su totalidad.
La única parte en la que el hardware emplea un papel es en el equipo en el cual se instala

el software. El hecho que funciona exclusivamente a base de su código hace que se
pueden realizar los cálculos necesarios en menor cantidad de tiempo.
Tabla 80: Costo de requerimientos.
REQUERIMIENTO COSTO REQUERIMIENTO COSTO

COMPONENTE
MINIMO IDEAL
HARDWARE
Equipo Equipo de escritorio Bs Equipo de escritorio Bs

con Procesador 1064.78 con Procesador 1634.54
Core 5, RAM de Core i7, RAM 15 Gb,
4Gb, Disco duro de Disco duro de 1 Tb y
500 Gb y Sistema de Sistema de 64 bits y
32 bits 32 bits
COSTO TOTAL Bs 1064.780 Bs 1634.54
SOFTWARE
Sistema Windows 7 Bs 75.66 Windows 10 Bs

Operativo 552.08
Gestor de Base MongoDB 2.0.0 Bs 0 MongoDB 3.18.0 Bs 0

de Datos
210 - 236
REQUERIMIENTO COSTO REQUERIMIENTO COSTO
COMPONENTE
MINIMO IDEAL
Lenguaje Python 2.7 Bs 0 Python 2.7 o

superior
COSTO TOTAL Bs 1140.44 Bs 2186.62
Para realizar el cálculo de los costos que tendrá nuestro proyecto empleamos el modelo
COCOMO o Modelo Constructivo de Costos. Estos se dividen en tres categorías de
modelo:
 Modelo Básico: Calcula el esfuerzo de desarrollo de software y el costo en función

del tamaño del programa.
 Modelo Intermedio: Calcula el esfuerzo de desarrollo de software en función del
tamaño del programa y un conjunto de "controladores de costos" que incluyen la
evaluación subjetiva del producto, el hardware, el personal y los atributos del
proyecto.
 Modelo Detallado: Incorpora todas las características de la versión intermedia con
una evaluación del impacto del controlador.
El proyecto se desarrollará empleando el modelo de COCOMO intermedio. Aparte de

estos tipos de modelo, también se los clasifica en tipos de proyecto:
 Proyectos Orgánicos: Emplea "pequeños" equipos con "buena" experiencia

trabajando con requisitos "menos que rígidos".
 Proyectos Medios: Donde equipos "medianos" con experiencia mixta trabajando con
una mezcla de requisitos rígidos y menos rígidos.
211 - 236
 Proyectos Empotrados: Desarrollados dentro de un conjunto de restricciones
"estrictas".
En este caso, el proyecto cae bajo la categoría de Proyectos Medios, por el nivel de
condiciones que debe cumplirse. En el caso del COCOMO básico se emplean las
siguientes fórmulas:
𝐸 = 𝐸𝐴𝐹 ∗ 𝑎 ∗ 𝐾𝐿𝑂𝐶 𝐵
𝐷 = 𝑐 ∗ 𝐸𝑑
𝐸 𝑆𝐿𝑂𝐶
𝑃= 𝑃𝑅 =
𝐷 𝐸
Donde E es el esfuerzo aplicado en el proyecto, D es el tiempo de desarrollo PR es la

productividad y P es la cantidad de personas necesarias para realizar el proyecto. Por
otro lado a, b, c, y d son constantes cuyo valor es definido según el tipo de proyecto.
Por otro lado, KLOC es el número estimado de líneas de código del proyecto. Cantidad
que es usualmente estimada en la escala de los miles. Estos datos se encuentran en la
tabla siguiente:
Tabla 81: Valores de coeficientes de COCOMO.
PROYECTO A B c D
Orgánico 3,2 1,05 2,5 0,38
Medio 3,0 1,12 2,5 0,35
Empotrada 2,8 1,20 2,5 0,32
212 - 236
Por otro lado, EAF es un valor que se consigue mediante establecimiento de 15 factores
de costo específicos que determinan la duración y el costo del proyecto. A continuación
se tiene la descripción de las características para dicha estimación de costos.
Tabla 82: Factores de costo en COCOMO
VALOR
ATRIBUTOS
MUY MUY EXTRA
BAJO NOMINAL ALTO
BAJO ALTO ALTO
ATRIBUTOS DE SOFTWARE
Fiabilidad requerida del

0,75 0,88 1,00 1,15 1,40 -
software
Tamaño de Base de
- 0,94 1,00 1,08 1,16 -
datos
Complejidad del
0,70 0,85 1,00 1,15 1,30 1,65
producto
ATRIBUTOS DE HARDWARE
Restricciones de tiempo
- - 1,00 1,11 1,30 1,66
de ejecución
Restricciones de
almacenamiento - - 1,00 1,06 1,21 1,56
principal
213 - 236
VALOR
ATRIBUTOS
MUY MUY EXTRA
BAJO NOMINAL ALTO
BAJO ALTO ALTO
Volatilidad de la
- 0,87 1,00 1,15 1,30 -
máquina virtual
Tiempo de respuesta del

- 0,87 1,00 1,07 1,15 -
ordenador
ATRIBUTOS DE PERSONAL
Capacidad de análisis 1,46 1,19 1,00 0,86 0,71 -
Experiencia en la
1,29 1,13 1,00 0,91 0,82 -
aplicación
Calidad de los
1,42 1,17 1,00 0,86 0,70 -
programadores
Experiencia en S.O
1,21 1,10 1,00 0,90 - -
utilizado
Experiencia en el
lenguaje de 1,14 1,07 1,00 0,95 - -
programación
ATRIBUTOS DEL PROYECTO
214 - 236
VALOR
ATRIBUTOS
MUY MUY EXTRA
BAJO NOMINAL ALTO
BAJO ALTO ALTO
Prácticas de
1,24 1,10 1,00 0,91 0,82 -
programación modernas
Utilización de
herramientas de 1,24 1,10 1,00 0,91 0,83 -
software
Limitaciones de
planificación del 1,22 1,08 1,00 1,04 1,10 -
proyecto
Si ponemos a la práctica todas estas fórmulas entonces tenemos:
𝑆𝐿𝑂𝐶 = 4028 𝐿𝑖𝑛𝑒𝑎𝑑 𝑑𝑒 𝐶𝑜𝑑𝑖𝑔𝑜
𝐾𝐿𝑂𝐶 = 4.028 𝐿𝑖𝑛𝑒𝑎𝑠 𝑑𝑒 𝐶𝑜𝑑𝑖𝑔𝑜
El proyecto en total se tiene 4028 líneas de código, sin embargo este número necesita
ser dividido por mil, debido de KLOC debe tener valor de cada mil líneas de código. Así
que el valor de KLOC seria 4,028.
215 - 236
𝐸𝐴𝐹 = 1.4 ∗ 1.0 ∗ 1.15 ∗ 1.11 ∗ 1.06 ∗ 0.87 ∗ 1.15 ∗ 0.86 ∗ 1 ∗ 1 ∗ 1 ∗ 1.07
∗ 0.91 ∗ 1,0 ∗ 1,0 = 1.587
Justificación de los valores de conductores de costo
 Software:
o Fiabilidad requerida del software:
Si existe algún dato erróneo ingresado para dar inicio a los cálculos básicos
implementados en el presente proyecto, por ejemplo incorrecto medidas del tamaño de
la pastilla estos pueden generar error en el sistema (V. Muy Alto)
o Tamaño de la base de datos:
La base de datos del sistema resulta ser de tamaño grande (V. Nominal)
o Complejidad del producto
El sistema se considera complejo porque requiere mucha implementación de código ya

que maneja gran cantidad de datos en el manejo de los datos (V. Alta)
 Hardware:
o Restricciones del tiempo de ejecución:
Se considera que el tiempo que tarda en ejecutarse la aplicación es alta (V. Alta)
o Restricciones del almacenamiento principal:
Se considera alta ya que se requiere hacer referencia a diferentes tecnologías para su

correcto funcionamiento (V. Alta)
o Volatilidad de la máquina virtual:
Se utilizara máquina virtual para ver que esté trabajando en Linux (V. Muy Bajo)
o Tiempo de respuesta del ordenador
Según los requerimientos el rendimiento es muy alto (V. Muy Alto)
216 - 236
 Atributos del personal:
o Capacidad de análisis:
Es alto dado que conoce los suficientes aspectos del proyecto (V. Alto)
o Experimentación en la aplicación:
No se cuenta con el conocimiento suficiente para el uso e implementación de algunas

tecnologías aplicadas en el proyecto (base de datos no relacionales, motores gráficos
2D), esto debido al coro tiempo de trabajo con estas y a la poca información presente
en medios como internet acerca del tema (V. Nominal)
o Calidad de los programadores:
Se debe contar con un alto conocimiento en programación y en el lenguaje implementado

dada las características que tiene el proyecto para su desarrollo (V. Nominal)
o Experiencia en S.O utilizado
El sistema operativo utilizado es Windows 7, por lo tanto, la experiencia es suficiente a un

nivel de usuario final (V. Nominal)
o Experiencia en el lenguaje de programación:
Se debe tener conocimiento en las tecnologías usadas para aplicarlas en el proyecto (V.
Bajo)
 Atributos del proyecto:

o Prácticas de programación modernas:
Se requieren prácticas y uso de herramientas de programación modernas para el

correcto desarrollo del proyecto (V. Alta)
o Utilización de herramientas software:
Dado que el proyecto abarca el uso de diferentes tecnologías de software, por tanto se
requiere un conocimiento basto de las mismas (V. Nominal)
217 - 236
o Limitaciones de planificación del proyecto:
Existen ciertas limitaciones comunes pero no las suficientes como para considerarlo
inviable (V. Nominal).
o Limitaciones de planificación del proyecto:
Existen ciertas limitaciones comunes pero no las suficientes como para considerarlo
inviable (V. Nominal).
Finalmente se procede a los respectivos cálculos siguientes:
EAF, por su parte, selecciona su valor en base a los factores cumplidos en el proyecto
por los desarrolladores. Una vez se sepa los valores de EAF y KLOC se puede proceder
con el cálculo de las formulas:
𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠
𝐸 = 1.587 ∗ 3,0 ∗ 4,0281,12 = 22.668
𝑚𝑒𝑠
𝐷 = 2,5 ∗ 22.6680,35 = 7.453 𝑚𝑒𝑠𝑒𝑠
22.668
𝑃= = 3.041 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠
7,453
4028 𝑆𝐿𝑂𝐶
𝑃𝑅 = = 177,695 ∗ 𝑀𝑒𝑠
22,668 𝑃𝑒𝑟𝑠𝑜𝑛𝑎
Tras haber aplicado las fórmulas de COCOMO podemos decir que el esfuerzo aplicado
en el proyecto es de 22,668 personas por mes, durante aproximadamente 7 meses con
alrededor de 3 personas. Sin embargo se debe destacar que en este caso el proyecto se
desarrolló con 2 personas, así que se debe calcular los costos tomando en cuenta dicha
condición.
Los desarrolladores trabajaron un mínimo de cuatro horas diarias, en las diferentes

tareas para la realización del proyecto. Cosa que se traduce en aproximadamente 122
horas al mes.
218 - 236
𝑇𝑜𝑟𝑎𝑙 𝐻𝑜𝑟𝑎𝑠 𝑑𝑒 𝑇𝑟𝑎𝑏𝑎𝑗𝑜 = 121.667 ∗ 7,453 = 906,784 ℎ𝑜𝑟𝑎𝑠
Como medida de referencia para calcular el costo del proyecto, se asume que el sueldo
para el área de programación en Bolivia es de alrededor de Bs 34.55 la hora.
Por lo tanto el costo estimado del proyecto sería:
906,784 ∗ 34,55 = 𝐵𝑠 31329,392
Con el cálculo realizado se estima que el costo estimado del proyecto es de

𝐵𝑠 31140,231. Ahora se puede calcular el costo mínimo e ideal estimado del proyecto.
Tabla 83: Costo mínimo estimado.
DESCRIPCIÓN COSTO
Recursos de hardware y software 1140.44
Desarrollo de proyecto 31329.392
TOTAL 32469,832
Tabla 84: Costo ideal estimado.
DESCRIPCIÓN COSTO
Recursos de hardware y software 2186.62
Desarrollo de proyecto 31329.392
219 - 236
DESCRIPCIÓN COSTO
TOTAL 33516.012
Ahora que se sabe cuáles son los costos estimados, toca realizar el análisis
costo/beneficio, donde los cálculos son la base de un estimado de tareas realizadas por
el programa aeroespacial.
Tabla 85: Tabla de costos con y sin sistema.
SISTEMA ACTUAL SISTEMA

DESCRIPCIÓN
(Bs) PROPUESTO (Bs)
Costo empleado en la fabricación de una

unidad piloto de un prototipo para 12500 12500
pruebas de campo.
Costo de fabricación de unidades extra

87500 0
para repeticiones de pruebas
Costo de adquisición de ingredientes

343.75 68.75
para fabricación de propelente.
Costo de adquisición de material de

2917.53 416.79
construcción del fuselaje del cohete.
Costo de fabricación de unidades por

33577.996 0
pedido a organizaciones externas
220 - 236
SISTEMA ACTUAL SISTEMA
DESCRIPCIÓN
(Bs) PROPUESTO (Bs)
TOTAL COSTO/MES 11403.273 1082.128
TOTAL COSTO/AÑO 117711.280 12985.54
Para el cálculo de la estimación Beneficio/Costo se tiene:
𝑌𝑛
∑𝑛𝑛=1
𝐵⁄ = (1 + 𝑖)𝑛
𝐶 𝐶𝑛
𝐼0 + ∑𝑛𝑛=1
(1 + 𝑖)𝑛
Donde Y es el beneficio, Cn es el costo, n es el tiempo de vida de duración del proyecto,

i es la tasa de interés (usualmente de 2,3). El tiempo de vida para el proyecto sería de
alrededor de unos 5 años. Tomando en cuenta esto y aplicando la formula tenemos lo
siguiente:
𝑛=5
𝑌𝑛 = 11403.273 − 1082.128 = 10321.145
𝑖 = 2,3% ≅ 0.023
𝐶𝑛 = 1082.128
𝐼0 = 34718.7558
10321.145 10321.145 10321.145 10321.145

+ + +
𝐵⁄ = 1.0231 1.0232 1.0233 1.0234
𝐶 1082.128 1082.128 1082.128 1082.128
34718.756 + ( + + + )
1.0231 1.0232 1.0233 1.0234
221 - 236
𝐵⁄ = 39018.974 = 1.005 > 1
𝐶 38809.729
Al obtener el resultado, siendo este mayor a 1 se puede concluir que los beneficios que
se obtienen con la implantación del proyecto son justificables respecto al costo invertido
para su desarrollo, por lo tanto el proyecto es económicamente viable.
VIABILIDAD OPERATIVA
Para demostrar la viabilidad operativa se realiza un análisis para verificar que el

programa pueda hacer simulaciones con los distintos propelentes, fuselajes y
condiciones de vuelo posibles, también reducirán los tiempos empleados en la creación
de nuevos prototipos.
Para garantizar el funcionamiento favorable del software, es preferible que el usuario

tenga conocimientos referentes a la química y física, particularmente en el área que
incluya conocimientos de cómo realizar una mezcla de un propelente, las dimensiones
apropiadas de un cohete, resistencia de los materiales a fracturas y otros peligros que
enfrente, y cómo se comporta un cohete durante el vuelo. Todo esto con el motivo de
que se utilicen datos de entrada apropiados para el proceso descrito en este documento.
Para el sistema propuesto se toma en cuenta solo un actor, el Usuario que emplea el software
para simular el lanzamiento de un cohete. Las funciones que ejecuta el usuario incluyen:
 Definir datos de Propelente

o Agregar Ingrediente
 Definir datos de Grano o Pastilla
 Definir datos de Motor
o Definir datos de Oxidante y Combustible
o Definir datos de presiones
o Definir datos de Rendimiento
 Definir datos de Fuselaje
o Definir datos de Tubo o Cuerpo
o Definir datos de Aletas
222 - 236
o Definir datos de Nariz
 Definir datos de Vuelo
Como todas las personas que hagan uso del software caen dentro del rol de Usuario,
toda persona tiene el mismo nivel de permisos dentro del software. Se tendrá la opción
de desarrollar motores por separado debido a que comúnmente se empieza a diseñar un
cohete con un motor previamente definido. Es decir, se tiene un motor determinado
puede ser emplean en distintos diseños de cohetes, a menos que se necesite diseñar un
cohete desde cero, en cuyo caso se debe diseñar el motor también.
Los resultados obtenidos con el software, consisten casi completamente de datos

estadísticos, es decir datos como impulso específico, densidad, volumen y demás,
aunque también se emplean tablas para simular la regresión o disminución de propelente
a medida que progresa el vuelo. Además se cuenta con gráficos para mostrar el
rendimiento del motor entre otros datos del cohete.
Actualmente, el desarrollo de prototipos tiene que ponerse en pausa debido a que todas
las partes de un prototipo lleguen porque las partes se consiguen mediante pedidos a
distribuidores los cuales demoran en llegar, con el sistema propuesto será posible
simular los prototipos con los componentes que desee implementar los desarrolladores.
La cantidad de tiempo empleado en la creación de prototipos se reducirá porque se

podrá simular todos los pasos para poder construir los prototipos. Las interfaces que se
emplean son adecuadas a las necesidades planteadas por el Programa Aeroespacial
que son muy fáciles de entender los miembros del programa aeroespacial.
223 - 236
5. CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
El presente trabajo se realizó para la representación de prototipos de cohetes y la

verificación de cámara de combustión los cuales ayudarán con la creación de los nuevos
prototipos y se realizarán en menos tiempo. Tras haber desarrollado el proyecto, se
puede decir que se lograron cumplir con los objetivos establecidos al principio de la
realización del mismo. Para lo cual se tiene las siguientes conclusiones:
 Se analizaron los datos de los nuevos prototipos que se elaboran en el Programa

Aeroespacial y se tradujo de manera satisfactoria los diferentes aspectos del proceso
de elaboración actual de cohetes, desde el mundo real a las funciones codificadas
dentro del software para poder simular de manera cercana a la realidad de dicho
proceso y que permitir corregir los errores de diseño de los prototipos.
 Usando los datos obtenidos previamente se determinaron las grandes falencias
destacadas dentro del proceso por el Programa Aeroespacial para ser tratadas y
dedicarles la atención, reflexión y medidas necesarias para contrarrestarlas, y ser
aplicadas en la formulación de los modelos para representar las etapas de la
elaboración de cohetes.
 Se llevó a cabo la implementación de los modelos formulados para simulación
listados a continuación:
o La parte del propelente que sirve para la recreación de la mezcla de los químicos,
donde se expone claramente la complejidad de los cálculos realizados en el trasfondo
durante esta etapa.
o La parte de creación del motor es aquella donde se introducirán los datos del grano
de propelente, las dimensiones que tendrá la cámara de combustión, datos del
oxidante y combustible para hallar el volumen de la cámara, el área inicial de la
garganta y permitirá visualizar un gráfico en 3D de la pastilla. Empleando y generando
una serie de datos que influyen al desempeño final del cohete.
224 - 236
o Datos de las partes del fuselaje, especificando sus diferentes dimensiones, su
material de construcción y se consigue un gráfico en 2D, donde se ilustra la apariencia
final que tendría el diseño del prototipo una vez se realice una unidad física.
o Datos de vuelo del cohete, donde se pone a prueba el rendimiento del vuelo mediante
el cálculo de su velocidad máxima, su altura máxima y otros datos que sean
relevantes a medir su efectividad durante el viaje a través del aire, en base a los datos
obtenidos.
Todo esto haciendo uso de distintas herramientas que ayudan a mejorar la

organización como la metodología Scrum la que permite dividir en diferentes Sprint
cada parte del modelo de simulación , el lenguaje de programación Python porque
es el más adecuado para hacer simulación y también tiene librerías que ayudan con
la parte química (scipy) y mejorar el almacenamiento con la base de datos no
relacional de MongoDB que permite realizar consultas y captura de datos de una
forma flexible.
 Tras haber terminado el código necesario de cada etapa del proceso, se llevaron a
cabo distintos experimentos usando datos de entrada definidos previamente por el
Programa Aeroespacial, para calcular los datos necesarios y verificar que el
simulador devuelve valores que coinciden con pruebas en la vida real llevadas a cabo
anteriormente.
El modelo de simulación permite visualizar, sin necesidad de la construcción real del

prototipo, evaluar las características ideales, los resultados que se obtienen y poder
traducir en un prototipo real en base a las características analizadas en el simulador. El
presente proyecto ayuda a realizar la creación de prototipos desde la parte más critica
que es la mezcla de los químicos para la creación de los propelentes, se crean la parte
del motor, diseño del fuselaje y recreación de las condiciones de vuelo con estos datos
son posibles realizar la recreación de nuevas unidades y con estos datos ayudara que
las unidades sean recreados en menos tiempo y que no consuma recursos
225 - 236
RECOMENDACIONES
Las recomendaciones que pueden ser aconsejadas por los desarrolladores del proyecto
para el buen funcionamiento del sistema incluyen:
 El usuario que desee manejar el software para sus propios motivos, debe tener
capacitación en el área de desarrollo de cohetes, o al menos un nivel de conocimiento
básico sobre el tema.
 Mantener actualizados los datos de las tablas de JANAF así como los demás datos
que emplea el software en su funcionamiento.
 También se recomienda hacer los mantenimientos mencionados cada seis meses
debido a la gran cantidad de datos que maneja.
Entre las recomendaciones a futuro que se puedan dar, esta:
 Se recomienda en el futuro agregar, más modelos en 3d para graficar e ilustrar como

iría a quedar el diseño final del cohete.
 Además, realizar posible modificaciones para maximizar la capacidad de las
interfaces de ser responsivas ante diversos tamaños de pantalla.
 Mejorar la dinámica o flexibilidad del cálculo de los datos del propelente, así como en
las otras fórmulas empleadas en el programa.
226 - 236
BIBLIOGRAFÍA
REFERENCIAS DE LIBROS
Banks, J., Carson, J., Nelson, B., & Nicol, D. (2010). Discrete-Event System Simulation.
Pearson Education Limited.
Banks, J. (Ed.). (1998). Handbook of simulation: principles, methodology, advances,

applications, and practice. John Wiley & Sons.
Bass, L., Clements, P., & Kazman, R. (2012). Software Archutecture in Practice. Addison-
Wesley.
Beck, K., & Andres, C. (2004). Extreme Programming Explained. Addison-Wesley

Professional.
Bozo, M. A. (2016). Sistema de estabilización electrónico para el cohete V4-20000.

Escuela Militar de Ingeniería.
Bu, R. C. (1993). Simulacion: Un enfoque practico. Limusa Noriega Editores.
Collier, K. W. (2011). Agile Analytics: A Value-Driven Approach to Business Intelligence

and Data Warehousing. Pearson Education.
Davenas, A. (2012). Solid Rocket Propulsion Techonology. Technology & Engineering.
Desrochers, M. F., Olsen, G. W., & Hudson, M. K. (2001). A ground test rocket thrust
measurement system. Journal of Pyrotechnics.
Dinesh Kumar B., Shishir Nayana B. & Shravya Shree D. (2016). Design and Structural
Analysis of Solid Rocket Motor Casing Hardware used in Aerospace Applications.
Journal of Aeronautics & Aerospace Engineering.
Fontana, A., & Prokos, A. H. (2016). The Interview: From Formal to Postmodern.
Routledge.
Gómez, J. L. (2011). AutoCAD 3D : dibujo y modelado. RC Libros.
227 - 236
IEEE (1991). IEEE Standard Glossary of Software Engineering Terminology. Institute of
Electrical and Electronic Engineers.
Kedar, S. (2009). Database Management Systems. Technical Publications.
Kingwell, J., Shimizu, J., Narita, K., Kawabata, H., & Shimizu, I. (1991). Weather factors
affecting rocket operations: a review and case history. Bulletin of the American
Meteorological Society.
Kuo, K., K. (1984). Fundamentals of solid-propellant combustion. American Institute of

Aeronautics and Astronautics
Laplante, P. A. (2007). What Every Engineer Should Know about Software Engineering.
CRC Press.
McConnell, S. (1996). Rapid Development. Microsoft Press.
Milligan, T. V. (2013). Exploring Rocketry Through The Use of Research Wind Tunnels.
Apogee Components, Inc.
MITRE Corporation. (2012). MITRE Systems Engineering Guide. MITRE Publications.
Pressman, R. (1997). Ingenieria de software: Un enfoque practico. McGraw-Hill

Interamericana Editores S.A.
Programa aeroespacial. (2016). Centro de Investigacion de Ciencia y Tecnologia del

Ejercito CICTE. Programa de desarrollo en tecnologia aeroespacial.
Roff, J. (2003). UML: A Beginner's Guide. McGraw Hill Professional.
Romano, F. (2015). Learning Python. Packt Publishing.
Russell, S. J., & Norvig, P. (2003). Artificial Intelligence: A Modern Approach. Upper
Saddle River, Nueva Jersey, EE.UU.: Pearson Education, Limited.
Schwartz, B. (2012). High Performance MySQL: Optimization, Backups, and Replication.

O'Reilly Media Inc.
228 - 236
Thalheim, B. (2013). Entity-Relationship Modeling: Foundations of Database Technology.
Springer Science & Business Media.
Tilley S. & Floss B. (2014). Hard Problems in Software Testing: Solutions Using Testing
as a Service. Morgan & Claypool Publishers.
Wehrle, K., Günes, M., & Gross, J. (2010). Modeling and Tools for Network Simulation.
Springer Science & Business Media.
REFERENCIAS DE PÁGINAS WEB
Administración de Requerimientos. (2017). LOS CASOS DE USO SUS VENTAJAS Y

DESVENTAJAS. Extraído de:
https://administracionderequerimientos.wordpress.com/2014/08/27/los-casos-de-
uso-sus-ventajas-y-desventajas. Fecha de Consulta: 20 de octubre de 2017.
Aha! Labs Inc, (2017). Agile Development Definition and Examples. Extraído de:
https://www.aha.io/roadmapping/guide/agile-development. Fecha de Consulta: 25
de octubre de 2017.
AnyLogic. (2017). Use of Simulation – AnyLogic Simulation Software. Extraído de:

https://www.anylogic.com/use-of-simulation. Fecha de Consulta: 20 de octubre de
2017.
Apple Inc. (2015). Model-View-Controller Extraido de:

https://developer.apple.com/library/content/documentation/General/Conceptual/D
evPedia-CocoaCore/MVC.html. Fecha de Consulta: 9 de abril de 2017.
Autodesk. (2017). 3D Modeling and Texture Mapping | 3DS Max | Autodesk. Extraido de:
http://www.autodesk.com/products/3ds-max/features/3d-modeling-and-texturing.
Fecha de Consulta: 6 de abril de 2017.
Blender. (2017). About | Blender.org. Extraido de: https://www.blender.org/about/. Fecha

de Consulta: 6 de abril de 2017.
229 - 236
Candillo J., Gil E., Alvarez E. & Rios M. (2012). Diagramas de Secuencia. Extraído de:
https://www.slideshare.net/evealva1302/diagrama-de-secuencia-2. Fecha de
Consulta: 20 de octubre de 2017.
Chandana. (2013). Scrum Project Management - Pros and Cons. Extraido de:
https://www.simplilearn.com/scrum-project-management-article. Fecha de
Consulta: 5 de abril de 2017.
CodeJava. (2015). Features of Java Programming Language. Extraido de:

http://www.codejava.net/java-core/features-of-the-java-programming-language.
Cuevas E. (2016). MVC (Modelo-Vista-Controlador). Extraído de:

https://prezi.com/yslnu82y6lmh/mvcmodelo-vista-controlador/. Fecha de
Encyclopedia Britannica. (2017). Computer Simulation. Extraído de:

https://www.britannica.com/technology/computer-simulation. Fecha de Consulta:
20 de octubre de 2017.
Encyclopedia Britannica. (2017). rocket and missile system - Tactical guided missiles |
weapons system | Britannica.com. Extraido de:
https://www.britannica.com/technology/rocket-and-missile-system/Tactical-
guided-missiles. Fecha de Consulta: 30 de octubre de 2017.
Entrevista de Trabajo.Org. (2017). Entrevista estructurada o preparada. Extraído de:

https://www.entrevistadetrabajo.org/entrevista-estructurada.html. Fecha de
Entrevista de Trabajo.Org. (2017). Entrevista no estructurada o libre. Extraído de:

https://www.entrevistadetrabajo.org/entrevista-no-estructurada-o-libre.html.
Fecha de Consulta: 21 de octubre de 2017.
230 - 236
Fowler, A. (2017). COMMON FEATURES OF NOSQL. Extraído de:
http://www.dummies.com/programming/big-data/common-features-of-nosql/.
Frontline Systems, Inc. (2017). Simulation Models. Extraido de:

https://www.solver.com/simulation-models. Fecha de Consulta: 22 de octubre de
2017.
Gamez L. (2014). MODELADO 3D COMPARATIVOS BLENDER SKETCH 3DS MAX.

Extraido de: https://prezi.com/lwr6kml1kyhl/modelado-3d-comparativos-blender-
sketch-3ds-max/. Fecha de Consulta: 20 de octubre de 2017.
Garling, C. (2012). AMAZON GOES BACK TO THE FUTURE WITH 'NOSQL'

DATABASE. Extraído de: https://www.wired.com/2012/01/amazon-dynamodb/.
Gosling, J., Joy, B., Steele, G., Bracha, G., & Buckley, A. (2015). docs.oracle.com.
Extraido de The Java Language Specification:
http://docs.oracle.com/javase/specs/jls/se8/jls8.pdf. Fecha de Consulta: 5 de abril
de 2017.
Gurendo, D. (2005). Scrum Development Life Cycle. Scrum Model Step By Step. Extraido
de: https://xbsoftware.com/blog/software-development-life-cycle-sdlc-scrum-step-
step/. Fecha de Consulta: 6 de abril de 2017.
Lacoma T. (2017). The Best 3D Modeling Software for Windows and MacOS | Digital
Trends. Extraído de: https://www.digitaltrends.com/computing/best-3d-modeling-
software/. Fecha de Consulta: 21 de octubre de 2017.
Leavitt, N. (2010). Will NoSQL Databases Live Up to Their Promise? Extraido de:
http://www.leavcom.com/pdf/NoSQL.pdf. Fecha de Consulta: 22 de octubre de
2017.
231 - 236
Lee Soltesz D. (2017). The Advantages of a Relational Database Management System.
Extraído de: https://www.techwalla.com/articles/the-advantages-of-a-relational-
database-management-system. Fecha de Consulta: 21 de octubre de 2017.
Mack, J. (2014). Five Advantages and Disadvantages of MySQL. Extraido de:

https://www.datarealm.com/blog/five-advantages-disadvantages-of-mysql/. Fecha
de Consulta: 5 de abril de 2017.
Martin, A. (2017). Disadvantages of a Relational Database. Extraído de:

https://www.techwalla.com/articles/disadvantages-of-a-relational-database.
Mary Dz. (2014). PATRON DE DISEÑO MVP. Extraído de:

https://prezi.com/ptmdkvfo51bt/patron-de-diseno-mvp/. Fecha de Consulta: 21 de
octubre de 2017.
Microsoft. (2016). Features in SQL Server Management Studio. Extraido de:

https://docs.microsoft.com/en-us/sql/ssms/features-in-sql-server-management-
studio. Fecha de Consulta: 5 de abril de 2017.
Microsoft. (2017). Architectural Patterns and Styles Extraido de:

https://msdn.microsoft.com/en-us/library/ee658117.aspx. Fecha de Consulta: 6 de
abril de 2017.
Microsoft. (2017). Diagramas de casos de uso de UML: Referencia. Extraído de:

https://msdn.microsoft.com/es-es/library/dd409427.aspx. Fecha de Consulta: 22
de octubre de 2017.
Microsoft. (2017). Diagramas de secuencia de UML: Instrucciones. Extraído de:

https://msdn.microsoft.com/es-es/library/dd409389.aspx. Fecha de Consulta: 22
de octubre de 2017.
Microsoft. (2017). Usar el patrón modelo-vista-modelo de vista (MVVM) en Hilo

(aplicaciones de la Tienda Windows con C++ y XAML). Extraido de:
232 - 236
https://msdn.microsoft.com/es-xl/library/windows/apps/jj160324.aspx. Fecha de
Microsoft. (2017). The Model-View-Presebter (MVP). Extraido de:

https://msdn.microsoft.com/en-us/library/ff649571.aspx. Fecha de Consulta: 9 de
abril de 2017.
MindsMapped. (2015). Java Advantages and Disadvantages. Extraido de:

http://blogs.mindsmapped.com/java-j2ee/java-advantages-and-disadvantages/.
Moufarrege, S. (2016). Advantages & Disadvantages of Microsoft SQL. Extraido de:

https://www.techwalla.com/articles/advantages-disadvantages-of-microsoft-sql.
National Aeronautics and Space Administration (NASA). (2017). Rocket Parts. Extraído
de: https://spaceflightsystems.grc.nasa.gov/education/rocket/rockpart.html. Fecha
de Consulta: 30 de octubre de 2017.
National Aeronautics and Space Administration (NASA). (2017). Rocket Stability.

Extraído de:
https://spaceflightsystems.grc.nasa.gov/education/rocket/rktstab.html. Fecha de
Oracle. (2017). MySQL. Extraido de:

http://www.oracle.com/technetwork/database/mysql/index.html. Fecha de
PlanetDestiny. (2015). Field Test Guide - PlanetDestiny. Extraído de:

planetdestiny.com/field-test-guide. Fecha de Consulta: 31 de octubre de 2017.
Pierce, W. (2016). Disadvantages and Advantages of Extreme Programming. Extraido

de: https://atlaz.io/blog/disadvantages-and-advantages-of-extreme-
programming/. Fecha de Consulta: 5 de abril de 2017.
233 - 236
Python. (2016). Begginers Guide/Overview. Extraido de:
https://wiki.python.org/moin/BeginnersGuide/Overview. Fecha de Consulta: 5 de
abril de 2017.
Richards, J. (2015). Advantages and Disadvantages of NoSQL databases – what you

should know. Extraído de:
https://www.hadoop360.datasciencecentral.com/blog/advantages-and-
disadvantages-of-nosql-databases-what-you-should-k. Fecha de Consulta: 22 de
octubre de 2017.
Rouse M. (2007). What is Use Case? Extraído del:

http://searchsoftwarequality.techtarget.com/definition/use-case. Fecha de
Science Learning Hub. (2011). Rocket aerodynamics — Science Learning Hub. Extraído
de: https://www.sciencelearn.org.nz/resources/392-rocket-aerodynamics. Fecha
de Consulta: 31 de octubre de 2017.
Shafer, D. (2002). Python in the enterprise: Pros and cons. Extraido de:
http://www.techrepublic.com/article/python-in-the-enterprise-pros-and-cons/.
SmartGeoMetrics. (2014). 4 benefits of 3D modeling for architects and engineers.

Extraído de: http://www.smartgeometrics.com/blog/engineering/4-benefits-of-3d-
modeling-for-architects-and-engineers/. Fecha de Consulta: 20 de octubre de
2017.
SOFTPEI. (2013). Implementando el patrón MVVM con ZK.I. Extraído de:

http://softpei.blogspot.com/2013/07/implementando-el-patron-mvvm-con-zk-
i.html. Fecha de Consulta: 20 de octubre de 2017.
Software Testing. (2014). RAD Model. Extraido de:

https://testingtypes.wordpress.com/tag/requirements-planning-phase. Fecha de
234 - 236
Sousa, S. d. (2009). The Advantages and Disadvantages of RAD Software Development.
Extraido de: http://www.my-project-management-expert.com/the-advantages-and-
disadvantages-of-rad-software-development.html. Fecha de Consulta: 5 de abril
de 2017.
Test Institute. (2017). Software Testing Levels. Extraido de: http://www.test-

institute.org/Software_Testing_Levels.php. Fecha de Consulta: 6 de abril de 2017.
The PostgreSQL Global Development Group. (2017). What is PostgreSQL?. Extraido de:
https://www.postgresql.org/docs/9.6/static/intro-whatis.html. Fecha de Consulta: 9
de abril de 2017.
ToolBox.Com. (2008). Characteristics of Relational Databases. Extraido de:

http://it.toolbox.com/blogs/enterprise-solutions/characteristics-of-relational-
databases-24134. Fecha de Consulta: 20 de octubre de 2017.
TutorialsPoint. (2017). Extreme Programming - Process Cycle. Extraído de:

https://www.tutorialspoint.com/extreme_programming/extreme_programming_pro
cess_cycle.htm. Fecha de Consulta: 21 de octubre de 2017.
TutorialsPoint. (2017). Software Testing - Levels. Extraído de:

https://www.tutorialspoint.com/software_testing/software_testing_levels.htm.
UML-Diagrams.Org. (2017). UML Sequence Diagrams. Extraido de: http://www.uml-

diagrams.org/sequence-diagrams.html. Fecha de Consulta: 23 de octubre de
2017.
UML-Diagrams.Org. (2017). UML Use Case Diagrams. Extraído de: http://www.uml-

diagrams.org/use-case-diagrams.html. Fecha de Consulta: 23 de octubre de 2017.
Universidad de Minesota. (2016). Data Collection Techniques | CYFAR. Extraido de:

https://cyfar.org/data-collection-techniques. Fecha de Consulta: 20 de marzo de
2017.
235 - 236
Universidad ICESI. (2017). Diagramas de Secuencia. Extraido de:
http://www.icesi.edu.co/departamentos/tecnologias_informacion_comunicaciones
/proyectos/lisa/home/analisis/diagramas_de_secuencia/inicio Fecha de Consulta:
22 de octubre de 2017.
W3i. (2017). MVVM - Ventajas. Extraido de:

http://www.w3ii.com/es/mvvm/mvvm_advantages.html. Fecha de ConsultaÑ 22
de octubre de 2017.
weaponsystems. (2016). Weaponsystems.net. Extraido de:

weaponsystems.net/weaponsystem/EE01 - HN-5.html. Fecha de Consulta: 20 de
marzo de 2017.
Wells D. (2013). Extreme Programing: A Gentle Introduction. Extraído de:

www.extremeprogramming.org. Fecha de Consulta: 21 de octubre de 2017.
236 - 236

Simulación de cohetes

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Simulación de cohetes

Încărcat de

Drepturi de autor:

Formate disponibile

ÍNDICE DE CONTENIDO

PLANTEAMIENTO DEL PROBLEMA ............................................................ 10

Identificación del Problema ........................................................................... 10

1.3.1.1. Identificación de la Situación Problemática .................................................... 10

1.3.1.2. Identificación de las causas ............................................................................ 10

Formulación del Problema .............................................................................. 11

Análisis Causa-Efecto .................................................................................... 11

1.3.3.1. Causa ............................................................................................................. 11

1.3.3.2. Efecto ............................................................................................................. 11

OBJETIVOS Y ACCIONES ............................................................................ 11

Objetivos Específicos y Acciones ................................................................... 12

Justificación Técnica ...................................................................................... 16

Justificación Económica ................................................................................. 16

Justificación Operativa .................................................................................. 16

Alcance institucional ....................................................................................... 17

Alcance Funcional .......................................................................................... 17

Análisis de Variables ...................................................................................... 18

1.7.1.1. Variable Independiente................................................................................... 18

1.7.1.2. Variable Dependiente ..................................................................................... 18

1.7.2.1. Variable Independiente................................................................................... 18

1.7.2.2. Variable Dependiente ..................................................................................... 18

Operativización de Variables .......................................................................... 19

MATRIZ DE CONSISTENCIA ........................................................................ 20

2. MARCO TEÓRICO ......................................................................................... 21

TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN ................................... 21

Análisis de documentos .................................................................................. 22

Modelos de desarrollo ágil .............................................................................. 24

2.2.1.1. Programación Extrema (XP) ........................................................................... 24

2.2.1.2. Scrum ............................................................................................................. 26

Pruebas de Software ...................................................................................... 32

2.2.2.1. Tipos de Prueba ............................................................................................. 33

SIMULACIÓN DE SISTEMAS ........................................................................ 34

Etapas para elaboración de un simulador ...................................................... 34

2.3.1.1. Herramientas de modelación .......................................................................... 35

2.3.1.2. Métodos de validación .................................................................................... 45

Herramientas de modelado en 3D .................................................................. 47

2.4.1.1. Blender ........................................................................................................... 47

2.4.1.2. AutoDesk 3DS Max ........................................................................................ 49

TECNOLOGÍAS DE DESARROLLO .............................................................. 50

Lenguaje de Programación ............................................................................ 50

2.5.1.1. Java ................................................................................................................ 50

2.5.1.2. Python ............................................................................................................ 53

Arquitectura de Software ................................................................................ 55

2.5.2.1. Patrones de Arquitectura ................................................................................ 55

Base de Datos ................................................................................................ 61

2.5.3.1. Tipos de Bases de Datos ............................................................................... 62

2.5.3.2. Software de Gestión de Bases de Datos ........................................................ 68

Análisis del proceso actual de desarrollo de prototipos .................................. 74

3.1.1.1. Planificación de Diseño de Prototipo .............................................................. 75

3.1.1.2. Fabricación del Propelente y las Pastillas ...................................................... 75

3.1.1.3. Construcción las piezas del motor de cohete ................................................. 77

3.1.1.4. Pruebas de Validación en Banco de Pruebas ................................................ 78

3.1.1.5. Planificación del Diseño de Fuselaje del Prototipo ......................................... 79

3.1.1.6. Pruebas de Validación del diseño del Prototipo ............................................. 80

3.1.1.7. Pruebas de Campo del Prototipo ................................................................... 80

Falencias del software de simulación ............................................................. 81

Definición del sistema propuesto .................................................................... 83

3.1.3.1. Requerimientos y estimaciones sobre el sistema a desarrollar ...................... 83

3.1.3.2. Definición de Variables ................................................................................... 84

3.1.3.3. Elaboración del modelo propuesto para el sistema ........................................ 90

FORMULACIÓN DE LOS MODELOS DE SIMULACIÓN PARA

3.2.1.1. Modelo de motor de combustible sólido. ........................................................ 91