Tes Is Roberto

UNIVERSIDAD MAYOR DE SAN SIMN
FACULTAD DE CIENCIAS Y TECNOLOGA

CARRERA DE INGENIERA DE SISTEMAS
LABORATORIO VIRTUAL DE FSICA, UNA
HERRAMIENTA DE APOYO PARA EL PROCESO DE
ENSEANZA APRENDIZAJE DE CINEMTICA
NEWTONIANA
Proyecto de grado, presentado para optar al diploma
acadmico de Licenciatura en Ingeniera de Sistemas
Presentado por: Luis Roberto Prez Rios.
Tutor: Ing. Roberto Juan Manchego Castelln.
COCHABAMBA BOLIVIA
DEDICATORIA
A mi querida familia, a mis grandes
amigos, a los docentes que
intervinieron en mi formacin y a
todos quienes me brindaron su
apoyo.
I
AGRADECIMIENTOS
A mi padre Roberto, por todos sus
consejos, por el gran ejemplo que
me da da a da y por el apoyo
incondicional que me brinda.
A mi madre Justina, por su cario,
ternura y comprensin que
me regala cada da.
A mi hermana Ana Karina, por dar
alegra a todos mis das.
A Soraya, por el amor y apoyo
que me brinda en todo
momento.
Al Ing. Roberto Manchego,
por ayudar a que sea
posible este proyecto.
A todos mis amigos por
su amistad
MUCHAS GRACIAS!
II
FICHA RESUMEN
En Bolivia no existe suficiente infraestructura de laboratorios de experimentacin,
consecuentemente esto imposibilita a los estudiantes de Fsica consolidar su
aprendizaje. A partir de la formacin como Ingeniero de Sistemas, el autor del
presente proyecto pretende aportar a la solucin de la situacin problemtica
antes mencionada mediante la construccin de un laboratorio virtual de Fsica
como herramienta de apoyo (medio didctico) para el proceso de enseanza
aprendizaje de cinemtica newtoniana.
El proyecto basa sus intenciones educativas en el paradigma de aprendizaje por
descubrimiento, posibilitando al estudiante un aprendizaje desarrollador y
significativo. El aprendizaje por descubrimiento permite a los docentes conducir la
enseanza a partir de la interaccin directa con el objeto de estudio, por lo que los
estudiantes tienden a comparar cuantitativa y cualitativamente la realidad con la
teora.
La construccin del software se basa fundamentalmente en las buenas prcticas
del desarrollo gil mediante la aplicacin de la metodologa XP, adems para el
anlisis y modelamiento de los fenmenos fsicos se utiliz la metodologa de
simulacin de eventos discretos.
La implementacin y puesta en prctica de LAVIFIS (Laboratorio Virtual de Fsica),
permite a los estudiantes centrar su atencin en el fenmeno fsico estudiado,
dejando de lado el proceso emprico de obtencin de datos que no es
determinante en la consolidacin del aprendizaje.
III
NDICE GENERAL
DEDICATORIA...........................................................................................................I
AGRADECIMIENTOS................................................................................................II
FICHA RESUMEN....................................................................................................III
CAPTULO 1. DESCRIPCIN DEL PROYECTO.....................................................1
1.1. INTRODUCCIN............................................................................................1
1.2. ANTECEDENTES...........................................................................................2
1.3. SITUACIN PROBLEMTICA.......................................................................3
1.4. OBJETIVOS....................................................................................................4
1.4.1. OBJETIVO GENERAL............................................................................4
1.4.2. OBJETIVOS ESPECFICOS...................................................................4
1.5. INNOVACIN TECNOLGICA......................................................................5
1.6. JUSTIFICACIN.............................................................................................6
1.7. ALCANCES Y LIMITACIONES.......................................................................7
1.7.1. ALCANCES.............................................................................................7
1.7.2. LIMITACIONES.......................................................................................7
1.8. METODOLOGA PARA EL DESARROLLO DEL PROYECTO......................8
CAPTULO 2. EDUCACIN Y EXPERIMENTACIN..............................................9
2.1. INTRODUCCIN............................................................................................9
2.2. EXPERIMENTO............................................................................................10
2.3. EXPERIMENTACIN EN LA EDUCACIN.................................................11
2.4. EXPERIMENTACIN CON AMBIENTES VIRTUALES EN LA EDUCACIN.
.............................................................................................................................13
2.5. APRENDIZAJE POR DESCUBRIMIENTO..................................................14
CAPTULO 3. FUNDAMENTOS DE CINEMTICA NEWTONIANA......................16
3.1. MECNICA NEWTONIANA.........................................................................16
3.2. CINEMTICA NEWTONIANA......................................................................17
3.3. ELEMENTOS DE CINEMTICA NEWTONIANA.........................................18
3.3.1. SISTEMA DE COORDENADAS...........................................................18
3.3.2. TIPOS DE MOVIMIENTO.....................................................................20
3.3.3. MOVIMIENTO RECTILNEO................................................................20
3.3.3.1. Movimiento rectilneo uniforme......................................................21
3.3.3.2. Rectilneo uniformemente acelerado.............................................23
3.3.3.3. Cada Libre.....................................................................................24
3.3.4. MOVIMIENTO MIXTO O PARABLICO...............................................26
CAPTULO 4. SIMULACIN DE SISTEMAS.........................................................28
4.1. INTRODUCCIN..........................................................................................28
4.2. SISTEMAS Y MODELOS.............................................................................29
4.3. EL PROCESO DE CONSTRUCCIN DE MODELOS................................31
4.4. SIMULACIN DE SISTEMAS CONTINUOS Y DISCRETOS......................33
4.5. MODELADO DE SISTEMAS DISCRETOS..................................................35
4.6. LA SIMULACIN COMO PROCESO EXPERIMENTAL..............................37
4.7. VENTAJAS Y DESVENTAJAS DE LOS MODELOS DE SIMULACIN......42
4.7.1. VENTAJAS............................................................................................43
4.7.2. DESVENTAJAS.....................................................................................44
CPITULO 5. INGENIERA DE SOFTWARE.........................................................45
5.1. INTRODUCCIN..........................................................................................45
5.2. PROCESO DEL SOFTWARE......................................................................46
5.2.1. MODELOS DEL PROCESO DE SOFTWARE......................................48
5.3. IMPLEMENTACIN DEL SOFTWARE........................................................52
5.3.1. GRUPOS DE TRABAJO EN EL DESARROLLO DE SOFTWARE......53
5.4. INGENIERA DE SOFTWARE ASISTIDO POR ORDENADOR..................57
5.4.1. LIMITACIONES.....................................................................................59
CAPTULO 6. METODOLOGAS DE DESARROLLO GIL..................................60
6.1. XP (PROGRAMACIN EXTREMA).............................................................60
6.1.1. PROCESO DE DE DESARROLLO EXTREMO....................................61
6.1.1.1. Interaccin con el cliente...............................................................61
6.1.1.2. Planificacin del proyecto.............................................................62
6.1.1.3. Diseo, desarrollo y pruebas.........................................................63
6.1.2. VALORES PROMOVIDOS POR XP.....................................................65
6.1.3. PRCTICAS DE LA PROGRAMACIN EXTREMA.............................66
6.1.4. CICLO DE VIDA DE UN PROYECTO XP.............................................71
6.2. SCRUM.........................................................................................................75
6.2.1. DESARROLLO GIL Y SCRUM...........................................................77
6.2.2. ROLES EN SCRUM..............................................................................78
6.2.3. PRINCIPALES ACTIVIDADES EN SCRUM.........................................83
6.2.3.1. Reunin de planificacin del sprint................................................85
6.2.3.2. Reunin diaria de Scrum (Scrum Daily Meeting)..........................88
6.2.3.3. Revisin del Sprint (Sprint Review)...............................................89
6.2.4. PRINCIPALES ARTEFACTOS DE SCRUM..........................................91
6.2.4.1. Lista de tareas de producto (Product Backlog).............................92
6.2.4.2. Lista de tareas del Sprint (Sprint Backlog)....................................93
6.2.4.3. Grficos de trabajo pendiente. (Burndown Chart).........................94
6.2.5. RETOS HABITUALES EN SCRUM......................................................96
6.2.6. RESUMEN DE SCRUM........................................................................99
CAPTULO 7. HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DEL
SOFTWARE...........................................................................................................101
7.1. LENGUAJE DE PROGRAMACIN JAVA..................................................101
7.1.1. CARACTERSTICAS DE JAVA...........................................................102
7.1.1.1. Lenguaje de programacin orientado a objetos..........................102
7.1.1.2. Distribuido....................................................................................102
7.1.1.3. Interpretado..................................................................................103
7.1.1.4. Robusto........................................................................................104
7.1.1.5. Seguro..........................................................................................104
7.1.1.6. Independiente del hardware........................................................106
7.1.1.7. Portable........................................................................................107
7.1.1.8. Dinmico......................................................................................107
7.1.1.9. Multitarea.....................................................................................108
7.1.1.1. Sintaxis simple.............................................................................109
7.2. ENTORNO INTEGRADO DE DESARROLLO: NETBEANS......................109
7.3. FRAMEWORK DE PRUEBAS UNITARIAS: JUNIT...................................110
CAPTULO 8. DESARROLLO DEL PROYECTO.................................................111
8.1. MODELAMIENTO DE EXPERIMENTOS...................................................111
8.1.1. PLANTEAMIENTO DEL PROBLEMA DE SIMULACIN Y
PLANIFICACIN DE SU ESTUDIO..............................................................111
8.1.1.1. Planteamiento del Problema de Simulacin................................112
8.1.1.2. Estudio del Problema de Simulacin...........................................112
8.1.1.2.1. Observacin del movimiento de partculas en el vaco........112
8.1.1.2.2. Observacin del movimiento de esferas en un medio distinto
del vaco................................................................................................113
8.1.1.2.3. Estudio de leyes del movimiento en el vaco.......................113
8.1.1.2.3.1. Movimiento constante...................................................113
8.1.1.2.3.2. Movimiento acelerado...................................................114
8.1.1.2.4. Estudio de fuerzas que actan sobre una partcula en reposo.
..............................................................................................................117
8.1.1.2.5. Estudio de fuerzas que actan sobre una partcula en
movimiento............................................................................................120
8.1.1.2.6. Clculo de la aceleracin de la partcula..............................122
8.1.2. RECOLECCIN Y FUENTE DE DATOS............................................123
8.1.3. CONSTRUCCIN Y VERIFICACIN DEL MODELO PARA
COMPUTADORA..........................................................................................124
8.1.3.1. Descripcin de contantes y variables de la simulacin...............125
8.1.3.2. Algoritmo general de la simulacin..............................................127
8.1.4. EJECUCIN DE PRUEBAS...............................................................127
8.1.5. VALIDACIN DEL MODELO..............................................................128
8.1.6. DISEO DE LOS EXPERIMENTOS DE SIMULACIN.....................128
8.2. DESARROLLO DEL LABORATORIO VIRTUAL........................................129
8.2.1. ROLES ASIGNADOS SEGN LA METODOLOGA XP......................129
8.2.2. DOCUMENTACIN DEL SOFTWARE...............................................130
8.2.3. HISTORIAS DE USUARIO.................................................................131
8.2.4. LISTA PRIORIZADA DE HISTORIAS DE USUARIO..........................136
8.2.5. PROTOTIPO DEL SOFTWARE..........................................................138
8.2.6. PLANIFICACIN DE LAS ENTREGAS..............................................139
8.2.7. PRIMERA ITERACIN.......................................................................141
8.2.7.1. Plan de la primera iteracin.........................................................141
8.2.7.2. Desarrollo de la primera iteracin................................................141
8.2.7.2.1. Implementacin....................................................................142
8.2.7.2.2. Refactorizacin.....................................................................147
8.2.7.2.3. Diagrama de clases..............................................................147
8.2.7.2.4. Diagrama de casos de uso...................................................148
8.2.7.2.5. Pruebas a la primera iteracin..............................................149
8.2.8. SEGUNDA ITERACIN......................................................................149
8.2.8.1. Plan de la segunda iteracin.......................................................149
8.2.8.2. Desarrollo de la segunda iteracin..............................................150
8.2.8.2.1. Implementacin....................................................................150
8.2.8.2.2. Refactorizacin.....................................................................157
8.2.8.2.5. Pruebas a la segunda iteracin............................................159
8.2.9. TERCERA ITERACIN.......................................................................160
8.2.9.1. Plan de la tercera iteracin..........................................................160
8.2.9.2. Desarrollo de la tercera iteracin.................................................160
8.2.9.2.1. Implementacin....................................................................160
8.2.9.2.2. Refactorizacin.....................................................................173
8.2.9.2.5. Pruebas a la tercera iteracin...............................................175
8.2.10. CUARTA ITERACIN.......................................................................176
8.2.10.1. Plan de la cuarta iteracin.........................................................176
8.2.10.2. Desarrollo de la cuarta iteracin................................................176
8.2.10.2.1. Implementacin..................................................................177
8.2.10.2.2. Refactorizacin...................................................................183
8.2.10.2.3. Diagrama de clases............................................................184
8.2.10.2.4. Diagrama de casos de uso.................................................185
8.2.10.2.5. Pruebas a la cuarta iteracin..............................................186
8.2.11. LAVIFIS VERSIN 1.0......................................................................186
CAPTULO 9. CONCLUSIONES Y RECOMENDACIONES................................187
9.1. CONCLUSIONES.......................................................................................187
9.2. RECOMENDACIONES..............................................................................189
9.2.1. DEMANDA SOCIAL............................................................................189
9.2.2. PROCESO EDUCATIVO.....................................................................190
9.2.3. TRABAJOS FUTUROS.......................................................................190
BIBLIOGRAFA.....................................................................................................191
ANEXOS................................................................................................................197
ANEXO A. PRUEBAS REALIZADAS A LA PRIMERA ITERACIN...................198
PRUEBAS DE UNIDAD.....................................................................................198
PRUEBAS DE CAJA BLANCA..........................................................................200
PRUEBAS DE CAJA NEGRA............................................................................202
ANEXO B. PRUEBAS REALIZADAS A LA PRIMERA ITERACIN...................203
ANEXO C. PRUEBAS REALIZADAS A LA TERCERA ITERACIN..................210
ANEXO D. PRUEBAS REALIZADAS A LA CUARTA ITERACIN....................217
ANEXO E. MANUAL DE USUARIO.....................................................................219
ACERCA DE LAVIFIS........................................................................................219
INSTALACIN...................................................................................................220
EJECUTAR........................................................................................................221
EN SISTEMAS UNIX/LINUX.........................................................................221
SISTEMAS WINDOWS.................................................................................222
OTROS SISTEMAS......................................................................................222
CONFIGURAR AMBIENTE...............................................................................223
CONFIGURAR PARTCULA..............................................................................225
CAMPOS DE CONFIGURACIN DE MEDIDAS DE LA PARTCULA.............226
CONFIGURACIN DEL MOVIMIENTO............................................................226
CAMPOS DE CONFIGURACIN PARA LOS DATOS INICIALES...................227
CONTROLES DE SIMULACIN.......................................................................228
AJUSTAR DATOS DE EXPERIMENTACIN...............................................228
INICIAR, DETENER Y CONTINUAR EXPERIMENTACIN........................228
REINICIAR EXPERIMENTACIN................................................................229
VELOCIDAD DE SIMULACIN....................................................................229
OPCIONES DE VISUALIZACIN.................................................................229
VISOR DE DATOS DE SIMULACIN...............................................................230
DETALLE DE LAS TABLAS DE INFORMACIN.........................................230
GENERAR INFORMES EN PDF.......................................................................232
ACCEDER A SISTEMA DE CONOCIMIENTOS...............................................234
AYUDA DE LAVIFIS...........................................................................................234
ANEXO F. MANUAL TCNICO.............................................................................235
DATOS TCNICOS DE LAVIFIS.......................................................................235
PARADIGMA DE PROGRAMACIN................................................................236
LENGUAJE DE PROGRAMACIN..................................................................236
INSTALACIN AVANZADA PARA SISTEMAS UNIX/LINUX............................236
DETALLE DE PORTABILIDAD DE LAVIFIS.....................................................237
NDICE DE FIGURAS
Figura 3.1: Coordenadas cartesianas planas..........................................................19
Figura 3.2: Movimiento rectilneo uniforme.............................................................22
Figura 3.3: Movimiento rectilneo uniformemente acelerado..................................24
Figura 3.4: Cada libre.............................................................................................25
Figura 3.5: Movimiento parablico...........................................................................27
Figura 4.1: Construccin de un modelo de simulacin...........................................32
Figura 4.2: Esquema del proceso experimental de la simulacin...........................38
Figura 4.3: Etapas de un estudio de simulacin......................................................41
Figura 5.1: Desarrollo tradicional vs. desarrollo gil................................................51
Figura 6.1: Fases de un proyecto en XP..................................................................71
Figura 6.2: Ciclos de la metodologa XP..................................................................74
Figura 6.3: Divisin de grupos de trabajo Scrum....................................................75
Figura 6.4: Divisin de trabajo en Scrum................................................................76
Figura 6.5: Divisin del tiempo en Scrum................................................................76
Figura 6.6: Tablero de tareas Scrum.......................................................................94
Figura 6.7: Grfico de trabajos pendientes Scrum..................................................95
Figura 6.8: Grfico de horas pendientes en la iteracin Scrum..............................95
Figura 6.9: Proceso de desarrollo con Scrum.......................................................100
Figura 8.1: Diagrama de cuerpo libre de una partcula en reposo........................118
Figura 8.2: Diagrama de cuerpo libre de una partcula en movimiento................120
Figura 8.3: Algoritmo general de la simulacin......................................................127
Figura 8.4: Prototipo de la arquitectura del software.............................................138
Figura 8.5: Clase Cuerpo, versin 0.1...................................................................142
Figura 8.7: Clase Vector, versin 0.1.....................................................................144
Figura 8.9: Clase Ambiente, versin 0.1................................................................146
Figura 8.10: Diagrama de clases, 1ra iteracin.....................................................147
Figura 8.11: Diagrama de casos de uso, 1ra iteracin..........................................148
Figura8.12: UPS + DBG........................................................................................151
Figura 8.13: Clase Ambiente, versin 0.2..............................................................152
Figura 8.15: Implementacin del espacio de simulacin referenciado.................154
Figura 8.16: Clase Control, versin 0.1.................................................................155
Figura 8.17: Clase Simulador, versin 0.1.............................................................156
Figura 8.18: Resultado implementacin de clases Ambiente, Control y Simulador.
...............................................................................................................................157
Figura 8.19: Interfaz Dibujable, versin 0.1...........................................................158
Figura 8.20: Diagrama de clases, 2da iteracin....................................................158
Figura 8.21: Diagrama de casos de uso, 2da iteracin.........................................159
Figura 8.23: Clase Tablas, versin 0.1..................................................................163
Figura 8.24: Implementacin de Tablas.................................................................164
Figura 8.25: Clase Flecha, versin 0.1..................................................................165
Figura 8.26: Clase Vector, versin 0.2...................................................................166
Figura 8.28: Controles de visualizacin.................................................................167
Figura 8.29: Prototipo de la interfaz de usuario.....................................................168
Figura 8.31: Clase BarraMenu, versin 0.1...........................................................171
Figura 8.32: Clase Simulador, versin 0.2.............................................................171
Figura 8.33: Tutoriales en barra men..................................................................172
Figura 8.34: Implementacin de interfaz de usuario.............................................172
Figura 8.35: Clase Flecha, versin 0.2..................................................................173
Figura 8.36: Clase Vector, versin 0.3...................................................................173
Figura 8.37: Diagrama de clases, 3ra iteracin.....................................................174
Figura 8.38: Diagrama de casos de uso, 3ra iteracin..........................................175
Figura 8.40: Clase Tablas, versin 0.2..................................................................180
Figura 8.41: Clase BarraMenu, versin 0.2...........................................................181
Figura 8.42: Interfaz Imprimible, versin 0.1.........................................................183
Figura 8.43: Diagrama de clases, 4ta iteracin.....................................................184
Figura 8.44: Diagrama de casos de uso, 4ta iteracin..........................................185
NDICE DE TABLAS
Tabla 8.1: Valores constantes para la simulacin..................................................125
Tabla 8.2: Datos iniciales para la simulacin.........................................................125
Tabla 8.3: Variables calculadas para iniciar la simulacin.....................................126
Tabla 8.4: Variables calculadas durante la simulacin..........................................126
Tabla 8.5: Historia de usuario 1.............................................................................131
Tabla 8.10: Historia de usuario 6...........................................................................134
Tabla 8.14: Lista priorizada de historias de usuario..............................................136
Tabla 8.15: Planificacin de entregas....................................................................140
Tabla 8.16: Plan de la primera iteracin................................................................141
Tabla 8.17: Plan de la segunda iteracin...............................................................149
Tabla 8.18: Plan de la tercera iteracin.................................................................160
Tabla 8.19: Grupos de variables de simulacin.....................................................162
Tabla 8.20: Divisin barra men............................................................................170
Tabla 8.21: Plan de la cuarta iteracin..................................................................176
Tabla 8.22: Requerimientos de software...............................................................182
Tabla 8.23: Requerimiento de hardware................................................................183
Tabla 8.24: Clases que componen a LAVIFIS.......................................................186
CAPTULO 1
CAPTULO 1. DESCRIPCIN DEL PROYECTO.
1.1. INTRODUCCIN.
En la actualidad existe una revolucin mundial acerca del uso de las
Nuevas Tecnologas de Informacin y Comunicacin (NTICs) para la
enseanza - aprendizaje de las ciencias, por lo que la educacin debe de
ser influida por la investigacin y observacin directa del objeto de estudio
[26, 28].
En el campo de la Fsica, es muy evidente la necesidad de usar la
experimentacin para lograr mayor comprensin acerca de los fenmenos
fsicos. Lamentablemente en Bolivia las oportunidades de acceso a un
laboratorio de experimentacin son mnimas y en muchos casos nulas, esto
se debe a varios factores como por ejemplo: alto costo, demanda elevada y
existencia de muy pocos lugares (universidades o centros de
experimentacin) para hacerlo, lo cual ocasiona en la poblacin estudiantil
una desmotivacin generalizada hacia el estudio de la Fsica.
1
El presente proyecto propone el desarrollo de un software que simular
fenmenos fsicos de cinemtica newtoniana para propiciar un proceso de
enseanza aprendizaje significativo de la Fsica.
La cinemtica newtoniana es un rea de estudio considerada como uno de
los pilares en la enseanza de la Fsica Bsica [33, 36], es por tal
consideracin que es el tema abordado en el desarrollo del proyecto.
1.2. ANTECEDENTES.
La experimentacin con fenmenos fsicos logra un aprendizaje significativo
en los estudiantes, ya que promueve habilidades tales como: observacin,
manipulacin de datos, creacin de hiptesis y capacidad de conclusin.
Las prcticas de laboratorio pueden desarrollarse de manera que el alumno
est en contacto fsico y pueda manipular dispositivos e instrumentos
requeridos para el experimento (laboratorio real) o utilizando simulaciones
interactivas programadas con el empleo de ordenadores (laboratorio virtual)
[5, 21, 26]. Ambas formas requieren auto preparacin por parte de los
estudiantes a travs de materiales impresos (textos o folletos) y en formato
electrnico. Varias experiencias muestran que el trabajo en ambos
ambientes es complementario [9].
2
Varios autores tratan la importancia de la experimentacin en el aprendizaje
de la Fsica, como ser: Aplicacin de la Informtica a la enseanza de la
Fsica y Qumica [1], Comprensin Newtoniana de la cada de cuerpos. Un
estudio de su evolucin en el Bachillerato [2], Modelling in Physics
teaching: The role of computer simulation [3], Pueden ayudar las
simulaciones con ordenador a provocar en los alumnos un cambio
conceptual en el campo de la mecnica clsica? [7], Software simulation
enhances science experiments [9], A study of use of computer simulated
experiments in the physics classroom [15], Estudio de la influencia de un
entorno de simulacin por ordenador en el aprendizaje por investigacin de
la Fsica en Bachillerato [36].
1.3. SITUACIN PROBLEMTICA.
En la actualidad el acceso a Laboratorios de Fsica en Bolivia es mnimo y
en muchos casos nulo, debido a la alta demanda para su uso, costos
elevados y falta de infraestructura. Las universidades pblicas cuentan con
cientos de alumnos que requieren realizar experimentos para mejorar sus
conocimientos y habilidades. El hecho de satisfacer a todos parece un reto
imposible debido a las limitaciones de infraestructura y recursos
econmicos que no permiten contar con laboratorios adecuadamente
equipados. Tambin se puede constatar que el costo de mantenimiento de
un laboratorio, equipado con instrumental adecuado, es considerablemente
alto debido a su constante uso.
3
Por lo mencionado se puede distinguir que el problema central es:
Insuficiente infraestructura en laboratorios para la experimentacin
de fenmenos fsicos, provoca un inadecuado aprendizaje de
cinemtica newtoniana en estudiantes de Fsica de las universidades.
1.4. OBJETIVOS.
1.4.1. OBJETIVO GENERAL.
Desarrollar un laboratorio virtual de Fsica como herramienta de
apoyo para el proceso de enseanza aprendizaje de cinemtica
newtoniana.
1.4.2. OBJETIVOS ESPECFICOS.
Los objetivos especficos determinados son los siguientes:
I. Identificar los experimentos con mayor valor pedaggico, para
apoyar de manera consistente el aprendizaje de los
estudiantes.
II. Disear un ambiente virtual para la experimentacin con
fenmenos de cinemtica newtoniana.
4
III. Disear modelos matemticos para simular el movimiento de
cuerpos bajo leyes de cinemtica newtoniana.
IV. Disear algoritmos de simulacin de cada modelo matemtico
para su codificacin.
V. Implementar la simulacin grfica en 2D para virtualizar los
experimentos.
VI. Elaborar documentos de forma automtica que muestren
informacin generada durante la simulacin, con el fin de
proporcionar informes de las experimentaciones.
VII. Probar el laboratorio virtual con el fin de asegurar el correcto
funcionamiento y estabilidad del Software.
1.5. INNOVACIN TECNOLGICA.
El presente proyecto forma parte de los NTICs (Nuevas Tecnologas de
Informacin y comunicacin), como una herramienta de apoyo al proceso
de enseanza aprendizaje de la Fsica bsica.
5
La diferencia con otros proyectos similares radica en que es un software
centrado en el estudiante y que a partir de un escenario virtual se propicia
el autoaprendizaje, ya que permite el descubrimiento de los distintos
experimentos mediante la metacognicin de los usuarios.
1.6. JUSTIFICACIN.
Existen varias metodologas para el desarrollo de software y de
modelamiento para la simulacin, el proyecto no requiere de hardware o
software especializado, estas ventajas hacen que el proyecto sea
tcnicamente factible.
La utilizacin de las NTIC's en el proceso de enseanza aprendizaje es
una cuestin prioritaria tanto en las agendas polticas europeas como en
Amrica Latina. En el caso de la Fsica, poder contar con software
educativo es un incentivo para el desarrollo de capacidades de abstraccin,
concentracin y observacin en los estudiantes logrando que se eleve el
nivel de preparacin de los mismos, con esto se evidencia que el presente
proyecto tiene un alto valor social por que integra a nuestra sociedad en el
mbito educativo moderno.
6
1.7. ALCANCES Y LIMITACIONES.
1.7.1. ALCANCES.
El presente proyecto tendr los siguientes alcances:
I. Investigar acerca de los experimentos ms relevantes en
cinemtica newtoniana.
II. Proporcionar al estudiante resultados vlidos, por medio de
informes automticamente generados.
III. Mostrar de forma grfica los fenmenos fsicos simulados.
IV. Proporcionar al estudiante tablas comparativas entre el
fenmeno fsico experimental y terico.
1.7.2. LIMITACIONES.
Las limitaciones que presenta el proyecto son:
I. Los grficos de simulacin sern en 2 Dimensiones (2D).
II. El laboratorio virtual es monousuario.
III. Solo se simular un cuerpo a la vez.
IV. El cuerpo estar representado por una esfera.
V. El software no realiza hiptesis sobre resultados de los
experimentos.
7
1.8. METODOLOGA PARA EL DESARROLLO DEL PROYECTO.
Basado en las actividades de la simulacin de sistemas discretos [6, 8] y
del desarrollo gil de software XP (eXtreme Programming) [10], se elabor
y sigui con la siguiente metodologa:
I. Relevar informacin sobre los experimentos de mayor valor
educativo.
II. Anlisis de los experimentos y estudio de factibilidad.
III. Desarrollar modelos matemticos para la simulacin.
IV. Pruebas a los modelos matemticos desarrollados.
V. Relevar requerimientos para desarrollo del software.
VI. Anlisis y estudio de factibilidad de los requerimientos.
VII. Construccin del Software.
VIII. Pruebas y validaciones al Software.
8
CAPTULO 2
CAPTULO 2. EDUCACIN Y EXPERIMENTACIN.
2.1. INTRODUCCIN.
El experimento es uno de los mtodos bsicos de la investigacin emprica
debido a la importancia que posee en la demostracin de las relaciones
causales. Desde hace mucho tiempo se conoce el experimento y ha sido
utilizado en la prctica para todas las etapas del desarrollo de la ciencia.
Sin embargo su utilizacin como mtodo central del conocimiento cientfico
es reciente.
La experimentacin sigue adquiriendo importancia trascendental por cuanto
utiliza mecanismos que posibilitan aislar el fenmeno estudiado, reproducir
muchas veces el curso del proceso en condiciones alteradas
intencionalmente sometidas a control y finalmente planificar para buscar
diferentes combinaciones con el objetivo de obtener el resultado buscado.
9
Existen varios paradigmas para lograr el aprendizaje, uno de los ms
conocidos y que hace uso de la experimentacin como herramienta es el
aprendizaje por descubrimiento.
2.2. EXPERIMENTO.
Es la experiencia cientfica en la cual se provoca deliberadamente algn
cambio de condiciones iniciales sobre un fenmeno determinado para que
tenga un comportamiento esperado, con el fin de observar e interpretar sus
resultados.
El experimento cientfico es aquel que involucra la manipulacin intencional
de una accin apara analizar sus posibles efectos, es decir, es un estudio
de investigacin en que se manipula una o mas variables independientes
(supuesta causa) para analizar las consecuencias de esa manipulacin
sobre una o ms variables dependientes (supuesto efecto) dentro de una
situacin de control para el investigador.
10
2.3. EXPERIMENTACIN EN LA EDUCACIN.
El uso de la experimentacin en la educacin contribuye a desarrollar en los
estudiantes habilidades que les permitirn manejarse en la vida cotidiana y
los llevar a un aprendizaje ms significativo y permanente.
Ensear Fsica utilizando experimentacin, entre otros procedimientos, es
para los estudiantes un desafo, ya que ellos cuestionan sobre algn
fenmeno y buscan por medio de diferentes caminos las respuestas ante
una duda, envolviendo as la creatividad, la formulacin de estrategias y el
intercambio de ideas con sus compaeros.
Al emplearse este procedimiento en el aula, se est trabajando y
potenciando los siguientes talentos que usa el ser humano en su vida diaria
[36]:
El pensamiento productivo, que tiene que ver con desarrollar la
creatividad brindando la oportunidad a los estudiantes de que
aprendan a utilizar su curiosidad e imaginacin sin establecer lmites.
Toma de decisiones, consiste en que el estudiante de forma
autnoma, por medio del razonamiento y de la reflexin aprenda a
dar solucin a problemas cotidianos.
11
Planificacin, pretende que el estudiante aprenda a planear,
organizado el tiempo de manera adecuada y utilizar los materiales
para lograr sus objetivos.
Comunicacin, consiste en lograr que los estudiantes se
comuniquen de una manera fluida a travs de su expresin oral,
escrita y corporal.
Para trabajar adecuadamente con la experimentacin en la educacin, se
deben de cumplir las siguientes caractersticas:
Identificacin de un problema.
Relacin Constante entre pensar y hacer.
Dilogo con la realidad.
Una bsqueda creativa.
Una actividad compartida.
Una decisin intencionada.
Es mediante la experimentacin donde el alumno pone en juego los
conocimientos adquiridos, explora, observa, concluye, crea sus propias
hiptesis y desarrolla habilidades, relacionadas con el pensamiento
analtico, crtico y creativo [26].
12
2.4. EXPERIMENTACIN CON AMBIENTES VIRTUALES EN LA
EDUCACIN.
El desarrollo de la Informtica ha permitido la creacin de laboratorios
automatizados (virtuales) que apoyan al aprendizaje y la investigacin de
tcnicos y profesionales en diversas ingenieras y ciencias exactas, como
parte del proceso educativo.
La propuesta del uso de ordenadores como herramienta alternativa
proporcionan un medio de enseanza aprendizaje que ofrece la
posibilidad de actualizar, adecuar, describir, procesar, representar y
modificar variables inherentes a la experimentacin de forma rpida y
precisa ahorrando cuantiosos recursos.
Los ambientes virtuales utilizados en la experimentacin con fines
educativos dan lugar a la aplicacin de una estrategia de aprendizaje por
descubrimiento, que es una forma innovadora de la apropiacin de saberes
a travs de experiencias de aprendizaje significativo provedas por el
facilitador para que el estudiante haciendo uso de las TIC's como recurso
didctico y como instrumento de mediacin tecnolgica, movilice
herramientas en la construccin del conocimiento [24]. Tambin los
ambientes virtuales aportan una nueva metodologa de aprendizaje
centrada en el estudiante, basada en desempeo acadmico que moviliza
conocimientos, habilidades, valores integrados para realizar tareas que le
son encomendadas con eficiencia, para ser utilizado en situaciones reales.
13
La aplicacin de laboratorios virtuales para la experimentacin logra un
aprendizaje significativo en cada uno de los alumnos dado que los
experimentos se hacen de manera individual, uniforme y mas completa que
en un laboratorio convencional, pues se dan instrucciones ms precisas,
con ms recursos multimedia de apoyo, pudiendo repetirse las experiencias
sin un lmite hasta lograr una compresin ptima del fenmeno estudiado
(Jonassen, 1995).
La implicaciones pedaggicas del uso de experimentacin en ambientes
virtuales contribuyen a elevar el nivel del logro acadmico entre los
estudiantes, por consecuencia, mejorar el proceso de aprendizaje.
2.5. APRENDIZAJE POR DESCUBRIMIENTO.
El modelo de aprendizaje por descubrimiento asume que la mejor manera
de que el alumno aprende ciencia es haciendo ciencia. Por tanto, su
enseanza debe basarse en experiencias que permitan al estudiante
investigar y reconstruir los descubrimientos cientficos.
La idea del alumno como cientfico parte del supuesto de que el primero
est dotado de capacidades intelectuales similares a las del segundo y, en
consecuencia, el estudiante, enfrentado a las mismas situaciones que el
cientfico, acabar por desarrollar las estrategias propias del mtodo
cientfico, obteniendo las mismas conclusiones.
14
Adems, el modelo asume una concepcin inductiva de la ciencia, al
considerar que la aplicacin rigurosa del mtodo cientfico conduce al
conocimiento de la realidad.
Los criterios para seleccionar y organizar los contenidos estn basado en lo
histrico, puesto que se basa en la seleccin de problemas que son
significativos para la comprensin de la ciencia que se estudia. Asimismo,
se pretende promover en los alumnos las actitudes propias de los cientficos
[36].
El docente debe disear escenarios para el descubrimiento, suscitando
preguntas o situaciones problemticas que deben ser resultas por los
alumnos.
Una actividad de descubrimiento tiene las siguientes fases [36]:
I. Presentacin de una situacin problemtica.
II. Observacin, identificacin de variables y recogida de datos.
III. Experimentacin para comprobar las hiptesis formuladas sobre las
variables y los datos.
IV. Organizacin e interpretacin de los resultados.
V. Reflexin sobre el proceso y los resultados obtenidos.
15
CAPTULO 3
CAPTULO 3. FUNDAMENTOS DE CINEMTICA NEWTONIANA.
3.1. MECNICA NEWTONIANA.
La mecnica newtoniana o mecnica vectorial es una formulacin
especfica de la mecnica clsica que estudia el movimiento de partculas y
slidos en un espacio eucldeo. Aunque la teora es generalizable, la
formulacin bsica de la misma se hace en sistema de referencia inerciales
donde las ecuaciones bsicas del movimiento se reducen a las leyes de
Newton. La mecnica es la parte de la fsica que estudia el movimiento. Se
subdivide en:
Esttica, que trata sobre las fuerzas en equilibrio mecnico.
Cinemtica, que estudia el movimiento sin tener en cuenta las
causas que lo producen.
Dinmica, que estudia los movimientos y las causas que los
producen.
16
La mecnica newtoniana es adecuada para describir eventos fsicos de la
experiencia diaria, es decir, a eventos que suceden a velocidades
muchsimo menores que la velocidad de la luz y tiene escala macroscpica.
En el caso de sistemas con velocidades apreciables a la velocidad de la luz
se debe hacer uso de la mecnica relativista.
La mecnica newtoniana es suficientemente vlida para la gran mayora de
los casos prcticos cotidianos en una gran cantidad de sistemas. Esta
teora, por ejemplo, describe con gran exactitud sistemas como cohetes,
movimiento de planetas, molculas orgnicas, trompos, trenes y
trayectorias de mviles en general.
3.2. CINEMTICA NEWTONIANA.
La cinemtica es la rama de la mecnica que estudia las leyes del
movimiento de los cuerpos sin tener en cuenta las causas que lo producen,
limitndose, esencialmente, al estudio de la trayectoria en funcin del
tiempo.
En cinemtica se utiliza un sistema de referencia para describir las
trayectorias. La velocidad es el ritmo con que cambia la posicin de un
cuerpo. La aceleracin es el ritmo con que cambia su velocidad. La
velocidad y la aceleracin son las dos principales cantidades que describen
como cambia su posicin en funcin del tiempo.
17
En la mecnica newtoniana se admite la existencia de un espacio absoluto
(vaco); es decir, un espacio anterior a todos los objetos materiales e
independiente de la existencia de estos. Este espacio es el escenario donde
ocurren todos los fenmenos fsicos, y se supone que todas las leyes de la
fsica se cumplen rigurosamente en todas las regiones de ese espacio. El
espacio fsico se representa en mediante un espacio puntual eucldeo.
Anlogamente, la mecnica newtoniana admite la existencia de un tiempo
absoluto que transcurre del mismo modo en todas las regiones del universo
y que es independiente de la existencia de los objetos materiales de la
ocurrencia de los fenmenos fsicos.
El mvil ms simple que se considera para el presente proyecto es el punto
material o partcula.
3.3. ELEMENTOS DE CINEMTICA NEWTONIANA.
3.3.1. SISTEMA DE COORDENADAS.
Para el estudio del movimiento los sistemas de coordenadas que son
ms tiles, son aquellos que permiten visualizar los lmites de la
trayectoria a recorrer y analizar el efecto geomtrico de la aceleracin
que afecta al movimiento.
18
As para describir el movimiento de una partcula con una trayectoria
circular, la coordenada ms conveniente sera el ngulo central relativo
a una direccin o radio preestablecido. Del mismo modo, para describir
el movimiento de una partcula sometida a la accin de una fuerza
central, las coordenadas polares seran ms tiles.
El estudio cinemtico en el presente proyecto se hace referido a un
sistema de coordenadas cartesianas en el plano que se presenta en la
figura 3.1, usando una o dos dimensiones segn sea la trayectoria
seguida por el cuerpo.
Fuente: Elaboracin propia.
19
Figura 3.1: Coordenadas cartesianas planas.
3.3.2. TIPOS DE MOVIMIENTO.
La cinemtica se ocupa de estudiar todos los tipos de movimiento que
existen en la naturaleza. A continuacin se listan los tipos de
movimiento mas relevantes en la mecnica newtoniana:
Movimiento rectilneo.
Movimiento mixto o parablico.
Movimiento circular.
El presente proyecto desarrolla los primeros dos tipos de movimiento, ya
que son fundamentales en la enseanza de la Fsica bsica.
3.3.3. MOVIMIENTO RECTILNEO.
En el movimiento rectilneo, la trayectoria que describe el mvil es una
lnea recta. Los tipos mas notables de movimiento rectilneo son:
uniforme, uniformemente acelerado y cada libre (caso particular del
movimiento acelerado).
20
3.3.3.1. Movimiento rectilneo uniforme.
Se denomina uniforme cuando la velocidad es constante en el
tiempo, dado que su aceleracin es nula.
El Movimiento Rectilneo Uniforme (MRU) se caracteriza por:
Movimiento que se realiza sobre una lnea recta.
Velocidad Constante; implica magnitud y direccin constantes.
Aceleracin Nula.
La distancia recorrida se calcula multiplicando la magnitud de la
velocidad por el tiempo transcurrido. Esta relacin tambin es
aplicable si la trayectoria no es rectilnea, con tal que el mdulo de la
velocidad sea constante.
La velocidad puede ser nula (reposo), positiva o negativa. Por lo
tanto el movimiento puede considerarse en dos sentidos; una
velocidad negativa representa un movimiento en direccin contraria
al sentido que convencionalmente se haya adoptado como positivo.
21
De acuerdo con la primera ley de Newton, toda partcula permanece
en reposo o en movimiento rectilneo uniforme cuando no hay una
fuerza neta que acte sobre el cuerpo. Esta es una situacin ideal,
ya que siempre existen fuerzas que tienden a alterar el movimiento
de las partculas.
La figura 3.2 presenta el comportamiento del movimiento rectilneo
uniforme en un grfico tiempo vs. distancia recorrida.
22
Figura 3.2: Movimiento rectilneo uniforme.
3.3.3.2. Rectilneo uniformemente acelerado.
El movimiento Rectilneo Uniformemente Acelerado (MRUA),
tambin conocido como Movimiento Rectilneo Variado (MRUV), es
aquel en el que un mvil se desplaza sobre una trayectoria recta
estando sometido a una aceleracin constante.
Tambin puede definirse el movimiento como el que realiza una
partcula que partiendo del reposo es acelerada por una fuerza
constante.
En la mecnica newtoniana el MRUA presenta tres caractersticas
fundamentales:
La aceleracin y la fuerza resultante sobre la partcula son
constantes.
La velocidad vara linealmente respecto del tiempo.
La posicin vara segn una relacin cuadrtica respecto del
tiempo.
La figura 3.3 presenta el comportamiento del movimiento rectilneo
uniformemente acelerado en un grfico tiempo vs. distancia
recorrida.
23
3.3.3.3. Cada Libre.
Es un caso particular del movimiento rectilneo uniformemente
acelerado, en el cual la aceleracin que interviene se debe a la
gravedad.
El valor de la aceleracin debido a la gravedad puede tomar valor
positivo o negativo en dependencia de la direccin en que se mueve
24
Figura 3.3: Movimiento rectilneo uniformemente acelerado.
la partcula, si esta descendiendo es positivo y si est ascendiendo
es negativo. Las caractersticas de la cada libre son:
La aceleracin es constante al valor de la gravedad.
La velocidad vara linealmente respecto del tiempo.
La posicin vara segn una relacin cuadrtica respecto del
tiempo.
En la figura 3.4 muestra el fenmeno de cada libre.
25
Figura 3.4: Cada libre.
3.3.4. MOVIMIENTO MIXTO O PARABLICO.
Se denomina movimiento mixto o parablico cuando la trayectoria
realizada por un cuerpo describe una parbola. Se corresponde con la
trayectoria ideal de un proyectil que se mueve en un medio que no
ofrece resistencia al avance y que est sujeto a un campo gravitatorio
uniforme. Puede ser analizado como la composicin de dos
movimientos rectilneos: un movimiento rectilneo uniforme horizontal y
un movimiento rectilneo uniformemente acelerado vertical.
En condiciones ideales las caractersticas del movimiento parablico
son:
Un cuerpo que se deja caer libremente y otro que es lanzado
horizontalmente desde la misma altura tardan el mismo tiempo en
llegar al suelo.
La independencia de la masa en la cada libre y el lanzamiento
vertical es igual de vlida.
Un cuerpo lanzado verticalmente hacia arriba y otro con un grado
de inclinacin que alcance la misma altura, tarda lo mismo en
caer.
26
En la figura 3.5 se puede observar que el cuerpo realiza dos tipos
de movimiento y forma una parbola, adems la altura y distancia
horizontal mximas alcanzadas (Ymax , Xmax).
Fuente: [33].
27
Figura 3.5: Movimiento parablico.
CAPTULO 4
CAPTULO 4. SIMULACIN DE SISTEMAS.
4.1. INTRODUCCIN.
A medida que el mundo avanza, tambin lo hace la tecnologa permitiendo
abordar problemas cada vez ms complejos. En cualquier toma de
decisiones, de tipo empresarial, industrial o gubernamental, se debe tener
un conocimiento muy profundo del problema a tratar y no se pueden tomar
acciones de control en base a suposiciones. Se exigen, por lo tanto,
tcnicas de anlisis fiables que minimicen los costos producidos por errores
en la toma de decisiones. Una de estas tcnicas es la simulacin por
ordenador [6].
La simulacin es el proceso de modelar una realidad o un sistema real para
imitar su comportamiento y permitir estudiarlo bajo una variedad de
circunstancias. La simulacin es frecuentemente utilizada para estudiar,
determinar, predecir comportamientos de un sistema.
28
En los ltimos aos la simulacin computacional se ha convertido en una de
las principales tcnicas en el estudio de sistemas complejos. Esto es debido
a que los ordenadores son cada vez ms baratos y con mayores
prestaciones, as como la mejora en las herramientas para la simulacin por
computador, que han hecho que se puedan estudiar sistemas complejos.
4.2. SISTEMAS Y MODELOS.
El trmino sistema se utiliza habitualmente con mltiples sentidos, tantos
que resulta difcil dar una definicin nica que los abarque todos y al mismo
tiempo sea lo suficientemente precisa para servir a propsitos especficos.
Se puede partir de la siguiente definicin de sistema: conjunto de
elementos que ordenadamente relacionados entre si contribuyen a lograr
uno o varios objetivos, se trata de una definicin sencilla pero que pone de
manifiesto los caracteres relevantes de lo que constituye el denominado
enfoque sistmico: contemplacin del todo y no de las partes aisladamente,
haciendo hincapi en las relaciones entre las partes y de su funcionamiento
en conjunto al tener en cuenta los propsitos u objetivos del sistema.
La visin o enfoque sistmico es una consecuencia del paso de una
filosofa reduccionista a una holstica, segn la cual los factores
29
determinantes en la naturaleza son totalidades. En otras palabras,
considera que un todo no puede reducirse a elementos discretos y enfatiza
las relaciones funcionales u orgnicas entre las partes y el todo.
El enfoque sistmico de resolucin de problemas reconoce que el
comportamiento de cualquier parte tiene algn efecto sobre el
comportamiento del sistema como un todo, en su desarrollo a partir de los
aos veinte ha ido solapando e interaccionando mltiples disciplinas dando
lugar a lo que hoy en da se conoce como ingeniera de sistemas, tcnica
que utiliza conocimientos procedentes de diferentes ramas de la ciencia y la
ingeniera para introducir innovaciones tecnolgicas en las etapas de
concepcin, planificacin, desarrollo y operacin de un sistema, o lo que es
lo mismo, el ciclo de vida de un sistema. Una de las caractersticas
principales de las tcnicas de la ingeniera de sistemas es su aplicacin en
situaciones en las que los sistemas son:
Grandes y complejos.
En ellos interviene el hombre.
El cambio en una parte puede afectar a muchas otras y al todo.
30
4.3. EL PROCESO DE CONSTRUCCIN DE MODELOS.
El anlisis del sistema a travs de un modelo implica que la representacin
del sistema que constituye el modelo ha de ser una representacin
manipulable numricamente. El ejercicio de construccin del modelo del
sistema comienza por la construccin de un modelo conceptual del sistema,
representacin equivalente lgica aproximada del sistema real que, como
tal, constituye una abstraccin simplificada del mismo, que a continuacin
se traduce en un modelo apto para su ejecucin en un ordenador. El
proceso de modelizacin o construccin del modelo implica [6]:
Identificacin de las entidades principales del sistema y de sus
atributos caractersticos.
Identificacin y representacin de las reglas que gobiernan el
sistema que se quiere simular.
Captacin de la naturaleza de las interacciones lgicas del sistema
que se modela.
Verificacin de que las reglas incorporadas al modelo son una
representacin vlida de las del sistema que se modela.
Representacin del comportamiento aleatorio.
31
Una precaucin importante a tener en cuenta en la construccin de modelos
es que ninguno es mejor que las hiptesis que encierra. Traducir el modelo
a uno especfico para ordenador consiste en representarlo de forma
conceptual mediante un lenguaje apto para su ejecucin. Este proceso se
simplifica cuando la representacin se hace utilizando un lenguaje
especializado orientado a problemas especficos. Las etapas del proceso de
construccin del modelo se sintetizan en la figura 4.1.
Fuente: [6].
32
Figura 4.1: Construccin de un modelo de simulacin.
4.4. SIMULACIN DE SISTEMAS CONTINUOS Y DISCRETOS.
En general los modelos matemticos de tipo dinmico representan sistemas
continuos, es decir sistemas en los que las actividades predominantes
causan pequeos cambios en los atributos de sus entidades, cuando las
relaciones entre ellas describen las tasas o cambios de los atributos, por lo
que, en general, tales modelos estn definidos formalmente por ecuaciones
diferenciales [8, 33].
Es posible, a partir del modelo matemtico del sistema, obtener informacin
por medios analticos. Cuando esto no es posible se recurre a
procedimientos numricos para resolver las ecuaciones del modelo,
especialmente en el caso de los modelos dinmicos representados por
ecuaciones o sistemas de ecuaciones diferenciales. Con el tiempo se ha ido
desarrollando una amplia variedad de mtodos numricos de clculo para
resolver las ecuaciones de los modelos, una tcnica numrica particular es
la que se denomina simulacin de sistemas, que consiste en un
seguimiento a lo largo del tiempo de los cambios que tienen lugar en el
modelo dinmico del sistema.
La manera de efectuar el seguimiento temporal de los cambios en el
modelo clasifica en dos categoras a la simulacin de sistemas, segn que
los cambios sean continuos o discretos. En el primer caso se supone que la
33
naturaleza del sistema permite cambios de estado continuos, mientras que
en el segundo los cambios solo pueden tener lugar en instantes discretos
en el tiempo.
Para los sistemas con cambios continuos, los sistemas de ecuaciones
diferenciales sern la forma mas adecuada de representarlos. Se denomina
simulacin continua a la simulacin basada en este tipo de modelos. Los
simuladores analgicos han sido ampliamente utilizados en este tipo de
simulacin, aunque el desarrollo de las tcnicas numricas para la
resolucin de sistemas de ecuaciones diferenciales, el avance tecnolgico
en los ordenadores digitales y la evolucin de los lenguajes de
programacin les han hecho perder protagonismo.
Para los sistemas discretos, el seguimiento de los cambios de estado
requiere la identificacin de qu es lo que causa el cambio y cuando lo
causa, lo que se denomina un suceso, las ecuaciones del modelo se
convierten entonces en relaciones lgicas que determinan las condiciones
en que tiene lugar la ocurrencia de un suceso. Este tipo de simulacin,
conocida con el nombre de simulacin discreta, consiste en el
seguimiento de los cambios de estado del sistema que tienen lugar como
consecuencia de la ocurrencia de una secuencia de sucesos.
34
4.5. MODELADO DE SISTEMAS DISCRETOS.
La simulacin es una disciplina esencial en el estudio de sistemas
complejos. Es til disponer de una herramienta que te permita analizar los
efectos y potenciales de las soluciones a problemas del mundo real.
Muchos de estos casos se pueden abordar realizando un modelo de
eventos discretos, esto es, un modelo dinmico, estocstico y discreto a
intervalos no regulares de tiempo [13].
Como su nombre indica, en la simulacin de eventos discretos el siguiente
evento indicar el comportamiento del modelo. Muchas aplicaciones de
simulacin de eventos discretos utilizan en sistema de colas, eventos
sujetos del tiempo, etc. [27]. En un sistema de eventos discretos existen
dos tipos fundamentales de elementos, la entidad y el recurso.
Las entidades son los elementos individuales del sistema que estn siendo
simulados y cuyo comportamiento est siendo ejecutado. En la simulacin,
el programa mantiene informacin de cada entidad y por lo tanto cada una
puede ser individualmente identificada. Cuando una entidad cambia de
estado, el programa actualiza este nuevo estado. El estado del sistema
global es el resultado de la interaccin de las entidades individuales.
Mientras que los recursos son elementos individuales del sistema pero que
no son modelados individualmente, mas bien son tratados como un
35
conjunto de elementos cuyo comportamiento individual no es mantenido por
el programa. El recurso consiste de un nmero de elementos idnticos, por
ello el programa mantiene el no de recursos disponibles pero no su estado
individual. Si un elemento del sistema debe ser tratado como entidad o
recurso es una cuestin a resolver por el modelador.
En el desarrollo de una simulacin de eventos discretos se requiere ver el
sistema desde el punto de vista que ayude en el proceso de modelado.
Todos los software de simulacin disponibles usan fundamentalmente una
de las siguientes dos aproximaciones: orientada al evento (redes de Petri) y
orientada al proceso (ModSim II). En un modelado orientado al evento es
necesario identificar todos los eventos diferentes que puedan ocurrir en el
sistema y determinar que efectos producen esos eventos. Un evento se
define como una ocurrencia instantnea que puede cambiar el estado del
sistema. Mientras que en la aproximacin orientada al proceso lo que se
define es la secuencia de pasos (eventos o serie de eventos) para cada
transaccin que ocurre en el sistema, esto es, se define cada proceso que
sucede en el sistema. Considerando que un proceso es una secuencia
ordenada en el tiempo de eventos interrelacionados separados por el paso
del tiempo. Esta secuencia describe el paso de un elemento (individuo,
informacin, etc.) a travs del sistema.
36
4.6. LA SIMULACIN COMO PROCESO EXPERIMENTAL.
La prctica de la simulacin es una tcnica que no realiza ningn intento
especfico para aislar las relaciones entre variables particulares, antes bien
adopta un punto de vista global desde el que se intenta observar como
cambian conjuntamente todas las variables del modelo con el tiempo. En
todo caso, las relaciones entre las variables deben obtenerse a partir de
tales observaciones. Esta concepcin caracteriza la simulacin como una
tcnica experimental de resolucin de problemas, lo que lleva a la
necesidad de repetir mltiples ejecuciones de la simulacin para poder
entender las relaciones implicadas por el sistema, en consecuencia el uso
de la simulacin en un estudio que debe planificarse como una serie de
experimentos que debe seguir las normas del diseo de experimentos para
que los resultados obtenidos puedan conducir a interpretaciones
significativas de las relaciones de inters.
La simulacin es por lo tanto una tcnica que realiza experimentos en un
ordenador con un modelo de un sistema dado. El modelo es el vehculo
utilizado para la experimentacin en sustitucin del sistema real. Los
experimentos pueden llegar a tener un alto grado de sofisticacin que
requiera la utilizacin de tcnicas estadsticas de diseo de experimentos.
37
En la mayor parte de los casos los experimentos de simulacin son la
manera de obtener repuestas a preguntas del tipo "qu pasara s?",
preguntas cuyo objetivo suele ser evaluar el impacto de una posible
alternativa que sirva de soporte a un proceso de toma de decisiones sobre
un sistema, proceso que puede representarse esquemticamente mediante
el diagrama de la figura 4.2.
Fuente: [6, 8].
La simulacin, y los experimentos de simulacin, se convierten en una
herramienta de anlisis de sistemas, para entender cmo opera un sistema
existente, o cmo puede operar uno propuesto.
La situacin ideal, en la cual el investigador realizara los experimentos
sobre el sistema real es sustituida por una en la que el investigador
construye un modelo del sistema utilizando un ordenador, para investigar su
comportamiento e interpretar los resultados en trminos del sistema.
38
Figura 4.2: Esquema del proceso experimental de la simulacin.
La simulacin, y el procedimiento experimental asociado, se convierten
tambin en una herramienta de diseo de sistemas, cuyo objetivo es la
produccin de un sistema que satisfaga ciertas especificaciones. El
diseador puede seleccionar o planear como deben ser los componentes
del sistema y concebir cuales deben ser las relaciones entre ellas. El diseo
se traduce en un modelo cuyo comportamiento permite inducir el sistema
previsto. El diseo se acepta cuando las previsiones se ajustan
adecuadamente a los comportamientos deseados, en caso contrario se
introducen las modificaciones pertinentes en el modelo y se repite el
proceso.
La aplicacin de la simulacin a diferentes tipos de sistemas combinada con
las diferentes clases de estudio que se pueden realizar conduce a una gran
cantidad de variantes en la manera que se puede realizar un estudio de
simulacin. Sin embargo hay determinados pasos bsicos del proceso que
pueden identificarse como los constituyentes de la metodologa de un
estudio de simulacin [6], y son los siguientes:
I. Definicin del problema y planificacin del estudio.
II. Recogida de datos.
39
III. Formulacin del modelo matemticos.
IV. Construccin y verificacin del programa para computador del
modelo.
V. Ejecuciones de prueba del modelo.
VI. Validacin del modelo.
VII. Diseo de los experimentos de simulacin.
VIII. Ejecucin de los experimentos.
IX. Anlisis de los resultados.
El proceso no es secuencial, sino iterativo, en el que algunos de los pasos
pueden tener que repetirse en funcin de los resultados intermedios tal
como muestra la figura 4.3.
40
Ningn estudio de simulacin puede llevarse a cabo sin establecer
claramente una definicin precisa del problema que se pretende resolver y
los objetivos del estudio. Los diseos alternativos del sistema que se han de
estudiar deben quedar claramente especificados, as como los criterios para
evaluar dichos diseos. Criterios que servirn de base al proceso de toma
de decisiones para elegir uno de los diseos. Para la formulacin del
modelo debe establecerse su estructura definiendo cuales son los aspectos
del funcionamiento del sistema que son significativos para la resolucin del
problema, y que datos son necesarios recoger para proporcionar al modelo
la informacin adecuada.
41
Figura 4.3: Etapas de un estudio de simulacin.
La construccin del modelo de simulacin es en muchos casos ms un arte
que una ciencia, que combina aspectos matemticos y lgicos. En general
se recomienda empezar con modelos moderadamente detallados que
paulatinamente se van haciendo ms sofisticados. El modelo nicamente
debe contener el nivel de detalle requerido por los objetivos del estudio.
Dado un modelo matemtico la construccin del programa mediante el
ordenador es requisito imprescindible para poder manipular numricamente
el modelo con el fin de obtener las soluciones que respondan a las
preguntas que el analista se formula sobre el sistema.
La validacin del modelo es uno de los pasos cruciales del proceso, suele
ser uno de los ms difciles, pero es indispensable para establecer si el
modelo representa o no adecuadamente el sistema objeto del estudio, de
manera que se puedan garantizar las inducciones y predicciones sobre el
comportamiento del sistema a partir de lo observado.
4.7. VENTAJAS Y DESVENTAJAS DE LOS MODELOS DE SIMULACIN.
Ya que la simulacin es en mucha ocasiones una herramienta apropiada de
anlisis, es preciso considerar las ventajas y desventajas de su utilizacin.
42
4.7.1. VENTAJAS.
Las ventajas de la construccin de modelos de simulacin son:
Una vez construido, el modelo puede ser modificado de manera
rpida con el fin de analizar diferentes polticas o escenarios.
Generalmente es ms barato mejorar el sistema va simulacin que
hacerlo directamente en el sistema real.
Es mucho ms sencillo comprender y visualizar los mtodos de
simulacin que los mtodos puramente analticos.
Los mtodos analticos se desarrollan casi siempre, para sistemas
relativamente sencillos donde suele hacerse un gran nmero de
suposiciones o simplificaciones, mientras que con los modelos de
simulacin es posible analizar sistemas de mayor complejidad o con
mayor detalle.
En algunos casos, la simulacin es el nico medio para lograr una
solucin.
43
4.7.2. DESVENTAJAS.
Las desventajas de la construccin de modelos de simulacin son:
Los modelos de simulacin en una computadora muchas veces son
costosos y requieren mucho tiempo para desarrollarse y validarse.
Se requiere gran cantidad de puestas en prueba del sistemas
simulado para encontrar soluciones ptimas, lo cual repercute en la
elevacin de costos.
Es difcil de aceptar los modelos de simulacin.
La solucin de un modelo de simulacin puede dar al analista un
falso sentido de seguridad.
44
CAPTULO 5
CPITULO 5. INGENIERA DE SOFTWARE.
5.1. INTRODUCCIN.
La Ingeniera de Software es una disciplina que comprende todos los
aspectos de la produccin de software desde las etapas iniciales de la
especificacin del sistema, hasta el mantenimiento de este despus de que
se utiliza [37].
En esta definicin existen dos frases claves:
Disciplina de ingeniera. Los ingenieros hacen que las cosas
funcionen. Aplican teoras, mtodos y herramientas donde sea
conveniente, pero las utilizan de forma selectiva y siempre tratando
de descubrir soluciones a los problemas, aun cuando no existan
teoras y mtodos aplicables para resolverlos. Los ingenieros
tambin trabajan con restricciones financieras y organizativas, por lo
que buscan soluciones tomando en cuenta estas restricciones.
45
Todos los aspectos de produccin de software. La ingeniera del
software no slo comprende los procesos tcnicos del desarrollo de
software, sino tambin actividades tales como la gestin de
proyectos de software, el desarrollo de herramientas, mtodos y
teoras de apoyo a la produccin de software.
En general, los ingenieros de software adoptan un enfoque sistemtico y
organizado en su trabajo, ya que es la forma ms efectiva de producir
software de alta calidad. Sin embargo, aunque la ingeniera consiste en
seleccionar el mtodo ms apropiado para un conjunto de circunstancias,
un enfoque ms informal y creativo de desarrollo podra ser ms efectivo en
algunas circunstancias. El desarrollo informal es apropiado para el
desarrollo de sistemas basados en web, los cuales requieren una mezcla
de tcnicas de software y de diseo grfico [37].
5.2. PROCESO DEL SOFTWARE.
Un proceso del software es un conjunto de actividades y resultados
asociados que producen un producto de software. Estas actividades son
llevadas a cabo por los ingenieros de software. Existen cuatro actividades
fundamentales de procesos que son comunes para todos los procesos del
software. Estas actividades son:
46
Especificacin del software donde los clientes e ingenieros definen el
software a producir y las restricciones sobre su operacin.
Desarrollo del software donde el software se disea y programa.
Validacin del software donde el software se valida para asegurar
que es lo que el cliente quiere.
Evolucin del software donde el software se modifica para adaptarlo
a los cambios requeridos por el cliente y el mercado.
Aunque no existe un proceso del software ideal, en las organizaciones
existen enfoques para mejorarlos. Los procesos pueden incluir tcnicas
anticuadas o aprovecharse de las mejores prcticas en la ingeniera del
software industrial. De hecho, muchas organizaciones aun no aprovechan
los mtodos de la ingeniera del software.
Los procesos del software se pueden mejorar por la estandarizacin del
proceso, donde la diversidad de los procesos del software en una
organizacin sea reducida. Esto conduce a mejorar la comunicacin y una
reduccin del tiempo de formacin, la estandarizacin tambin es un primer
paso importante para introducir nuevos mtodos, tcnicas y buenas
prcticas de ingeniera de software.
47
5.2.1. MODELOS DEL PROCESO DE SOFTWARE.
Cada modelo de proceso aborda todas las fases del ciclo de vida del
desarrollo de cualquier sistema software, se representan desde una
perspectiva particular, son abstracciones de los procesos que se pueden
aplicar para explicar diferentes enfoques para el desarrollo de software.
Puede pensarse en ellos como marcos de trabajo que pueden ser
extendidos y adaptados para crear procesos ms especficos de
ingeniera de software.
Algunos de los modelos de procesos entre muchos, pueden ser:
El modelo en cascada. Es un modelo de proceso de desarrollo
secuencial que considera las actividades fundamentales del
proceso de especificacin, desarrollo, validacin y evolucin, son
representadas como fases separadas del proceso, tales como la
especificacin de requerimientos, el diseo del software, la
implementacin, las pruebas, etc. La documentacin se produce
en cada fase, no existe flexibilidad al dividir el proyecto en
distintas etapas. Se deben hacer compromisos en las etapas
iniciales, lo que hace difcil responder a los cambios del
requerimientos del cliente. Por lo tanto su uso es conveniente
cuando los requerimientos se comprenden bien y sea improbable
que cambien radicalmente durante el desarrollo del sistema.
48
Desarrollo evolutivo. Este enfoque entrelaza las actividades de
especificacin, desarrollo y validacin. Un sistema inicial se
desarrolla rpidamente a partir de especificaciones abstractas.
Este se refina basndose en las peticiones del cliente para
producir un sistema que satisfaga sus necesidades. Las
actividades de especificacin, desarrollo y validacin se
entrelazan en vez de separarse, con una rpida retroalimentacin
entre estas.
Ingeniera del software basada en componentes. Este enfoque
se basa en la existencia de un nmero significativo de
componentes reutilizables. El proceso del sistema se enfoca en
integrar estos componentes en el sistema ms que en
desarrollarlos desde cero. Tiene la ventaja obvia de reducir la
cantidad de software a desarrollarse y as reduce los costos y los
riesgos, Por lo general, tambin permite una entrega ms rpida
del software. Sin embargo, los compromisos en los
requerimientos son inevitables, y esto puede dar lugar a un
sistema que no cumpla las necesidades reales de los usuarios.
Estos tres modelos de procesos genricos se utilizan ampliamente en la
prctica actual de la ingeniera del software de sistemas grandes. Se
han propuesto todo tipo de variantes de estos procesos genricos y
pueden ser usados en algunas organizaciones.
49
Debido a esto surgieron nuevas definiciones como ser el desarrollo gil
de software que evolucion a mediados de los aos 1990 como parte de
una reaccin contra los mtodos de peso pesado, muy estructurados y
estrictos mencionados anteriormente.
Estos nuevos mtodos de desarrollo gil e iterativos intentan evitar los
tortuosos y burocrticos caminos de las metodologas tradicionales,
pueden ser vistos como un retroceso a las practicas de desarrollo
observadas en los primeros aos del desarrollo de software.
Inicialmente los mtodos giles fueron llamados mtodos de peso
liviano [25].
Los mtodos giles enfatizan las comunicaciones cara a cara en vez de
la documentacin. La mayora de los equipos giles estn localizados en
una simple oficina abierta, a veces llamadas "plataformas de
lanzamiento". La oficina debe incluir revisores, escritores de
documentacin y ayuda, diseadores de iteracin y directores de
proyecto. Los mtodos giles tambin enfatizan que el software
funcional es la primera medida del progreso. Combinado con la
preferencia por las comunicaciones cara a cara, generalmente los
mtodos giles son criticados y tratados como "indisciplinados" por la
falta de documentacin tcnica.
50
Algunos de los contrastes entre el desarrollo tradicional y el desarrollo
gil se pueden observar en la figura 5.1.
Fuente: [25].
Cuando se utilizan mtodos giles de desarrollo, el producto resultante
del proceso de diseo no son documentos de especificacin separados,
sino que la documentacin est representada en el cdigo del
programa. Algunas metodologas de desarrollo gil son: XP, Scrum.
Crystal Clear, DSDM, FDD, ASD, XBreed [32].
Una vez diseada la arquitectura de un sistema, las etapas posteriores
del diseo son incrementales. Cada incremento se representa como
cdigo del programa en vez de un modelo de diseo, Normalmente el
desarrollo de componentes y las pruebas se entrelazan. Los
programadores definen sus propios datos de prueba y de forma
incremental prueban el cdigo que se va desarrollando [25].
51
Figura 5.1: Desarrollo tradicional vs. desarrollo gil.
5.3. IMPLEMENTACIN DEL SOFTWARE.
Dentro de las diversas etapas del proceso de software, podemos observar
cuatro actividades bsicas que cualquier modelo presenta, pero en esta
seccin se dar nfasis a la etapa de implementacin del software.
Este proceso es intensamente intelectual, afectado por la creatividad y
juicio de las personas involucradas. Aunque un proyecto de software es
equiparable en muchos aspectos a cualquier otro proyecto de ingeniera, en
la implementacin de software hay una serie de desafos adicionales,
relativos esencialmente a la naturaleza del producto obtenido.
La programacin es una actividad personal y no existe un proceso general
que siga comnmente; algunos programadores empiezan con los
componentes que comprenden, los desarrollan y despus continan con los
que comprenden menos. Otros toman el enfoque opuesto, dejando los
componentes que son ms familiares hasta el final debido a que saben
como desarrollarlos. Algunos desarrolladores prefieren definir los datos al
inicio del proceso y los utilizan para conducir el desarrollo del programa,
otros dejan los datos sin especificar tanto como sea posible [37]. En
aspectos generales dejando de lado el concepto de cada metodologa
utilizada, para realizar esta labor, se debe enfocar el proceso en la
evolucin del cdigo. Ya sea que se trabaje de forma grupal o de forma
individual, esta actividad comienza con una hoja en blanco y una idea.
52
El cdigo va evolucionando, cambiando con iteraciones pequeas que se
van introduciendo por diversos motivos como: correcciones o caractersticas
nuevas en el software. Estos cambios realizados en el cdigo son de
manera organizada y ordenada debido a que corresponden a alguna
construccin mental, porque al momento de implementar algo o corregir un
bug (gusano: resultado de un fallo o deficiencia durante el proceso de
creacin de programas de ordenador), se tiene que tener claros los
objetivos del proyecto que esta siendo desarrollado.
5.3.1. GRUPOS DE TRABAJO EN EL DESARROLLO DE SOFTWARE.
En la actividad de desarrollo de software con frecuencia los
desarrolladores son organizados en grupos, independientemente de que
metodologa empleen. Surgiendo la suma necesidad de coordinar el
trabajo, no slo por una cuestin natural sino tambin como
mecanismos para organizar los recursos.
Por eso, para desarrollar en grupo es imprescindible la buena
comunicacin y el entendimiento entre sus pares. Esto implica que, en
general los desarrollos se dan de forma coordinada (ya sea de manera
horizontal o vertical, independientemente del mecanismo que se elija
explicita o implcitamente para ello) al menos en un nivel social, las
tareas se reparten y los cambios se discuten donde afecten al grupo
para facilitar el trabajo.
53
El desarrollar en grupo, a pesar de que las relaciones grupales puedan
ser excelentes, acarrea ciertas incomodidades que en si son ms
tcnicas. Al haber ms de una persona modificando cdigo fuente de
forma simultanea, existe una complejidad con el trato de cdigo, y nada
menor, en lo que se refiere al hecho de mantenerlo coherente entre los
miembros del grupo.
Tambin se dan relaciones asimtricas con respecto a la modificacin
de cdigo dentro del grupo de trabajo, debido a que cada grupo tiene
una forma y flujo de trabajo particular, en el cual por ejemplo, se pueden
dar relaciones jerrquicas, revisin de cdigo entre pares, subgrupos,
etc.
Esto va a reflejarse en el cdigo fuente con el surgimiento de una nueva
necesidad, que va a ser la integracin de mltiple trabajos individuales,
la distribucin del mismo en distintas maquinas y la coordinacin para
que todos puedan trabajar sobre la misma base de cdigo.
Los miembros pertenecientes al grupo de trabajo en el desarrollo de
software cumple uno o mas roles de los que se detalla a continuacin
[29]:
54
Administrador de proyecto: Es la persona que administra y
controla los recursos asignados a un proyecto, con el propsito
de que se cumplan correctamente los planes definidos. Los
recursos asignados pueden ser humanos, econmicos,
tecnolgicos, espacio fsico, etc. En un proyecto, siempre debe
existir un administrador.
Analistas: Los analistas deben realizar la especificacin de
requisitos de software. Esto es, no como una especificacin en
lenguaje del cliente, sino que como especificacin para el equipo
de trabajo. descomponiendo el problema en subproblemas de
menor complejidad.
Programadores: Los programadores deben convertir la
especificacin del sistema en cdigo fuente ejecutable utilizando
uno o ms lenguajes de programacin, as como herramientas de
software de apoyo a la programacin.
Tster: El objetivo principal de la labor de tster es el de disear
tests que en forma sistemtica, permita eliminar diferentes clases
de errores, realizando esto con la mnima cantidad de tiempo y
esfuerzo.
55
Aseguradores de calidad: La actividad ms importante es la de
participar en las revisiones tcnicas formales (RTF). Si estas
revisiones estn bien conducidas, son la forma ms efectiva de
encontrar, revelar y corregir errores mientras an es barato
encontrarlos y arreglarlos. Los objetivos de las RTFs son: 1.
descubrir errores en funciones, lgica e implementacin en
cualquiera de las representaciones del software; 2. verificar que
el software bajo revisin cumple con los requisitos; 3. asegurarse
que el software ha sido representado de acuerdo al estndar en
uso; 4. alcanzar software que es desarrollado en forma uniforme;
y 5. hacer el proyecto ms manejable.
Administrador de configuracin: La administracin de
configuracin de software, es una disciplina que identifica la
configuracin de un sistema en puntos discretos en el tiempo, con
el propsito de controlar sistemticamente los cambios a esa
configuracin, manteniendo integridad y trazabilidad de la
configuracin a travs del ciclo de vida del sistema.
Ingeniero de validacin y verificacin: El objetivo principal del
proceso de validacin y verificacin de software es el de analizar
y testear en forma completa el software durante el desarrollo para
determinar que ejecuta su funcionalidad correctamente,
asegurarse que no ejecuta funciones no intencionalmente
definidas y proveer informacin sobre su calidad y confiabilidad.
56
Documentador: El objetivo principal de este rol es el de
mantener la informacin generada durante el proceso de
desarrollo.
Ingeniero de manutencin: Los objetivos a cumplir por un
ingeniero de manutencin son: Modificar el software para adaptar
nuevas funciones o modificar algunas funciones existentes,
Modernizar el software por medio de cambios al sistema y
Asegurarse de que el equipo de desarrollo est informado de los
errores encontrados en el sistema.
Cliente comprometido: Los usuarios corresponden a las
personas que estn operando da a da un sistema de software.
Es la persona que conoce el problema, y utiliza la herramienta
computacional para apoyar su trabajo. Un cliente y un usuario no
siempre son lo mismo, ya que es posible que el cliente no opere
el sistema de informacin.
5.4. INGENIERA DE SOFTWARE ASISTIDO POR ORDENADOR.
CASE (Computer Aided Software Engineering. Ingeniera de software
asistida por computadora) comprende un amplio abanico de diferentes tipos
de programas que se utilizan para ayudar a las actividades del proceso del
software, como el anlisis de requerimientos, el modelado de sistemas, la
57
depuracin y las pruebas. En la actualidad, todos los mtodos vienen con
tecnologas CASE asociada, como los editores para las notaciones
utilizadas en el mtodo, mdulos de anlisis que verifican el modelo del
sistema segn las reglas del mtodo y generadores de informes que
ayudan a crear la documentacin del sistema. Las herramientas CASE
tambin incluyen un generador de cdigo que automticamente genera
cdigo fuente a partir del modelo del sistema y de algunas guas de
procesos para los ingenieros de sistemas.
Una razn por la cual la eficacia de las herramientas CASE esta limitada se
halla en la inmensa diversidad de procesos del software. No existe un
proceso ideal, y muchas organizaciones han desarrollado su propio enfoque
para el desarrollo del software. Los procesos han evolucionado para
explotar las capacidades de las personas de una organizacin, as como las
caractersticas especificas de los sistemas que se estn desarrollando. Para
algunos sistemas, como los sistemas crticos, se requiere un proceso de
desarrollo muy estructurado. Para sistemas de negocio, con requerimientos
rpidamente cambiantes, un procesos flexible y gil probablemente sea
ms efectivo.
58
5.4.1. LIMITACIONES.
Las mejoras por la utilizacin de CASE estn limitadas por dos factores:
Esencialmente, la ingeniera del software es una actividad de
diseo que se basa en la creatividad. Los sistemas CASE
automatizan las actividades rutinarias, pero los intentos de utilizar
la inteligencia artificial para proporcionar ayuda al diseo, no han
tenido xito.
En la mayora de las organizaciones, la ingeniera de software es
una actividad de equipo, y los ingenieros invierten mucho tiempo
interactuando con los otros miembros del equipo. La tecnologa
CASE no proporciona mucha ayuda para esto.
59
CAPTULO 6
CAPTULO 6. METODOLOGAS DE DESARROLLO GIL
Para el ejecucin del proyecto se siguieron buenas prcticas de desarrollo
de software inspiradas en metodologas de desarrollo gil, principalmente
XP y Scrum.
A continuacin se resumen ests dos metodologas dando un nfasis
especial a la metodologa XP, puesto que es la que se us para el
desarrollo del proyecto.
6.1. XP (PROGRAMACIN EXTREMA).
La programacin extrema se basa en una serie de reglas y principios que
se ha ido gestando a lo largo de la historia de la ingeniera de software.
Usadas en conjunto proporcionan una nueva metodologa de desarrollo de
software que se puede englobar dentro de las metodologa giles .
60
6.1.1. PROCESO DE DE DESARROLLO EXTREMO.
La programacin extrema parte del desarrollo de software a medida, y
existen diferentes roles: un equipo de gestin, un equipo de
desarrolladores y los clientes. La relacin con el cliente es totalmente
diferente de lo que se hace en las metodologas tradicionales que se
basan en el revelamiento de requisitos y validacin al finalizar.
6.1.1.1. Interaccin con el cliente.
El cliente es parte del equipo de desarrollo por su alto grado de
interactividad con el mismo. La importancia del cliente es vital a la
hora de abordar las historias de los usuarios y las reuniones de
planificacin. Adems el cliente tiene como tarea principal el
realimentar al equipo de desarrolladores despus de cada iteracin
con los problemas con los que se ha encontrado, mostrando sus
prioridades.
En resumen, el cliente se encuentre mucho ms cercano al proceso
de desarrollo. El proceso de captura de requisitos de XP gira entorno
a una lista de caractersticas que el cliente desea que existan en el
sistema final, cada una de las cuales recibe el nombre de historias
de usuarios y su definicin consta de dos fases:
61
Primera fase, el cliente describe con sus propias palabras las
caractersticas y el responsable del equipo de desarrollo le
informa de la dificultad tcnica de cada una de ellas y por lo
tanto de su coste. A travs del dilogo resultante el cliente
deja por escrito un conjunto de historias y las ordena en
funcin de la prioridad que tiene para l.
Segunda fase, consiste en escoger las primeras historias que
sern implementadas (primera iteracin) y dividirlas en las
tareas necesarias para llevarlas a cabo. El cliente tambin
tiene participa, pero hay ms peso del equipo de desarrollo,
que dar como resultado una planificacin ms exacta. En
cada iteracin se repetir esta segunda fase para las historias
planificadas para ella.
6.1.1.2. Planificacin del proyecto.
En esta etapa se debe de elaborar la planificacin de entregas
(release planning), la cual debe seguir ciertas premisas. La
primordial es que las entregas se hagan cuanto antes y que con
cada iteracin el cliente reciba una nueva versin. La entrega
continua permite detectar errores de forma temprana.
62
En cada iteracin planificada tambin se debe elaborar la
planificacin de la misma, lo que se llama planificacin de iteracin
(iteration planning). En esta planificacin se especifican las historias
de los usuarios cuya implementacin se considera primordial y se
aaden aqullas que no han pasado las pruebas de aceptacin de
anteriores iteraciones. La planificacin de una iteracin tambin hace
uso de tarjetas en las que se escribirn tareas, que durarn entre
uno y tres das.
6.1.1.3. Diseo, desarrollo y pruebas.
El desarrollo es la pieza clave en la metodologa XP, tambin se
otorga una importancia importante al diseo pero este se va
mejorando conforme se vayan agregando funcionalidades al sistema,
dejando de lado la tradicional concepcin del gran diseo previo
que muchos autores consideran errnea puesto que desde el inicio
del proyecto no se pueden conocer absolutamente cada uno de los
requisitos de forma clara.
La clave en el proceso de desarrollo de XP es la comunicacin, y es
por esto que se implementa la metfora. El principal objetivo de la
metfora es crear una visin global y comn del sistema que se va a
63
desarrollar.
De forma general es realizado por los propios desarrolladores, en
ocasiones se renen aquellos con ms experiencia o incluso se
involucra al cliente para disear las partes ms complejas. En estas
reuniones se emplean un tipo de tarjetas llamadas CRC (Class,
Responsabilities and Colaboration) cuyo objetivo es facilitar la
comunicacin y documentar resultados. Para cada clase identificada
se rellenar una tarjeta y se especificar su finalidad, as como otras
clases con las que interacciones.
La programacin extrema es innovadora en el sentido de las pruebas
unitarias, puesto que estas se implementan paralelamente a la
produccin de cdigo, esta prctica se lleva al extremo puesto que
por cada funcionalidad que se implementa en el sistema. Se escribe
una prueba sencilla y luego el cdigo suficiente para que la pase.
Esta forma de trabajo es muy til para lograr detectar bugs (errores)
en el sistema a tiempo. De esta forma las pruebas unitarias ayudan a
priorizar y comprobar la evolucin del desarrollo y ofrecen
retroalimentacin inmediata. Ya no se requiere tener de forma
imprescindible dos equipos diferenciados que desarrollan y prueban
cada uno por su cuenta.
64
6.1.2. VALORES PROMOVIDOS POR XP.
La metodologa XP promueve los siguientes valores:
Comunicacin.
XP prioriza la comunicacin directa entre personas. Muchos
proyectos de desarrollo de software han fracasado por una mala
comunicacin. Cuando existe una adecuada comunicacin entre
actores del proceso este se agiliza, logrando alcanzar los
objetivos de manera ms eficaz y eficiente.
Coraje.
Los miembros de un equipo de desarrollo extremo deben de tener
el coraje de exponer sus dudas, miedos, experiencias sin
embellecer stas de ninguna manera. Este valor es muy
importante ya que un equipo de desarrollo extremo se basa en la
confianza para con sus miembros. Faltar a esta confianza es una
falta ms que grave.
Simplicidad.
Dado que no se puede predecir como va a ser en el futuro un
equipo de programacin XP intenta mantener el software lo ms
sencillo posible. Esto quiere decir que no se va a invertir ningn
65
esfuerzo en hacer un desarrollo que en un futuro pueda llegar a
tener valor.
Retroalimentacin.
La agilidad tambin es influenciada y se logra gracias a la
capacidad de respuesta ante los cambios que se van haciendo
necesarios a lo largo del camino. Por este motivo uno de los
valores que logra la agilidad es el continuo seguimiento o
retroalimentacin de lo que se est desarrollando.
6.1.3. PRCTICAS DE LA PROGRAMACIN EXTREMA.
Existen 12 prcticas que se pueden llevar a cabo en XP, y son las
siguientes:
I. El juego de planificacin (planning game).
En la metodologa XP se asume que la planificacin nunca ser
perfecta, y que variar en funcin de cmo varen las necesidades
del proyecto. Por tanto, el valor real reside en obtener rpidamente
un plan inicial, y contar con mecanismos de retroalimentacin que
permitan conocer la situacin del proyecto en cualquier momento. El
objetivo en XP es generar varias versiones del software tan
pequeas como sean posibles, pero que proporcionen un valor
adicional claro, desde el punto de vista del negocio. A estas
versiones se denominan entregables o releases. Un release cuenta
66
con un cierto nmero de historias de usuario desarrollados lo que
hace que contenga un valor tangible para el cliente.
Es fundamental la obtencin de retroalimentaciones que permitan
llevar a cabo estimaciones precisas. Se hacen estimaciones para
cada historia, de modo que cuando se comienza a tener datos
histricos, stos se utilizan para hacer que las siguientes
estimaciones sean ms precisas.
II. Pequeas entregas (small releases).
La poltica de XP es la de dar valor agregado a todo lo que se hace
en todo momento, es por esto que logra construir y liberar versiones
del software con frecuencia, stas debe ser tan pequeas como sean
posibles pero con valor comprobable por el cliente.
III. Metfora.
Las metforas permiten la fluidez en la comunicacin entre todos los
miembros, estn escritas en lenguaje tcnico informal que huye de
las definiciones abstractas. Estas metforas comunican intenciones,
son descriptivas, enfatizan el qu y no el cmo.
IV. Diseo simple (simple design).
Es importante trabajar a partir de lo que funciona con la mirada
puesta en lo que debe funcionar, no se debe tratar de anticipar a lo
que vendr si no ms bien hacer que algo funcione. Esto permite
tener siempre un diseo pequeo y simple que solucione el
67
problema. Las pruebas unitarias y la refactorizacin hacen que el
cdigo y las soluciones sean claras y sencillas. La metodologa XP
define un diseo simple como aqul que: pasa todos los tests, no
contiene cdigo duplicado (refactorizado), deja clara las intenciones
de los programadores (enfatiza el qu, no el cmo) en cada lnea de
cdigo y contiene el menor nmero de clases y mtodos.
V. Pruebas (testing).
La pruebas se deben realizar en todo momento ya que son la nica
forma de garantizar que el software funcione correctamente. En XP si
no hay pruebas, las cosas solo funcionan en apariencia, y si no son
automatizadas no se pueden considerar como tales. La pruebas
unitarias son la que se promueven en XP.
VI. Refactorizacin (refactoring).
Al comenzar con la codificacin siempre se tiene un orden y calidad
razonable, pero con el paso de las iteraciones este se va
deteriorando hasta llegar a tener un costo elevando para su
modificacin y mantenimiento. Frente a este problema existen
tcnicas como la refactorizacin que hace que el cdigo sea legible y
sencillo, adems se utiliza cuando se desea modificar cdigo
existente para hacer ms fcil implementar nueva funcionalidad.
VII. Programacin por parejas.
En XP se promueve la programacin en parejas frente a un solo
68
ordenador, esta caracterstica es la ms cuestionada al principio del
uso de la metodologa. El principal argumento en contra de la
programacin en pares se basa en el hecho de que dos
programadores programan el doble por separado, lo cual no es
necesariamente cierto por las siguientes razones: Si dos personas
toman decisiones juntas proporciona un mecanismo de seguridad
enormemente valioso; existe control personal en cada momento, se
reduce el riesgo de que los programadores puedan dejar de escribir
test, documentar cdigo, etc.; permite aplicar el know-how (como
hacer), que logra la incorporacin de nuevos miembros al equipo de
forma mucho ms rpida y eficaz; ayuda a la calidad del software,
puesto que el cdigo est siendo revisado en todo momento.
La metodologa XP es flexible en esta caracterstica, puesto que las
ventajas de la programacin en parejas puede ser reemplazado por
el compromiso, y alto grado de responsabilidad en un solo
programador, en el caso extremo de no contar con muchos recursos
humanos.
VIII. Propiedad colectiva.
Todos los programadores tienen acceso al cdigo que se est
desarrollando, en otras palabras, todos tienen autoridad para hacer
cambios a cualquier cdigo, y es responsable por ellos.
IX. Integracin continua. (continuos integration).
En metodologas tradicionales se realizaba la integracin en una fase
69
separada, lo cual poda llegar a ser traumtico, puesto que todos
programaban para que funcione y no con la lgica del diseo original,
lo cual hace que existan fallas por motivos desconocidos. En cambio,
la integracin continua permite percibir los errores de forma
inmediata y lograr que los programadores lo arreglen a tiempo y
respondiendo a la lgica del diseo.
X. 40 horas semanales (40 hour week).
XP exige al equipo de desarrollo estar en un modo de trabajo que
este siempre al 100%. Una semana de 40 horas en las que se dedica
la mayor parte del tiempo a tareas que suponen un avance y hace
necesarios, no en todos los casos, recurrir a sobreesfuerzos. Es por
esto que se cuida mucho que los programadores estn sin estrs y
con alta moral, permitiendo a los mismos disfrutar del tiempo
adecuado de descanso.
XI. Cliente en casa (on site costumer).
Cliente en casa se refiere a que este presente en las instalaciones
donde se desarrolla el software, es decir en casa del programador,
esto permite que los desarrolladores tomen decisiones acertadas y
que provienen del cliente mismo.
XII. Estndares de codificacin (coding standars).
Para conseguir que el cdigo se encuentre en buen estado y que
cualquier persona del equipo pueda modificar cualquier parte del
70
cdigo es imprescindible que el estilo de codificacin sea
consistente. XP es muy pragmtica en ese sentido, puesto que
establece un mnimo nmero de reglas que deben ser de
conocimiento y consentimiento de cada uno de los programadores.
La mayora de los estndares se establecen en funcin de la
comodidad de los programadores.
6.1.4. CICLO DE VIDA DE UN PROYECTO XP.
Las fases que define la metodologa XP pueden verse en la figura 6.1,
Fases de un proyecto XP
El ciclo de vida ideal de XP consisten en seis fases [20]:
71
Figura 6.1: Fases de un proyecto en XP.
Fase 1: Exploracin.
En esta fase el cliente plantea de forma general y a grandes rasgos las
historias de usuario. El equipo de desarrollo se familiariza con las
herramientas, tecnologas y prcticas que se utilizarn. Se prueba
tecnologa y se exploran posibilidades de la arquitectura del sistema
construyendo un prototipo.
Fase 2: Planificacin de la entrega.
En esta fase el cliente establece el nivel de prioridad de cada historia de
usuario y los programadores hacen una estimacin del esfuerzo
necesario para cada una de ellas. Se toman acuerdo sobre el contenido
de la primer entrega y se determina un cronograma en conjunto con el
cliente.
Fase 3: Iteraciones.
Esta fase contiene todas las iteraciones que son necesarias para la
conclusin del proyecto. Debe responder y ser coherente con la
planificacin de entregables. En la primera iteracin el equipo de
desarrollo intenta aproximar la arquitectura del software que servir de
gua para el resto del proceso, pero esto no siempre es posible ya que
est en manos del cliente definir que historias de usuario se
desarrollaran primero.
72
Fase 4: Produccin.
En esta fase se realizan pruebas adicionales y de rendimiento al sistema
antes de ser trasladado al entorno del cliente. Tambin se toman
decisiones sobre la implementacin de nuevas caractersticas a la
versin actual.
Fase 5: Mantenimiento.
Esta fase en continua, puesto que desde que se inicia con el desarrollo
de la primera versin se debe tener en continuo funcionamiento al
software para verificar y mantener su estabilidad. En esta fase se
requiere de tareas de soporte para el cliente.
Fase 6: Muerte del proyecto.
Esto ocurre cuando el cliente ya no tiene mas historias de usuario para
ser incluidas en el sistema. En esta fase es necesario satisfacer
necesidades ergonmicas del cliente y sistema, como ser: rendimiento,
confiabilidad, portabilidad, etc.
La figura 6.2 muestra los ciclos de la metodologa XP.
73
Fuente: [31].
La metodologa de desarrollo XP es la que se utilizar en el proceso de
desarrollo de software del presente proyecto, puesto que se puede aplicar
en el caso de que exista un solo programador [10].
74
Figura 6.2: Ciclos de la metodologa XP.
6.2. SCRUM.
A continuacin se presenta a Scrum por medio de sus principales
caractersticas:
Divide la organizacin en equipos pequeos, interdisciplinarios y
auto-organizados. En la figura 6.3 se muestra una posible divisin en
equipos.
Fuente: [18].
75
Figura 6.3: Divisin de grupos de trabajo Scrum.
Divide el trabajo en una lista de paquetes a entregar pequeos y
concretos. Ordena la lista por orden de prioridad y estima el esfuerzo
relativo de cada elemento. La figura 6.4 muestra la divisin del
trabajo y su efecto econmico.
Fuente: [18].
Divide el tiempo en iteraciones cortas de longitud fija (generalmente
de una a cuatro semanas), con cdigo potencialmente a ser
entregado y demostrado despus de cada iteracin. La figura 6.5
muestra la divisin del tiempo de Enero hasta Abril.
Fuente: [18].
76
Figura 6.4: Divisin de trabajo en Scrum.
Figura 6.5: Divisin del tiempo en Scrum.
Optimiza el plan de entrega y actualiza las prioridades de
colaboracin con el cliente, basada en los conocimientos adquiridos
mediante la inspeccin de lo que se entrega despus de cada
iteracin.
Optimiza el proceso teniendo una retrospectiva despus de cada
iteracin.
As en lugar de un grupo numeroso pasando mucho tiempo construyendo
algo grande, se tendr un equipo menor pasando un tiempo ms corto
construyendo algo menor. Pero integrando con regularidad para ver el
conjunto.
6.2.1. DESARROLLO GIL Y SCRUM.
La familia de mtodos de desarrollo giles evolucion a partir de los
conocidos ciclos de vida incremental e iterativo. Nacieron de la creencia
que un acercamiento ms en contacto con la realidad humana - y la
realidad del desarrollo de productos basados en el aprendizaje,
innovacin y cambio - dara mejores resultados. Los principios giles
ponen el nfasis en construir software que funcione y que se pueda usar
rpidamente, en vez de pasarse mucho tiempo al principio escribiendo
especificaciones. El desarrollo gil se centra en equipo multifuncin con
77
capacidad para decidir por ellos mismos, en vez de grandes jerarquas y
divisiones por funcionalidad. Y se centra en iteraciones rpidas, con el
cliente dando su opinin continuamente. Suele pasar que cuando la
gente oye hablar sobre desarrollo gil o Scrum hay un gesto de
reconocimiento - se parece mucho a lo que se haca antes, cuando
simplemente lo hacamos.
El mtodo gil ms popular es Scrum. Tuvo una fuerte influencia de un
artculo de 1986 en el Harvard Business Review sobre prcticas
asociadas con grupos exitosos de desarrollo de producto. El primer
equipo de Scrum lo cre Jeff Sutherland en Easel Corporation en 1993
y el marco de trabajo Scrum lo formaliz Ken Schwaber en 1995. Hoy en
da Scrum es usado por empresas de todos los tamaos tales como
Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE,
CapitalOne y la Reserva Federal de los EE.UU. Muchos equipos que
usan Scrum dicen haber obtenido mejoras sustanciales, y en alguno
casos una completa transformacin de la productividad y la moral. Para
desarrolladores de producto muchos de los cuales estn quemados
por los constantes cambios de tendencia de gestin esto es
significativo.
6.2.2. ROLES EN SCRUM.
En Scrum hay tres roles principales: El Dueo de Producto (DP), el
Equipo y el ScrumMaster (SM).
78
El Dueo de Producto es el responsable de maximizar el retorno de
inversin (ROI) identificando las funcionalidades del producto,
ponindolas en una lista priorizada de funcionalidades, decidiendo
cuales deberan ir al principio de la lista para el siguiente Sprint, y
repriorizando y refinando continuamente la lista. El Dueo de Producto
tiene la responsabilidad de las prdidas y ganancias del producto,
asumiendo que es un producto comercial. En el caso de una aplicacin
interna, el DP no es responsable del ROI en el mismo sentido de un
producto comercial (que dar beneficio), pero es responsable de
maximizar el ROI en el sentido de elegir en cada Sprint los
elementos de ms valor de negocio y menos coste. En algunas
ocasiones el DP y el cliente son la misma persona; esto es muy comn
en aplicaciones internas. En otras, el cliente podra ser millones de
personas con diferentes necesidad, en cuyo caso el rol de DP es
parecido al rol de jefe de producto o jefe de marketing del producto que
hay en muchas empresas. Sin embargo el Dueo de Producto es
diferente al tradicional jefe de producto porque interacta activa y
frecuentemente con el equipo, estableciendo personalmente las
prioridades y revisando el resultado en cada iteracin de 1 a 4
semanas , en vez de delegar las decisiones de desarrollo en el jefe de
proyecto. Es importante destacar que en Scrum hay una persona y slo
una, que hace y tiene la autoridad final de Dueo de Producto.
79
El Equipo construye el producto que va a usar el cliente, por ejemplo
una aplicacin o un sitio web. El equipo en Scrum es multifuncin -
tiene todas las competencias y habilidades necesarias para entregar un
producto potencialmente distribuible en cada Sprint y es auto-
organizado (auto-gestionado), con un alto grado de autonoma y
responsabilidad. En Scrum, los equipos se auto-organizan en vez de ser
dirigidos por un jefe de equipo o jefe de proyecto. El equipo decide a
que se compromete, y como hacer lo mejor para cumplir con lo
comprometido; en el mundo de Scrum, al equipo se le conoce como
Cerdos y a todos los dems como Gallinas (que viene de un chiste
sobre un cerdo y una gallina que estn hablando sobre abrir un
restaurante llamado Huevos con jamn, y el cerdo no lo ve claro
porque l estara verdaderamente comprometido, pero la gallina solo
estara implicada). El equipo en Scrum consta de por lo menos dos
personas (de forma ideal 5), y para un producto de software el equipo
podra incluir analistas, desarrolladores, diseadores de interface, y
testers. El equipo desarrolla el producto y da ideas al DP de cmo hacer
un gran producto. En Scrum, el equipo debera estar dedicado 100% al
trabajo en el producto durante el Sprint; intentando evitar hacer varias
tareas en diferentes productos o proyectos. A los equipos estables se
les asocia con una productividad ms alta, as que evita cambiar
miembros del equipo. A los grupos de desarrollo de aplicaciones con
mucha gente se les organiza en varios equipos Scrum, cada uno
centrado en diferentes funcionalidades del producto, coordinando sus
esfuerzos muy de cerca. Dado que el equipo hace todo el trabajo
80
(planificacin, anlisis, programacin y pruebas) para una funcionalidad
completa centrada en el cliente, a los equipos de Scrum tambin se les
llama equipos por funcionalidades.
El ScrumMaster ayuda al grupo del producto a aprender y aplicar
Scrum para conseguir valor de negocio. El ScrumMaster hacer lo que
sea necesario para ayudar a que el equipo tenga xito. El ScrumMaster
NO es el jefe del equipo o jefe de proyecto; el ScrumMaster sirve al
equipo, le protege de interferencias del exterior, y ensea y gua al DP y
al equipo en el uso fructfero de Scrum. El ScrumMaster se asegura de
que todo el mundo en el equipo (incluyendo al DP y la gerencia)
entienda y siga las prcticas de Scrum, y ayuda a llevar a la
organizacin, a travs de los cambios necesarios y frecuentemente
difciles, a conseguir el xito con el desarrollo gil.
Como Scrum hace visibles muchos impedimentos y amenazas a la
efectividad del DP y el equipo, es importante tener un ScrumMaster
comprometido y que trabaje enrgicamente para ayudar a resolver
dichos asuntos, o si no el equipo y el DP tendrn dificultades para tener
xito. Los equipos de Scrum deberan tener un ScrumMaster a tiempo
completo, aunque en un equipo ms pequeo podra ser un miembro del
equipo (llevando una carga de trabajo ms ligera). Un gran
ScrumMaster puede venir de cualquier experiencia o disciplina previa:
ingeniera, diseo, testing, gestin de productos, gestin de proyectos o
gestin de calidad.
81
El ScrumMaster y el Dueo de Producto no pueden ser la misma
persona; a veces el ScrumMaster necesitar parar los pies al DP (por
ejemplo si intenta meter nuevas funcionalidades en mitas de un Sprint).
Y al contrario de un jefe de proyecto, el ScrumMaster no le dice a la
gente las tareas que tienen asignadas lo que que hace es facilitar el
proceso, apoyando al equipo que se organiza y gestiona solo. Si el
ScrumMaster tuvo un puesto de gestin en el equipo, necesitar
cambiar radicalmente su forma de pensar y el estilo de comunicacin
con el equipo para tener xito con Scrum. En el caso de una transicin
de antiguo jefe a ScrumMaster, es mejor que est en un equipo
diferente al equipo de donde proviene, si no habr un conflicto potencial
por las dinmicas sociales y de poder.
Se debe tomar en cuenta que no existe el rol de jefe de proyecto en
Scrum. A veces un jefe de proyecto pasa a ser ScrumMaster, esto tiene
un historial de xito variado hay una diferencia fundamental entre los
dos roles en las responsabilidades del da a da y en la mentalidad
necesaria para tener xito.
Adems de estos tres roles, hay otros que contribuyen al xito del
producto, incluyendo los jefes y gestores. Aunque sus roles cambian
en Scrum, siguen siendo valiosos. Por ejemplo:
82
Ayudan al equipo respetando las reglas y el espritu de Scrum.
Ayudan a quitar los impedimentos identificados por el equipo.
Ponen su experiencia y conocimiento a disposicin del equipo.
En Scrum los jefes cambian el tiempo que dedicaban a hacer de
nieras (asignar tareas, pedir informes de estado y otras formas de
micro-gestin) por tiempo como gurus o sirvientes del equipo
(mentoring, coaching, ayudar a quitar obstculos, ayudar a resolver
problemas, dar ideas creativas y guiar el desarrollo de habilidades de los
miembros del equipo). Para llevar a cabo este cambio los gestores
puede que necesiten cambiar su estilo de gestin; por ejemplo usar
cuestionamiento socrtico para ayudar al equipo a descubrir la solucin
a un problemas en lugar de simplemente decidir una solucin e
imponrsela al equipo.
6.2.3. PRINCIPALES ACTIVIDADES EN SCRUM.
El Sprint es la actividad principal de un proyecto Scrum. Scrum es un
proceso iterativo e incremental y se divide en una serie de Sprints
consecutivos. Cada Sprint tiene una duracin de entre una semana a un
mes calendario. Una encuesta reciente encontr que la duracin mas
comn es de dos semanas. Durante este tiempo el equipo hace todo
83
para tener un pequeo conjunto de caractersticas de los requerimientos
codificados y probados.
La primera actividad de cada iteracin es una reunin de planificacin
para el sprint (sprint planning meeting). Durante esta reunin el dueo
del producto habla sobre los temas de mayor prioridad a ser
desarrollados para lograr el producto. Los miembros del equipo analizan
y responden con el nmero de tareas a las cuales se pueden
comprometer, para finalizar se crea la lista de tareas a realizar durante
el sprint (sprint backlog).
Por lo menos una vez al da se lleva a cabo una reunin con la
participacin de todos los miembros del equipo, incluidos el
ScrumMaster y Dueo de Producto. Esta reunin tiene una duracin
corta de 15 minutos. Durante ese tiempo, los miembros del equipo
comparten aquello con lo que trabajaron el da anterior, lo que se
trabajar en la jornada actual, adems se identifican los impedimentos
para su progreso. Las reuniones diarias sirven para sincronizar el
trabajo de los miembros del equipo mientras discuten sobre el trabajo a
realizar para alcanzar el Sprint.
Al finalizar el Sprint, los equipos llevan a cabo una revisin del sprint
(sprint review). Durante la revisin, el equipo muestra la funcionalidad
aadida con respecto del anterior sprint. El objetivo de esta reunin es
obtener retroalimentacin por parte de los usuario o de cualquier otra
84
parte interesada que haya sido invitada a la reunin. Esta informacin
puede resultar en cambio en la funcionalidad recin integrada. Pero es
posible que solo se tenga que agregar elementos a la lista de tareas del
Sprint.
Otra actividad que se realiza al final de cada iteracin es la retrospectiva
del sprint (sprint retrospective). Es una reunin donde todos participan,
en esta se toma un tiempo de reflexin sobre el Sprint que termina para
identificar oportunidades de mejorar el nuevo Sprint.
6.2.3.1. Reunin de planificacin del sprint.
La reunin de planificacin (Sprint Planning Meeting) se divide en
dos partes:
Primera Parte. (Duracin mxima de 4 horas).
El Cliente presenta al equipo la lista de requisitos con mayor
prioridad del producto o proyecto, pone nombre a la meta de
la iteracin (de manera que ayude a tomar decisiones durante
su ejecucin).
85
El equipo examina la lista, pregunta al cliente las dudas que le
surgen, aade condiciones de satisfaccin y selecciona los
requisitos que se compromete a completar en el Sprint, de
manera que puedan ser entregados.
Segunda Parte. (Duracin mxima de 4 horas).
El equipo planifica el Sprint, elabora la tctica que le permitir
conseguir el mejor resultado posible con el mnimo de
esfuerzo. Esta actividad la realizan solo miembros del equipo.
El equipo define las tareas necesarias para poder completar
cada objetivo/requisito, creando la lista de tareas del Sprint
(Sprint Backlog) basndose en la definicin de completado.
El equipo realiza una estimacin conjunta del esfuerzo
necesario para realizar cada tarea.
Cada miembro del equipo se auto-asigna las tareas que
puede realizar.
86
Los beneficios de esta actividad son:
Productividad, mediante comunicacin y creacin de sinergias,
todos los miembros del equipo tienen la misma visin del objetivo
y se ha utilizado los conocimientos y las experiencias de todos
para elaborar la mejor solucin entregable en el mnimo tiempo y
con el mnimo esfuerzo, eliminando tareas innecesarias,
detectando conflictos y dependencias entre tareas.
Una estimacin conjunta es ms fiable, dado que tiene en
cuenta los diferentes conocimientos, experiencia y habilidades de
los integrantes del equipo.
Potenciacin del compromiso del equipo sobre el objetivo
comn del Sprint, es todo el equipo quien asume la
responsabilidad de completar en el Sprint los requisitos que
selecciona. Facilita la ayuda de cualquier miembro si se detecta
algn impedimento que bloquea el progreso de las tareas,
especialmente si se est llegando al final del Sprint es necesaria
la participacin de todos para poder completar los objetivos
comprometidos; es cada una de las personas la que se
responsabiliza de realizar sus tareas (a las que se auto-asigno)
en los tiempos que proporcion. Si existe falta de compromiso
con respecto al resto de miembros del equipo se har muy
evidente en las reuniones diarias de Scrum.
87
6.2.3.2. Reunin diaria de Scrum (Scrum Daily Meeting).
El objetivo de esta actividad es la de facilitar la transferencia de
informacin y la colaboracin entre los miembros del equipo para
aumentar su productividad, al poner de manifiesto puntos en que se
pueden ayudar unos a otros.
Cada miembro del equipo debe responder las siguiente preguntas en
un tiempo mximo de 15 minutos:
Qu hice desde la ltima reunin diaria?, Logre cumplir con
todo lo que tena planeado?, Cules fueron mis problemas?.
Que voy a hacer a partir de este momento?.
Qu impedimentos tengo o voy a tener para cumplir mis
compromisos en esta iteracin y en el proyecto?.
Como apoyo a esta reunin, el equipo cuenta con la lista de tareas
del Sprint, donde se actualiza el estado y el esfuerzo pendiente para
cada tarea.
88
Beneficios de esta actividad:
Aumenta la productividad en el proyecto y potencia el
compromiso de equipo.
Fomenta el aprendizaje de los miembros del equipo, ya que
pueden ver cmo trabaja los otros segn sus especialidades y
experiencias.
Ayuda a conocer el estado del Sprint, ver si es posible completar
los requisitos a los que se comprometi el equipo, en vista de las
desviaciones y de las tareas pendientes.
Restricciones a tomar en cuenta:
La reunin diaria NO es para resolver problemas, los problemas
se resuelven despus de la reunin.
El equipo debe contar con unos criterios consensuados sobre
el proceso de ejecucin de las tareas.
6.2.3.3. Revisin del Sprint (Sprint Review).
Es una reunin informal, con una duracin mxima de 4 horas, donde el
equipo presenta al cliente los requisitos completados en el Sprint, en
89
forma de incremento de producto a ser entregado. En funcin de los
resultados mostrados y de los cambios que haya habido en el contexto
del proyecto, el cliente realiza las adaptaciones necesarias de manera
objetiva, ya desde el primer Sprint, replanificando el proyecto.
Beneficios de esta actividad:
El cliente puede ver de manera objetiva cmo han sido
desarrollados los requisitos que proporcion, ver si se cumplen
sus expectativas, entender que es lo que se necesita y tomar
mejores decisiones respecto al proyecto.
El equipo puede ver si realmente entendi cules eran los
requisitos que solicit el cliente y ver en qu puntos hay que
mejorar la comunicacin entre ambos.
El equipo se siente ms satisfecho cuando puede ir mostrando
los resultados que va obteniendo. No est meses trabajando sin
poder exhibir su obra.
Restriccin de esta actividad:
Slo se pueden mostrar los requisitos completados, para que el
cliente no se haga falsas expectativas y pueda tomar decisiones
90
correctas y objetivas en funcin de la velocidad de desarrollo y el
resultado realmente completado. Un requisito no completado
quedar como un requisito ms a replanificar.
6.2.4. PRINCIPALES ARTEFACTOS DE SCRUM.
El artefacto principal de un proyecto Scrum es, por supuesto, el propio
producto. El equipo debe llevar el producto a un estado potencialmente
adecuado de pasar al siguiente Sprint.
La lista de tareas de Producto (Product Backlog), es una lista
completa de las funcionalidades que quedan por aadir al producto. La
lista de tareas se prioriza por el Dueo del producto para que el equipo
pueda trabajar siempre en la caractersticas ms valiosas.
Otro artefacto es el resultado de la reunin de planificacin del Sprint y
es la lista de tareas del Sprint (Sprint Backlog), esta lista es
considerada por el equipo de desarrollo como las tareas primordiales a
realizar en cada Sprint.
Para lograr con xito los otros dos artefactos, es necesario un tercero
llamado Grfico de trabajos pendientes (Burndown Chart) que es un
conjunto de grficos muy eficaces para determinar a simple vista el
estado de un Sprint y principalmente el avance de cumplimiento en la
lista de tareas del Sprint.
91
6.2.4.1. Lista de tareas de producto (Product Backlog).
Tambin conocido como Lista de Objetivos o Requisitos
Priorizada, representa la visin y expectativas del cliente respecto a
los objetivos y entregas del producto o proyecto. El cliente es el
responsable de crear y gestionar la lista (con la ayuda del
ScrumMaster y del equipo de desarrollo). Dado que refleja las
expectativas del cliente, esta lista permite involucrarle en la direccin
de los resultados del producto final.
La lista contiene los requisitos de alto nivel del producto, que se
suelen expresar en forma de historias de usuario. Para cada
requisito se indica el valor que aporta al cliente y el coste estimado
de completarlo. La lista est priorizada balanceando el valor que
cada requisito aporta al negocio frente al coste estimado que tiene su
desarrollo, es decir, basndose en el retorno de la inversin (ROI).
En la lista se indican las posible iteraciones y las entregas (releases)
esperadas por el cliente (los puntos en los cuales desea que se
entreguen los requisitos completados hasta ese momento), en
funcin de la velocidad de desarrollo de los equipos que trabajarn
en el proyecto. Es conveniente que el contenido de cada iteracin
tenga una coherencia, de manera que se reduzca el esfuerzo de
completar todos sus objetivos.
92
La lista tambin tiene que considerar los riesgos del proyecto e
incluir los requisitos o tareas necesarios para mitigarlos.
6.2.4.2. Lista de tareas del Sprint (Sprint Backlog).
Esta lista es elaborada por el equipo de desarrollo, como plan para
completar los requisitos seleccionados para el Sprint y que se
compromete a demostrar al cliente al finalizar la iteracin, en forma
de incremento de producto preparado para ser entregado.
Esta lista permite ver las tareas donde el equipo est teniendo
problemas y permite tomar decisiones al respecto.
Para cada uno de los requisitos se muestran tareas, el esfuerzo
pendiente para finalizarlas y la auto-asignacin que han hecho los
miembros del equipo. La lista de tareas del sprint tambin se puede
gestionar mediante un tablero de tareas Scrum (Scrum
Taskboard). Al lado de cada objetivo se poner las tareas necesarias
para completarlo, en forma de hojitas posteadas, y se van moviendo
hacia la derecha para cambiarlas de estado (pendientes de iniciar,
en progreso, hechas). Para cada miembro del equipo se puede
utiliza distintos colores, de manera que se pueda ver en qu tareas
est trabajando cada cual. En la figura 6.6 se puede apreciar un
ejemplo de un tablero de tareas Scrum.
93
Fuente: [20].
6.2.4.3. Grficos de trabajo pendiente. (Burndown Chart).
Un grfico de trabajo pendiente a lo largo del tiempo muestra la
velocidad a la que se est completando los requisitos. Permite
extrapolar si el equipo de desarrollo podr completar el trabajo en el
tiempo estimado.
Se pueden utilizar los siguientes grficos de esfuerzo pendiente:
Das pendientes para completar los requisitos del producto
(Product Burndown Chart), realizado a partir de la lista de
requisitos de producto. La figura 6.7 muestra el grfico de trabajo
pendiente del producto.
94
Figura 6.6: Tablero de tareas Scrum.
Fuente: [18].
Horas pendientes para completar las tareas del Sprint (Sprint
Burndown Chart), realizado a partir de la lista de tareas del
Sprint. La figura 6.8 muestra el grfico de horas pendientes en la
iteracin.
Fuente: [18].
95
Figura 6.7: Grfico de trabajos pendientes Scrum.
Figura 6.8: Grfico de horas pendientes en la iteracin Scrum.
Este tipo de grfico permite realizar diversas simulaciones: ver
cmo se aplazan las fechas de entrega si se le aaden requisitos,
ver cmo se avanzan si se les quitan requisitos o se aade otro
equipo, etc.
6.2.5. RETOS HABITUALES EN SCRUM.
Scrum no es solamente un conjunto concreto de prcticas ms bien y
lo que es ms importante, es un marco de trabajo que proporciona
visibilidad al equipo y un mecanismo que les permite inspeccionar y
adaptar en consecuencia. Scrum hace visible los impedimentos y
disfunciones que estn impactando en la efectividad del Dueo de
Producto y del equipo, a fin que puedan ser abordados. Por ejemplo, el
DP puede no conocer realmente el mercado, las funcionalidades, o
como estimar el valor de negocio relativo. O el equipo puede no tener la
habilidades necesarias para el trabajo de desarrollo o para la estimacin
del esfuerzo.
El marco de trabajo Scrum revelar estas debilidades rpidamente.
Scrum no soluciona los problemas de desarrollo; los hace
dolorosamente visibles, y proporciona un marco de trabajo para que la
gente explore nuevas formas de resolver los problemas en ciclos cortos
y con pequeos experimentos de mejora.
96
En una situacin en la que el equipo no entrega lo que haba
comprometido en el primer Sprint por un mal anlisis y estimacin de
tareas, parece un fallo a ojos del equipo, pero en realidad esta
experiencia es el primer paso necesario para ser ms realistas y
reflexivos en los compromisos. Este patrn de que Scrum ayude a
hacer visibles las disfunciones, permitiendo que el equipo haga algo al
respecto es el mecanismo bsico que produce los mayores beneficios
experimentados por los equipos que usan Scrum.
Un fallo tpico de los equipos cuando se encuentran con una prctica de
Scrum que les resulta difcil es cambiar Scrum en vez de cambiar ellos.
Por ejemplo, los equipos con problemas en la entrega de sus
compromisos podran decidir ampliar la duracin del Sprint, as siempre
tendrn tiempo y en el proceso se aseguran de no tener que mejorar
la estimacin y gestin de su tiempo. De esta forma, sin un coaching y
apoyo de un ScrumMaster experimentado las organizaciones pueden
hacer que Scrum sea simplemente un reflejo de sus propias debilidades
y disfunciones, y socavar los beneficios reales que ofrece Scrum: Hacer
visible lo bueno y lo malo, y dar a la organizacin la oportunidad de
moverse a un nivel mas alto.
Otro fallo tpico es asumir que una prctica est desaconsejada o
prohibida simplemente porque Scrum no la dicta especficamente. Por
ejemplo, Scrum no dice que el Dueo de Producto tenga una estrategia
a largo plazo sobre el producto; tampoco dice que los ingenieros
97
busquen consejo en otros mas experimentados sobre problemas tcnico
complejos. Scrum deja que los individuos involucrados tomen la decisin
correcta; y en la mayora de los casos son aconsejables estas prcticas
(junto con muchas otras).
Otra cosa con la que hay que tener cuidado es que los gestores o jefes
impongan Scrum en sus equipos; Scrum consiste en dar al equipo
espacio y herramientas para que se gestionen ellos mismos, y que se
les obligue a esto desde arriba no es una receta para el xito. Un mejor
enfoque sera que el equipo aprendiera Scrum de un compaero o un
jefe, que obtenga una educacin completa con entrenamiento
profesional, y despus se tome la decisin como equipo de seguir las
prcticas fielmente durante un periodo definido; al final del periodo, el
equipo evaluar su experiencia y decidir si quiere continuar.
Las buenas noticias son que aunque el primer Sprint suele ser muy
difcil para el equipo, los beneficios de Scrum tienden a ser visibles al
final del Sprint, haciendo que muchos equipos de Scrum exclamen:
Scrum es duro, pero es mucho mejor que lo que estbamos haciendo
antes!.
98
6.2.6. RESUMEN DE SCRUM.
Scrum es un marco de trabajo iterativo e incremental para el desarrollo
de proyectos, productos y aplicaciones. Estructura el desarrollo en ciclos
de trabajo llamados Sprints. Son iteraciones de 1 a 4 semanas, y se
van sucediendo una detrs de otra. Los Sprints son de duracin fija
terminan en una fecha especfica aunque no se haya terminado el
trabajo, y nunca se alargan. Se limitan en tiempo. Al comienzo de
cada Sprint, un equipo multifuncin selecciona los elementos (requisitos
del cliente) de una lista priorizada. Se comprometen a terminar los
elementos al final del Sprint. Durante el Sprint no se pueden cambiar los
elementos elegidos. Todos los das el equipo se rene brevemente para
informar del progreso, y actualizan unas grficas sencillas que les
orientan sobre el trabajo restante. Al final del Sprint, el equipo revisa los
logros con los interesados del proyecto, y les ensea lo que han
construido. La gente obtiene comentarios y observaciones que se puede
incorporar al siguiente Sprint. Scrum pone el nfasis en productos que
funcionen al final del Sprint que realmente estn hechos; en el caso del
software significa que el cdigo est integrado, completamente probado
y potencialmente para entregar. Los roles, artefactos y eventos
principales se resumen en la siguiente figura 6.9.
Un tema importante en Scrum es inspeccionar y adaptar. El desarrollo
inevitablemente implica aprender, innovacin y sorpresas. Por eso
Scrum hace hincapi en dar un pequeo paso de desarrollo;
99
inspeccionar el producto resultante y la eficacia de las prcticas
actuales; y entonces adaptar el objetivo del producto y las prcticas del
proceso. Y volver a repetir.
La figura 6.9 presenta el proceso de desarrollo con Scrum.
Fuente: [18].
100
Figura 6.9: Proceso de desarrollo con Scrum.
CAPTULO 7
CAPTULO 7. HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DEL
SOFTWARE.
Se opt por seleccionar herramientas libres para el desarrollo de la
aplicacin, se selecciono el lenguaje de programacin JAVA para el
desarrollo, NETBEANS como IDE (Entorno integrado de desarrollo) para la
codificacin y finalmente JUNIT para realizar pruebas de unidad al software.
A continuacin se detalla cada una de stas planteando los motivos por los
cuales fueron seleccionadas
7.1. LENGUAJE DE PROGRAMACIN JAVA.
Java es simultneamente una plataforma y un lenguaje de programacin
orientado a objetos diseado por Sun Microsystems.
101
7.1.1. CARACTERSTICAS DE JAVA.
A continuacin se mencionan caractersticas importantes de Java.
7.1.1.1. Lenguaje de programacin orientado a objetos.
Las ventajas de la programacin orientada a objetos son: un mejor
dominio de la complejidad (dividiendo un problema complejo en una
serie de pequeos problemas) y una reutilizacin ms simple as
como mejores correcciones y evoluciones. Java est provisto de un
conjunto de clases que permiten manipular todo tipo de objetos
(interfaz grfica, acceso a la red, gestin entrada/salida, etc.).
7.1.1.2. Distribuido.
Java se distribuye con los protocolos de acceso a la red, como
TCP/IP, UDP, HTTP o FTP. Esto permite realizar desarrollos en
arquitectura cliente/servidor, para acceder a los datos de una
mquina remota. Con lo cual, se puede desarrollar aplicaciones para
acceder a informacin en la red, de la misma forma que se hace para
acceder a los discos locales.
102
7.1.1.3. Interpretado.
Un programa Java no se ejecuta, es interpretado por la mquina
virtual o JVM (Java Virtual Machine), lo que hace que no sea
necesario recompilar un programa Java para cambiarlo de sistema,
siendo tan solo necesario poseer la mquina virtual Java propia de
cada uno de los sistemas. Pero adems, para que sea un lenguaje
totalmente independiente de la mquina y del sistema operativo,
debe ser compilado e interpretado. El cdigo intermedio que se
genera al ser compilado, llamado bytecodes, es cdigo mquina de
muy bajo nivel, y corresponde al 80% de las instrucciones del
programa. Para adaptar este cdigo genrico a una plataforma
concreta (un procesador y un sistema operativo concreto), debemos
interpretarlo para aadir el 20% que falta para su ejecucin.
Evidentemente, el carcter interpretado del lenguaje Java influye en
su rendimiento. Aunque es mejor que un lenguaje de script, y lo
suficientemente rpido para aplicaciones interactivas, Java es ms
lento que los lenguajes tradicionales cuyo cdigo fuente es
compilado directamente en el cdigo mquina de una plataforma
concreta. Para mejorar el rendimiento del Java, y solventar este
problema, se ha desarrollado el compilador justo a tiempo (Just-In-
Time, JIT) que se ejecuta concurrentemente con la mquina virtual
de Java. JIT determina que partes del cdigo se ejecutan ms
frecuentemente para compilarlas dinmicamente en cdigo
103
ejecutable y que no tengan que ser interpretadas. Esto es, cuando
en una mquina virtual de Java hay un compilador JIT, despus de
traerse una clase y verificarla, y antes de ejecutarla, se compila al
cdigo mquina nativo. Este proceso de compilacin es gradual, es
decir, se realiza conforme se van necesitando las clases. El
rendimiento de un programa en Java es comparable al de uno
realizado en C.
7.1.1.4. Robusto.
Java incorpora toda una serie de medidas y comprobaciones para
evitar errores inesperados. Realiza chequeos tanto en tiempo de
compilacin, como en tiempo de ejecucin. Tambin comprueba los
tipos de datos y obliga a una definicin explcita de los mtodos que
se definen para las clases en Java. Adems, la gestin de los
punteros es realizada en su totalidad por Java, sin que el
programador tenga medio alguno de acceder a ella, lo que evita la
posibilidad de sobreescribir datos en memoria de forma inoportuna.
7.1.1.5. Seguro.
La seguridad de Java incorpora 4 niveles que deben servir para
controlar, entre otras, la posibilidad de ejecutar software de manera
distribuida entre diferentes mquinas, y de cargar applets
104
(programas en Java que se carga en un navegador) procedentes de
internet. Para ello, el cdigo es verificado en la compilacin, y
tambin por el intrprete en el momento de la ejecucin. Los niveles
de seguridad son:
Nivel de lenguaje: se realiza una gestin automtica de la
memoria y se eliminan los punteros, con ello se reduce al 50%
los errores producidos durante la ejecucin de un programa.
Nivel de verificacin de los bytecode: Java realiza una
comprobacin de los bytecode en busca de irregularidades y
detectando posibles anomalas.
Nivel de cargador de clases: cuando se carga una clase
utilizada por una aplicacin, estas sern sometidas a una
serie de reconocimientos y comprobaciones, estn en el
ordenador local, distribuidas en una red local o en Internet.
Nivel de API de Java: Java incluye mecanismos de control y
comprobacin sobre las clases de acceso a los recursos del
sistema .
La seguridad para Internet se centra en la ejecucin de los applets.
La posibilidad de cargar un applet desde cualquier punto de la red,
es una puerta abierta para virus y programas no deseados. Por ello,
105
todos los navegadores actuales, a partir de 1998, incorporan una
serie de restricciones: los applets no pueden ejecutar programas
sobre el equipo local, tampoco pueden leer o escribir sobre este
equipo y slo se podrn conectar al servidor que los contena antes,
es decir, de donde fueron descargados.
7.1.1.6. Independiente del hardware.
El lenguaje Java ha sido diseado para crear aplicaciones que
funcionen en entornos de red, operando en una amplia variedad de
arquitecturas hardware y sistemas operativos. El compilador de Java
genera bytecodes, un formato intermedio independiente de la
arquitectura utilizado para transportar el cdigo entre los distintos
sistemas hardware y software. El bytecode es el cdigo mquina
para la Mquina Virtual Java, que es el procesador virtual para el que
estn generados los programas Java. Debido a la naturaleza
interpretada del lenguaje, el mismo bytecode puede ejecutarse sobre
cualquier plataforma sin necesidad de recompilacin .
106
7.1.1.7. Portable.
La neutralidad respecto a la arquitectura es slo una parte de un
sistema verdaderamente portable. El lenguaje Java va ms all,
definiendo estrictamente las especificaciones del lenguaje. En Java
estn definidos, por ejemplo, el tamao de los tipos de datos bsicos
(norma IEEE754) o el comportamiento estricto de todos los
operadores aritmticos sea cual sea la plataforma de desarrollo.
Los programas se ejecutan sobre la Mquina Virtual Java, que
especifica todas las instrucciones permitidas y su significado. Para
que los bytecodes se puedan ejecutar sobre un nuevo sistema
hardware, slo es necesario portar la mquina virtual a ese nuevo
sistema, y todos los programas existentes pasaran a ejecutarse sin
problemas .
7.1.1.8. Dinmico.
La naturaleza portable e interpretada de Java proporcionan un
sistema dinmico y dinmicamente extensible. Las clases son
enlazadas en el momento en que son requeridas, no antes de la
ejecucin del programa, y pueden ser cargadas de la red. Todo el
cdigo nuevo es verificado antes de ser ejecutado.
107
La carga dinmica permite evitar tener que recompilar todos los
programas que contengan clases hijas cuando se modifica una clase
padre. Tambin permite actualizar un programa simplemente
cambiando algunas de sus clases, sin tener que recompilarlo
completo, siempre que las nuevas clases mantengan la misma
interfaz o un superconjunto.
7.1.1.9. Multitarea.
Java permite desarrollar aplicaciones que realicen la ejecucin
simultnea de varios threads (procesos ligeros o hilos de ejecucin).
Y este soporte lo da a nivel del lenguaje de programacin, y no como
unas libreras aadidas aparte, como es normal en otros lenguajes,
lo que le da al lenguaje una mayor robustez y sencillez de uso.
Existe una clase Thread a partir de la cual pueden derivarse nuevos
objetos thread. Cada una de estas threads es un hilo de ejecucin
distinto dentro del mismo proceso. La clase Thread proporciona
mtodos para crear una nueva thread, ejecutarla, detenerla y
conocer su estado. Tambin se incluyen primitivas de sincronizacin
basadas en el empleo de monitores y variables condicin. Todas las
clases que forman la librera estndar de Java han sido diseadas de
modo que puedan ser utilizadas simultneamente por varias threads.
Cualquier objeto puede ser convertido en una thread y comenzar su
108
ejecucin por separado con un mnimo de esfuerzo de
programacin .
7.1.1.1. Sintaxis simple.
La sintaxis de Java es similar a la del lenguaje C o del C++, pero
omite aquellas caractersticas semnticas que los hacen complejos,
confusos y poco seguros: imposibilidad de que el programador
gestione punteros, falta de herencia mltiple, de sobrecarga de tipos
ni de operadores, ausencia de macros o de archivos de encabezados
(.h en el lenguaje C). Adems, Java dispone de un sistema llamado
recogida de basura (garbage colector), que se ocupa de la
destruccin automtica de los objetos que ya no se utilizan, con el fin
de liberar memoria. Java permite la gestin de excepciones (errores
de ejecucin).
7.2. ENTORNO INTEGRADO DE DESARROLLO: NETBEANS.
Es un entorno integrado de desarrollo (IDE) gratuito para desarrollar
aplicaciones con el lenguaje de programacin JAVA. Se utiliz la versin
6.9 la cual al momento del desarrollo del software era la ms reciente.
Si bien no es el nico IDE disponible para JAVA, se selecciono esta
herramienta por que integra el framework de pruebas JUNIT, automatiza la
generacin de versiones de software y documentacin.
109
7.3. FRAMEWORK DE PRUEBAS UNITARIAS: JUNIT.
JUNIT es un framework de pruebas que fue diseado para ser empleado en
JAVA. Un aspecto importante es que cumple con la mayora de las
recomendaciones realizadas por la metodologa de desarrollo gil XP en lo
que a pruebas se refiere, de las cuales se destaca el permitir hacer pruebas
autnomas.
Muchos programadores en el mundo opinan que las pruebas unitarias
automatizadas son una parte esencial del proceso de desarrollo.
Una prueba de unidad examina por separado distintas unidades de trabajo
(mdulos, clases, etc.), se asegura de que las funciones implementadas
funcionen correctamente.
110
CAPTULO 8
CAPTULO 8. DESARROLLO DEL PROYECTO.
En el presente captulo se resumen las actividades realizadas para lograr
los objetivos planteados en la captulo uno seccin 1.4. El proyecto requiere
de dos etapas para su desarrollo, la primera trata de la aplicacin de
simulacin de sistemas con el fin de modelar los experimentos y la segunda
aborda el desarrollo del Software para desarrollar el laboratorio virtual.
8.1. MODELAMIENTO DE EXPERIMENTOS.
A continuacin se detalla los procedimientos realizados y resultados
obtenidos siguiendo la metodologa de simulacin de sistemas.
8.1.1. PLANTEAMIENTO DEL PROBLEMA DE SIMULACIN Y
PLANIFICACIN DE SU ESTUDIO.
111
8.1.1.1. Planteamiento del Problema de Simulacin.
Como se menciona anteriormente el fenmeno fsico a ser simulado
es el movimiento de partculas sometidas a fuerzas de oposicin al
movimiento y en el vaco. De esta forma podemos indicar que el
problema de simulacin es:
Simular el movimiento de partculas afectadas por fuerzas de
oposicin al movimiento existentes en el medio
8.1.1.2. Estudio del Problema de Simulacin.
A continuacin se detallan las actividades desarrolladas para lograr
establecer de forma clara el modelo de simulacin.
8.1.1.2.1. Observacin del movimiento de partculas en el
vaco.
Esta actividad fue realizada mediante el uso de vdeos, en los
cuales se pudo evidenciar que la trayectoria, velocidad y otros
elementos del movimiento son independientes del tipo de
partcula y que responden a las leyes del movimiento
planteadas en la cinemtica newtoniana.
112
8.1.1.2.2. Observacin del movimiento de esferas en un
medio distinto del vaco.
Para esta actividad se utilizaron esferas lisas, puesto que
tericamente se asemejan a una partcula. Se verific que la
trayectoria, movimiento, velocidad y aceleracin son afectados
considerablemente por fuerzas de oposicin existentes en el
medio (rozamiento del suelo, rozamiento del aire).
8.1.1.2.3. Estudio de leyes del movimiento en el vaco.
La Fsica a lo largo de su historia y sus estudios determina las
siguientes leyes del movimiento sin importar sus causas y en
el vaco, donde las variables fundamentales a ser calculadas y
tomadas en cuenta son el tiempo, velocidad, aceleracin y
distancia; hay que tomar en cuenta que la variable
fundamental para que exista movimiento es la velocidad. Para
el estudio solo se tomarn en cuanta dos dimensiones
(coordenadas cartesianas en el plano).
8.1.1.2.3.1. Movimiento constante.
Anlisis en el eje horizontal, el movimiento que se
presenta es constante debido a que no existen
fuerzas externas que aceleren a la partcula.
113
La ecuacin 8.1 muestra la equivalencia de la
velocidad en funcin de la posicin y el tiempo.
V
x
=
A r
x
At
(8.1)
donde:
V
x
: Velocidaden X.
A r
x
: Variacindela posicinen X.
A
t : Variacindel tiempo.
Realizando operaciones sobre la ecuacin 8.1 se
puede obtener la coordenada x de la posicin en un
tiempo 't', esto se muestra en la ecuacin 8.2.
x
f
=x
0
+V
0x
t
(8.2)
donde:
x
f
: Coordenada x final de posicin paratiempo ' t ' .
x
0
: Coordenada x inicial de posicin.
V
0x
: Velocidadinicial endireccin x.
t : tiempo.
Anlisis en el eje vertical, no existe movimiento
constante debido a la existencia de la gravedad
(aceleracin).
8.1.1.2.3.2. Movimiento acelerado.
Previamente al anlisis del movimiento, es preciso definir la
aceleracin.
114
La aceleracin es directamente proporcional al cociente del
cambio en la velocidad en un determinado lapso de tiempo.
Esta definicin se aprecia en la ecuacin 8.3
a=
A
V
At
(8.3)
donde:
a: Aceleracin.
A
V : Variacindela velocidad.
At : Variacindetiempo.
Anlisis en el eje horizontal, suponiendo que existe
aceleracin en la partcula, se determina el siguiente
comportamiento:
La ecuacin 8.4 presenta la velocidad final de una
partcula con aceleracin constante para un tiempo 't'.
V
fx
=V
0x
+a
x
t
(8.4)
donde:
V
fx
: Mdulodela velocidad final en X.
V
ox
: Mdulodela velocidad inicial en X.
t : tiempo.
Para calcular la posicin en la direccin x para un
tiempo 't' se emplea la ecuacin 8.5.
115
x
f
=x
0
+V
0x
t +
a
x
t
2
2
(8.5)
donde:
x
f
: Coordenadadela posicin final en X.
x
0
: Coordenadade la posicininicial en X.
V
0x
: Mdulodela velocidadinicial en X.
a
x
: Mdulodela aceleracin en X.
t : tiempo.
Anlisis en el eje vertical, es importante recalcar que
en esta dimensin existe aceleracin debido a la
gravedad.
El clculo de la velocidad con la existencia de gravedad
y aceleracin constante se representa en la ecuacin
8.6.
V
fy
=V
0y
+( a
y
+g)t
(8.6)
donde:
V
fy
: Mdulode lavelocidad final enY.
V
0y
: Mdulodela velocidadinicial enY.
a
y
: Mdulodela aceleracinenY.
g: Gravedad.
t : tiempo.
El clculo de la posicin en el eje y con la existencia de
gravedad y aceleracin constante se representa en la
ecuacin 8.7.
116
y
f
=y
0
+V
0y
t +
(a
y
+g) t
2
2
(8.7)
donde:
y
f
: Coordenadadela posicin final enY.
y
0
=Coordenadade la posicininicial enY.
a
y
: Mdulodela aceleracinenY.
g: Gravedad.
t : tiempo.
A continuacin se se presentan las ecuaciones 8.8 y 8.9
que muestran el clculo de las componentes en X y Y
del vector velocidad.
V
x
=
Vcos(0)
(8.8)
V
y
=
Vsen(0)
(8.9)
donde:
V
x
: Mdulodecomponente dela velocidad eneje X.
V
y
: Mdulodecomponente dela velocidad eneje Y.
V: Mdulodel vector velocidad.

0: Direccinde vector velocidad(ngulo).
8.1.1.2.4. Estudio de fuerzas que actan sobre una
partcula en reposo.
Para este estudio se utilizan las tres leyes de Newton [33].
Para que una partcula est en reposo debe estar apoyada, en
este caso estar sobre una superficie horizontal.
117
La figura 8.1 presenta el diagrama de cuerpo libre para una
partcula en reposo.
Como se observa en la figura sobre la partcula actan dos
fuerzas: la fuerza peso debido a la masa del cuerpo y la
fuerza normal como reaccin de la superficie.
La fuerza peso, en este caso, solo tiene componente en la
direccin 'Y', y su ngulo de direccin es de
O=
3
2
rad
, por
lo tanto se puede definir por la ecuacin 8.10.
118
Figura 8.1: Diagrama de cuerpo libre
de una partcula en reposo
W=

W
y
W=
Wsen(O)
j=mgsen(
3
2
)
j =mg
j
W=mg
(8.10)
donde:
W : Fuerza peso.
W
y
: Componentede fuerza peso enY.
W: Mdulodefuerza peso.
O: Direccinde fuerza peso.
j : Vector unitario eneje Y.

m: masadela partcula.
g: gravedad
La fuerza normal, en este caso, aparece como reaccin de la
superficie al peso apoyado de la partcula, tiene la misma
magnitud que el de la fuerza peso, pero est en sentido
contrario, es decir la direccin es
O=
2
. En este caso se
puede definir a esta fuerza mediante la ecuacin 8.11.
N=

N
y
N=
Nsen(O)
j =mgsen(
2
)
j =mg
j
W=mg
(8.11)
donde:
N : Fuerzanormal.
N
y
: Componentede fuerzanormal enY.
N: Mdulode fuerzanormal.
O: Direccinde fuerzanormal.
j : Vector unitario eneje Y.

m: masadela partcula.
g: gravedad
119
8.1.1.2.5. Estudio de fuerzas que actan sobre una
partcula en movimiento.
La figura 8.2 muestra el diagrama de cuerpo libre para una
partcula en movimiento y apoyada a una superficie horizontal.
En la figura anterior se puede observar la aparicin de dos
fuerzas de oposicin al movimiento, una debido al rozamiento
con la superficie (solo si esta apoyada) y otra debido al medio.
La fuerza de rozamiento con la superficie horizontal se debe a
que esta ltima puede no ser totalmente lisa, es decir, que su
coeficiente de rozamiento ( ) es distinto de mayor a 0.
El coeficiente de rozamiento es un valor escalar adimensional
cuyo valor oscila entre 0 y 1.
120
Figura 8.2: Diagrama de cuerpo libre de una partcula en
movimiento.
La fuerza de rozamiento, en este caso particular, puede tener
una direccin de O=0rad si la partcula se mueve a la
izquierda y O=Irad si lo hace a la derecha.
De forma general se define a la fuerza de rozamiento en la
ecuacin 8.12.
F
r
=

N
F
r
= mg
(8.12)
donde:
F
r
: Fuerza derozamiento.
N : Fuerzanormal.
: Coeficiente de rozamiento.
m: masa dela partcula.
g: gravedad
La fuerza de oposicin al movimiento es proporcional al
cuadrado de la velocidad de la partcula, proporcional a la
densidad del medio (ejemplo aire), al rea proyectada de
manera perpendicular a la direccin de la velocidad y a un
factor de forma (adimensional), que en el caso de cuerpos
esfricos tiene un valor de 0,4.
La ecuacin 8.13 define la fuerza de oposicin al movimiento.
121
F
op
=
K p
m
A
p
V
2
2
F
op
=
(0,4)p
m
( 4r
2
)V
2
2
F
op
=2,513p
m
(rV )
2
(8.13)
donde:
F
op
: Fuerzade oposicinal movimiento.
K : Factor de forma=0,4
p
m
: Densidad del medio.
A
p
: rea proyectadadela partcula.
V : Velocidaddela partcula.
r : radio dela partcula.
8.1.1.2.6. Clculo de la aceleracin de la partcula.
La segunda ley de Newton seala que la sumatoria de fuerzas
concurrentes a un punto material (partcula) es igual a la masa
por el vector aceleracin.
La ecuacin 8.14 muestra la segunda ley de Newton.
F=ma
(8.14)
donde:
F: Fuerzaresultante.
m: masade partcula.
a: Aceleracinde la partcula.
El vector resultante
F se obtiene de la sumatoria de todos

los vectores que afectan a un punto, en este caso a la
partcula, esta relacin se muestra en la ecuacin 8.15.
122
F=

F
x
+

F
y (8.15)
donde:
F: Fuerzaresultante.

F
x
: Sumatoriade fuerzas enel eje X.

F
y
: Sumatoriade fuerzasenel eje Y.
Despejando la aceleracin de la ecuacin 8.14 se obtiene las
aceleraciones para cada eje, estas se muestran en las
ecuaciones 8.16 y 8.17.
a
x
=

F
x
m
(8.16)
a
y
=

F
y
m
(8.17)
donde:
a
x
: Aceleracinen X.
a
x
: AceleracinenY.

F
x
: Sumatoriade fuerzas enel eje X.

F
y
: Sumatoriade fuerzasenel eje Y.
m: Masa de partcula.
8.1.2. RECOLECCIN Y FUENTE DE DATOS.
Para la obtencin de datos se recurri a la informacin histrica
obtenida de informes de laboratorio de Fsica Bsica.
123
Una vez organizada la informacin, se determin que el movimiento es
un fenmeno cuya variable discreta es el tiempo y adems que el
comportamiento del cuerpo durante el movimiento est determinado por
las leyes mencionadas en la seccin 8.1.1 de este captulo.
8.1.3. CONSTRUCCIN Y VERIFICACIN DEL MODELO PARA
COMPUTADORA.
Para lograr la correspondencia con el paradigma educativo de
aprendizaje por descubrimiento se defini desarrollar un ambiente
cinemtico de simulacin y no as experimentos elaborados, esto con el
fin de incentivar en los estudiantes su capacidad imaginativa y adems
ellos puedan desarrollar por si mismos una variedad de experimentos en
un solo ambiente.
Es por esto que se procedi a crear un modelo del fenmeno fsico de
movimiento cinemtico para los siguiente tpicos estudiados en la
mecnica newtoniana:
Movimiento rectilneo: uniforme, uniformemente acelerado y
cada libre.
Movimiento mixto o parablico.
124
8.1.3.1. Descripcin de contantes y variables de la simulacin.
En la construccin del modelo para computadora se determinaron
contantes y variables.
En la tabla 8.1 se detallan las constantes que se utilizan para la
simulacin.
Tabla 8. 1 : Valores constantes para la simulacin.
DESCRIPCIN NOMBRE VALOR
(constante). Pi 3,14
Factor de forma de partcula. K 0,4
En la tabla 8.2 se detallan los datos iniciales para la simulacin.
Tabla 8. 2 : Datos iniciales para la simulacin
DESCRIPCIN NOMBRE UNIDAD
Densidad del medio.
m
Kg/m
3
Direccin velocidad inicial.
v
radianes
Gravedad. g m/s
2
Masa del cuerpo. m Kg
Radio de partcula. r m
Velocidad inicial. V
0
m/s
125
En la tabla 8.3 se detallan las variables que se calculan solo al iniciar
la simulacin.
Tabla 8. 3 : Variables calculadas para iniciar la simulacin.
rea partcula. A
p
m
2
Densidad partcula.
p
Kg/m
3
Peso partcula. W
p
N = Kg.m/s
2
En la tabla 8.4 se detallan las variables calculadas durante cada
variacin de tiempo de la simulacin.
Tabla 8. 4 : Variables calculadas durante la simulacin.
Aceleracin en X a
x
m/s
2
Aceleracin en Y a
y
m/s
2
Direccin movimiento
p
radianes
Fuerza Rozamiento Ambiente en X F
rx
N = Kg.m/s
2
Fuerza Rozamiento Ambiente en Y F
ry
N = Kg.m/s
2
Posicin en X x m
Posicin en Y y m
Suma de Fuerzas en X F
x
N = Kg.m/s
2
Suma de Fuerzas en Y F
y
N = Kg.m/s
2
Velocidad en X V
x
m/s
Velocidad en Y V
y
m/s
126
8.1.3.2. Algoritmo general de la simulacin.
El algoritmo a seguir para lograr la simulacin se presenta en el
diagrama de flujo de la figura 8.3.
8.1.4. EJECUCIN DE PRUEBAS.
Puesto que el modelo de simulacin es determinstico y discreto, las
pruebas de validacin se realizaron mediante la comparacin de datos
calculados manualmente y los generados por la simulacin, donde se
pudo evidenciar que no existen errores.
127
Figura 8.3: Algoritmo general de la simulacin.
8.1.5. VALIDACIN DEL MODELO.
La validacin del Modelo se realiz en dos etapas:
Validacin de la fundamentacin terica, se contrasto las
leyes fsicas utilizadas con las expuestas en diversos libros de
Fsica [33, 34, 35]. Adems la revisin de profesionales
Fsicos: Ph. D. Roberto Mamani y M. Sc. Milka Torrico.
Validacin del comportamiento cinemtico, se prob el
modelo de simulacin con ejercicios propuestos en diversa
bibliografa [33, 34] y se pudo verificar que los resultados
obtenidos fueron los esperados.
8.1.6. DISEO DE LOS EXPERIMENTOS DE SIMULACIN.
El modelo desarrollado en este proyecto no requiere de
experimentaciones debido a que esta totalmente determinado por las
ecuaciones definidas en el apartado 8.1.1.2 del presente captulo. La
experimentacin se debe realizar cuando existe incertidumbre acerca de
el origen de los datos o en el caso de clculos extremadamente
complicados.
128
8.2. DESARROLLO DEL LABORATORIO VIRTUAL.
En este apartado se dar a conocer detalles sobre el desarrollo del
software, basado en las buenas prcticas que nos brinda la metodologa de
desarrollo gil XP.
8.2.1. ROLES ASIGNADOS SEGN LA METODOLOGA XP.
Los roles identificados son los siguientes:
Cliente, estudiantes y docentes de Fsica.
Administrador del proyecto, Ing. Roberto Juan Manchego
Castelln, tutor del presento proyecto.
Programador, Luis Roberto Prez Rios, autor del presente
proyecto.
Debido al reducido nmero de personas solo se pudo asignar un solo
programador, lo cual es posible por la flexibilidad de la metodologa XP,
bajo el compromiso y sentido de responsabilidad del programador [10].
Con los roles determinados se hace factible el inicio del desarrollo del
software utilizando la metodologa XP.
129
8.2.2. DOCUMENTACIN DEL SOFTWARE.
La metodologa XP no impone ni sugiere ninguna documentacin. Lo
que marca el ciclo de vida son las actividades realizadas en cada
iteracin realizada.
Existen en XP artefactos que suelen tener un soporte documental
asociado como ser: Historias de usuarios (user stories), lista de historias
de usuarios priorizados, planificacin de entregas, planificacin de
iteracin, pero no tiene una forma estndar impuesta por la
metodologa.
La lista historias de usuario priorizada representa la visin y
expectativas del cliente respecto a los objetivos y funciones que debe
cumplir el software. El cliente es el responsable de crear y gestionar la
lista bajo la direccin del programador.
XP como metodologa gil se basa en el principio del manifiesto gil que
dice: Valorar ms el software que funciona que la documentacin
exhaustiva. Solo lo que hace el software y lo bien que lo hace es
medida del progreso del proyecto. Sin embargo XP no restringe ningn
tipo de documentacin, se puede hacer uso de algunos artefactos o
herramientas como ser UML que puedan ser tiles para documentar el
proceso.
130
Para el proyecto se utilizaron diagramas UML para mejorar la
comunicacin e identificar de forma adecuada las tareas a realizar para
cada iteracin, tambin para representar la arquitectura del software.
8.2.3. HISTORIAS DE USUARIO.
Las historias de usuario fueron inferidas a partir de los objetivos del
proyecto, alcances del sistema y las recomendaciones de expertos en
docencia de Fsica.
La tabla 8.5 detalla la historia de usuario 1:
Tabla 8. 5 : Historia de usuario 1.
MOSTRAR MOVIMIENTO EN 2D.
Actores Docente, estudiante.
Descripcin
El Software deber poder mostrar en un espacio el
movimiento de un cuerpo esfrico.
Urgencia Inmediata.
Comentarios
El cuerpo debe ser representado por una esfera que
este a escala con los limites del rea de graficacin.
Fuente: Elaboracin Propia.
131
UN ESPACIO DE SIMULACIN GENERAL.
Descripcin
Debe haber solo un espacio donde se realice dos tipos
de movimiento RECTILNEO y MIXTO. Adems de
mostrar coordenadas cartesianas planas.
Urgencia Inmediata.
Comentarios
El espacio debe permitir realizar los experimentos sin
proveer al estudiante experimentos prediseados para
permitir la creatividad del mismo.
CONTROL SOBRE EL ESTADO DE LA SIMULACIN.
Descripcin
El software debe permitir el control de la velocidad, y
reproduccin de la simulacin.
Urgencia Inmediata.
Comentarios
Es importante que se pueda detener y proseguir con la
simulacin para lograr una observacin de mayor valor.
132
MOSTRAR EL VALOR DE LAS VARIABLES IMPLICADAS EN LA
SIMULACIN.
Descripcin
Se debe mostrar en cada momento de la simulacin los
valores obtenidos en la simulacin mediante y una tabla
de valores.
Urgencia Media.
Comentarios
Es importante que el usuario pueda evaluar el cambio
de valores en cada momento de la simulacin.
MOSTRAR LAS FUERZAS QUE SE APLICAN SOBRE LA
PARTCULA.
Descripcin
El usuario debe poder visualizar los vectores aplicados
sobre la partcula en la simulacin, adems de sus
valores en cada instante.
Urgencia Media.
Comentarios Agrega el valor didctico a la simulacin.
133
SIMULAR MOVIMIENTO EN EL VACO Y EN UN MEDIO DISTINTO.
Descripcin
El Software debe ofrecer la posibilidad de simular vaco y
un medio distinto. (Por ejemplo aire).
Urgencia Media.
Comentarios
Los usuario deben poder diferenciar el movimiento en
variedad de fluidos.
CAPTURAR GRFICA DE MOVIMIENTO EN CUALQUIER
MOMENTO DE LA SIMULACIN.
Descripcin
El software debe proporcionar al usuario la posibilidad de
capturar la grfica de simulacin.
Urgencia Media.
Comentarios
Se generar un documento PDF que contenga la grfica
de la simulacin con datos adicionales acerca del
ambiente y el cuerpo en movimiento.
134
GENERAR INFORMES A PARTIR DE LOS DATOS GENERADOS EN
LA SIMULACIN.
Descripcin
El programa podr generar informes que muestren la
tabulacin de los datos generados en la simulacin.
Urgencia Media.
Comentarios
Se generar un informe por separado para cada tabla en
la simulacin, el documento sera un archivo PDF.
PROPORCIONAR TUTORIALES ACERCA DE LA CINEMTICA
NEWTONIANA.
Descripcin
El programa debe ofrecer material digital sobre los
experimentos que son posibles de simular y adems del
fundamento terico de los mismos.
Urgencia Baja.
Comentarios
Los tutoriales deben ser diseados por profesores de
Fsica para asegurar la calidad educativa de los mismos,
se recomienda delegar esta tarea a expertos en didctica
de la Fsica.
135
8.2.4. LISTA PRIORIZADA DE HISTORIAS DE USUARIO.
A continuacin se muestra la lista de historias de usuario con
prioridades de desarrollo. Como solo existe un solo programador
(LRPR) se le asign todos los tems de la lista. La tabla 8.14 muestra el
detalle de la lista priorizada de historias de usuario.
Tabla 8. 14 : Lista priorizada de historias de usuario.
Item Descripcin
Duracin
Estimada
(Horas)
Asignado
a
Prioridad MUY ALTA
1
Implementar un objeto que represente a una
partcula, que ser fundamental para la
simulacin. Debe ser capaz de dibujarse.
10 LRPR
2
Implementar un espacio donde se pueda ver la
animacin.
20 LRPR
3 Implementar movimiento en el vaco. 25 LRPR
4 Implementar movimiento en el NO vaco. 25 LRPR
5
Implementar controles sobre la animacin:
velocidad, iniciar, detener.
15 LRPR
6
Implementar Sistema de referencia en el espacio
de animacin, (Coordenadas Cartesianas)
10 LRPR
7
Implementar campos para configuracin del
espacio de animacin y valores del cuerpo que
estar sometido a movimiento.
20 LRPR
ALTA
8 Implementar visor de valor de las variables en la
simulacin.
20 LRPR
136
9 Implementar coherencia entre simulacin grfica
y tiempo de simulacin.
30 LRPR
10 Implementar Controles para mostrar y ocultar
magnitudes vectoriales asociadas al cuerpo que
est en movimiento o reposo.
10 LRPR
11 Implementar captura de imagen de la simulacin
en cualquier momento y exportarla en un
documento PDF.
20 LRPR
12 Implementar la generacin de informes en PDF
de la simulacin realizada.
25 LRPR
13 Diseo de interfaz de usuario. 15 LRPR
14 Implementacin de Interfaz de usuario. 20 LRPR
MEDIA
15 Verificar Portabilidad del Software en distintos
Sistemas Operativos y monitores.
10 LRPR
16 Establecer requisitos de hardware y software
para el correcto funcionamiento del programa.
5 LRPR
BAJA
17 Disear tutoriales sobre el fundamento terico
de la cinemtica newtoniana.
40 LRPR
18 Implementar tutoriales digitales en el software. 15 LRPR
La lista anterior es el resultado de varias modificaciones realizadas en
cada iteracin y a lo largo del proceso.
137
8.2.5. PROTOTIPO DEL SOFTWARE.
Haciendo seguimiento a la metodologa XP, a partir de la lista priorizada
se desarrollo un prototipo de arquitectura que se observa, a
continuacin, en la figura 8.5.
138
Figura 8.4: Prototipo de la arquitectura del software.
8.2.6. PLANIFICACIN DE LAS ENTREGAS.
La planificacin de las entregas se realiz tomando en cuenta los
siguientes aspectos:
La lista priorizada de historias de usuario.
Usando como medida de esfuerzo el punto. (Un punto equivale a
25 horas de trabajo).
Una semana de trabajo regular equivale a un punto de esfuerzo.
La tabla 8.15 muestra la divisin en iteraciones del trabajo a realizar.
139
Tabla 8. 15 : Planificacin de entregas.
Iteracin Items Horas Esfuerzo Inicio Fin
1ra
1 10 0,4
27 de
Septiembre
8 de
Octubre
3 25 1
5 15 0,6
Total 50 2
2da
2 10 0,4
11 de
Octubre
26 de
Octubre
6 8 0,32
7 8 0,32
9 15 0,6
13 15 0,6
Total 56 2,24
3ra
4 15 0,6
26 de
Octubre
9 de
Noviembre
8 10 0,4
10 8 0,32
14 20 0,8
Total 53 2,12
4ta
11 20 0,8
9 de
Noviembre
24 de
Noviembre
12 25 1
15 10 0,4
16 5 0,2
Total 60 2,4
TOTAL GENERAL 219 8,76
27 de
Septiembre
24 de
Noviembre
TOTAL REAL 238 9,2
27 de
Septiembre
26 de
Noviembre
140
8.2.7. PRIMERA ITERACIN.
8.2.7.1. Plan de la primera iteracin.
El plan para la primera iteracin se se realiz acorde a la
planificacin de entregas. La lista de items a ser desarrollados,
durante la primera iteracin, se presentan en la tabla 8.16.
Tabla 8. 16 : Plan de la primera iteracin.
Tareas Responsable
Esfuerzo
estimado
en horas
Item 1 LRPR 10
Item 3 LRPR 25
Item 5 LRPR 15
50 horas
8.2.7.2. Desarrollo de la primera iteracin.
La primera iteracin se llev a cabo a partir del 27 de septiembre al 8
de octubre de 2010, cumpliendo con la planificacin de entregas.
141
8.2.7.2.1. Implementacin.
Para desarrollar el Item 1: Implementar un objeto que represente
a una partcula, que ser fundamental para la simulacin y debe
ser capaz de dibujarse, se realizaron las siguientes tareas:
Abstraccin de una partcula en la clase Cuerpo.
La figura 8.5 muestra la clase Cuerpo en su primera versin.
142
Figura 8.5: Clase Cuerpo, versin 0.1
Agregar funcionalidad de dibujarse a la clase Cuerpo.
Para esto se agregaron atributos a la clase cuerpo, tales como
posicin (donde se encuentra la partcula) y color. La figura 8.6
muestra la clase cuerpo con la funcionalidad de dibujarse.
Para desarrollar el item 3: Implementar movimiento en el vaco.
se realizaron las siguientes tareas:
143
Figura 8.6: Clase Cuerpo, versin 0.2.
Construir la clase Vector para modelar las magnitudes
vectoriales de velocidad y aceleracin.
La figura 8.7 muestra la primera versin de la clase Vector.
Agregar propiedades y funcionalidad de movimiento a la
clase Cuerpo.
Se agregan propiedades y funcionalidades a la clase Cuerpo con
el fin de implementar movimiento en el mismo.
144
Figura 8.7: Clase Vector, versin 0.1.
La figura 8.8 muestra la versin 0.3 de la clase cuerpo, que
implementa el movimiento.
145
Figura 8.8: Clase Cuerpo, versin 0.3.
Para desarrollar el item 5: Implementar controles sobre la
animacin: velocidad, iniciar, detener, se construy la clase
Ambiente que tiene al tiempo como propiedad, y es a partir de
la manipulacin de la variable tiempo se puede controlar la
velocidad, el inicio y el fin de la simulacin. Con el fin de que la
clase Ambiente corra de manera independiente se implemento
el mtodo run() de la interfaz Runnable de Java.
La figura 8.9 muestra la versin 0.1 de la clase Ambiente.
146
Figura 8.9: Clase Ambiente, versin 0.1.
8.2.7.2.2. Refactorizacin.
El proceso de refactorizacin aplicado a la primera iteracin no
produjo ningn cambio ni modificacin.
8.2.7.2.3. Diagrama de clases.
La figura 8.10 muestra el diagrama de clases desarrollado
durante la primera iteracin.
147
Figura 8.10: Diagrama de clases, 1ra iteracin.
8.2.7.2.4. Diagrama de casos de uso.
El diagrama de casos de uso se elabor con el fin de mostrar en
lenguaje natural la funcionalidad que se presenta en el desarrollo
de la primera iteracin.
La figura 8.11 muestra el diagrama de casos de uso para la
primera iteracin.
148
Figura 8.11: Diagrama de casos de uso, 1ra iteracin.
8.2.7.2.5. Pruebas a la primera iteracin.
Tal como indican las prcticas de la metodologa XP, las pruebas
se llevaron a cabo de forma paralela al desarrollo de la iteracin.
El detalle de las pruebas a la primera iteracin se encuentran en
el anexo A del presente documento.
8.2.8. SEGUNDA ITERACIN.
8.2.8.1. Plan de la segunda iteracin.
El plan para la segunda iteracin se se realiz acorde a la
planificacin de entregas. La lista de items a ser desarrollados,
durante la primera iteracin, se presentan en la tabla 8.17.
Tabla 8. 17 : Plan de la segunda iteracin.
TAREAS Responsable
Esfuerzo
estimado
en horas
Item 2 LRPR 10
Item 6 LRPR 8
Item 7 LRPR 8
Item 9 LRPR 15
Item 13 LRPR 15
56 Horas
149
8.2.8.2. Desarrollo de la segunda iteracin.
La segunda iteracin se llev a cabo a partir del 11 de octubre al 26
de octubre de 2010, cumpliendo con la planificacin de entregas.
Para desarrollar el Item 2: Implementar un espacio donde se
pueda ver la animacin, se realizaron las siguientes tareas:
Agregar animacin a la clase Ambiente.
Para lograr la animacin se utiliz el mtodo de UPS (Updates
Per Second), que trata de actualizar lo que se muestra en
pantalla por cada variacin de tiempo, para lograrlo de forma
eficiente tambin se recurre al mtodo DBG (Double Graphics
Buffer) que asegura que siempre habr algo que mostrar.
El mtodo DBG utiliza dos objetos grficos para la animacin el
primero es el que se est mostrando y el segundo el que se est
dibujando mientras se actualiza animacin.
150
La figura 8.12 explica el uso del UPS y DBG.
De este modo se logra la animacin y se implementa en la clase
Ambiente que proporciona un espacio donde se pueden dibujar
el resto de los objetos de la simulacin.
La figura 8.13 muestra la versin 0.2 de la clase Ambiente.
151
Figura8.12: UPS + DBG.
Para desarrollar el Item 6: Implementar sistema de referencia en
el espacio de animacin se realiz las siguiente tarea:
152
Cuadricular el espacio de animacin a partir de ejes X e Y.
Utilizando el objeto Graphics de Java se dibujan lneas
perpendiculares y paralelas a los ejes X e Y, esta funcionalidad
se agrega a la clase Ambiente.
La figura 8.14 muestra la versin 0.3 de la clase Ambiente que
implementa dibujar el espacio cuadriculado respecto de los ejes X
e Y.
153
La figura 8.15 muestra el resultado de la implementacin de un
espacio de simulacin referenciado y una partcula dentro del
mismo.
Para desarrollar el Item 7: Implementar campos para
configuracin del espacio de animacin y valores del cuerpo que
estar sometido al movimiento se realiz las siguiente tarea:
154
Figura 8.15: Implementacin del espacio de simulacin referenciado.
Implementar un formulario para la obtencin de datos de
configuracin.
Se desarrollo la clase Control que obtiene datos de
configuracin a travs de formularios.
La figura 8.16 muestra la clase Control versin 0.1.
155
Figura 8.16: Clase Control, versin 0.1.
Implementar una clase principal para interactuar interfaz con
simulacin.
La clase principal se denomino Simulador, tiene la
responsabilidad de coordinar el control con la simulacin, adems
de dividir la funcionalidad en hilos (procesos independientes).
La figura 8.17 muestra la clase Simulador en su versin 0.1.
La implementacin de las clase Ambiente, Control y Simulador
permiten tener la primera versin donde se puede interactuar con
el usuario de forma amigable.
156
Figura 8.17: Clase Simulador, versin 0.1.
La figura 8.18 muestra el resultado de la implementacin de las
clases Ambiente, Control y Simulador.
El desarrollo de los items 9 y 13 se realizaron como consecuencia
del desarrollo de todos los anteriores items desarrollados.
El proceso de refactorizacin aplicado a la segunda iteracin
logr el siguientes resultado:
157
Figura 8.18: Resultado implementacin de clases Ambiente, Control y
Simulador.
- Generalizar comportamiento dibujarse de las clases Ambiente
y Cuerpo mediante la interfaz Dibujable que se muestra en la
figura 8.19.
durante la segunda iteracin.
158
Figura 8.19: Interfaz Dibujable, versin 0.1.
Figura 8.20: Diagrama de clases, 2da iteracin.
durante la segunda iteracin.
8.2.8.2.5. Pruebas a la segunda iteracin.
Las pruebas a la segunda iteracin se llevaron a cabo de forma
paralela al desarrollo. El detalle de las pruebas se encuentran en
el anexo B del presente documento.
159
Figura 8.21: Diagrama de casos de uso, 2da iteracin.
8.2.9. TERCERA ITERACIN.
8.2.9.1. Plan de la tercera iteracin.
El siguiente plan se realiz acorde a la planificacin de entregas. En
el cuadro 8.18 se detallan los tems a desarrollar en la tercera
iteracin.
Tabla 8. 18 : Plan de la tercera iteracin.
TAREAS Responsable
Esfuerzo
estimado
en horas
Item 4 LRPR 15
Item 8 LRPR 10
Item 10 LRPR 8
Item 14 LRPR 20
53 Horas
8.2.9.2. Desarrollo de la tercera iteracin.
La tercera iteracin se llev a cabo a partir del 27 de octubre al 9 de
noviembre de 2010, cumpliendo con la planificacin de entregas.
Para desarrollar el Item 4: Implementar movimiento en el NO
vaco, se realiz la siguiente tarea:
160
Agregar caractersticas del NO vaci al medio donde ocurre
el movimiento, es decir en la clase Ambiente.
Se agreg a la clase Ambiente valores de densidad de ambiente,
coeficiente de rozamiento del suelo. La versin 0.4 de la clase
Ambiente contiene las nuevas caractersticas y se muestra en la
figura 8.22.
161
Para desarrollar el Item 8: Implementar visor de valores de las
variables en la simulacin, se realizaron las siguiente tareas:
Agrupar variables por tipo.
La agrupacin se realiz en 7 grupos que se detalla en la tabla
8.19.
Tabla 8. 19 : Grupos de variables de simulacin.
GRUPO DESCRIPCIN
Situacin actual
Estado actual de todas las variables en
cada momento de la simulacin.
Posicin
Listado histrico de valores de las
variables de posicin en el vaco y en un
ambiente para cada variacin de tiempo.
Velocidad en vaco
Listado histrico de valores de la
velocidad en el vaco para cada
variacin de tiempo.
Velocidad en
ambiente
velocidad en un ambiente para cada
variacin de tiempo.
Aceleracin en vaco
aceleracin en el vaco para cada
variacin de tiempo.
Aceleracin en
ambiente
aceleracin en un ambiente para cada
variacin de tiempo.
Rozamiento
Listado de las fuerzas de rozamiento
generadas por el suelo y por el ambiente
en cada variacin de tiempo.
162
Ordenar por tablas.
Cada grupo de variables se ordenan mediante el uso de modelos
de tabla (javax.swing.table.DefaultTableModel) y como ndice de
filas se utiliza la variacin de tiempo.
Implementar visor de tablas.
Se construy la clase Tablas para agrupar todos los conjuntos de
variables y mostrarse en la interfaz de usuario. El contenido de
las tablas se actualiza en cada variacin de tiempo.
La figura 8.23 muestra la clase Tablas versin 0.1.
163
Figura 8.23: Clase Tablas, versin 0.1.
La implementacin de la clase tablas en la interfaz de usuario se
muestra en la figura 8.24.
164
Figura 8.24: Implementacin de Tablas.
Para el desarrollo del item 10: Implementar controles para
mostrar y ocultar magnitudes vectoriales asociadas al cuerpo que
est en movimiento o reposo, se realizaron las siguientes tareas:
Mostrar magnitudes vectoriales.
Se agrega a la clase vector la funcin de dibujarse, como es una
magnitud vectorial no basta con mostrar un valor numrico, sino
un componente grfico que se representa mediante flechas, para
ello se construyo la clase Flecha.
La figura 8.25 muestra la versin 0.1 de la clase Flecha.
165
Figura 8.25: Clase Flecha, versin 0.1.
La figura 8.26 muestra la versin 0.2 de la clase Vector.
Controles para ocultar y mostrar magnitudes vectoriales.
Se agrego a la clase Control, controles para mostrar u ocultar la
visualizacin de las magnitudes vectoriales.
La figura 8.27 muestra la versin 0.2 de la clase Control.
166
La implementacin de los controles para la visualizacin se
muestran en la figura 8.29.
167
Figura 8.28: Controles
de visualizacin.
Para desarrollar el Item 14: Implementar la interfaz de usuario,
se realizaron las siguiente tareas:
Diseo de prototipo de interfaz para usuario.
El prototipo final para la interfaz de usuario se muestra a
continuacin en la figura 8.29.
168
Figura 8.29: Prototipo de la interfaz de usuario.
Agregar administracin de simulacin a la clase Control.
La administracin de la simulacin, comprende la configuracin
configuracin de datos iniciales, del ambiente, opciones de
visualizacin y adems control de tiempos y generador de
informes digitales, para ello se modifico la clase Control, la cul
se muestra en la figura 8.30.
169
Agregar barra men.
La barra men est dividida en 4 categoras y varios items en
cada una de ellas, como se detalla en la tabla 8.20.
Tabla 8. 20 : Divisin barra men.
CATEGORA SUB-CATEGORA ACCIN
Archivo
Generar informes
Generar informes
del estado de la
simulacin y de los
datos en PDF
Salir Cerrar LAVIFIS
Conocimiento
Aceleracin partcula
Abrir tutorial
Cinemtica newtoniana
Componentes velocidad
en el plano
Fuerzas sobre partcula en
movimiento
Fuerzas sobre partcula en
reposo
Movimiento acelerado
Movimiento constante
Tablas
Densidad aire
Mostrar tabla con
informacin
Densidad substancias
Ayuda
Autor Autor de software
Acerca de LAVIFIS
Datos sobre
LAVIFIS
Manual de usuario
Mostrar manual de
usuario
170
La figura 8.31 muestra la clase BarraMenu, donde se desarrolla
todo el contenido de la tabla 8.20.
Finalmente se agreg la clase BarraMenu al Simulador, como se
muestra en la figura 8.32.
171
Figura 8.31: Clase BarraMenu, versin 0.1.
Figura 8.32: Clase Simulador, versin 0.2
Algunos de los tutoriales a los que se puede acceder desde la
barra men, se muestran a continuacin en la figura 8.33.
La implementacin de la interfaz grfica se muestra a
continuacin en la figura 8.34.
172
Figura 8.34: Implementacin de interfaz de usuario.
Figura 8.33: Tutoriales en barra men.
En el proceso de refactorizacin se detecto que las clases Flecha
y Vector tienen comportamiento similar, por lo que se extrajo el
comportamiento bsico en comn y se determino que la clase
padre ser Flecha y est a su vez implementar la interfaz
Dibujable, el cambio en las clases mencionadas se muestra a
continuacin.
La figura 8.35 muestra la clase Flecha (clase padre de Vector).
La figura 8.36 muestra la clase Vector.
173
Figura 8.35: Clase Flecha, versin 0.2.
durante la tercera iteracin.
174
Figura 8.37: Diagrama de clases, 3ra iteracin.
La figura 8.38 muestra el diagrama de casos de uso de la tercera
iteracin.
8.2.9.2.5. Pruebas a la tercera iteracin.
Las pruebas se llevaron a cabo de forma paralela al desarrollo de
la iteracin. El detalle de las pruebas realizadas a la tercera
iteracin se encuentran en el anexo C del presente documento.
175
Figura 8.38: Diagrama de casos de uso, 3ra iteracin.
8.2.10. CUARTA ITERACIN.
8.2.10.1. Plan de la cuarta iteracin.
El siguiente plan se realiz acorde a la planificacin de entregas, en
la tabla 8.21 se detallan los tem a desarrollar.
Tabla 8. 21 : Plan de la cuarta iteracin.
Requerimientos Responsable Esfuerzo estimado
en horas
Item 11 LRPR 20
Item 12 LRPR 25
Item 15 LRPR 10
Item 16 LRPR 5
Item 18 LRPR 15
75 horas
8.2.10.2. Desarrollo de la cuarta iteracin.
La cuarta iteracin se llev a cabo a partir del 9 de noviembre al 26
de noviembre de 2010.
176
Para desarrollar el Item 11: Implementar captura de imagen de la
simulacin en cualquier momento y exportarla en un documento
PDF, se realizaron las siguiente tareas:
Crear un documento PDF vaco con las dimensiones del
espacio de simulacin.
El espacio de simulacin est implementado mediante la clase
Ambiente, es en esta clase que se agrega el objeto
com.lowagie.text.Document de la libreria itext que contiene clases
para la manipulacin y creacin de documentos PDF y RTF.
Capturar el contenido del objeto java.awt.Graphics que
contiene la grfica de la simulacin y copiarla al documento
PDF.
La libreria itext puede capturar el contenido del objeto
java.awt.Graphics2D de java, por esto es necesario convertir el
objeto java.awt.Graphics mediante un casting, una vez realizada
la conversin se puede copiar el contenido grfico de la clase
Ambiente al documento PDF.
177
Agregar datos del ambiente de simulacin por medio de una
tabla al documento PDF.
Se agrega a la clase Ambiente una tabla para PDF donde se
mostrarn los valores configurados para el Ambiente, adems
datos de la partcula.
La figura 8.39 muestra la clase Ambiente en su versin 0.5 que
implementa el item 11.
178
Para desarrollar el Item 12: Implementar la generacin de
informes en PDF sobre la simulacin realizada, se realizaron las
siguientes tareas:
Crear un documento PDF por cada categora de variables de
la clase Tablas.
En la clase Tablas se crean 6 documentos PDF que almacenarn
todo el contenido de las tablas (Situacin actual, posicin,
velocidad, aceleracin, rozamiento) en un objeto PdfPTable.
Exportar el contenido de cada tabla en la clase Tablas a un
documento PDF.
Se implementa el mtodo llenar tabla que copia el contenido de
una tabla a una PdfPTable, el contenido copiado se puede
realizar en cualquier momento de la simulacin.
Agregar un selector de carpeta donde se guardaran los
documentos PDF generados.
Se agrega a la clase Simulador un mtodo que llama a un
selector de ventanas (JfileChooser) de java, para que el usuario
pueda determinar el lugar donde se guardaran los informes PDF
generados.
179
La figura 8.40 muestra la clase Tablas, que implementa la
capacidad de generar informes PDF.
Para desarrollar el Item 18: Implementar tutoriales digitales en el
software, se realiz la siguiente tarea:
180
Figura 8.40: Clase Tablas, versin 0.2.
Agregar funciones en la clase BarraMenu y su categora
Conocimientos, para abrir los tutoriales apropiados
previamente seleccionados.
Se agreg funcionalidad que permite abrir archivos de tipo PDF
desde el software, haciendo uso del sistema operativo anfitrin
del software.
La clase BarraMenu que implementa la apertura de documentos
externos se muestra a continuacin en la figura 8.41.
Para cumplir con el Item 17: Verificar portabilidad del software en
distintos sistemas operativos, se debe tomar en cuenta que el
software desarrollado en el presente proyecto requiere un JVM
(Java Virtual Machine) en su versin 6 o superior, por lo tanto por
lo definido en el captulo 7 del presente proyecto acerca de las
181
Figura 8.41: Clase BarraMenu, versin 0.2.
caracterstica de portabilidad (multiplataforma) del lenguaje de
programacin java, se indica que el software tiene amplia
portabilidad.
Para el cumplimiento del Item 16: Establecer requisitos de
hardware y software, los requisitos se software se detallan a
continuacin.
La tabla 8.22 muestra los requerimiento de software, bajo el
criterio de funcionalidad.
Tabla 8. 22 : Requerimientos de software.
Tipo de Software Funcin Recomendado
Mquina virtual de
JAVA.
Plataforma para la
ejecucin del
software.
Java 1.6 o superior
Lector de
documentos PDF
Administracin de
documentos
digitales contenidos
y generados por el
software.
Windows.
- Adobe Acrobat
Reader 2.0 o
superior.
Linux.
- gPDF
- xPDF
La tabla 8.23 muestra los requerimiento de hardware, basado en
el criterio de que el funcionamiento depende completamente de
JVM, por lo que se el requerimiento se basa en lo que expone
Oracle en el sitio oficial de Java [38].
182
Tabla 8. 23 : Requerimiento de hardware.
HARDWARE Requerimiento.
Disco duro 100 MB de espacio disponible.
Memoria RAM.
64 MB para arquitecturas de 32 bits.
128 MB para arquitecturas de 64 bits.
Procesador Pentium II superior o similar.
Monitor Resolucin mnima de 1000*850 pixels.
Fuente: [38].
En el proceso de refactorizacin se determino generalizar el
comportamiento de las clases que generan informes PDF
(Ambiente y Tablas) mediante la interfaz imprimible.
La interfaz Imprimible, se muestra a continuacin en la figura
8.42.
183
Figura 8.42: Interfaz Imprimible,
versin 0.1.
durante la tercera iteracin.
184
Figura 8.43: Diagrama de clases, 4ta iteracin.
La figura 8.44 muestra el diagrama de casos de uso de la cuarta
y ltima iteracin.
185
Figura 8.44: Diagrama de casos de uso, 4ta iteracin.
8.2.10.2.5. Pruebas a la cuarta iteracin.
Las pruebas se llevaron a cabo de forma paralela al desarrollo de
la iteracin. El detalle de las pruebas realizadas a la cuarta
iteracin se encuentran en el anexo D del presente documento.
8.2.11. LAVIFIS VERSIN 1.0.
A la culminacin del proyecto se denomin al software como
Laboratorio virtual de Fsica LAVIFIS versin 1.0 con lo cual se
concluy el desarrollo del software. La tabla 8.dad se detallan las
versiones de las clases que componen a LAVIFIS 1.0.
Tabla 8. 24 : Clases que componen a LAVIFIS.
Clase Versin Descripcin
Ambiente 0.6
Clase encargada de simular un ambiente de
simulacin.
BarraMenu 0.2 Opciones de interfaz para usuario.
Control 0.3
Controles sobre la simulacin, configuracin de
ambiente y cuerpo.
Cuerpo 0.3 Simula una partcula.
Flecha 0.2
Abstraccin de una flecha para el entorno de
simulacin.
Vector 0.3
Abstraccin del comportamiento de una magnitud
vectorial.
Tablas 0.2 Contenedor de datos de simulacin.
Simulador 0.2 Administrador general del software.
186
CAPTULO 9
CAPTULO 9. CONCLUSIONES Y RECOMENDACIONES.
9.1. CONCLUSIONES.
En el presente trabajo se ha realizado un software educativo basado en
aprendizaje por descubrimiento, con el fin de apoyar el proceso enseanza
aprendizaje de la Fsica bsica.
Para el desarrollo del software se ha optado por utilizar soluciones de
actualidad tanto en tecnologa como metodologa. Escogiendo una de las
llamadas giles como es programacin extrema (XP), separando el proceso
en sucesivas iteraciones que han aadido funcionalidad progresivamente.
La identificacin de experimentos a implementar por el software
desarrollado, ha permitido ampliar el alcance del proyecto y no limitarse a la
mera repeticin experimental basada en un enfoque conductista, sino mas
bien permitir al usuario disear y configurar una variedad de experimentos,
187
respondiendo a una de las tendencias pedaggicas contemporneas, el
aprendizaje por descubrimiento.
Se ha puesto en evidencia el gran potencial educativo que guardan los
simuladores, al permitir a los estudiantes comparar la realidad con lo terico
y lograr que estos puedan inferir y aplicar la teora en la vida cotidiana.
Se pudo constatar la enorme factibilidad con la que se pueden disear e
implementar los modelos matemticos de fenmenos fsicos, por haber una
amplia investigacin sobre los mismos.
La aplicacin de metodologa de simulacin debe necesariamente incluir el
desarrollo de mdulos de visualizacin de las realidades simuladas para
aumentar el valor de uso de las mismas.
Una vez puesto en prctica el software desarrollado, se pudo evidenciar
que logra la atencin de los estudiantes en el fenmeno estudiado, y deja
de lado la medicin directa puesto que los datos obtenidos se ordenan y
generan automticamente.

El uso de la metodologa de desarrollo gil XP en cuanto a pruebas se
refiere, logr su cometido haciendo evidente la reduccin en el tiempo de
desarrollo.
188
El desarrollo del proyecto, por su naturaleza educativa, revel la
importancia del uso de medios didcticos en clase (aula), ya sean
orientados al grupo o al sujeto, que respondan a la realidad tecnolgica
actual, para lograr motivar e interesar a los estudiantes en el aprendizaje de
las ciencias.
9.2. RECOMENDACIONES.
Las recomendaciones dadas por el autor se las hace partir de los siguientes
puntos de vista: Demanda social, proceso educativo y trabajos futuros.
9.2.1. DEMANDA SOCIAL.
Es de suma importancia aportar con una solucin a la escasez de
laboratorios de experimentacin en Bolivia, es por esto que se
recomienda continuar con lneas de investigacin y desarrollo que a
corto o mediano plazo puedan potenciar a todo el sistema educativo
boliviano con laboratorios virtuales en todas las reas.
189
9.2.2. PROCESO EDUCATIVO.
El uso de LAVIFIS por los estudiantes puede tener mayor impacto en su
educacin si se trabaja en equipos y con la tutora de un docente.
El docente debe estimular, con ejemplos del uso de LAVIFIS, al
descubrimiento de experimentos que se pueden realizar en el ambiente
virtual.
9.2.3. TRABAJOS FUTUROS.
Para futuras investigaciones, trabajos similares o profundizacin del
tema se recomienda tomar en cuenta los siguientes aspectos:
Implementar la interaccin de mas de un cuerpo en el ambiente de
simulacin, para as poder experimentar con fenmenos mas
complejos que los de la cinemtica newtoniana.
Hacer uso del ambiente para insertar objetos con comportamiento
propio.
Ampliar el rango de escala de la dimensin espacio para poder
estudiar y simular cuerpos diminutos e invisibles al ojo humano.
Generar informacin basado en hiptesis.
Implementar la visualizacin de los experimentos en tres
dimensiones (3D).
190
BIBLIOGRAFA.
[1] ABASCAL, M. T., Castillo, S., Toribio, A. y Ynez, I. (1983-1984), Aplicacin
de la Informtica a la enseanza de la Fsica y Qumica, Madrid, CIDE.
[2] ACEVEDO, J. A. (1989), Comprensin newtoniana de la cada de cuerpos. Un
estudio de su evolucin en el bachillerato, Enseanza de las Ciencias,
7(3), 241-246.
[3] ANDALORO, G., Donzelli, V. y Sperandeo-Mineo, R. M. (1991), Modelling in
Physics teaching: The role of computer simulation, International Journal of
Science Education, 0. 13(3), 243-254.
[4] AQUEDA, C. y otros (2004). Anlisis de la enseanza de la Fsica en Europa:
el fomento de competencias generales a estudiantes universitarios. Revista
Iberoamericana de Educacin. Universidad Europea de Madrid.
[5] ARIAS, A. (2006). La Fsica en 2005 y el aprendizaje significativo. Revista
Iberoamericana de Educacin. Universidad de la Habana, Cuba.
[6] BARCEL, J. (1996). Simulacin de Sistemas Discretos. Publicaciones de
Ingeniera de Sistemas. ISDEFE. Madrid.
191
[7] BARRIO, F, J. y MORALES, J. A. (1989). Pueden ayudar las simulaciones
con ordenador a provocar en los alumnos un cambio conceptual en el
campo de la mecnica clsica?. CIDE. Madrid.
[8] COSS B, R. (2003). SIMULACIN. Un enfoque prctico. Editorial Limusa,
S.A. Grupo Noriega editores. Balderas, Mxico.
[9] COLEMAN, F. M. (1997). Software simulation enhances science experiments,
T.H.E. Journal, 25(2), 56-58.
[10] CRONIN, G. (2000). Extreme solo. A case study in single developer extreme
programming. Universidad de Auckland.
[11] DEEMER, P. BENEFIELD G., LARMAN C. Y VODDE B. (2009). The Scrum
Primer.
[12] FOWLER, M. (2010). Is design dead?. Consulta web. Disponible en:
http://www.martinfowler.com/articles/designDead.html . Consulta realizada
el 12 de Junio 2010.
[13] GUASCH A., PIERA, M., Casanovas J., FIGUERAS J., (2002). Modelado y
Simulacin. Aplicacin a procesos logsticos de fabricacin y servicios.
Ediciones UPC.
192
[14] HEINECK, R. (2005). Software educativo no ensino de Fsica: analise
quantitativa e qualitativa. Revista Iberoamericana de Educacin.
Universidad de Passo Fundo, Brasil.
[15] HUGUES, W. R. (1973), A study of use of computer simulated experiments in
the physics classroom, tesis, The Ohio state University.
[16] HERRAMIENTAS CASE (2010). Consulta web. Disponible en
http://phyro.pastebin.com/zeqkMgjs. Consulta realizada el 20 de Junio,
2010.
[17] JONASSEN, D.H. (1996). Computers in the classroom: Mindtools for critical
Thinking. Englewood Cliffs, NJ: Prentice Hall.
[18] KNIBERG, H. y SKARIN M. (2010). Kanban y Scrum obteniendo lo mejor de
ambos. Media Inc. Estados Unidos.
[19] KEITH, L. (2010). The Java is Faster than C++ and C++ Sucks Unbiased
Benchmark. Consulta Web disponible en http://kano.net/javabench/.
Consulta realizada el 1 de Junio, 2010.
[20] LETELIER, P. (2004). Metodologas giles para el desarrollo de software:
eXtreme Programming. Recurso web disponible en:
http://www.willydev.net/descargas/masyxp.pdf . Consulta realizada en 11
diciembre, 2010.
193
[21] LUCERO, I., y otros. (2000). Trabajo de laboratorio de Fsica en ambiente
real y virtual. Memorias Comunicaciones Cientficas y Tecnolgicas.
UNNE. Argentina.
[22] MARCHISIO, S. y otros. (2004). Experiencia con uso de simulaciones de la
Fsica de los dispositivos electrnicos. Primer Congreso Virtual
Latinoamericano de Educacin a Distancia. Facultad de Ciencias
Exactas, Ingeniera y Agrimensura, Universidad de Rosario.
[23] MARQUES, P. (1995). Software educativo. Gua de uso y metodologa de
diseo. Barcelona, Estel.
[24] NORTON, P., and WILDBURG, K. (1998). Teaching with technology. Fort
Worth, Tx: Harcourt Brace.
[25] PALACIO, J. (2008). Flexibilidad con SCRUM: Principios de diseo e
implantacin de campos Scrum.
[26] PIAGET, J. (1978). La equilibracion de las estructuras cognitivas. Madrid,
Siglo XXI.
[27] PIDD, M. (1998). Computer Simulation in Management Science, Ed. Wiley.
[28] POZO, J. I. (1987). Aprendizaje de la ciencia del pensamiento causal, Madrid,
Visor.
194
[29] PRESSMAN, R. S. (2002). Ingeniera de Software, un enfoque prctico.
Editorial McGraw Hill / Interamericana. Madrid, Espaa.
[30] RUIZ, J. C. y otros (2005). Estrategia didctica para la formacin integral del
estudiante de Bachillerato mediante el proceso de enseanza aprendizaje
de la Fsica. Universidad de Nueva Len, Mxico.
[31] SNCHEZ, C. (2004). Oness: un proyecto open source para el negocio textil
mayorista desarrollado con tecnologas innovadoras. Facultad de
informticas. Universidad da Corua. Espaa.
[32] SCHENONE, M. H. (2004). Diseo de una metodologa gil de desarrollo de
software. Facultad de Ingeniera. Universidad de Buenos Aires. Argentina.
[33] SERWAY, F. (1990). Fsica. Tomo I. Editorial McGraw Hill, Estados Unidos.
[34] SERWAY, F. (1990). Fsica. Tomo II. Editorial McGraw Hill, Estados Unidos.
[35] SERWAY, F. (1995). Fsica Clasica. Editorial McGraw Hill, Estados Unidos.
[36] SIERRA, J. L. (2004). Estudio de la influencia de un entorno de simulacin por
ordenador en el aprendizaje por investigacin de la Fsica en bachillerato,
Tesis Doctoral. Premio nacional EX AEQUO de investigacin educativa
2004. Ministerios de Educacin y Ciencia, Espaa.
195
[37] SOMMERVILLE, I. (2005). Ingeniera del software. Sptima Edicin.
Editorial Pearson Addison Wesley. Madrid.
[38] SUN MICROSYSTEMS (2010). Consulta web. Disponible en
http://www.java.com/en/download/help/6000011000.xml. Consulta realizada
el 23 de Diciembre, 2010.
196
ANEXOS
197
ANEXO A
ANEXO A. PRUEBAS REALIZADAS A LA PRIMERA ITERACIN.
PRUEBAS DE UNIDAD.
Para realizar estas pruebas se utilizo el framework JUnit usando el IDE Netbeans.
Las pruebas se aplicaron a cada una de las clases desarrolladas para la primera
iteracin y a los mtodos y funciones de cada una de ellas.
La figura A.1 muestra el resultado de la prueba de unidad aplicada a la clase
Cuerpo, en el primera iteracin.
198
Figura A.1: Resultado prueba de unidad a clase Cuerpo, 1ra iteracin.
Vector, en el primera iteracin.
Ambiente, en el primera iteracin.
199
Figura A.2: Resultado prueba de unidad clase Vector, 1ra iteracin.
Figura A.3: Resultado prueba de unidad clase Ambiente, 1ra iteracin.
PRUEBAS DE CAJA BLANCA.
Las pruebas se realizarn a los siguientes algoritmos: dibujar la animacin del
movimiento (Clase Ambiente) y actualizar datos del cuerpo (Clase Cuerpo), debido
a que son los que presentan mayor complejidad y son imprescindibles para el
funcionamiento del sistema.
La figura A.4. muestra la grfica de flujo para dibujar la animacin del movimiento.
Como se observa existen cinco nodos en total, dos nodos predicado (1 y 2), dos
regiones (R1 y R2) y seis aristas. Basados en los datos del grfico se proceder al
clculo de la complejidad ciclomtica (V(G), donde G es el grfico de flujo) y la
identificacin de las rutas independientes:
V (G)=NumAristasNumNodos+2=65+2=3
V (G)=NumNodosPredicado+1=2+1=3
200
Figura A.4: Grfica de flujo del algoritmo para dibujar la
animacin del movimiento en la clase Ambiente.
La complejidad ciclomtica es 3, por lo tanto deben de existir la misma cantidad de
rutas independientes, las cuales son:
ruta 1: n1 n3 .
ruta 2: n1 n2 n5 n1 n3.
ruta 3: n1 n2 n4 n2 n5 n1 n3.
En la figura A.5 se puede observar la grfica de flujo para actualizar los datos del
cuerpo.
Se puede evidenciar que existen seis nodos, tres nodos predicado (1, 2 y 4), tres
regiones (R1, R2 y R3) y ocho aristas, por lo tanto se procede al calculo de la
complejidad ciclomtica.
201
Figura A.5: Grfica de flujo del
algoritmo para actualizar los datos
en la clase Cuerpo.
La complejidad ciclomtica es 4, por lo tanto las rutas independientes son:
ruta 1: n1 n4.
ruta 2: n1 n2 n3 n4.
ruta 3: n1 n2 n2 n3 n4.
ruta 4: n1 n2 n3 n3 n4.
A partir de las rutas independientes halladas para los casos revisados, es que se
pudo probar la correcta funcionalidad del software.
PRUEBAS DE CAJA NEGRA.
Las pruebas de caja negra al estar orientadas a la funcionalidad del software se
basaran en la interfaz del laboratorio virtual, en la primera iteracin an no se
desarroll una interfaz, es por esto que no se realizaron estas pruebas.
202
ANEXO B
ANEXO B. PRUEBAS REALIZADAS A LA PRIMERA ITERACIN.
PRUEBAS DE UNIDAD.
La evaluacin se realiz a los cambios realizados y nuevas implementaciones, los
resultados se exponen a continuacin.
La figura B.1 muestra el resultado de la prueba de unidad aplicada a la clase
Ambiente, en la segunda iteracin.
203
Figura B.1: Resultado prueba de unidad clase Ambiente, 2da iteracin.
Control, en la segunda iteracin.
Simulador, en la segunda iteracin.
En esta iteracin no se desarrollaron algoritmos que sean relevantes para el
funcionamiento, es por esto que no se realizaron las pruebas de caja blanca.
204
Figura B.2: Resultado prueba de unidad clase Control, 2da iteracin.
Figura B.3: Resultado prueba de unidad clase Simulador, 2da iteracin.
Se realiz la prueba de valores lmites a los formularios de la interfaz de usuario,
para verificar la respuesta correcta del sistema ante los datos de entrada del
usuario.
Se aplico la prueba a los formularios de medidas de esfera, posicin y
velocidad inicial.
PRUEBAS A FORMULARIO MEDIDAS DE ESFERA.
El formulario tiene cuatro campos (cr, cm, cd y cv) y se detallan a continuacin:
CR: Campo de texto para configurar el radio de la esfera y esta habilitado a
escritura, este campo acepta valores numricos de tipo real positivo. En caso de
no cumplir se muestra un aviso de error.
CM: Campo de texto para configurar la masa de la esfera y esta habilitado a
escritura, este campo acepta valores numricos de tipo real positivo. En caso de
no cumplir se muestra un aviso de error.
CD: Campo de texto que muestra el valor calculado de la densidad de la esfera a
partir de los datos de radio y masa. Este campo esta deshabilitado a la escritura
puesto que el calculo es automtico.
205
CV: Campo de texto que muestra el valor calculado del volumen de la esfera a
partir del valor del radio. Este campo esta deshabilitado a la escritura puesto que
el calculo es automtico.
Se aplicaron los 3 casos de prueba (CP1, CP2 y CP3), los mismos y sus
resultados se muestran a continuacin.
Resultados aplicacin caso de prueba 1.
Campos Tipo aceptado Valor de prueba Resultado
obtenido
Resultado
esperado
CR
Nmero real
positivo.
1.250 1.250 1.250
CM 15.00 15.00 15.00
CD - 1.83346494 1.83346494
CV - 8.18123087 8.18123087
Campos Tipo Aceptado Valor de
Prueba
Resultado
Obtenido
Resultado
Esperado
Observaciones
CR
Nmero real
positivo
-2.5 2.5 2.5
Autocorreccin
CM -100 100 100
CD - 1.52788745 1.52788745 -
CV - 65.4498469 65.4498469 -
206
Campos Tipo
aceptado
Valor de
prueba
Resultado
Obtenido
Resultado
Esperado
Observaciones
CR
Nmero real
positivo
3jkal ERROR ERROR Mostrar
mensaje de
error para su
correccin.
CM
345erCF ERROR ERROR
PRUEBAS A FORMULARIO POSICIN INICIAL.
El formulario para la configuracin de la posicin inicial tiene dos campos te texto:
CH: Campo de texto que recibe nmero reales positivos, donde se configura la
posicin inicial de la esfera en el eje x (horizontal) del eje de coordenadas
cartesianas.
CV: Campo de texto que recibe nmero reales positivos, donde se configura la
posicin inicial de la esfera en el eje y (vertical) del eje de coordenadas
cartesianas.
resultados se muestran a continuacin.
207
Campos Tipo
aceptado
Valor de
prueba
Resultado
Obtenido
Resultado
Esperado
Observaciones
CH Nmero real
positivo
5.8 5.8 5.8 -
CV 10.5 10.5 10.5 -
Campos
Tipo
aceptado
Valor de
prueba
Resultado
Obtenido
Resultado
Esperado
Observaciones
CH
Nmero real
positivo
-5.8 5.8 5.8
Auto Correccin
CV -10.5 10.5 10.5
Campos
Tipo
aceptado
Valor de
prueba
Resultado
Obtenido
Resultado
Esperado
Observaciones
CH
Nmero
real positivo
48.3 5.8 5.8 -
CV Letra34 ERROR ERROR Mensaje de Error
208
PRUEBAS A FORMULARIO VELOCIDAD INICIAL.
El formulario para la configuracin de la velocidad inicial tiene dos campos te
texto:
CMO: Campo de texto que recibe nmero reales, con los que se configura el
mdulo de la velocidad inicial.
CAN: Campo de texto que recibe nmero reales para configurar el sentido del
vector velocidad inicial, es decir el grado de inclinacin en el sistema radial.
Se aplicaron dos casos de prueba (CP7 y CP8), los mismos y sus resultados se
muestran a continuacin:
Campos Tipo aceptado Valor de
prueba
Resultado
Obtenido
Resultado
Esperado
Observaciones
CMO Nmero real positivo 10.5 10.5 10.5 -
CAN Nmero real -0.7 -0.7 -0.7 -
Campos Tipo aceptado Valor de
prueba
Resultado
Obtenido
Resultado
Esperado
Observaciones
CMO Nmero real positivo -10.5 10.5 10.5 Auto correccin
CAN Nmero real Letra34 ERROR ERROR Mensaje de
error
209
ANEXO C
ANEXO C. PRUEBAS REALIZADAS A LA TERCERA ITERACIN.
PRUEBAS DE UNIDAD.
La figura C.1 muestra el resultado de la prueba de unidad aplicada a la clase
Ambiente, en la tercera iteracin.
210
Figura C.1: Resultado prueba unidad clase Ambiente, 3ra iteracin.
Tablas, en la tercera iteracin.
Flecha, en la tercera iteracin.
211
Figura C.2: Resultado prueba de unidad clase Tablas, 3ra iteracin.
Figura C.3: Resultado prueba de unidad clase Flecha, 3ra iteracin.
Vector, en la tercera iteracin.
Control, en la tercera iteracin.
212
Figura C.4: Resultado prueba de unidad clase Vector, 3ra iteracin.
Figura C.5: Resultado prueba de unidad clase Control, 3ra iteracin.
La prueba se realiz al algoritmo de clculo de aceleracin bajo la influencia de
fuerzas externas y medio ambiente (Clase Cuerpo), debido a que presenta mayor
complejidad y es imprescindible para el funcionamiento del sistema.
La figura C.6 presenta la grfica de flujo para el clculo de la aceleracin en un
ambiente distinto del vaco.
Se puede evidencia que existen siete nodos, tres nodos predicado (1, 2 y 4), tres
regiones (R1, R2 y R3) y nueve aristas, por lo tanto se procede al calculo de la
complejidad ciclomtica.
213
Figura C.6: Grfica de flujo del algoritmo
para el clculo de la aceleracin en un
ambiente distinto del vaco.
La complejidad ciclomtica es 4, por lo tanto las rutas independientes son:
ruta 1: n1 n7.
ruta 2: n1 n2 n4 n5 - n7.
ruta 3: n1 n2 n3 n4 n5 n7.
ruta 4: n1 n2 n3 n4 n6 n7.
A partir de las rutas independientes halladas se pudo probar la correcta
funcionalidad del software.
Se realiz la prueba de valores lmites a los formularios de la interfaz de usuario,
para verificar la respuesta correcta del sistema ante los datos de entrada del
usuario.
Se aplic la prueba al formulario medio ambiente, en el formulario se pueden
observar cinco campos (CG, CD, CR, CAn y CAl) y se detallan a continuacin:
CG: Campo de texto para configurar la gravedad que influye en el medio, esta
habilitado a escritura, este campo acepta nmeros reales mayores a cero. En caso
de no cumplir se muestra un aviso de error.
CD: Campo de texto para configurar la densidad del fluido del ambiente, esta
habilitado a escritura, este campo acepta nmeros reales mayores o iguales a
cero. En caso de no cumplir se muestra un aviso de error.
214
CR: Campo de texto para configurar el rozamiento del suelo, esta habilitado a
escritura, este campo acepta nmeros reales mayores o iguales a cero. En caso
de no cumplir se muestra un aviso de error.
CAn: Campo de texto para configurar el ancho del ambiente, esta habilitado a
escritura, este campo acepta nmeros reales mayores a cero. En caso de no
cumplir se muestra un aviso de error.
CAl: Campo de texto para configurar el alto del ambiente, esta habilitado a
escritura, este campo acepta nmeros reales mayores a cero. En caso de no
cumplir se muestra un aviso de error.
resultados se muestran a continuacin:
Resultados aplicacin caso de prueba 9 .
Campos
Tipo
Aceptado
Valor de
prueba
Resultado
obtenido
Resultado
Esperado
Observaciones
CG
Nmero real
positivo
-5 5 5
Autocorreccin
CD -0,2 0,2 0,2
CR -3 3 3
CAn Nmero real
positivo
distinto de 0
-5 5 5
CAl -7 7 7
215
Campos Tipo Aceptado
Valor de
prueba
Resultado
obtenido
Resultado
Esperado
Observaciones
CG
Nmero real
positivo
0 0 0
- CD 0 0 0
CR 0 0 0
CAn
Nmero real
positivo distinto de
0
0 2 2
Autocorreccin
CAl 0 1 1
Campos Tipo Aceptado Valor de
prueba
Resultado
obtenido
Resultado
Esperado
Observaciones
CG
Nmero real
positivo
3jkal Error Error
Mensaje
de
Error
CD 3jkal Error Error
CR 3jkal Error Error
CAn Nmero real
positivo distinto de
0
3jkal Error Error
CAl 3jkal Error Error
216
ANEXO D
ANEXO D. PRUEBAS REALIZADAS A LA CUARTA ITERACIN.
PRUEBAS DE UNIDAD.
La figura D.1 muestra el resultado de la prueba de unidad aplicada a la clase
Ambiente, en la cuarta iteracin.
217
Figura D.1: Resultado prueba de unidad clase Ambiente, 4ta iteracin.
La figura D.2 muestra el resultado de la prueba de unidad aplicada a la clase
Tablas, en la cuarta iteracin.
En la cuarta iteracin no se implemento ningn nuevo algoritmo que sea relevante
para el funcionamiento del software, es por esto que no se realizaron las pruebas
de caja blanca.
Para esta iteracin se evaluaron todos los formularios del software, por lo tanto no
se llev a cabo las pruebas de valores lmites.
218
Figura D.2: Resultado prueba de unidad clase Tablas, 4ta iteracin.
ANEXO E
ANEXO E. MANUAL DE USUARIO.
El presente manual pretende mostrar al usuario el funcionamiento de la software
LAVIFIS (Laboratorio virtual de fsica), para simular experimentos que se llevan a
cabo en el estudio de la cinemtica newtoniana.
ACERCA DE LAVIFIS.
Laboratorio virtual de Fsica (LAVIFIS), es un software educativo que simula el
movimiento de partculas basado y limitado en la teora de cinemtica newtoniana.
Ofrece un entorno virtual de experimentacin que aplica la lnea filosfica del
materialismo dialctico y est basado en el paradigma de aprendizaje por
descubrimiento, permitiendo al estudiante lograr un aprendizaje significativo y
desarrollador.
Se sugiere hacer uso de LAVIFIS bajo la tutela de un profesional de Fsica para
lograr experiencias mas enriquecedoras para la educacin.
El presente manual tcnico responde a la versin 1.0.0 lanzado el 20 de
noviembre de 2010.
219
INSTALACIN.
Para instalar LAVIFIS, su sistema requiere tener la JVM 1.6 (Maquina virtual de
java) o superior en su equipo, adems de un lector de archivos PDF.
LAVIFIS es un software multiplataforma, por lo tanto la instalacin se realiza de
forma similar en cualquier sistema operativo. El software est contenido en el
archivo lavifis1.0.0.zip.
Los pasos para la instalacin son los siguientes:
Crear una carpeta con el nombre lavifis en cualquier directorio.
Copiar el archivo lavifis1.0.0.zip en la carpeta creada lavifis.
Descomprimir el contenido de lavifis1.0.0 dentro de la carpeta lavifis.
De forma opcional se puede eliminar el archivo lavifis1.0.0.zip de la carpeta
lavifis.
Si se siguen los pasos de forma correcta, se debe obtener dentro de la carpeta
lavifis el contenido que se muestra a continuacin.
220
EJECUTAR.
EN SISTEMAS UNIX/LINUX.
En la carpeta lavifis existe un archivo llamado lavifis.sh que es un script que
ejecuta lavifis. Se deben seguir los siguientes pasos:
- Desde consola.
1. Ingresar a la carpeta lavifis.
2. Ejecutar el siguiente comando.
- Modo grfico.
2. Doble click sobre el archivo lavifis.sh.
221
3. Seleccionar ejecutar.
SISTEMAS WINDOWS.
De forma similar a los sistema UNIX, los pasos son los siguientes:
2. Doble click sobre el archivo lavifis.jar.
OTROS SISTEMAS.
Cuando no se cuenta con windows ni sistemas unix, se debe ejecutar
directamente desde una lnea de comandos pasando como referencia a
LAVIFIS.jar a la mquina virtual de java, los pasos a seguir son los siguientes:
1. Abrir una terminal, consola o lnea de comandos del sistema.
2. Desde la lnea de comandos ingresar a la carpeta lavifis.
3. Ejecutar el siguiente comando:
java -jar LAVIFIS.jar
222
CONFIGURAR AMBIENTE.
Para lograr experimentar en distintos tipos de ambiente y contextualizar los
experimentos a una determinada realidad ambiental, LAVIFIS ofrece una interfaz
sencilla para manipular las variables mas importantes que afectan al movimiento
de un cuerpo. A continuacin se muestra el formulario para la configuracin del
medio ambiente.
Gravedad.
Este campo es donde se debe de ingresar el mdulo de la aceleracin debido a la
gravedad en el sistema internacional de unidades.
Densidad del aire.
Este campo es donde se configura la densidad del aire en el ambiente, en la barra
men --> Tablas --> Densidad aire, se pueden apreciar distintos valores en
diversas condiciones, la siguiente figura muestra la tabla de densidades del aire.
223
Coeficiente de Rozamiento.
La configuracin de la constante de rozamiento del suelo que puede ser cero o
menor igual a uno (0 <= r <= 1).
Ancho.
En este campo se puede configurar el rango de visualizacin horizontal del
ambiente de simulacin. El valor es un nmero real positivo y en metros.
Alto.
En este campo se puede configurar el rango de visualizacin vertical del ambiente
de simulacin. El valor es un nmero real positivo y en metros.
224
CONFIGURAR PARTCULA.
La configuracin de los datos se realiza mediante el formulario Medidas de Esfera
que se muestra en la siguiente figura.
LAVIFIS ofrece una tabla comparativa de densidades de algunas sustancias en la
barra men --> Tablas --> Densidades Sustancias que se puede apreciar en la
figura e.12.
225
CAMPOS DE CONFIGURACIN DE MEDIDAS DE LA PARTCULA.
Radio.
En este campo se puede configurar la dimensin del radio de la esfera, el valor
puede ser un nmero real positivo y en metros.
Masa.
En este campo se puede configurar la masa de la esfera, el valor puede ser un
nmero real positivo y en metros.
Densidad.
A partir de los datos de radio y masa, LAVIFIS calcula la densidad de la esfera
para el experimento.
Volumen.
A partir de los datos de radio y masa, LAVIFIS calcula el volumen de la esfera
para el experimento.
CONFIGURACIN DEL MOVIMIENTO.
Los datos iniciales para el movimiento se configuran por medio de tres formularios;
Posicin Inicial, Velocidad inicial y Aceleracin Inicial. En la siguiente figura se
muestra los tres formularios para la configuracin de datos iniciales para la
simulacin.
226
CAMPOS DE CONFIGURACIN PARA LOS DATOS INICIALES.
Posicin inicial horizontal.
En este campo se logra establecer el punto en la coordenada X en el cual se
encontrar la esfera antes de iniciar la simulacin.
Posicin inicial horizontal.
En este campo se logra establecer el punto en la coordenada Y en el cual se
encontrar la esfera antes de iniciar la simulacin.
Velocidad inicial mdulo.
Indica al experimento cual ser el mdulo de la velocidad inicial para la esfera.
ngulo de velocidad inicial.
En este campo se configura el ngulo inicial, tambin conocido como ngulo de
tiro. El sistema utilizado es en grados Radianes, para permitir mayor precisin al
usuario.
227
Aceleracin inicial en X.
En este campo se configura la aceleracin inicial del sistema en el eje horizontal.
Aceleracin inicial en Y.
En este campo se configura la aceleracin inicial del sistema en el eje vertical.
CONTROLES DE SIMULACIN.
Los controles del experimento son opciones que permiten al usuario administrar y
controlar la experimentacin en cada momento (variaciones de tiempo).
AJUSTAR DATOS DE EXPERIMENTACIN.
El botn ajustar permite que el entorno virtual se ajuste a todos los datos iniciales,
de ambiente y de cuerpo. Es de suma importancia presionar este botn antes de
iniciar un experimento.
INICIAR, DETENER Y CONTINUAR EXPERIMENTACIN.
El botn simular / pausar permite iniciar el tiempo y la experimentacin, adems
detener y continuar en cualquier momento con el fin de analizar el fenmeno
estudiado.
228
REINICIAR EXPERIMENTACIN.
El botn reiniciar permite restablecer la simulacin al estado inicial configurado
por el usuario.
VELOCIDAD DE SIMULACIN.
El usuario puede controlar la velocidad en la que transcurre el tiempo, por defecto
la velocidad esta ajustada a un tiempo real, pero este puede ser modificado en
cualquier momento para poder apreciar con mayor detalle el experimento en
curso. El control de velocidad del tiempo se lo realiza a travs de un barra
deslizante que se muestra a continuacin.
OPCIONES DE VISUALIZACIN.
LAVIFIS ofrece la posibilidad al usuario de visualizar magnitudes escalares y
vectoriales de forma grfica, adems de proporcionar una visin del permetro de
observacin de la esfera.
229
VISOR DE DATOS DE SIMULACIN.
Los datos generados durante, antes y al finalizar la simulacin del experimento
son tabuladas y presentadas al usuario en tablas.
DETALLE DE LAS TABLAS DE INFORMACIN.
Es importante la correcta interpretacin de la informacin en cualquier proceso de
experimentacin, a continuacin se detalla cada tabla.
Tabla: Situacin actual.
La tabla situacin actual cuenta con tres columnas: variable, vaco y ambiente. En
estas columnas se almacenan los valores actuales en cada variacin de tiempo.
Tabla: Datos posicin.
La tabla datos posicin cuenta con cinco columnas, las cuales se detallan a
continuacin.
t[s], variacin del tiempo en segundos.
x(v), posicin horizontal de la esfera en el vaco.
y(v), posicin vertical de la esfera en el vaco.
x(a), posicin horizontal de la esfera en ambiente.
y(a), posicin vertical de la esfera en ambiente.
230
Tabla: Velocidad en vaco.
La tabla velocidad en vaco cuenta con cinco columnas, las cuales se detallan a
continuacin.
V, mdulo de la velocidad en un tiempo t.
Vx, componente horizontal de la velocidad en un tiempo t.
Vy, componente vertical de la velocidad en un tiempo t
Ang, ngulo de la velocidad actual en radianes.
Tabla: Velocidad en ambiente.
La tabla velocidad en ambiente cuenta con cinco columnas, las cuales se detallan
a continuacin.
V, mdulo de la velocidad en un tiempo t.
Vx, componente horizontal de la velocidad en un tiempo t.
Vy, componente vertical de la velocidad en un tiempo t.
Ang, ngulo de la velocidad actual en radianes.
Tabla: Aceleracin en vaco.
La tabla aceleracin en vaco cuenta con cuatro columnas, las cuales se detallan a
continuacin.
A, mdulo de la aceleracin en un tiempo t.
Ax, componente horizontal de la aceleracin en un tiempo t.
Ay, componente vertical de la aceleracin en un tiempo t
231
Tabla: Aceleracin en ambiente.
La tabla aceleracin en vaco cuenta con cuatro columnas, las cuales se detallan a
continuacin.
A, mdulo de la aceleracin en un tiempo t.
Ax, componente horizontal de la aceleracin en un tiempo t.
Ay, componente vertical de la aceleracin en un tiempo t
Tabla: Rozamiento.
La tabla rozamiento cuenta con cinco columnas, las cuales se detallan a
continuacin.
R, mdulo del rozamiento en un tiempo t.
Rx, componente horizontal del rozamiento en un tiempo t.
Ry, componente vertical del rozamiento en un tiempo t.
Rp, rozamiento con el piso.
GENERAR INFORMES EN PDF.
LAVIFIS ofrece la posibilidad de generar informes con los datos de la simulacin
de forma automtica. Los documentos se generan en formato pdf y son siete. Para
generar informes de forma correcta es necesario seguir los siguientes pasos:
- El experimento no debe estar ejecutndose, es decir, debe estar en pausa o sin
iniciar.
232
- Presionar el botn Crear Informes PDF.
- Seleccionar o crear una nueva carpeta y presionar abrir.
- Esperar el mensaje de confirmacin de la creacin de los informes.
- Verificar que se hayan generado siete documentos pdf en el directorio
seleccionado.
233
ACCEDER A SISTEMA DE CONOCIMIENTOS.
El sistema de conocimientos son mini-tutoriales que permiten al usuario revisar el
fundamento terico de los experimentos.
Para acceder a ellos se debe ir a la barra men --> conocimientos, luego
seleccionar el tpico requerido.
AYUDA DE LAVIFIS.
Se puede acceder cualquier momento a este manual de usuario, informacin
acerca del software LAVIFIS y datos sobre el autor. Para hacerlo se debe ingresar
a la barra men --> Ayuda y seleccionar el requerimiento.
234
ANEXO F
ANEXO F. MANUAL TCNICO.
El presente manual tiene como objetivo explicar el funcionamiento de LAVIFIS.
LAVIFIS (Laboratorio Virtual de Fsica), es un software que proporciona un
ambiente virtual para la experimentacin de fenmenos fsicos de cinemtica
newtoniana, usando como elemento mnimo a la partcula.
El objetivo general de LAVIFIS es ser una herramienta didctica para apoyar el
proceso de enseanza - aprendizaje de cinemtica newtoniana en estudiantes
universitarios de Fsica.
DATOS TCNICOS DE LAVIFIS.
La siguiente tabla resume los datos tcnicos del software.
LAVIFIS Versin 1.0.0. - 20/11/2010
Desarrollador Luis Roberto Prez Rios.
luis.robertop87@gmail.com
Tipo de software Software educativo basado en
simulacin.
Se basa en paradigma de enseanza
por descubrimiento.
Lenguaje de programacin utilizado. JAVA
Metodologa de desarrollo del software. Programacin extrema (XP)
235
PARADIGMA DE PROGRAMACIN.
El modelamiento, desarrollo e implementacin se hizo bajo el paradigma de
programacin orientado a objetos, debido a que permite mayor flexibilidad y
representacin de abstracciones de la realidad.
La lgica y filosofa de la orientacin a objetos es coherente con los pasos de la
metodologa de simulacin de sistemas discretos (utilizada en el modelamiento de
los fenmenos cinemticos), adems responde adecuadamente a la metodologa
de desarrollo de software XP.
LENGUAJE DE PROGRAMACIN.
El lenguaje utilizado para la codificacin y desarrollo de software fue JAVA, por los
motivos explicados en el captulo 7 apartado 7.1, y que se resumen en las
siguientes caractersticas: orientado a objetos, distribuido, interpretado, robusto,
seguro, independiente de hardware, portable, dinmico, multitarea y flexible.
INSTALACIN AVANZADA PARA SISTEMAS UNIX/LINUX
Se deben de seguir los mismos pasos mencionados en el manual de usuario, con
la diferencia de que el ejecutable se agregar a la lista de programas del sistema
Unix, a continuacin los pasos:
- Descomprimir el archivo lavifis1.0.0.zip en un directorio que tenga permisos de
escritura.
- Ingresar a la carpeta donde se descomprimio.
- Dar permisos de ejecucin al archivo lavifis.sh
- Agregar lavifis.sh al sistema local de usuario.
236
La figura siguiente resume el procedimiento mencionado anteriormente.
El detalle de la implementacin del software se puede apreciar en el captulo 8
apartado 8.2.
DETALLE DE PORTABILIDAD DE LAVIFIS.
La siguiente tabla resumen los resultados de la ejecucin de LAVIFIS en diversos
sistemas operativos.
Sistema
Operativo
Versin
Arquitectura
(bits)
Calificacin de
funcionamiento
Observaciones
Windows
XP
Profesional
32 Buena
Menos de 0.0001
segundos en relacin
a un cronmetro real.
Vista Home
Premium
32 / 64 Excelente -
Linux
Ubuntu
10.04
32 / 64 Excelente -
Mac Leopard 32 Excelente -
237

Tes Is Roberto

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tes Is Roberto

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD MAYOR DE SAN SIMN

FACULTAD DE CIENCIAS Y TECNOLOGA

V: Mdulodel vector velocidad.

j : Vector unitario eneje Y.

j : Vector unitario eneje Y.

F se obtiene de la sumatoria de todos

You might also like