Leeer

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN Desarrollo de un Sistema de Cont

Views 49 Downloads 6 File size 5MB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN

Desarrollo de un Sistema de Control y Digitalización de Pruebas Psicotécnicas para GNEX Gabinete Psicotécnico ADÁN ESCOBAR LAGOS

Profesor Guía: MATT BARDEEN

Memoria para optar al título de Ingeniero Civil en Computación Curicó – Chile Marzo, 2013

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN

Desarrollo de un Sistema de Control y Digitalización de Pruebas Psicotécnicas para GNEX Gabinete Psicotécnico ADÁN ESCOBAR LAGOS

Profesor Guía: MATT BARDEEN Profesor Informante: CÉSAR ASTUDILLO Profesor Informante: RODOLFO ALLENDE Memoria para optar al título de Ingeniero Civil en Computación Curicó – Chile Marzo, 2013

1

i

AGRADECIMIENTOS

El presente trabajo representa la culminación de una gran meta que me propuse y que de no ser por personas muy importantes en mi vida que son mi mujer, mi hijo y mis padres, tal vez no lo hubiera logrado. Y este triunfo se los dedico a ellos que han sido pilares fundamentales en mi vida. Agradezco: A quiénes se han convertido en lo más importante en mi vida, mi mujer, Natalia Silva con su fuerza incasable y ese apoyo incondicional que me ha brindado siempre que lo he requerido, eres todo lo que un hombre puede esperar de una excelente mujer, a mi amado hijo, que con una simple sonrisa me devuelve la fuerza que creí había perdido, eres lejos lo más maravilloso que la vida me ha dado. Ustedes son el motor de todo lo que quiero de todo lo que sueño. A mi padre Adán Escobar por ser un gran hombre y por ser un gran padre, que con su constante esfuerzo, su sacrificio, su ejemplo me motivó y me motiva a ser cada día más y mejor. A mi madre por los valores entregados y por el invitarme constantemente a soñar y a trabajar con mucho empeño para lograr todos mis sueños y por enseñarme que nada es imposible si hay dedicación. A mis amigos Mauricio, Ever, Rodrigo, Cristián y Eduardo y otros tantos que me apoyaron en momentos complicados, sobre todo cuando no podía ir a la universidad por temas de trabajo, me ayudaron mucho y se los agradezco. Gracias a Dios por darme la vida que me has dado y todas las bendiciones que has puesto en ella.

ii

TABLA DE CONTENIDOS página

Dedicatoria

i

Agradecimientos

ii

Tabla de contenidos

iii

Índice de figuras

vii

Índice de tablas

x

Resumen

xi

Abstract

xii

1. Introducción 1.1. Descripción del Contexto . . . . . . . 1.2. Descripción del Problema . . . . . . 1.3. Objetivos . . . . . . . . . . . . . . . 1.3.1. Objetivo general . . . . . . . 1.3.2. Objetivos específicos . . . . . 1.4. Alcance y Limitaciones del Proyecto . 1.5. Resumen . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2. Marco Teórico 2.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Psicología Aplicada a los Transportes. . . . . . . . . . . . . . . . 2.3. Referencia Histórica de las Pruebas Psicotécnicas. . . . . . . . . 2.4. Algunos de los Primeros Instrumentos Psicométricos. . . . . . . 2.4.1. Silbato de Galton. . . . . . . . . . . . . . . . . . . . . . 2.4.2. Acúmetro. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3. Cuadriperceptímetro Mallard. . . . . . . . . . . . . . . . 2.4.4. Cronoscopio de D’Arsonval. . . . . . . . . . . . . . . . . 2.4.5. Taquistoscopio de Proyección con Obturador Automático iii

. . . . . . .

. . . . . . . . .

. . . . . . .

. . . . . . . . .

. . . . . . .

1 1 3 3 4 4 4 5

. . . . . . . . .

6 6 6 7 8 8 9 9 10 10

iv

2.5.

2.6. 2.7.

2.8.

2.9.

2.4.6. Perceptor de Profundidad . . . . . . . . . . . . . . . . . Pruebas Psicosométricas Actuales. . . . . . . . . . . . . . . . . . 2.5.1. Pruebas de Coordinación Bimanual. . . . . . . . . . . . . 2.5.2. Pruebas de Reacción. . . . . . . . . . . . . . . . . . . . . 2.5.3. Prueba de Punteo Lahy. . . . . . . . . . . . . . . . . . . 2.5.4. Pruebas de Visión. . . . . . . . . . . . . . . . . . . . . . 2.5.5. Prueba de Audio. . . . . . . . . . . . . . . . . . . . . . . Otros Métodos de Detección de Conductores de Alto Riesgo. . . 2.6.1. NADS . . . . . . . . . . . . . . . . . . . . . . . . . . . . La Evaluación Psicosométrica en Nuestro País. . . . . . . . . . . 2.7.1. Entidades Autorizadas para Expedir Licencias. . . . . . . 2.7.2. Comparativa con Gabinetes de Similares Características. 2.7.3. Exámenes e Instrumentación. . . . . . . . . . . . . . . . Conceptos Relacionados con la Implementación. . . . . . . . . . 2.8.1. Digitalización de Pruebas Psicotécnicas. . . . . . . . . . 2.8.2. Manejo de Pruebas Mediante Drivers. . . . . . . . . . . . 2.8.3. Interoperabilidad COM. . . . . . . . . . . . . . . . . . . 2.8.4. Acerca de MCI (Windows). . . . . . . . . . . . . . . . . 2.8.5. Acerca de las Herramientas de GDI+. . . . . . . . . . . . Resumen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. Metodología 3.1. Introducción. . . . . . . . . . . . . . . . . . . . . . 3.2. Desarrollo Guiado por Funcionalidades (FDD). . . . 3.2.1. Desarrollo de un Modelo Global. . . . . . . . 3.2.2. Equipo de Desarrollo. . . . . . . . . . . . . . 3.2.3. Elaboración de la Lista de Funcionalidades. 3.2.4. Planeación por Funcionalidad. . . . . . . . . 3.2.5. Diseño por Funcionalidad. . . . . . . . . . . 3.2.6. Desarrollo por Funcionalidad. . . . . . . . . 3.3. Metodología del Proyecto. . . . . . . . . . . . . . . 3.3.1. Desarrollo de un Modelo Global. . . . . . . . 3.3.2. Elaborar Lista de Funcionalidades. . . . . . 3.3.3. Planeación por Funcionalidad. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

11 11 11 13 15 15 20 21 21 24 24 24 25 27 27 28 28 29 29 31

. . . . . . . . . . . .

32 32 33 33 34 34 34 35 35 35 35 36 36

v

3.3.4. Diseño por Funcionalidad. . . . . . 3.3.5. Desarrollo por Funcionalidad. . . . 3.4. Herramientas Generales. . . . . . . . . . . 3.4.1. Lenguaje de Programación CSharp. 3.4.2. Visual Studio 2005. . . . . . . . . . 3.4.3. Subversión. . . . . . . . . . . . . . 3.5. Resumen. . . . . . . . . . . . . . . . . . . 4. Requisitos, Diseño y Planificación. 4.1. Introducción. . . . . . . . . . . . . . . . 4.2. Descripción del Contexto de Desarrollo. . 4.3. Requerimientos Valorados por el Usuario. 4.4. Diseño de Arquitectura. . . . . . . . . . 4.5. Identificación de Funcionalidades. . . . . 4.6. Modelo General de Clases. . . . . . . . . 4.7. Planificación por Funcionalidades. . . . . 4.7.1. Iteración I. . . . . . . . . . . . . 4.7.2. Iteración II. . . . . . . . . . . . . 4.7.3. Iteración III. . . . . . . . . . . . . 4.7.4. Iteración IV. . . . . . . . . . . . . 4.7.5. Iteración V. . . . . . . . . . . . . 4.7.6. Iteración VII. . . . . . . . . . . . 4.7.7. Iteración VIII. . . . . . . . . . . . 4.7.8. Iteración IX. . . . . . . . . . . . . 4.7.9. Iteración X. . . . . . . . . . . . . 4.7.10. Iteración XI. . . . . . . . . . . . . 4.7.11. Iteración XII. . . . . . . . . . . . 4.7.12. Iteración XIII. . . . . . . . . . . . 4.7.13. Iteración XIII. . . . . . . . . . . . 4.8. Resumen. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

37 37 37 38 38 38 39

. . . . . . . . . . . . . . . . . . . . .

40 40 40 42 44 45 48 50 50 51 51 52 53 54 54 55 56 57 57 58 58 59

5. Implementación. 60 5.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2. Interfaz de Usuario Aplicación Principal. . . . . . . . . . . . . . . . . 60

vi

5.3. Digitalización de la prueba de punteo Lahy. . . . . . . . . . . 5.3.1. Diseño e Implementación del Disco. . . . . . . . . . . . 5.3.2. Diseño e Implementación de los Orificios. . . . . . . . . 5.3.3. Implementación del Giro del Disco. . . . . . . . . . . . 5.3.4. Detección de Colisiones. . . . . . . . . . . . . . . . . . 5.3.5. Interfaz de Evaluación. . . . . . . . . . . . . . . . . . . 5.4. Prueba de Visión. . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1. Construcción Driver de Control para el Visor DVS-GT. 5.4.2. Interfaz de Usuario. . . . . . . . . . . . . . . . . . . . . 5.5. Digitalización Prueba de Palanca Lahy. . . . . . . . . . . . . . 5.5.1. Diseño e Implementación del Recorrido. . . . . . . . . 5.5.2. Detección de Interacciones. . . . . . . . . . . . . . . . . 5.5.3. Interfaz de Evaluación. . . . . . . . . . . . . . . . . . . 5.6. Prueba de Reacción. . . . . . . . . . . . . . . . . . . . . . . . 5.6.1. Interfaz de Evaluación. . . . . . . . . . . . . . . . . . . 5.7. Prueba de Audio. . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1. Interfaz de Evaluación. . . . . . . . . . . . . . . . . . . 5.8. Configuración de Pruebas. . . . . . . . . . . . . . . . . . . . . 5.9. Interfaz de Interoperabilidad. . . . . . . . . . . . . . . . . . . 5.10. Resumen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Conclusiones 6.1. Introducción. . . . . . . . . . . . 6.2. Conclusiones del Producto. . . . . 6.3. Conclusiones del Desarrollo. . . . 6.4. Conclusiones de la Investigación. 6.4.1. Limitaciones. . . . . . . . 6.4.2. Trabajo Futuro. . . . . . . Bibliografía

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . .

63 64 70 73 74 78 81 82 86 89 89 91 96 98 99 101 103 105 113 115

. . . . . .

116 116 116 116 117 118 118 119

ÍNDICE DE FIGURAS página 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9.

Silbato de Galton. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parte Frontal y Trasera del Cuadriperceptímetro. . . . . . . . . . . . Cronoscopio de D’Arsonval. . . . . . . . . . . . . . . . . . . . . . . . Taquitoscopio de Proyección con Obturador Automático. . . . . . . . Perceptor de Profundidad. . . . . . . . . . . . . . . . . . . . . . . . . Prueba de Coordinación Bimanual. . . . . . . . . . . . . . . . . . . . Prueba de Coordinación Bimanual Lahy. . . . . . . . . . . . . . . . . Prueba de Coordinación Bimanual Lafayette y Contador de Pulsos. . Prueba de Coordinación Bimanual Digital Lafayette y Joistick de Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10. Prueba de Reacción. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11. Prueba de Reacción y Contador de Pulsos. . . . . . . . . . . . . . . . 2.12. Prueba de Reacción Digital de Schunhfried y Joystick Controlador. . 2.13. Prueba de Punteo Lahy. . . . . . . . . . . . . . . . . . . . . . . . . . 2.14. Prueba de Visión DVS-GT. . . . . . . . . . . . . . . . . . . . . . . . 2.15. Prueba de Visión: Agudeza Visual. . . . . . . . . . . . . . . . . . . . 2.16. Prueba de Visión: Agudeza Ojo Izquierdo. . . . . . . . . . . . . . . . 2.17. Prueba de Visión: Agudeza Ojo Derecho. . . . . . . . . . . . . . . . . 2.18. Prueba de Visión: Agudeza Binocular. . . . . . . . . . . . . . . . . . 2.19. Prueba de Visión: Percepción del Color. . . . . . . . . . . . . . . . . 2.20. Prueba de Visión: Reconocimiento de Signos y Visión Estereoscópica. 2.21. Prueba de Visión: Phoria. . . . . . . . . . . . . . . . . . . . . . . . . 2.22. Prueba de visión: Recuperación al Encandilamiento. . . . . . . . . . . 2.23. Prueba de Visión: Control de Comandos. . . . . . . . . . . . . . . . . 2.24. Prueba de Visión Schuhfried VTS. . . . . . . . . . . . . . . . . . . . . 2.25. Prueba de Audio: Audiómetro. . . . . . . . . . . . . . . . . . . . . . . 2.26. MA 55 Audio-PC-System Audiometer de Maico. . . . . . . . . . . . . 2.27. NADS-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.28. Cúpula NADS-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.29. Sistema de Movimiento NADS-1. . . . . . . . . . . . . . . . . . . . . 2.30. Digitalización Prueba Punteo Lahy. . . . . . . . . . . . . . . . . . . . vii

9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 17 18 18 18 19 19 20 20 21 22 22 23 28

viii

2.31. Ejemplo de regiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.32. Intersección y unión de regiones. . . . . . . . . . . . . . . . . . . . . . 2.33. Xor y resta de regiones. . . . . . . . . . . . . . . . . . . . . . . . . .

30 31 31

3.1. Fases Metodología FDD. . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.1. Gabinete Psicotécnico GNEX. . . . . . . . . . . . . . . . . . . . . . . 4.2. Arquitectura del Proyecto. . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Clases gráficas Aplicación Principal. . . . . . . . . . . . . . . . . . . .

41 45 49

5.1. Pantalla Login. . . . . . . . . . . . . . . . 5.2. Pantalla Principal. . . . . . . . . . . . . . 5.3. Pantalla Impresión. . . . . . . . . . . . . . 5.4. Disco Prueba Punteo Lahy. . . . . . . . . 5.5. Parámetros Disco Lahy. . . . . . . . . . . 5.6. Paso I Dibujo Disco. . . . . . . . . . . . . 5.7. Paso II Dibujo Disco. . . . . . . . . . . . . 5.8. Paso III Dibujo Disco. . . . . . . . . . . . 5.9. Paso IV Dibujo Disco. . . . . . . . . . . . 5.10. Paso V Dibujo Disco. . . . . . . . . . . . . 5.11. Paso VI Dibujo Disco AA ≤ 90◦ . . . . . . 5.12. Paso VI Dibujo Disco 90◦ < AA ≤ 180◦ . . 5.13. Paso VI Dibujo Disco 180◦ < AA ≤ 270◦ . . 5.14. Paso VI Dibujo Disco AA > 270◦ . . . . . . 5.15. Paso VII Dibujo Disco AA ≤ 90◦ . . . . . . 5.16. Paso VII Dibujo Disco 90◦ < AA ≤ 180◦ . . 5.17. Paso VII Dibujo Disco 180◦ < AA ≤ 270◦ . 5.18. Paso VI Dibujo Disco AA >270◦ . . . . . . 5.19. Paso VIII Dibujo Disco. . . . . . . . . . . 5.20. Parámetros Orificios de Prueba Lahy. . . . 5.21. Paso I Dibujo Orificios. . . . . . . . . . . . 5.22. Paso II Dibujo Orificios. . . . . . . . . . . 5.23. Área Exterior del Disco. . . . . . . . . . . 5.24. Área Interna del Disco. . . . . . . . . . . . 5.25. Área de Abertura del Disco. . . . . . . . .

61 62 63 64 64 65 65 66 66 66 67 67 68 68 69 69 69 70 70 71 72 72 75 75 76

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

ix

5.26. Definiciones Detección de Colisiones. . . . . . . . . . . . . . . 5.27. Casos de no Colisión. . . . . . . . . . . . . . . . . . . . . . . . 5.28. Puntero Dentro del Radio de Abertura. . . . . . . . . . . . . . 5.29. Pantalla de Evaluación de la Prueba de Punteo. . . . . . . . . 5.30. Cuadro Resumen Prueba de Punteo. . . . . . . . . . . . . . . 5.31. Prueba de Punteo Digitalizada. . . . . . . . . . . . . . . . . . 5.32. Terminales Comunicación Control-Visor. . . . . . . . . . . . . 5.33. Diagrama Sniffer Control-Visor. . . . . . . . . . . . . . . . . . 5.34. Diagrama de Clases Controlador Visor. . . . . . . . . . . . . . 5.35. Interfaz Gráfica Prueba de Visión. . . . . . . . . . . . . . . . . 5.36. Cuadro de Resumen Prueba de Visión. . . . . . . . . . . . . . 5.37. Recorrido Prueba Palanca Lahy. . . . . . . . . . . . . . . . . . 5.38. Definición Recorrido Prueba de Palanca Lahy. . . . . . . . . . 5.39. Definición Ancho Recorrido Prueba de Palanca Lahy. . . . . . 5.40. Detección de Interacciones por Color Prueba de Palanca Lahy. 5.41. Rectas Restricción Recorrido Prueba de Palanca Lahy. . . . . 5.42. Rectas Restricción Recorrido Prueba de Palanca Lahy. . . . . 5.43. Pantalla de Evaluación de la Prueba de Palanca. . . . . . . . 5.44. Pantalla de Resultado de la Prueba de Palanca. . . . . . . . . 5.45. Prueba de Palanca Digitalizada. . . . . . . . . . . . . . . . . 5.46. Estados Semáforo Prueba de Reacción. . . . . . . . . . . . . . 5.47. Pantalla de Evaluación de la Prueba de Palanca. . . . . . . . . 5.48. Pantalla de Resultado de la Prueba de Reacción. . . . . . . . . 5.49. Prueba de Reacción. . . . . . . . . . . . . . . . . . . . . . . . 5.50. Niveles Prueba de Audio. . . . . . . . . . . . . . . . . . . . . . 5.51. Botonera Prueba de Audio. . . . . . . . . . . . . . . . . . . . 5.52. Interfaz de Evaluación. . . . . . . . . . . . . . . . . . . . . . . 5.53. Pantalla resumen de la Prueba de Audio. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

76 77 78 79 80 81 82 83 86 88 89 89 90 91 92 94 95 96 97 97 98 99 100 100 101 102 103 104

ÍNDICE DE TABLAS página 2.1. 2.2. 2.3. 2.4.

Tabla Tabla Tabla Tabla

Comparativa de Gabinetes. . . . . . . . . Instrumentación Exámenes Visuales . . . Instrumentación Examen de Audiometría Instrumentación Examen de Psicométrico

. . . .

24 26 27 27

4.1. Tabla de Funcinalidades. . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.1. Tabla de Funcinalidades. . . . . . . . . . . . . . . . . . . . . . . . . .

84

x

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

RESUMEN

En nuestro país, como en cualquier parte del mundo el conducir un vehículo motorizado conlleva una enorme responsabilidad, por ello se hace indispensable demostrar que se está capacitado para dicho ejercicio. Para obtener un permiso de conducción se debe acreditar un adecuado estado moral, psíquico y físico, además de contar con los conocimientos teóricos y prácticos de conducción enmarcados dentro de las disposiciones legales y reglamentarias dispuestas por la legislación vigente. Dentro del contexto psíquico y físico los municipios realizan evaluaciones psicosensométricas con un equipo de evaluación que mide la concentración, la velocidad de reacción y el nivel de visión entre otras habilidades, este equipo se conoce como gabinete psicotécnico [1]. Este proyecto tiene como objetivo el desarrollo de un sistema de software para el control de un gabinete psicotécnico denominado Gnex, desarrollado por la empresa Exceed Ltda. Este software tiene como finalidad el control centralizado de las distintas pruebas que conforman el gabinete y la administración de datos emanados de cada evaluación, permitiendo entre otras cosas:

Evitar el falseo de resultado por parte de los evaluadores en perjuicio o beneficio de quien está siendo evaluado. La idea es que los resultados de las interacciones del evaluado con las pruebas sean leídas y registradas por el software y no dependan del juicio de quien está realizando la evaluación, mejorando de esta forma la veracidad de los resultados. Dar mayor confianza del resultado de los exámenes psíquicos a los evaluados; reemplazando las pruebas mecánicas por pruebas virtuales, las cuales permiten visualizar de forma gráfica e inequívoca los errores y/o aciertos cometidos. Tener un registro histórico de los resultados de las evaluaciones realizadas. Permitir el control de pruebas y la obtención de resultados desde otras aplicaciones, (comúnmente usadas para la gestión de licencias de conducir) mediante el uso de una interfaz de interoperabilidad.

xi

ABSTRACT

In our country as elsewhere in the world to drive a motor vehicle carries enormous responsibility, so it is essential to demonstrate to be qualified for that practice. To obtain a driving license you must demonstrate an adequate moral, mental and physical status, in addition you need to have a theoretical and practical knowledge of driving according to the laws and regulations set by the legislation. In the context of physical and psychological the municipalities made psychometric evaluations, with an equipement that measures the concentration, the reaction rate and the level of vision, among other skills, this equipement is known as psycho cabinet [1]. This project aims to develop a software system for controlling a psycho cabinet called GNEX, developed by Exceed Company Ltd. This software objetive is the centralized control of various tests that are part of cabinet and management data obtained from each test, allowing among other things: Avoid falsified results by evaluator in aid or benefit of who are being evaluated. The idea is that the interactions results of evaluated with tests are read and recorded by the software does not depend on the judgment of who is making the evaluation, thereby improving the accuracy of the results. Give greater confidence psychic test results for evaluated, replacing mechanical testing for virtual testing, allowing graphical display of mistakes and / or successes done. To have a historical record of evaluations results. Allow the control and obtaining of testing results from another applications (commonly used for managing drivers licenses) through an interoperability interface .

xii

1. 1.1.

Introducción Descripción del Contexto

La principal causa de accidentes de tránsito en el mundo se deben principalmente a fallas humanas, ello hace indispensable la detección exacta y oportuna de cualquier limitación, por la cual un conductor pueda ser un riesgo potencial de accidente [2]. Para lleva a cabo dicha tarea, se evalúa la capacidad sensométrica y psicomotriz del individuo, midiendo la coordinación de la audición y la visión con los miembros superiores e inferiores, esto permite detectar el nivel de coordinación entre lo que el individuo decide mentalmente hacer y la posibilidad real de efectuar las acciones en tiempo y forma, más aun, si este lo hace con la velocidad y precisión adecuadas [3]. Por ello es una tarea fundamental medir adecuadamente las capacidades psicométricas y sensométricas del individuo en la tarea de prevenir accidentes. Teniendo conciencia de lo anterior, es requisito para un conductor al obtener o renovar su licencia de conducir, ser sometido a una serie de pruebas que conforman lo que hoy se conoce como examen psicosensométrico. Las pruebas que incluye un examen psicosensométrico son las que se listan a continuación: Exámenes Físicos (Sensomotrices): Prueba de Visión: Mide la agudeza visual, la visión en profundidad, discriminación de colores, phoria vertical-horizontal, visión nocturna, recuperación al encandilamiento y perimetría. Prueba de Audio: Mide la capacidad de audición de un individuo mediante la exposición de los oídos a sonidos de distinta intensidad y frecuencia. 1

CAPÍTULO 1. INTRODUCCIÓN

2

Exámenes Psíquicos (Psicotécnicos): Prueba de Reacción: Mide el tiempo de reacción de un individuo frente a un evento. Generalmente se somete al individuo al cambio de la luz de un semáforo al cual debe reaccionar rápidamente. Prueba de Punteo Lahy: Esta prueba mide la concentración, coordinación viso motora, resistencia a la monotonía y tiempo de razonamiento positivo. Consta de un disco giratorio con una ranura la cual permite ver orificios bajo él, que deben ser tocados con un puntero sin tocar el disco que gira. Prueba de Palanca Lahy: Mide la coordinación, el control bimanual y la velocidad de razonamiento. La prueba consiste en completar un circuito que debe ser recorrido con un instrumento que tiene un puntero el cual debe ser llevado por medio de dos palancas en forma de tijera a través de un circuito en un tiempo definido y evitando el los posible salirse de él. Según lo estipula la ley vigente en nuestro país, dependiendo del uso final para el cual se desee, los tipos de licencias se clasifican en tres grupos: Profesionales: Clase A1, Clase A2, Clase A3, Clase A4, Clase A5. No profesionales: Clase B, Clase C. Especiales: Clase D, Clase E, Clase F. La definición y los requerimientos de evaluación y aprobación para las licencias previamente descritas, los dictan las leyes: DFL N◦ 1 (Ley de Tránsito). Decreto 170, de enero de 1986. Decreto 251, de 1999. Dependiendo del tipo de licencia que se desee obtener será el tipo de pruebas a las que deba someterse [4].

CAPÍTULO 1. INTRODUCCIÓN

1.2.

3

Descripción del Problema

En la actualidad las pruebas psicosensométricas en gran parte del país se hacen con rústicos instrumentos mecánicos, que están quedando obsoletos, ya que en muchos casos ni siquiera son electrónicos, los cuales no permiten llevar un catastro de exámenes realizados, más que los apuntes o fichas que usen quienes toman dichos exámenes. Hay otros casos en los que se cuenta con gabinetes más avanzados, que incorporan un software para el manejo de las pruebas psicotécnicas y el manejo de los datos del evaluado, sin embargo en la mayoría de estos existe la problemática de que las pruebas sensométricas (audio y visión) no son parte integral del software, sino que se operaran a través de sus propios mecanismos de control. Una problemática que se detectó en los municipios que tienen sistemas de gestión de conductores, es que les resulta tedioso estar manejando dos software o agregando manualmente la información de los resultados de las pruebas psicosensométricas a su sistema de control. Muchas veces los evaluados no quedan conformes y dudan de los resultados obtenidos. Dada la naturaleza de las pruebas no hay forma de mostrarles evidencia inequívoca de sus errores más que las lecturas hechas por el evaluador y/o el juicio que utilice este último. Otra debilidad detectada en los métodos de evaluación existentes es que no se puede parametrizar la dificultad con la que se realizan las pruebas, si bien es cierto, los instrumentos existentes cumplen con la normativa vigente, no permiten la parametrización de los aspectos de evaluación.

1.3.

Objetivos

Lo siguiente es la descripción de los objetivos a los que apunta el desarrollo del presente trabajo.

CAPÍTULO 1. INTRODUCCIÓN

1.3.1.

4

Objetivo general

Este proyecto tiene como propósito la creación de un gabinete psicotécnico moderno, que solucione los inconvenientes mencionados. Unificar en un solo software el manejo y recolección de datos de todas las pruebas. Brindar interoperabilidad a otros sistemas. Digitalizar las pruebas psicotécnicas. Brindar un método de parametrización de las pruebas. 1.3.2.

Objetivos específicos

La creación del nuevo gabinete contempla: Crear un software que maneje y administre unificadamente cada una de las pruebas mediante una interfaz sencilla y amigable. Software especializado (drivers) para el manejo de las pruebas de audio, reactímetro y visión. Inclusión de una base de datos para el registro histórico de los evaluadores, evaluados y los resultados obtenidos. Digitalización de las pruebas psicotécnicas. Creación de una interfaz de interoperación que mediante llamada a métodos y lanzamiento de eventos permita un control total de las diferentes pruebas y sus resultados.

1.4.

Alcance y Limitaciones del Proyecto

Este proyecto contempla el desarrollo de un sistema de control para un gabinete psicotécnico para la obtención de licencia de conducir, que incluye la paleta de pruebas que un individuo debe superar de acuerdo a la legislación chilena, el cual ha sido desarrollado por el departamento I+D de Exceed Ltda. y oportunamente

CAPÍTULO 1. INTRODUCCIÓN

5

homologado ante el Ministerio de Transportes y el Servicio Médico Legal. En cuanto a la digitalización de las pruebas psicotécnicas, esta es sólo la adecuación de las pruebas ya existentes a un formato digital, en ningún caso se pretende la creación de nuevas pruebas psicotécnicas, dado que esta tarea le compete plenamente al área de la psicología y escapa del alcance de este desarrollo. Los drivers para los dispositivos no serán parte del sistema operativo sino que estarán disponibles por medio de librerías dll, el acceso externo para el manejo de las pruebas solo será permitido mediante la interfaz de interoperabilidad. La interoperabilidad con otros sistemas solo estará disponible para aplicaciones desarrolladas en cualquier lenguaje compatible con tecnología COM.

1.5.

Resumen

En este capítulo se ha presentado tanto la problemática existente en el ámbito de la evaluación psicosensométrica como la solución propuesta, la cual es el tema central del presente trabajo. En el siguiente capítulo se abordaran los puntos bibliográficos más relevantes involucrados en la evaluación psicosensométrica partiendo por sus orígenes, siguiendo con una presentación algunas de las primeras pruebas psicotécnicas y su evolución a las pruebas actuales. También se hará una revisión de cómo se realiza en nuestro país la evaluación psicosensométrica y finalmente se hará una revisión de los aspectos técnicos referentes al desarrollo del proyecto.

2. 2.1.

Marco Teórico Introducción.

En este capítulo se presentan los factores que forman parte del tema en estudio, se hace un repaso por los hechos que han dado como consecuencia su evolución hasta nuestros días, así como también otros proyectos afines con la evaluación de las aptitudes físicas y síquicas de los conductores, luego se presenta el modelo de evaluación chilena y por último se hace una revisión de los conceptos involucrados en el desarrollo del proyecto.

2.2.

Psicología Aplicada a los Transportes.

A lo largo de la historia el psicoanálisis ha producido permanentes contribuciones teóricas que han ofrecido las bases para el desarrollo de una amplia variedad de técnicas de evaluación que han contribuido a enriquecer la escena psicodiagnóstica. El desarrollo del modelo psicoanalítico ha permitido tener una visión íntegra del comportamiento funcional y disfuncional de los sujetos [9]. A partir del siglo XIX en Europa, gracias a los aportes hechos por quien es considerado padre de la psicología científica, Wilhelm Wundt (1838-1920), se funda el laboratorio de psicología experimental en Leipzig (Alemania 1879), desde entonces empiezan a proliferar los centros de orientación y selección profesional, sobresaliendo por sus experiencias e investigaciones los centros de París, Bruselas, Ginebra y España [6]. Durante la I y II guerra mundial, el desarrollo de políticas de seguridad, medidas y técnicas preventivas, produjo que el desarrollo de la psicología recibiera un impulso, y desde entonces se encuentra íntimamente asociada con los desarrollos de las grandes agencias del transporte y la industria automovilística. Este impulso produce el desarrollo de una 6

CAPÍTULO 2. MARCO TEÓRICO

7

psicología social que incluía teorías de la comunicación y de persuasión, además de una psicofisiología apoyada en el desarrollo de instrumentación electrónica. La expansión del transporte en Europa y la continua demanda de selección de empleados calificados, para las compañías de transporte, potenció un importante desarrollo sobre el conocimiento de la conducta de las personas, lo que fue un factor determinante en el desarrollo de un análisis científico de incidentes, accidentes y riesgos [7].

2.3.

Referencia Histórica de las Pruebas Psicotécnicas.

A partir de la primera mitad del siglo XX la reducción del factor humano como causa de accidentes ha sido uno de los aspectos de preocupación fundamentales en seguridad de transportes. Es también en esa época cuando más avances se producen en la psicotécnia, gracias al trabajo de diversos investigadores de este campo como Münsterberg, 1910, Marbe y Lahy 1915, Ulbricht 1917; Tramm 1920, Mira 1928 y Bonnardel 1959, entre otros. Con el surgimiento de estos nuevos desarrollos muchos países del mundo comenzaron a exigir a los conductores profesionales de vehículos de servicio público o de transporte colectivo, aprobar un examen psicotécnico, esta exigencia ayudó a definir un campo especializado, la psicotecnia aplicada al transporte de personas y mercancías (tranvías, trenes, autobuses, camiones, coches) [8]. En España, en la década de 1920-1930 en el Instituto de Orientación Profesional de Barcelona se elaboraron las primeras pruebas psicotécnicas por Emilio Mira y López, a petición del ayuntamiento de dicha ciudad, con el fin de examinar determinadas aptitudes psicológicas a los conductores profesionales. Esta batería de pruebas, pionera en el campo del examen psicológico aplicado a conductores, evaluaba las siguientes aptitudes [9]: La atención distribuida, la coordinación de movimientos y la resistencia a la fatiga se medían a través del aparato de Piokowski. La percepción de velocidades, distancias y los resultados comparativos se medían con el perceptotaquímetro, inventado por el propio Mira y López. El Tiempo de Reacción que se medía con el cronoscopio de Arsonval. La precisión de las reacciones, la inhibición motriz voluntaria y el grado de emotividad se medían con el taquistoscopio, colocado en una cámara oscura,

CAPÍTULO 2. MARCO TEÓRICO

8

el cual permitía la exposición de estímulos, tanto luminosos como sonoros. La eficacia de los tests utilizados, además de la fiabilidad de los resultados, permitió la estructuración del examen psicológico. De esta manera, la selección de los conductores profesionales pronto se convirtió en práctica habitual del laboratorio psicotécnico del Instituto de Orientación Profesional [9]. En Japón en 1961 Maruyama y Kitamura en Takei Co.-Japan (T.K.K.) desarrollan el test de reacción de anticipación de velocidad. Esta prueba permite evaluar la capacidad de los conductores para percibir lamide la capacidad de autocontrol del sujeto, permitiendo detectar la precipitación o impulsividad a una respuesta [9]. El polirreactímetro fue desarrollado por Bonnardel 1953-1954 en la E.A.P.-France con el nombre de "Polirreactígrafo". Este aparato presenta estímulos y registra las respuestas, sobre el que se pueden diseñar y aplicar diversas pruebas de Tiempo de Reacción [9]. En 1946 Bonnardel crea el test del "Doble Laberinto.o "19-D.L."de BONNARDEL, desarrollado para evaluar la coordinación viso-motriz simultánea de ambos miembros superiores de forma independiente y a ritmo impuesto [9]. En el año 1921 el profesor Jean M. Lahy, inició las evaluaciones de conductores con equipamien¬tos técnicos y mecánicos que le permitieron medir velocidades y reacciones, cuantificados por la “Société des Transport” en París, Francia, los que fueron aplicados con gran éxito en la disminución de accidentes [10].

2.4. 2.4.1.

Algunos de los Primeros Instrumentos Psicométricos. Silbato de Galton.

Este instrumento permitía mediar la sensibilidad auditiva en general a las altas frecuencias, permitía saber si el sujeto era o no capaz de percibir los sonidos emitidos, graves y agudos a distintas distancias. Fue ideado por Francis Galton en el año 1883, pensado inicialmente para el control de perros [11].

CAPÍTULO 2. MARCO TEÓRICO

9

Figura 2.1: Silbato de Galton. 2.4.2.

Acúmetro.

Percepción y medida de la agudeza auditiva. Determinación de la sensibilidad auditiva. Este instrumento consistía de dos bobinas, un zumbador, dos conmutadores circulares, un conmutador fijo, un enchufe de tres tomas, dos auriculares, dos bornes de conexión y las guías de la bobina móvil con divisiones de 0 a 100. Al evaluado se le podían enviar los sonidos separados o ambos a la vez, cuando este escuchaba el sonido debía levantar el brazo izquierdo o derecho indicando de qué lado escucho el sonido. Una bobina móvil permitía graduar la gravedad o agudeza de los sonidos detectados [11]. 2.4.3.

Cuadriperceptímetro Mallard.

Permitía medir la apreciación visual de las dimensiones de un cuadrado, relacionando la longitud vertical con la horizontal. Este instrumento consistía en un cuadrado grabado con uno de sus lados movible y un mando que permitía ajustar dicho lado hasta el punto donde el evaluado estimara que se formaba el cuadrado perfecto. En la parte posterior contaba con una graduación que iba de -10 a 10 la cual permitía evaluar la precisión del cuadrado formado, cuando la línea marcaba 0 se había acertado a la medida correcta [12].

CAPÍTULO 2. MARCO TEÓRICO

10

Figura 2.2: Parte Frontal y Trasera del Cuadriperceptímetro. 2.4.4.

Cronoscopio de D’Arsonval.

Este instrumento permitía medir el tiempo de reacción de varios estímulos (visuales, auditivos, olfativas y táctiles). Los valores resultantes en comparación con los medidos en sujetos normales, ayudaría a aclarar las alteraciones perceptuales derivadas de una fuente de ciertas enfermedades mentales [12].

Figura 2.3: Cronoscopio de D’Arsonval.

2.4.5.

Taquistoscopio de Proyección con Obturador Automático

Este conjunto de aparatos se usa para mostrar diapositivas a velocidades extremadamente altas, con tiempos de exposición programables de: 5, 10, 20, 50, 100, 200 y 500 milisegundos, más 1 y 2 segundos. A estas velocidades tan altas se evalúa la percepción visual del sujeto. El sistema incluye; proyector de diapositivas Kodak, obturador de alta velocidad y rack de control. Este rack permite controlar el porta diapositivas, la lámpara del proyector, la velocidad del obturador y el intervalo de diapositiva a diapositiva (1-99 segundos). El proyector puede colocarse a 4 metros de la unidad de control [13].

CAPÍTULO 2. MARCO TEÓRICO

11

Figura 2.4: Taquitoscopio de Proyección con Obturador Automático. 2.4.6.

Perceptor de Profundidad

Este instrumento sistema está compuesto de dos barras contenidas en un compartimento de madera. El objetivo es colocar ambas barras a la misma distancia del sujeto. El compartimento de iluminación elimina todas las pistas de profundidad, de forma que el sujeto debe juzgar la profundidad basándose en su percepción visual [13].

Figura 2.5: Perceptor de Profundidad.

2.5.

Pruebas Psicosométricas Actuales.

En este segmento se hace una simple presentación de un grupo de aparatos e instrumentos modernos utilizados habitualmente en las evaluaciones, estimación y medida de las aptitudes físicas y perceptivas sensoriales. 2.5.1.

Pruebas de Coordinación Bimanual.

Prueba de Coordinación Bimanual. Esta prueba es la versión mejorada del test "Le test du double labyrinthe"de Bonnardel, mide la coordinación entre ojos y manos en una tarea a una velocidad predeterminada. Es un test estándar en psicología de tráfico.

CAPÍTULO 2. MARCO TEÓRICO

12

Tiene por objetivo que el evaluado lleve simultáneamente el control de dos puntos a través de un camino con curvas, del cual solo se ve un segmento (ver figura 2.6), donde el tiempo de reacción del individuo tiene un efecto modulador importante (rapidez en la rectificación de los errores) [14]. En la figura se muestra

Figura 2.6: Prueba de Coordinación Bimanual. Prueba de Palanca Lahy. El siguiente es la versión prueba bimanual utilizada en nuestro pais comúnmente conocida como "Test de Palanca Lahy", la cual forma parte de un gabinete usado en varios municipios del país y que ha sido homologada ante las autoridades pertinentes. El objetivo es manejar un puntero sobre una guía evitando salir de ella, esta prueba mide coordinación basada en la cantidad de veces que el evaluado se extravió de la ruta y el tiempo que le tomo completarla [15].

Figura 2.7: Prueba de Coordinación Bimanual Lahy. Coordinación bimanual Lafayette. El test de coordinación bimanual Lafayette, es otra versión usada en Europa ídem a la anterior. Para su funcionamiento utiliza un contador de pulsos que detecta la cantidad de veces que se hizo contacto con los extremos metálicos al salirse del trazado [16].

CAPÍTULO 2. MARCO TEÓRICO

13

Figura 2.8: Prueba de Coordinación Bimanual Lafayette y Contador de Pulsos. 2HAND. 2HAND - Two-Hand Coordination desarrollada por Schuhfried, no es otra cosa que la digitalización de la prueba clásica. Con la salvedad que, no se utiliza una tijera para seguir el circuito. El objetivo en esta prueba es hacer que el punto rojo se mueva de derecha a izquierda a lo largo de una pista determinada. Los dispositivos usados para controlar son dos perillas de control o dos joysticks. La pista se compone de tres secciones que hacen diferentes demandas sobre la coordinación de mano izquierda y derecha [17].

Figura 2.9: Prueba de Coordinación Bimanual Digital Lafayette y Joistick de Control.

2.5.2.

Pruebas de Reacción.

Prueba de Reacción. Este test utiliza la versión mejorada del Polirreactígrafo, instrumento clásico de reactimetría, programable de orientación francesa, (Bonnardel, 1953; 1954). Evalúa tiempo de reacción de una persona a ciertos estímulos típicamente luminosos, mide reacciones simples, reacciones de elección. [18].

CAPÍTULO 2. MARCO TEÓRICO

14

Figura 2.10: Prueba de Reacción. Prueba de Reacción con Contador de Pulsos. La siguiente es la versión del test de reacción utilizado en Chile, el cual también forma parte de un gabinete usado en varios municipios del país y que ha sido homologada ante las autoridades pertinentes. Con este instrumento se logra conocer con exactitud el tiempo de reacción de un conductor ante un estimulo visual o auditivo, al cual el evaluado debe responder aplicando el freno [19].

Figura 2.11: Prueba de Reacción y Contador de Pulsos. Prueba de Reacción Digital de Schunhfried. Una versión más moderna de esta prueba, la desarrolló Schuhfried, esta prueba denominada RT-Reaction Test, utiliza como dispositivo de entrada un panel de control. La prueba consiste en la presentación de estímulos de color y / o señales acústicas. Al evaluado se le indica que pulse la reacción tecla sólo cuando los estímulos específicos que se presentan y, después de haber pulsado el clave, para regresar de inmediato con el dedo a la tecla de descanso. El uso de auriculares garantiza la exclusión de los ruidos que distraen [20].

CAPÍTULO 2. MARCO TEÓRICO

15

Figura 2.12: Prueba de Reacción Digital de Schunhfried y Joystick Controlador. 2.5.3.

Prueba de Punteo Lahy.

Este es un instrumento con ritmo impuesto y repetitivo, le impone al examinado una acción constante. El objetivo de esta prueba es medir la capacidad de vencer la monotonía y continuar coordinado en sus movimientos. La prueba consta de dos discos colocados uno sobre otro y un puntero, el disco en la parte inferior tiene una serie de orificios, mientras el de la parte superior tiene una ranura de un cuarto de su diámetro. La prueba consiste en hacer girar el disco superior y tratar de atinar con el puntero a los orificios que se dejan ver por la ranura, evitando tocar el disco que gira [21].

Figura 2.13: Prueba de Punteo Lahy.

2.5.4.

Pruebas de Visión.

DVS-V GT Vision Screener. El visor DVS-GT viene incorporado con una serie de pruebas que permiten una completa evaluación de las condiciones visuales de un individuo y se detallan a continuación [22].

CAPÍTULO 2. MARCO TEÓRICO

16

Figura 2.14: Prueba de Visión DVS-GT. Agudeza Visual. Presentación simple para la rápida evaluación de la agudeza de visión monocular y binocular 20/40 en la escala de Snellen1 .

Figura 2.15: Prueba de Visión: Agudeza Visual. Agudeza Ojo Izquierdo. Agudeza del ojo izquierdo consta de dos presentaciones, una para cada ojo. La prueba evalúa mientras el ojo derecho está abierto y viendo una presentación igual a la de la imagen pero sin números. La medición de la agudeza va de 20/200 a 20/20 en la escala Snellen. Agudeza Ojo Derecho. Agudeza del ojo derecho consta de dos presentaciones, una para cada ojo. La prueba se evalúa mientras el ojo izquierdo está abierto y viendo una presentación igual a la de la imagen pero sin números. La medición de la agudeza va de 20/200 a 20/20 en la escala Snellen. 1

Herman Snellen, oftalmólogo holandés quien diseñó la prueba en 1862.

CAPÍTULO 2. MARCO TEÓRICO

17

Figura 2.16: Prueba de Visión: Agudeza Ojo Izquierdo.

Figura 2.17: Prueba de Visión: Agudeza Ojo Derecho. Agudeza Binocular. Agudeza binocular presenta el mismo grupo de números para ambos ojos simultáneamente. La medición de la agudeza va de 20/200 a 20/20 en la escala Snellen.

Figura 2.18: Prueba de Visión: Agudeza Binocular. Percepción de Color. Los números son presentados para indicar si existe una severa deficiencia en la discriminación de color (rojo/verde). Esta prueba también puede revelar una insuficiencia en los estímulos de percepción figura fondo. Reconocimiento de Signos y Visión Estereoscópica. Seis signos de tránsito comunes son presentados en la prueba de reconocimiento. Esta presentación es en 3D para permitir la evaluación estereoscópica (visión en profundidad). Una baja estereoscopia puede ser síntoma de una incapacidad de percepción. Phoria. Determina si los músculos de los ojos están balanceados y coordinados. Si solo la

CAPÍTULO 2. MARCO TEÓRICO

18

Figura 2.19: Prueba de Visión: Percepción del Color.

Figura 2.20: Prueba de Visión: Reconocimiento de Signos y Visión Estereoscópica. caja o solo el punto son vistos esto indica un trastorno de supresión. El desequilibrio visual es desorden común entre los niños y puede causar fatiga visual, dolor de cabeza y nerviosismo.

Figura 2.21: Prueba de Visión: Phoria. Recuperación al Encandilamiento. Mide la velocidad y eficiencia con la que el examinado se readapta a las condiciones nocturnas después de ser encandilado repentinamente con una luz brillante. Esta prueba simula lo que experimenta un conductor al exponerse a las luces de un automóvil acercándose de frente en horas de la noche. Vision Periférica Horizontal. Luces led situadas entre los lentes y empotradas en las aéreas laterales del cabezal del visor, permiten evaluar que tanto se extiende el campo de visión lateral de un individuo. Un restringido campo periférico o “visión de tunnel” es rápidamente identificable con este instrumento.

CAPÍTULO 2. MARCO TEÓRICO

19

Figura 2.22: Prueba de visión: Recuperación al Encandilamiento. La evaluación es de 85o , 70o , 55o y 45o (nasal) para cada ojo. Vision Periférica Vertical. Luces led situadas arriba y debajo de los lentes, permiten evaluar que tanto se extiende el campo de visión vertical de un individuo. Control de Comandos. El visor es operado mediante un control alámbrico que permite un completo control de las pruebas y sus características. El control permite avanzar o retroceder en una prueba, encender y apagar las luces de periferia, activar las condiciones de conducción nocturna etc.

Figura 2.23: Prueba de Visión: Control de Comandos. Prueba de Vision Schuhfried VTS. Este instrumento permite determinar el grado de detección a altas velocidades angulares que se suceden en el campo de visión periférica y la detección de objetos que se mueven en la periferia. Esta prueba simula las situaciones de conducción en la que nos enfrentamos a personas u objetos en la calzada. Mide la vigilancia del medio ambiente, detección de eventos y objetos. El objetivo de esta prueba es evaluar las

CAPÍTULO 2. MARCO TEÓRICO

20

capacidades de detección de vehículos, personas u otros, provenientes de una calle lateral que pudieran inesperadamente cruzarse en el camino [23].

Figura 2.24: Prueba de Visión Schuhfried VTS.

2.5.5.

Prueba de Audio.

Este examen expone a un individuo a una serie de estímulos sonoros, en frecuencias y ciclos que se reciben cotidianamente del medio ambiente, evaluando el nivel de orientación basado en su capacidad auditiva frente a cada estímulo. El audiómetro es un instrumento que permite determinar el nivel auditivo de un sujeto para cada uno de sus oídos. A pesar de que existe una extensa variedad de este tipo de instrumento, su funcionamiento es básicamente el mismo, la exposición de un individuo a sonidos en distintas frecuencias e intensidades.

Figura 2.25: Prueba de Audio: Audiómetro.

CAPÍTULO 2. MARCO TEÓRICO

21

Otros más sofisticados incluyen la gestión de datos de diagnóstico, como el MA 55 Audio-PC-System Audiometer de Maico [24].

Figura 2.26: MA 55 Audio-PC-System Audiometer de Maico.

2.6.

Otros Métodos de Detección de Conductores de Alto Riesgo.

En el último tiempo se han ido desarrollando nuevas tecnologías que buscan a identificar de forma más eficiente y dentro de un entorno más realista a aquellos sujetos que son más propensos a terminar envueltos en un accidente automovilístico. 2.6.1.

NADS

El NADS o NADS-1 es conocido como uno de los simuladores de conducción terrestre de mayor fidelidad del mundo. Este simulador tiene una base de movimiento con 13 grados de libertad. Sus capacidades únicas de movimiento lo distinguen de otros simuladores, permitiendo al NADS-1 reproducir con exactitud los movimientos de aceleración sostenida y las maniobras de frenado, el movimiento a través de múltiples carriles de tráfico y la interacción con diferentes superficies de carreteras.

CAPÍTULO 2. MARCO TEÓRICO

22

Figura 2.27: NADS-1. Para añadir más realismo, el NADS-1 cuenta con un vehículo real, vehículos utilitarios deportivos o cabina de camión ubicados dentro de una cúpula de aproximadamente ocho metros de diámetro. Cada cabina está equipada con instrumentación completa y específica para cada modelo de vehículo.

Figura 2.28: Cúpula NADS-1. Los pedales del acelerador y freno utilizan motores eléctricos controlados por software que proporcionan información, lo que permite una flexibilidad ilimitada en la programación específica de mecanismos de retroalimentación de los pedales. El volante es de similar diseño para permitir una respuesta de dirección personalizada para cada tipo de vehículo. Todos los indicadores del tablero están en funcionamiento. Múltiples cámaras a bordo de los vehículos proporcionan vistas personalizadas del entorno de la cabina. Otra característica que define al NADS-1 de otros simuladores de conducción es su sistema envolvente de 360 grados de visualización. Este sistema está compuesto por ocho proyectores que proyectan imágenes dentro de la cúpula. Todos los escenarios se actualizan 60 veces por segundo.

CAPÍTULO 2. MARCO TEÓRICO

23

La cabina está montada al suelo a través de cuatro actuadores hidráulicos que producen vibraciones emulando sensación del camino. La cúpula entera está montada en una corona de giro que puede girarla 330 grados en cada dirección sobre su eje vertical. El ensamble de la corona de giro se monta en la parte superior de un hexápodo hidráulico tradicional, que a su vez está montado sobre dos vigas que son accionadas por correas y que se pueden mover de forma independiente a lo largo de los ejes X e Y. El ensamblado X-Y produce aceleraciones transversales y longitudinales. El sistema de movimiento es capaz de proporcionar con alta fidelidad la aceleración producida por la mezcla de aceleraciones inducidas por el hexápodo con la corona de giro y aceleraciones del ensamblado X-Y.

Figura 2.29: Sistema de Movimiento NADS-1. La simulación proporciona la herramienta ideal para realizar investigaciones que no son factibles o serian demasiado costosas o peligrosas en el mundo real. En un entorno simulado, investigadores de la NADS pueden examinar los efectos de llevar tecnologías (reproductores mp3 y teléfonos móviles), fatiga, mala visión, la asunción de riesgos, edad, y deterioro físico y el mental debido a la utilización del alcohol o medicamentos sin dañar al conductor, experimentador, u otros vehículos y peatones que pueblan las carreteras reales. La simulación de conducción también puede ayudar con la formación de conductores, la reconstrucción de accidentes y simulación forense. Con tres plataformas de simulación que ofrece distintos niveles de realismo, el NADS tiene una posición única para satisfacer esas necesidades y problemas [25].

CAPÍTULO 2. MARCO TEÓRICO

2.7.

24

La Evaluación Psicosométrica en Nuestro País.

2.7.1.

Entidades Autorizadas para Expedir Licencias.

Por resolución del Ministerio de Transportes y Telecomunicaciones y la Subsecretaria de Transportes, en nuestro país solo se autoriza a otorgar licencias de conducir municipios que cuenten con los siguientes requisitos [26]: Departamento de Tránsito y Trasporte Público. Uno o más profesionales con título de médico cirujano expedido por alguna de las universidades reconocidas por el estado. Un gabinete técnico para el examen de los postulantes a obtener licencia de conductor. 2.7.2.

Comparativa con Gabinetes de Similares Características.

Actualmente en el mercado existen empresas dedicadas al desarrollo de gabinetes psicotécnicos en las que se destacan nombres como Pretinovic, Norklan y Psicotech. Estas empresas han desarrollado gabinetes de similares características al desarrollado en esta memoria (ATS Integrado, NORKLAN 3000 y ESE 2000, respectivamente). Lo siguiente es una comparativa entre las características más relevantes que los diferencian los gabinetes de las respectivas empresas con el nuestro [38] [39] [40]. Cuadro 2.1: Tabla Comparativa de Gabinetes. Características Software de Control Test de Vision Integrado Otras Pruebas no Homologadas Base de Datos Configura Parámetros de Medición Interoperable Administración de Otros Datos

GNEX ATS Integrado SI SI SI NO NO SI SI SI SI NO SI NO NO SI

NORKLAN ESE 2000 3000 SI SI NO NO SI NO SI NO Especifica NO NO NO NO SI NO

Según el cuadro anterior lo destacable del desarrollo de esta memoria con respecto a trabajos ya existentes en el mercado son:

CAPÍTULO 2. MARCO TEÓRICO

25

Integración de la prueba de visión: El gabinete Gnex incluye en su software un controlador que permite manipular las pruebas contenidas en el visor, no así los otros gabinetes que lo controlan de forma independiente. En el caso particular de Pretinovic que solo tienen un modulo de registro para los resultados de esta prueba en su sistema de control. Parametrización de los parámetros de evaluación: A diferencia de los otros gabinetes unas de las partes fuertes del desarrollo está enfocada en hacer parametrizables los valores de medición de las distintas pruebas. Los valores como cantidad de errores, tiempo de realización, máximo y mínimo de errores etc. vienen definidos por defecto en lo que estipula la ley para cada tipo de licencia, pero son de fácil modificación ya que están disponibles en archivos de configuración que el software va a leer. Interoperable: El software encargado del control de las pruebas psicotécnicas está pensado para ser interconectado con un hipotético software de gestión que sea compatible con tecnología .Net, que generalmente utilizan las municipalidades para la administración de los datos de las licencias y los resultados de las pruebas, no solo las psicotécnicas sino también las teóricas y prácticas. Por último quisiera resaltar las ventaja que ofrece la digitalización de las pruebas psicotécnicas, la cuales tienen por objetivo que el evaluado perciba inequívocamente que cometió un error al dejar rastros gráficos que lo evidencian, cosa imposible en las pruebas mecánicas actuales. 2.7.3.

Exámenes e Instrumentación.

De acuerdo a la ley para conceder a un individuo un permiso de conducción para un vehículo motorizado, los departamentos de tránsito y transporte público municipales, deben practicar exámenes a los postulantes para verificar su idoneidad física y síquica, además de evaluar sus conocimientos teóricos y prácticos sobre conducción y legislación del tránsito [2]. Por ley para que un gabinete técnico se pueda utilizar como medio de evaluación, deberá contar con los instrumentos y exámenes que se detallan en la siguiente tabla [26]:

CAPÍTULO 2. MARCO TEÓRICO

26

Exámenes Físicos (Sensométricos): Cuadro 2.2: Tabla Instrumentación Exámenes Visuales Exámenes Visuales Examen Agudeza Visual

Objetivo Mide la capacidad de percepción nítida de objetos a diferentes distancias, en el día y en la noche.

Perimetría

Mide los límites de las áreas perceptoras de la retina hacia el exterior, en el plano de enfoque horizontal. Mide la capacidad de ver objetos en diferentes planos, permitiendo evaluar la distancia de acercamiento. Mide la capacidad de percepción visual con el mínimo de luminosidad. Disminución de la percepción visual por exceso de luminosidad. Mide la capacidad de los ojos de percibir y diferenciar colores en sus diferentes tonalidades.

Visión de Profundidad

Visión Nocturna

Encandilamiento

Visión de Colores

Instrumentos Optotipos en escala de décimas o escalas equivalentes. Se pueden usar: Optotipos integrados a un instrumento, procediéndose de acuerdo a las especificaciones del aparato. Optotipos proyectados, en que el proyector y el examinado deben encontrarse en un mismo plano vertical. Distancia entre proyector y pantalla: 3 a 6 metros. Perímetro Horizontal

Evaluador de distancia

Nictómetro

Nictómetro

Tablas seudoisocromáticas que incluyen láminas con colores puros, rojo, verde y amarillo, de acuerdo a las normas internacionales de la A.O.A. ( American Optical Association).

CAPÍTULO 2. MARCO TEÓRICO

27

Cuadro 2.3: Tabla Instrumentación Examen de Audiometría Examen Audiometría

Examen de Audiometría Objetivo Instrumentos Mide el nivel de audición Audiómetro con frecuencia de a lo mínima, en decibeles, en menos de 500 - 1000 - 2000 y 4000 ambos oídos, separadamen- c.p.s. te, para la frecuencia de 500 – 1000 – 2000 y 4000 ciclos por segundo (c.p.s.)

Exámenes Psíquicos (Sicométricos) [26]: Cuadro 2.4: Tabla Instrumentación Examen de Psicométrico Examen Tiempos de Reacción.

Coordinación Motriz

2.8. 2.8.1.

Examen Psicométrico Objetivo Instrumentos Evalúa los tiempos de reac- Reactímetro para reacciones simción entre estímulos visuales ples (automático o manual) con y reacción con pie o mano escala en centésimas de segundos, o Reactímetros para reacciones compuestas, con escala en centésimas de segundo. Evaluar coordinación ojo- Prueba punteado y prueba de pamano para acciones rápidas, lanca. precisas y seguras

Conceptos Relacionados con la Implementación. Digitalización de Pruebas Psicotécnicas.

Digitalización es la representación de un objeto, imagen, sonido, documento o una señal a una representación binaria. El resultado se llama la representación digital o, más concretamente, una imagen digital del objeto. Estrictamente hablando, la digitalización significa simplemente la captura de una señal analógica en formato digital. La anterior definición corresponde a lo que en estricto rigor es el término digitalización, sin embargo en el contexto de este proyecto su significado es algo distinto, de aquí en adelante entiéndase digitalización como el proceso la toma de requerimientos

CAPÍTULO 2. MARCO TEÓRICO

28

y características asociadas a una prueba las cuales se representaran en un formato digital. En otras palabras se trata de la misma prueba con la diferencia que la prueba ya no es un artefacto mecánico sino que una representación de la misma en formato digital.

Figura 2.30: Digitalización Prueba Punteo Lahy.

2.8.2.

Manejo de Pruebas Mediante Drivers.

Un controlador de dispositivo (device driver, en inglés) es un módulo del kernel o sistema operativo que se encarga de gestionar a bajo nivel las operaciones de entrada y salida para la manipulación del hardware. Un controlador cuenta con todo el código específico para el funcionamiento de un dispositivo así como las interfaces necesarias para su comunicación [27]. 2.8.3.

Interoperabilidad COM.

El modelo interoperabilidad COM permite básicamente a un objeto exponer y permitir el uso de sus funcionalidades a otros objetos, mediante ensamblados o dlls, independiente del lenguaje en el que se hayan desarrollado [28]. Este modelo permite de manera fácil y transparente que otros programadores utilicen el código, sin necesidad de darles acceso al código fuente, sino al resultado ya compilado. Una ventaja de esto es que asegura que quien use el ensamblado, no podrá modificar su código ni obtener detalles de su implementación [29].

CAPÍTULO 2. MARCO TEÓRICO

29

Todas las aplicaciones desarrolladas en .NET Framework son traducidas a un entorno en tiempo de ejecución denominado Common Language Runtime (CLR), esto, permite la interacción del código administrado con otros tipos de código denominado no administrado (el código que se ejecuta bajo el control de Common Language Runtime (CLR) se denomina código administrado, mientras que el código que se ejecuta fuera de CLR se denomina código no administrado). Los componentes COM, COM+, C++, los componentes de ActiveX y la API de Microsoft Win32 son ejemplos de código no administrado. La aplicación .NET Framework habilita la interoperabilidad con el código no administrado a través de los servicios de Plataform Invoke, el espacio de nombres System.Runtime.InteropServices y la interoperabilidad C++ y COM [35]. 2.8.4.

Acerca de MCI (Windows).

La Media Control Interface (MCI) o interfaz de control de medios es una librería del sistema operativo Windows que provee comandos estándar para la reproducción y grabación de recursos multimedia. Estos comandos son una interfaz genérica para casi todo tipo de dispositivos multimedia. MCI provee a las aplicaciones independencia del dispositivo, para controlar periféricos de audio o video, pudiendo usarla para controlar todo tipo de dispositivo multimedia soportados [36]. Para la comunicación con los dispositivos MCI utiliza Command Strings y Command Messages [37]: Command Messages: utiliza constantes y estructuras para enviar las instrucciones al dispositivo a través de la función mciSendCommand. Command Strings: utiliza una versión textual de command messages. Para enviar las instrucciones al dispositivo utiliza la función mciSendString. 2.8.5.

Acerca de las Herramientas de GDI+.

Microsoft Windows GDI+ es parte de los sistemas operativos Windows XP y Windows Server 2003, esta provee herramientas para dibujar gráficas vectoriales en dos dimensiones, imágenes y tipografías. Lo siguiente es una revisión de algunos conceptos y herramientas que son parte de

CAPÍTULO 2. MARCO TEÓRICO

30

esta librería gráfica y que serán utilizados en la implementación de la parte gráfica de las pruebas digitales. Regiones. Una región es una porción de superficie visible. Las regiones pueden ser elementos simples como un rectángulo o complejas como la combinación de polígonos y curvas cerradas. En la siguiente figura se muestran dos regiones, una construida por un rectángulo y otra construida por un path2 .

Figura 2.31: Ejemplo de regiones. Es posible llegar a crear complejas regiones que se forman al aplicar funciones de edición sobre otras regiones más simples. La clase Region nos permite crear representaciones elementos simples o creados a partir de un path y además permite combinar regiones al aplicar sobre ellas las siguientes funciones: Intersect. Union. Xor. Exclude. Complement. Al aplicar el método intersect a dos regiones se obtiene una región compuesta por el conjunto de puntos en común de las dos regiones. Al aplicar el método union a dos regiones se obtiene una región compuesta por todos los puntos de las regiones. La siguiente figura muestra la intersección y unión de las regiones mostradas en la figura anterior. 2

Un path es un conjunto de puntos que forman una región.

CAPÍTULO 2. MARCO TEÓRICO

31

Figura 2.32: Intersección y unión de regiones. El método xor aplicado a un par de regiones, produce una región que contiene todos los puntos de ambas regiones excepto aquellos que tienen en común. El método exclude aplicado a un par de regiones, produce una región que contiene todos los puntos de la primera región que no estén en la segunda región.

Figura 2.33: Xor y resta de regiones.

2.9.

Resumen.

En este capítulo se ha hecho una revisión de algunos de los conceptos más relevantes en el desarrollo de esta memoria, comenzando con el desarrollo y la evolución de las pruebas psicotécnicas y como estas fueron evolucionando hasta transformarse en una potente herramienta en la lucha contra los accidentes de tránsito, permitiendo la detección oportuna de conductores de alto riesgo. También se vio como es la psicometría en nuestro país, los instrumentos que se utilizan y las legislaciones que los rigen. Por último se hizo una revisión de los conceptos técnicos relacionados directamente en el desarrollo de esta memoria. En el siguiente capítulo se describirá la metodología de desarrollo elegida y la adaptación a la cual fue sometida para ser utilizada en la creación del este proyecto.

3. 3.1.

Metodología Introducción.

Teniendo en cuenta que el presente proyecto se lleva a cabo para una empresa privada, la cual espera que en el desarrollo del mismo sean presentados resultados funcionales que permitan evaluar lo planificado vs los resultados obtenidos, en períodos de tiempos acotados, se hace necesario utilizar una metodología que permita cumplir las siguientes exigencias de desarrollo:

Desarrollo de un sistema modular. Períodos reducidos de desarrollo con entregables tangibles. Cada una de sus pruebas funcione con óptima calidad. Evolución y perfeccionamiento de la pruebas. Permitir realizar pruebas independientes. Flexibilidad de desarrollo ante eventuales cambios. Documentación reducida. Grupo de desarrollo reducido. Por lo anterior lo que mejor se ajusta al perfil de las exigencias de desarrollo es una metodología ágil. Estas metodologías se aplican bien en equipos pequeños que resuelven problemas concretos. Dividir el trabajo en módulos abordables minimiza los fallos y el costo. Las metodologías ágiles presentan diversas ventajas, entre las que podemos destacar [30]: 32

CAPÍTULO 3. METODOLOGÍA

33

Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo. Entrega continua y en plazos breves de software funcional. Trabajo conjunto entre el cliente y el equipo de desarrollo. Importancia de la simplicidad, eliminado el trabajo innecesario. Atención continua a la excelencia técnica y al buen diseño. Mejora continua de los procesos y el equipo de desarrollo. En este capítulo se expondrá la metodología elegida para el diseño y desarrollo del presente proyecto y su adaptación para las condiciones existentes en esta memoria.

3.2.

Desarrollo Guiado por Funcionalidades (FDD).

FDD por sus siglas en ingles (Feature-Driven Development) es un enfoque ágil para el desarrollo de sistemas, no hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de diseño y construcción. Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto. Se basa en un proceso iterativo con iteraciones cortas que están enfocadas en producir prototipos funcionales. Define claramente entregas tangibles y formas de evaluación del progreso del proyecto. Estas cualidades posibilitan al cliente y/o a la dirección de la empresa a tener una conciencia real del avance del proyecto y evaluar si los resultados se ajustan realmente a lo requerido, lo que permite tomar decisiones tempranas ante posibles cambios o problemas que pudieran surgir [31]. FDD consta de cinco fases secuenciales durante las cuales el diseño y la construcción del sistema se llevan a cabo. 3.2.1.

Desarrollo de un Modelo Global.

En este primer paso se construye un modelo global del sistema con la ayuda de los expertos del dominio quienes están al tanto de la visión, el contexto y los requerimientos del sistema a construir. El dominio es dividido en áreas de desarrollo que son analizadas detalladamente. Una vez finalizada cada área, el grupo se reune para realizar un modelo global en base a todas las alternativas.

CAPÍTULO 3. METODOLOGÍA

34

Figura 3.1: Fases Metodología FDD. 3.2.2.

Equipo de Desarrollo.

El equipo de Desarrollo lo encabeza German Bravo Gerente de I+D, el cual para este proyecto ejercio tambien como Jefe de Proyecto es quien se ocupa de hacer las definiciones dar los requerimientos. El desarrollo y la definición de las funcionalidades las realiza el autor de esta memoria Adan Escobar, por otra parte el diseñador Juan Cordero nos asistió en la creacion de las interfaces. 3.2.3.

Elaboración de la Lista de Funcionalidades.

El desarrollador identifica las funcionalidades , las agrupa, por otro lado el jefe de proyectos las prioriza y las pondera. En iteraciones subsecuentes del proceso, el equipo se divide en subgrupos que se especializan en áreas relacionadas a dichas funcionalidades. El desarrollador elabora una lista de funcionalidades que resuma las funcionalidades generales del sistema, luego las divide en subconjuntos según la afinidad y la dependencia que existan entre ellas. Finalmente la lista es evaluada por el cliente y/o los usuarios y el desarrollador para su validación y aprobación. 3.2.4.

Planeación por Funcionalidad.

En este punto se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia. Se establecen hitos y se establece un cronograma de diseño y construcción.

CAPÍTULO 3. METODOLOGÍA

3.2.5.

35

Diseño por Funcionalidad.

Se toma la próxima funcionalidad a ser diseñada, se identifican las clases involucradas. Se realiza una descripción de ellas y sus métodos. 3.2.6.

Desarrollo por Funcionalidad.

En esta etapa se construyen los métodos de las clases para cada funcionalidad correspondiente y luego realiza pruebas unitarias para cada clase. Luego se realiza la integración de funcionalidad al sistema, realizando las pruebas de integración correspondiente.

3.3.

Metodología del Proyecto.

En este ítem se describe la adaptación realizada de la metodología FDD para ajustarla a los requerimientos del presente proyecto. 3.3.1.

Desarrollo de un Modelo Global.

Requisitos: Haber realizado reuniones de levantamiento donde se hayan manifestado las necesidades principales del cliente y comprender el contexto del proyecto. Contar con una lista de requerimientos valorada por el cliente. Tareas: Se crea una lista de las funcionalidades del sistema. De las funcionalidades obtenidas se diferencian aquellas que son prioridad de otras que se desean pero que no son absolutamente necesarias. Se identifican aquellas funcionalidades que pueden llegar a tomar más de dos semanas en ser desarrolladas y se les divide en funcionalidades más pequeñas. Salida: Como resultado se obtendrá un modelo global del sistema que perimirá al desarrollador identificar los actores y funcionalidades que serán requeridas por el sistema.

CAPÍTULO 3. METODOLOGÍA

3.3.2.

36

Elaborar Lista de Funcionalidades.

Entrada: Requerimientos valorados por el cliente. Tareas: Se crea una lista de las funcionalidades del sistema. De las funcionalidades obtenidas se diferencian aquellas que son prioridad de otras que se desean pero que no son absolutamente necesarias. Se identifican aquellas funcionalidades que pueden llegar a tomar más de dos semanas en ser desarrolladas y se les divide en funcionalidades más pequeñas. Salida: Como resultado se obtienen grupos de funcionalidades prioritarias y bien definidas con una duración acotada a no más de dos semanas. 3.3.3.

Planeación por Funcionalidad.

Entrada: Listado de funcionalidades, resultado de la etapa anterior. Tareas: Se determina en qué orden serán desarrolladas las funcionalidades y se establecen los plazos de inicio y de fin. Se identifican las clases involucradas con el desarrollo de cada funcionalidad y se establecen los períodos de implementación y de prueba. Salida: Como resultado de esta etapa se obtendrá un plan global con fecha de inicio y término de cada funcionalidad, las cuales luego darán paso a las iteraciones principales del desarrollo del sistema.

CAPÍTULO 3. METODOLOGÍA

3.3.4.

37

Diseño por Funcionalidad.

Entrada: Se requiere de los documentos generados en las últimas iteracciones. Tareas: Se identifican las clases atributos y métodos que implementarán las funcionalidades requeridas. Se crean los diagramas de clases y de base de datos. Salida: Como resultado se obtendrá un diseño de las distintas funcionalidades para ser implementado. 3.3.5.

Desarrollo por Funcionalidad.

Entrada: Diagrama de clases actualizado y su descripción. Notas del equipo que consideren significativas para el desarrollo. Tareas: Se implementan las clases y sus respectivos métodos. Se realiza testing de las funcionalidades implementadas. Se realiza la integración a sistema. Salida: Como resultado se obtendrá una pieza de software funcional la cual se podrá evaluar, de acuerdo a su funcionamiento, si se apega o no a las necesidades del cliente, si existe conformidad con lo realizado se continuará con la siguiente funcionalidad, de lo contrario vuelve a pasar al ciclo de desarrollo para hacer las correcciones respectivas.

3.4.

Herramientas Generales.

Lo siguiente es la descripción del lenguaje y las herramientas que serán utilizadas en el proceso de desarrollo.

CAPÍTULO 3. METODOLOGÍA

3.4.1.

38

Lenguaje de Programación CSharp.

CSharp es un lenguaje orientado a objetos y con seguridad de tipos que permite a los desarrolladores crear una amplia gama de aplicaciones sólidas y seguras que se ejecutan en .NET Framework. Es posible utilizar este lenguaje para crear aplicaciones de escritorio para Windows, servicios Web XML, componentes distribuidos, aplicaciones cliente-servidor, aplicaciones de base de datos etc. Para el presente proyecto se utilizara la versión 2.0 del lenguaje incluida en .net framework 2.0 [32]. 3.4.2.

Visual Studio 2005.

Visual Studio es un conjunto completo de herramientas de desarrollo para la generación de aplicaciones Web ASP.NET, Servicios Web XML, aplicaciones de escritorio y aplicaciones móviles. Visual Basic, Visual C++, Visual CSharp y Visual JSharp utilizan el mismo entorno de desarrollo integrado (IDE), que les permite compartir herramientas y facilita la creación de soluciones en varios lenguajes. Asimismo, dichos lenguajes aprovechan las funciones de .NET Framework, que ofrece acceso a tecnologías clave para simplificar el desarrollo de aplicaciones Web ASP y Servicios Web XML [33]. 3.4.3.

Subversión.

Subversión es un sistema de control de versiones free/opensource, que permite administrar archivos y directorios, y los cambios hechos en ellos en el tiempo, esta característica permite recuperar antiguas versiones de los datos o examinar el histórico de cómo han cambiado en el proceso de desarrollo. El repositorio subversion puede ser accesado a través de redes, lo que le permite ser usado remotamente por personas que se encuentran en distintos lugares. A cierto nivel, la capacidad para que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboración [34].

CAPÍTULO 3. METODOLOGÍA

3.5.

39

Resumen.

En este capítulo se ha presentado la metodología FDD que será utilizada en el proceso de desarrollo de este proyecto, enunciado de forma simplificada la adaptación de cada una de las actividades a utilizar en esta memoria. Se hizo también una breve descripción de las herramientas que serán utilizadas en el proceso de desarrollo para la construcción del software y la administración del código fuente. En el siguiente capítulo se presenta el contexto del proyecto, sus requerimientos, diseño y planificación de la solución propuesta.

4.

4.1.

Requisitos, Diseño y Planificación. Introducción.

Una buena implementación tiene sus bases en la correcta determinación de los requisitos y en la realización de un buen diseño, pero para ello, es necesario conocer y entender todas las necesidades de los involucrados de forma de brindar una solución adecuada a las necesidades de los clientes. En este capítulo se presenta el proceso de diseño y planificación del presente trabajo.

4.2.

Descripción del Contexto de Desarrollo.

La empresa Exceed Ltda. requiere para su producto GNEX gabinete psicotécnico, un sistema de control que le permita manipular cada uno de los instrumentos de medición y recolectar los datos de las evaluaciones para las distintas pruebas. El gabinete es en sí un conjunto de hardware que ha sido diseñado especialmente para la detección de conductores de alto riesgo, que como ya se mencionó, requiere de un software de control para su adecuado funcionamiento. A continuación se describen las componentes de hardware que conforman el gabinete psicotécnico GNEX: Pedalera para la prueba de reacción: Esta pedalera fue desarrollada para leer las reacciones de aceleración y frenado de un sujeto en evaluación que se esperara reaccione al cambio de luces de un semáforo.

40

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

41

Figura 4.1: Gabinete Psicotécnico GNEX. La pedalera está diseñada para ser conectada al puerto serial al cual se enviarán distintas señales dependiendo si el pedal derecho está presionado, ambos etc. El DVS-GT Vision Screener: Es un instrumento especializado para la medición de la capacidad visual de un individuo. Este instrumento trae de fábrica un control alámbrico que utiliza comunicación serial, el cual se espera sea remplazado por una pieza de software que permita controlar íntegramente cada una de las pruebas que son parte del instrumento. Pantalla táctil: Esta pantalla será utilizada como periférico para mostrar las representaciones gráficas de las pruebas de reacción (semáforo termitente), punteo (representación gráfica del disco) y tijeras (trazo a recorrer), así como para recoger las interacciones realizadas con éstas que no son otra cosa que clicks en el caso de la prueba de punteo y la realización del trazo para la prueba de tijera. Tijera de la prueba de palanca Lahy: Esta tijera fue adaptada para realizar el trazo sobre la pantalla táctil, en la parte inferior tiene un puntero adecuado para dibujar en una pantalla táctil, el cual que debe ser guiado por el recorrido que se muestre en la pantalla. Puntero prueba de punteo: Entiéndase como un lápiz adaptado para ser usado como medio para la interacción con el disco que se dibujará en la pantalla

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

42

táctil. Audífonos profesionales: Los audífonos serán usados para enviar los estímulos sonoros al oído en distintas frecuencias en intensidades que se esperan sean reconocidas por el usuario. El propósito de este proyecto es desarrollar un sistema de interfaz amigable y sencilla que implemente las pruebas necesarias para el completo funcionamiento del gabinete psicotécnico GNEX, además de almacenar los datos y los resultados de las pruebas de los evaluados. Se espera también que las pruebas puedan ser accesibles a través de una interfaz de interoperabilidad, con la que otras aplicaciones puedan tener control de las pruebas y acceder a los resultados de estas mismas de forma independiente a la aplicación. En lo que concierne a la implementación, en un afán de la empresa por ofrecer un producto con un plus más moderno, con tecnología digital, se requiere emular las pruebas de punteo y tijeras para que estas puedan ser realizadas a través de la pantalla táctil, este proceso se ha definido como digitalización de pruebas de tijera y punteo.

4.3.

Requerimientos Valorados por el Usuario. Restringir acceso a la aplicación mediante sistema de login. Mostrar en una pantalla principal las distintas pruebas que pueden ser utilizadas. Solicitar el ingreso de los datos del evaluado antes de comenzar la evaluación. Mientras se esté realizando una evaluación permitir ver el progreso de la prueba y al finalizar un cuadro resumen con el resultado de la evaluación. Luego de realizar la prueba permitir darla por finalizada o dejarla como intento o permitir repetir la prueba. Al dejarla como finalizada no permitir repetir la prueba. El sistema debe registrar los resultados de la prueba y el número de veces que se ha realizado una antes de darla por finalizada.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

43

Permitir continuar con un examen en cual no se hayan terminado todas las pruebas. Impresión con el detalle de un examen que incluya los datos del evaluado, las pruebas a las que fue sometido indicando el número de veces que repitió cada prueba, los resultados obtenidos, los mínimos esperados para la aprobación y la indicación si ha aprobado o no. Digitalización prueba de punteo. • Emular las mismas características de la prueba original de punteo. • Parametrizar diámetro y velocidad de giro. Digitalización prueba de tijeras. • Emular las mismas características de la prueba original de tijeras. • Parametrizar el recorrido a seguir, esto es tener la posibilidad de dibujar distintos trazos y que la prueba siga teniendo el mismo comportamiento. Implementación de la prueba de audio. • Reproducir los sonidos predefinidos aleatoriamente a distintas intensidades, frecuencias y lados (izquierdo o derecho). • Parametrizar de los intervalos de tiempo de reproducción y las frecuencias a reproducir. • Permitir calibrar el volumen y balance de los sonidos de la prueba de audio. • Leer las reacciones del individuo en evaluación mediante la pedalera. Implementación de la prueba de reacción. • Mostrar aleatoriamente el cambio de luz verde a roja, esto se hará mediante la representación de un semáforo que se mostrará en la pantalla táctil. • Parametrizar la cantidad de veces del cambio de luz y el tiempo entre cambios.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

44

• Lectura y registro del tiempo de reacción desde que se muestra la luz roja hasta que se presiona el pedal de freno. Implementación de la prueba de visión. • Registro de los resultados de cada prueba. • Control del visor y sus características. Configuración de la dificultad de la prueba, tiempo de evaluación, cantidad mínima de aciertos, cantidad máxima de errores etc, para cada prueba. Contar con un archivo de configuración individual para cada tipo de licencia. Se debe poder controlar las pruebas por medio de una interfaz de interoperable. Para mantener la integridad de las configuraciones del sistema se requiere tener mantenedores independientes de la aplicación para las distintas configuraciones y calibraciones del software y/o las pruebas según corresponda.

4.4.

Diseño de Arquitectura.

Dadas las características requeridas para el sistema no es posible que estas sean cubiertas por un solo sistema, por ello se hace necesaria la creación de subsistemas que trabajen en conjunto para cumplir con todas las exigencias establecidas. A continuación se describe cada componente definido en la arquitectura propuesta para el proyecto. Aplicación: Esta parte del sistema corresponde a la aplicación principal, con la que interactuará directamente el usuario y la cual le permitirá manejar las pruebas y realizar evaluaciones a los candidatos a conductor. En ella se implementan la interfaces de usuario y la lógica de acceso a datos. Servidor de base de datos: Representa el servidor de base de datos PostgreSql, donde se aloja el modelo relacional de datos. Pruebas psicotécnicas: Ensamblado com (dll) que implementa la lógica de las pruebas psicotécnicas, sus clases, métodos y eventos necesarios para su funcionamiento y control.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

45

Administrador de configuraciones: Ensamblado com que implementa la lógica para la carga las distintas configuraciones disponibles para cada prueba. Drivers de control: Ensamblados com que implementan los controladores, las clases, métodos y eventos necesarios para el control e interacción con los dispositivos físicos del gabinete psicotécnico. Interfaz de interoperabilidad: Ensamblado com que implementa las clases, métodos y eventos de adaptador de alto nivel que permite el control de las pruebas psicotécnicas, independiente de la aplicación. A continuación en la Fig.4.2 se muestra la relación existente entre los distintos componentes de la arquitectura.

Figura 4.2: Arquitectura del Proyecto.

4.5.

Identificación de Funcionalidades.

A continuación se presenta el listado preliminar de funcionalidades detectado a partir de los requerimientos valorados por el cliente.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

46

Cuadro 4.1: Tabla de Funcinalidades. Prioridad A B A

A A A A A A A A A A

A A A A A A

Funcionalidad Implementar servicio de autenticación de usuario que valide rut y contraseña. Lanzar mensaje de error en caso de fallar la autenticación. Registrar los datos del conductor rut, nombre, apellidos paterno y materno y fecha de nacimiento. Cargar los datos del conductor por rut. Obtener el último examen que no registre todas las pruebas terminadas por rut. Crear representación y acceso a las pruebas. Crear vista previa de impresión y lógica de impresión. Crear lógica de inicio y fin para pruebas Crear lógica para capturar los eventos provocados por las pruebas. Crea representación de los resultados. Guardar los resultados de la prueba. Implementar representación gráfica del disco y los orificios del test. Implementar variación de dimensiones del disco (radio interno, radio externo, radio de orificios y ángulo entre orificios). Implementar variación del número de orificios del disco. Implementar representación del giro y variación de velocidad del disco. Implementar detección de colisiones del disco. Implementar lógica del test (tiempo de ejecución, inicio, recolección de datos). Implementar eventos para las interacciones y resultados del test. Implementar representación gráfica del trazo que debe seguir el evaluado.

Grupo Login

Grupo Superior Aplicación

Login

Aplicación

Principal

Aplicación

Principal Principal

Aplicación Aplicación

Principal Principal

Aplicación Aplicación

Vista Test Vista Test

Aplicación Aplicación

Vista Test Vista Test Test de Punteo Test de Punteo

Aplicación Aplicación Tests

Test Punteo Test Punteo Test Punteo Test Punteo Test Punteo Test de jera

de

Tests

de

Tests

de

Tests

de

Tests

de

Tests

Ti-

Tests

Tests

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

A A A A A A

A A A A

A A A A A

Implementar reconocimiento de variados trazos. Dibujar la huella que deja el usuario al hacer el recorrido. Dibujar marcas de los errores cometidos (Salir del trazo, levantar la tijera) Implementar lógica del test (tiempo de ejecución, dar inicio, dar fin, recolección de datos). Implementar eventos para las interacciones y resultados del test. Implementar representación gráfica de semáforo con dos luces, verde y roja y la representación de estado encendido y apagado de cada una de ellas. Leer las interacciones del usuario con driver de control de la pedalera del gabinete. Implementar lógica del test (tiempo de ejecución, dar inicio, dar fin, recolección de datos). Implementar eventos para las interacciones y resultados del test. Leer las interacciones del usuario mediante driver de control efectuadas con la pedalera del gabinete. (Identificando el pedal de freno como lectura de audición del lado izquierdo y el acelerador como lectura de audición del lado derecho). Implementar lógica del test (tiempo de ejecución, dar inicio, dar fin, recolección de datos). Reproducir aleatoriamente los sonidos de las distintas frecuencias a distintos decibeles. Implementar eventos para las interacciones y resultados del test. Implementar la recolección de los registros de las pruebas Leer las interacciones del usuario mediante driver de control efectuadas con la pedalera del gabinete. Identificando el pedal de freno como lectura de audición del lado izquierdo y el acelerador como lectura de audición del lado derecho

47

Test de Tijera Test de Tijera Test de Tijera Test de Tijera Test de Tijera Test de Reacción

Tests

Test de Reacción Test de Reacción Test de Reacción Test de Audio

Tests

Test Audio Test Audio Test Audio Test de sión Test de sión

de

Tests

de

Tests

de

Tests

Vi-

Tests

Vi-

Tests

Tests Tests Tests Tests Tests

Tests Tests Tests

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

A A A A A A A A A A A A A A

4.6.

Implementar lógica del test (tiempo de ejecución, dar inicio, dar fin, recolección de datos). Implementar eventos para las interacciones y resultados del test. Avanzar o retroceder entre pruebas. Reseteo del visor. Activar visión día/noche. Activar y desactivar sensor de cabeza. Ocultar despejar ojos. Activar y desactivar encandilamiento. Activar y desactivar luces de periferia. Detectar pedal presionado. Detectar pedal liberado. Carga y lectura de las configuraciones de pruebas desde los archivos xml. Creación de los métodos para la obtención de la configuración para cada tipo de licencia. Controlar pruebas a través de interoperabilidad

48

Test de Visión Test de Visión Visor Visor Visor Visor Visor Visor Visor Pedales Pedales Files

Tests

Lectores

Configuraciones

Manejo

Interoperabilidad

Tests Drivers Drivers Drivers Drivers Drivers Drivers Drivers Drivers Drivers Configuraciones

Modelo General de Clases.

En base a la arquitectura antes presentada se elaboró un modelo general de clases, en el cual se hace énfasis en la estructura que tendrá el proyecto y la relación que existirá entre las distintas clases y no en la definición de los aspectos particulares de cada una de ellas.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

Figura 4.3: Clases gráficas Aplicación Principal.

49

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

4.7.

50

Planificación por Funcionalidades.

4.7.1.

Iteración I.

Grupo de Funcionalidades: Aplicación Principal Creación de maqueta aplicativa. Clases comprometidas: Gnex: Clase gráfica principal, se encarga de cargar las distintas vistas de la aplicación. Se compone de las clases LoginPanel, MainPanel y TestPanel. LoginPanel: Esta clase se encargada de ofrecer al usuario los medios para el ingreso de las credenciales de acceso y la validación de las mismas. MainPanel: Esta la clase es la encargada de permitir al usuario los medios necesarios para realizar las siguientes acciones: El ingreso de datos de los evaluados. La elección del test a evaluar. Guardar un examen y toda su información asociada. Imprimir los resultados de un examen por medio de la clase PrintPanel. PrintPanel: Esta clase permite previsualizar e imprimir la información asociada a un examen. TestPanel: Esta clase permite al usuario controlar la realización de un test y visualizar los datos de la evaluación y el estado en el que se encuentra el test, se implementará un TestPanel para cada prueba. Fechas de Entrega: Semana I: Maqueta interactiva que permite mostrar las distintas interacciones que se espera soporte el sistema.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

4.7.2.

51

Iteración II.

Grupo de Funcionalidades: Aplicación Principal Creación de las clases encargadas de la persistencia de los datos en la aplicación. Clases comprometidas: PersonTo: Clase persistente que contiene los datos personales de un persona. UserTo: Clase persistente que contiene los datos personales y las credenciales de un usuario, esta clase extiende a la clase PersonTo. ExamenTo: Clase persistente que contiene los datos de un examen como tipo de licencia, información de los test, etc. TetTo: Clase persistente que contiene los datos de evaluación de un test, se implementará un TestTo para cada prueba. Fechas de Entrega: Semana II: Creación de la estructura de paquetes del proyecto. Creación de los objetos de transferencia de datos. 4.7.3.

Iteración III.

Grupo de Funcionalidades: Aplicación Principal. Crear de las clases encargadas de la obtención, almacenamiento y edición de los datos en la aplicación. Clases comprometidas: ConnectionManager: Esta clase implementa los métodos necesarios para crear y cerrar conexiones a la base de datos. PersonDB: Esta clase implementa los métodos necesarios para el ingreso, actualización y eliminación de los datos de un usuario.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

52

UserDB: Esta clase implementa los métodos necesarios para el ingreso, actualización y eliminación de los datos de un usuario en la base de datos (Si se pregunta por qué no solo se creó la clase usuario con los datos de la persona, la respuesta es simple, no todos las personas son usuarios). TestDB: Esta clase implementa los métodos necesarios para el ingreso, obtención y actualización de los datos de un test, se implementará un TestDB para cada prueba. ExamenDB: Esta clase implementa los métodos necesarios para el ingreso, obtención y actualización de los datos de un Examen. Fechas de Entrega: Semana II: Creación de los objetos y métodos para la obtención de datos. Implementación del proceso de login. Registro y obtención de datos del evaluado. 4.7.4.

Iteración IV.

Grupo de Funcionalidades: Prueba de Punteo: Creación de la lógica de la prueba de punteo. Clases comprometidas: Disc: Esta clase se encargará de dibujar el disco y entregar un bitmap con su representación. Permitirá además definir los parámetros necesarios para la variación de la dimensiones del mismo. Points: Esta clase se encargará de dibujar los orificios y entregar un bitmap con su representación. Permitirá además definir los parámetros necesarios para la variación del número de estos. DiscView: Esta clase es la encargada de implementar las rutinas netamente gráficas de la prueba, básicamente es la pantalla que pinta el disco y lo muestra en la pantalla touch.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

53

DiscTest: Esta clase implementa la lógica de la prueba y las rutinas que permitirán procesar las interacciones del usuario con el disco. Fechas de Entrega: Semana III: Diseño e implementación de la representación del disco con dimensiones variables. Diseño e implementación de la representación de los orificios así como el número de estos. Semana IV: Implementación de la rutina que permitirá el giro del disco a velocidades variables. Implementación de la rutina que permitirá discriminar si la interacción del usuario con el disco ha sido una colisión con el disco o con los orificios lo que luego se traducirá en un acierto o un error de acuerdo a la lógica de esta prueba. Implementación de la lógica de flujo de la prueba, métodos de inicio, fin y obtención de resultados, etc. Semana V: Integración con aplicación principal. Pruebas de integración. 4.7.5.

Iteración V.

Grupo de Funcionalidades Prueba de Visión: Creación de la lógica de la prueba de Visión. Clases comprometidas: TestVision: Esta clase implementa la lógica de control para cada una de las pruebas que conforman el test de visión.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

54

Fechas de Entrega: Semana VI: Creación de las distintas interfaces y la lógica de las pruebas que conforman en test de visión. 4.7.6.

Iteración VII.

Grupo de Funcionalidades: Drivers y Prueba de Visión. Creación del driver control para el manejo del Visor DVS-GT. Integración con prueba de visión. Clases comprometidas: DVSCommands: Esta clase enumera todos los comandos con los que opera el visor. DVSDriver: Esta clase implementa la lógica de control para el envío de comandos desde y hacia el visor. Fechas de Entrega: Semana VI: Creación de la lógica para la comunicación serial que activa y/o desactiva las distintas funcionalidades del visor. Semana VII: Integración de las funcionalidades de control con cada una de las pantallas desarrolladas para cada prueba. Pruebas de integración. 4.7.7.

Iteración VIII.

Grupo de Funcionalidades: Prueba de Tijera. Creación de la lógica de la prueba de tijera. Clases comprometidas:

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

55

PathTest: Esta clase se encargará de dibujar el trazo o camino a recorrer y entregar un bitmap con su representación, además carga los puntos que definen cada segmento del trazo desde un archivo xml. Segment: Esta clase es la encargada de definir un segmento a partir de dos puntos, además de validar si dado un punto este se encuentra dentro o fuera de él. ScissorsView: Esta clase es la encargada de implementar las rutinas netamente gráficas de la prueba, básicamente es la pantalla que pinta el trazo y lo muestra en la pantalla touch. ScissorsTest: Esta clase implementa la lógica de la prueba y las rutinas que permitirán procesar las interacciones del usuario con el trazo. Fechas de Entrega: Semana VIII: Diseño e implementación de la representación del trazo configurable. Semana IX: Implementación de la rutina que permitirá discriminar si la interacción del usuario ha seguido el trazo establecido lo que luego se traducirá en aciertos o errores de acuerdo a la lógica de esta prueba. Implementación de la lógica de flujo de la prueba, métodos de inicio, fin y obtención de resultados, etc. Semana X: Integración con aplicación principal. Pruebas de integración. 4.7.8.

Iteración IX.

Grupo de Funcionalidades: Prueba de Reacción. Creación de la lógica de la prueba de reacción. Clases comprometidas:

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

56

ReactionView: Esta clase es la encargada de dar la salida gráfica a los eventos visuales a los cuales debe reaccionar el evaluado, en este caso, el cambio de luces de un semáforo. ReactionTest: Esta clase implementa la lógica de la prueba que genera y procesa los distintos eventos a los que el evaluado debe reaccionar. Fechas de Entrega: Semana XI: Implementación de la rutina que permitirá lanzar eventos aleatorios de cambios de luz del semáforo y su representación gráfica. Implementación de la lógica de flujo de la prueba, métodos de inicio, fin y obtención de resultados, etc. 4.7.9.

Iteración X.

Grupo de Funcionalidades: Drivers y Prueba de Reacción Creación de las clases necesarias para la lectura de las acciones realizadas con la pedalera. Integración con prueba de reacción. Clases comprometidas: ParalelPort: Esta clase permite leer y escribir una palabra en el puerto paralelo. PedarDriver: Esta clase permite identificar los distintos estados en los que se encuentra la pedalera, si se está presionando el freno, el acelerador o ambos. Fechas de Entrega: Semana XII: Creación de la lógica para la lectura del puerto paralelo que activa y/o desactiva la pedalera y permite leer el estado de esta. Integración de las funcionalidades de control de la pedalera con la prueba de reacción. Pruebas de integración.

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

4.7.10.

57

Iteración XI.

Grupo de Funcionalidades: Prueba de Audio. Creación de la lógica de la prueba de audio. Clases comprometidas: AudioTest: Esta clase implementa la lógica de la prueba, en ella básicamente se generan aleatoriamente las ordenes de reproducción de los distintos sonidos a distintas frecuencias e intensidades y se procesan las reacciones que tiene el evaluado ante cada estimulo. MediaControler: Esta clase permite la reproducción de los recursos de audio, iniciar la reproducción, detenerla y dar el volumen preestablecido para cada reproducción. Fechas de Entrega: Semana XIII: Implementación de la rutina que permitirá la reproducción aleatoria de los sonidos. Implementación de la lógica de flujo de la prueba, métodos de inicio, fin y obtención de resultados, etc. 4.7.11.

Iteración XII.

Grupo de Funcionalidades: Drivers y Prueba de Audio Creación de las clases para el manejo del audio a nivel de sistema operativo. Integración con prueba de Audio. Clases comprometidas: AudioDriver: Esta clase permite controlar el audio y el balance del sonido a nivel de sistema operativo. Fechas de Entrega: Semana XIV:

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

58

Implementación de la lógica de control de audio. Integración con la prueba de audio. Integración de la prueba de audio con pedalera. 4.7.12.

Iteración XIII.

Grupo de Funcionalidades: Configuraciones Creación de las clases necesarias para la lectura y persistencia de los datos de configuración asociadas a cada prueba. Clases comprometidas: ConfigManager: Esta clase implementa las rutinas necesarias para la carga de los distintos archivos de configuración asociados a cada tipo de examen. ExamenConfig: Clase persistente que contiene la información de configuración de un examen, (cada examen representa la configuración para los distintos tipos de licencia disponibles). TestConfig: Clase persistente que contiene la información de configuración de una prueba. Fechas de Entrega: Semana XV: Implementación de las rutinas de carga y lectura de los archivos de configuración. Integrar las configuraciones con la aplicación principal. 4.7.13.

Iteración XIII.

Grupo de Funcionalidades: Interoperabilidad Creación de las clases necesarias para el control y la obtención de los resultados de las pruebas. Clases comprometidas:

CAPÍTULO 4. REQUISITOS, DISEÑO Y PLANIFICACIÓN.

59

IManager: Interfaz que permite definir el contrato para los métodos que serán visibles a nivel de ensamblado com. IDispatch: Interfaz que permite definir el contrato para los eventos que serán visibles a nivel de ensamblado com. TestManager: Esta clase implementa las interfaces IManager e IDispacher y es quien permitirá iniciar las pruebas, cargar sus configuraciones y obtener los resultados para cada evaluación. TestEvent: Clase que implementa la funcionalidad de los eventos asociados a las acciones de las pruebas. TestData: Clase persistente que contiene la información acerca de cada acción disparada por una prueba. Fechas de Entrega: Semana XVI: Implementación de las rutinas de interoperabilidad. Integración con el módulo de carga de configuraciones. Pruebas de control.

4.8.

Resumen.

En este capítulo se ha hecho una revisión del contexto de la aplicación, de la problemática presentada y el diseño y planeación de la solución propuesta. En el siguiente capítulo se hará una revisión del la implementación de la solución en base al modelo aquí definido.

5. 5.1.

Implementación. Introducción.

El trabajo descrito en esta memoria es fruto del desarrollo de un sistema de control para el equipo de pruebas psicotécnicas Gnex. Desarrollado por la empresa Exceed Ltda. en un afán de agregar innovación y automatización a las pruebas psicotécnicas que son utilizadas en la evaluación de conductores de alto riesgo, por la dirección de tránsito de nuestro país. Este capítulo describe del proceso de desarrollo del sistema de control, las pruebas y cada una de las componentes involucradas en el funcionamiento esperado, según requerimientos, de gabinete psicotécnico, centrándose en los aspectos más relevantes de la solución a los problemas sucedidos en el desarrollo.

5.2.

Interfaz de Usuario Aplicación Principal.

Para poder tener una perspectiva más amplia de cómo se vería la aplicación se construyó una maqueta aplicativa, basada en los requerimientos previamente obtenidos, que mostrara las distintas pantallas, su navegación, las interacciones y todos los controles esperados por el cliente de forma de obtener una retroalimentación que permitirá mejorar el diseño de la misma. Luego de un proceso de refinamiento se estableció que la aplicación se dividiría en cuatro pantallas fundamentales: Pantalla de login. Pantalla de registro y pruebas o pantalla principal. 60

CAPÍTULO 5. IMPLEMENTACIÓN.

61

Pantalla de Impresión. Pantalla de evaluación. Login. Al iniciar la aplicación la primera pantalla que se obtiene es la pantalla de login.

Figura 5.1: Pantalla Login. Pantalla Principal. Luego que el usuario se ha identificado con éxito en la pantalla de login, se accede a la pantalla principal, desde aquí se tiene acceso a las pruebas, la realización de un nuevo examen, el ingreso de datos del evaluado y la impresión de los resultados del examen en curso. A continuación se describen las componentes que conforman la interfaz enumeradas en la Fig. 5.2:

Información del evaluador. Cree un nuevo examen. Ingreso o búsqueda de los datos del evaluado. Acceso a pruebas psicotécnicas y estado de aprobación de cada una. Acceso a pantalla impresión de examen en curso.

CAPÍTULO 5. IMPLEMENTACIÓN.

62

Figura 5.2: Pantalla Principal. Pantalla Impresión. La pantalla de impresión (Fig. 5.3), muestra una vista previa del documento que contiene los resultados del examen, la información que contiene el documento es: Datos del conductor evaluado. Datos del evaluador. Resultados de cada prueba. Por cada prueba se detalla la cantidad de veces que fue evaluada antes de ser dada por terminada, los resultados obtenidos y los resultados de referencia de aprobación de cada ítem de la prueba.

CAPÍTULO 5. IMPLEMENTACIÓN.

63

Figura 5.3: Pantalla Impresión.

5.3.

Digitalización de la prueba de punteo Lahy.

Recordemos que la prueba de punteo lahy consiste en acertar la mayor cantidad de veces, a unos orificios a través de la ranura de un disco que se encuentra girando evitando tocar este último. En este segmento se muestra el proceso de digitalizar de la prueba lahy, pero ¿qué significa digitalizar la prueba lahy?, significa que la nueva prueba será la representación gráfica de un disco girando en una pantalla táctil y que emulara el mismo funcionamiento de la prueba convencional, adicionando algunos atributos que se han solicitado por parte del cliente, aprovechando las ventajas del mundo digital. El primer problema que se presentó fue el cómo diseñar el dibujo de un disco, idéntico al real, que pudiera variar su estructura, dados ciertos parámetros en tiempo de ejecución, la respuesta provino del cómo los dibujantes pueden lograr dibujar formas complejas a partir de la composición de figuras más simples utilizando programas como firework o photoshop. El API GDI+, incluida en .Net Framework, que además de contar con las funciones típicas para dibujar formas básicas, tiene la par-

CAPÍTULO 5. IMPLEMENTACIÓN.

64

Figura 5.4: Disco Prueba Punteo Lahy. ticularidad que incluye funciones sobre figuras como exclusión, unión, intersección etc., las mismas que se pueden realizar en con estos avanzados editores de dibujo digital, esta funcionalidades fueron de gran utilidad y facilitaron en gran medida la creación de nuestro disco digital. 5.3.1.

Diseño e Implementación del Disco.

Identificación de los parámetros del disco. El primer paso en el proceso de dibujo fue identificar que partes del disco que serían variables y así elaborar un método de dibujo que nos permita crear una representación del disco a partir de estos parámetros. La Fig. 5.5 describe en detalle cada uno de los parámetros que conforman el disco.

Figura 5.5: Parámetros Disco Lahy.

CAPÍTULO 5. IMPLEMENTACIÓN.

65

Donde: RA: radio abertura. AA: ángulo de abertura. RD: radio del disco. RI: radio del disco interior, donde RI = RD - 2RA. Dada su complejidad, no es posible dibujar la imagen del disco en una sola pieza, para ello se hará uso de una técnica de dibujo que se basa en dibujar una serie de regiones más simples, que combinadas bajo ciertas operaciones irán dando forma a la pieza que se espera. Lo siguiente es el detalle paso a paso de la técnica utilizada para dibujar el disco, aprovechando las potencialidades ofrecidas por la clase Region de GDI+. Paso I: Se comienza por dibujar una región circular de radio RD.

Figura 5.6: Paso I Dibujo Disco. Paso II: Luego se dibuja una región circular de radio RA, horizontalmente centrada y acoplada a la parte superior del disco.

Figura 5.7: Paso II Dibujo Disco.

CAPÍTULO 5. IMPLEMENTACIÓN.

66

Paso III: Utilizando la función exclude, al disco mayor se le extrae menor.

Figura 5.8: Paso III Dibujo Disco. Paso IV: Al igual que en el paso ii, se dibuja una región circular del mismo tamaño y en la misma posición, luego se le aplica una transformación de rotación en un ángulo AA con respecto al centro del la circunferencia mayor.

Figura 5.9: Paso IV Dibujo Disco. Paso V: Se realiza una operación de exclusión, al igual que el paso III.

Figura 5.10: Paso V Dibujo Disco. Paso VI: Para conseguir quitar el resto de la parte correspondiente a la abertura se dibujaran n regiones cuadradas en cada cuadrante de dimensiones RD x RD, considerando como centro del eje coordenado, el centro de la circunferencia. Dependiendo del ángulo de abertura deseado, serán en número de regiones que se utilicen. Las siguientes ilustraciones muestran la cantidad de regiones utilizadas para cada valor del ángulo AA.

CAPÍTULO 5. IMPLEMENTACIÓN.

67

Para AA ≤ 90◦ se dibujan dos regiones cuadradas, una en el I y otra en el IV cuadrante. Se realiza una operación de rotación a la región del IV cuadrante en AA grados, usando como pivote su esquina inferior derecha y luego se hace una operación de intersección entre ambas regiones.

Figura 5.11: Paso VI Dibujo Disco AA ≤ 90◦ . Si 90◦ < AA ≤ 180◦ se dibujan regiones cuadradas en el I y IV cuadrante. Se realiza una rotación de la región del IV cuadrante en AA+90 grados, usando como pivote su esquina inferior derecha y luego se hace una operación de unión entre ambas regiones.

Figura 5.12: Paso VI Dibujo Disco 90◦ < AA ≤ 180◦ . Si 180◦ < AA ≤ 270◦ se dibujan regiones cuadradas en el I, II y IV cuadrante. Se realiza una rotación a la región del IV cuadrante en AA grados, usando como pivote su esquina inferior derecha y luego se hace una operación de unión entre todas las regiones.

CAPÍTULO 5. IMPLEMENTACIÓN.

68

Figura 5.13: Paso VI Dibujo Disco 180◦ < AA ≤ 270◦ . Si AA > 270◦ se dibujan regiones cuadradas en todos los cuadrantes. Se realiza una rotación a la región del IV cuadrante en AA grados, usando como pivote su esquina inferior derecha y luego se hace una operación de unión entre todas las regiones cuadradas.

Figura 5.14: Paso VI Dibujo Disco AA > 270◦ . Paso VII: En este paso se realiza una operación de exclusión entre la figura formada por las circunferencias y la formada por los regiones cuadradas. Las siguientes figuras ilustran el resultado para todos los casos posibles.

CAPÍTULO 5. IMPLEMENTACIÓN.

Si AA ≤ 90◦ .

Figura 5.15: Paso VII Dibujo Disco AA ≤ 90◦ . Si 90◦ < AA ≤ 180◦ .

Figura 5.16: Paso VII Dibujo Disco 90◦ < AA ≤ 180◦ . Si 180◦ < AA ≤ 270◦ . Si AA >270◦ .

Figura 5.17: Paso VII Dibujo Disco 180◦ < AA ≤ 270◦ .

69

CAPÍTULO 5. IMPLEMENTACIÓN.

70

Figura 5.18: Paso VI Dibujo Disco AA >270◦ . Paso VIII: Finalmente sobre la región obtenida en el paso VII, se dibuja una región circular de radio RI. Aplicando una operación de unión entre ambas logramos dar la forma final al disco, y con ello se ha alcanzado el objetivo que era dibujar un disco que cumpliera con los parámetros antes definidos.

Figura 5.19: Paso VIII Dibujo Disco. Toda la operación de dibujado antes descrita la lleva a cabo la clase Disc, esta clase es del tipo utilitaria ya que su única función es dibujar el disco. Su uso se hace a través de su único método estático llamado draw, este método recibe los parámetros deseados, realiza las operaciones de dibujado antes descritas y retorna un bitmap con el dibujo del disco como resultado. 5.3.2.

Diseño e Implementación de los Orificios.

La representación del los orificios es mucho más sencilla de hacer, que la del disco. Para representarlos se dibujarán regiones circulares en la posición donde debieran ir estos. Parámetros de los orificios. Las partes parametrizables de los orificios son el radio del orificio, la cantidad y la distancia de su posición respecto al centro del disco, en la siguiente figura se muestran todas las variables involucradas para el dibujo de los estos. Donde:

CAPÍTULO 5. IMPLEMENTACIÓN.

71

Figura 5.20: Parámetros Orificios de Prueba Lahy. RO: radio orificio. n: número de orificios (en imagen n=3). (Dx, Dx): coordenadas centro del disco. DO: distancia del centro del disco al centro del orificio. a: distancia equidistante en grados entre cada orificio, donde a = 360/n. Lo siguiente es el detalle paso a paso del método utilizado para realizar el dibujo de los orificios. Paso I: Se comienza por dibujar una región circular de radio RO a una distancia DO con respecto al centro del disco.

CAPÍTULO 5. IMPLEMENTACIÓN.

72

Figura 5.21: Paso I Dibujo Orificios. Paso II: Lo segundo es trasladar la región en un grado a, este proceso se repite tantas veces como orificios se desee representar.

Figura 5.22: Paso II Dibujo Orificios. Al igual que en el dibujo del disco, toda la operación de dibujado antes descrita la lleva a cabo la clase Points, esta clase es del tipo utilitaria ya que su única función es dibujar los orificios. Su uso se hace a través de su único método estático llamado draw, este método recibe los parámetros deseados, realiza las operaciones de dibujado y retorna un bitmap como resultado.

CAPÍTULO 5. IMPLEMENTACIÓN.

5.3.3.

73

Implementación del Giro del Disco.

Una vez que contamos con la representación del disco, el siguiente paso es hacerlo girar a distintas velocidades o revoluciones. La implementación de giro se realiza aplicando una operación de rotación en ∆α grados en cada milisegundo a la imagen del disco, el valor que tenga dicha rotación esta en directa relación con las rpm a las que se desea que gire el disco, esta relación dada por la siguiente ecuación:

∆α =

360·rpm 60

1000

Para obtener intervalos de un milisegundo se hizo uso de la clase nativa timer, la cual nos permite programar la operación de giro y actualizar su estado en cada intervalo, la variación que va experimentando el disco en su ángulo de rotación en relación al tiempo, a(t) viene dado por la siguiente fórmula. α (t) = (∆α · t) %360 Donde: ∆α : Giro en grados en un milisegundo a una velocidad de rpm. t: Tiempo transcurrido en milisegundos. De esta forma para generar el giro, en cada evento timer _refresh _elapsed lanzado por la clase timer en sus intervalos de un milisegundo, se incrementa el tiempo t, se calcula el ángulo y se aplica la transformación de rotación a la imagen del disco, el siguiente código muestra en parte la implementación del giro. void timer_refresh _Elapsed(object sender, System.Timers.ElapsedEventArgs e) { ElapsedMilliseconds++; alfa = (deltaAngulo ∗ ElapsedMilliseconds) % 360.0f; rotarDisco(alfa); } En la teoría, lo anterior es correcto, pero en la práctica no lo es tan así dado que el procesador puede estar ocupado en otras tareas los intervalos de un timer no son

CAPÍTULO 5. IMPLEMENTACIÓN.

74

homogéneos, o sea no se ejecutan exactamente cada x tiempo como es de esperarse, lo que lógicamente produce intervalos irregulares. Tomemos un ejemplo de un timer que se ejecuta cinco veces en intervalos de un milisegundo, si midiéramos los tiempos transcurridos en cada llamada podríamos obtener la siguiente muestra: 1 - 1.2 - 0.9 - 0.9 - 1.3, en vez de 1 - 1 - 1 - 1 - 1 como se esperaría. Este comportamiento provoca que el giro del disco sea poco natural, dado que el tiempo que se calcula como transcurrido difiere del real, por lo que es necesario encontrar una manera de saber el tiempo exacto transcurrido entre un intervalo y otro, aplicar ese tiempo en la formula y con ello conseguir una rotación fluida y más realista del disco. Esto se consigue con ayuda de la clase stopwatch, la cual nos permite cronometrar tiempos de forma exacta, así en cada evento en vez de calcular el tiempo transcurrido, que en teoría era un milisegundo más, se obtiene el tiempo real transcurrido desde que comenzó la prueba y se estima el giro que debiera tener el disco en ese tiempo. Aplicando lo anterior al código quedaría de la siguiente forma: void timer_refresh _Elapsed(object sender, System.Timers.ElapsedEventArgs e) { alf a = (deltaAngulo ∗ stopwach.ElapsedM illiseconds) %360,0f ; rotarDisco(alfa); }

5.3.4.

Detección de Colisiones.

En este punto es importante recordar que la interacción con el disco se hará a través de un monitor touch y las colisiones que se esperan detectar son las del puntero sobre algunos de los orificios y/o cuando el disco se intercepta con la posición del puntero, cuando a éste se le ha hecho click. En este segmento se describe el análisis hecho para determinar si en un determinado tiempo t el usuario habría hecho colisionar el puntero del mouse con el disco. Para simplificar un poco los cálculos que establecen si un determinado punto (x, y) está o no en el área del disco, se hará un análisis sectorizado, el cual consiste en separar el área de análisis en tres sub áreas denominadas área exterior, área interior y área de aberturas.

CAPÍTULO 5. IMPLEMENTACIÓN.

75

Análisis del Área Exterior A1: Si se considera que el punto (x,y) del mouse se encuentra a una distancia d del centro del disco, mayor al radio del disco, entonces podemos asegurar que no se está tocando el disco.

Figura 5.23: Área Exterior del Disco. Análisis del Área Interior A2: Si se considera que el punto (x,y) del mouse se encuentra a una distancia d del centro del disco, inferior al radio del interior del disco, entonces podemos asegurar que si está tocando el disco.

Figura 5.24: Área Interna del Disco. En el caso de que las dos afirmaciones A1 y A2 sean falsas el puntero podría estar en cualquier lugar de la zona sombreada mostrada en Fig. 5.25, en la cual es un poco más complejo determinar si está tocando el disco o no.

CAPÍTULO 5. IMPLEMENTACIÓN.

76

Figura 5.25: Área de Abertura del Disco. Análisis del Área de Abertura. Para determinar si se está en colisión o no en la zona de estudio, partiremos haciendo algunas definiciones.

Figura 5.26: Definiciones Detección de Colisiones. Donde: α : ángulo que ha girado en disco respecto al centro de la primera abertura en un tiempo t. β : ángulo que ha girado en disco respecto al centro de la segunda abertura en un tiempo (β = α + AA).

CAPÍTULO 5. IMPLEMENTACIÓN.

77

θ: ángulo que forma la recta que pasa por el centro del disco y por el punto del puntero, con respecto a la vertical. Basándose solo en la posición respecto a los ángulos formados, podemos asegurar que en los siguientes casos no se está tocando el disco: α