domingo, 4 de diciembre de 2011

Herramientas CASE para UML

Debido a la popularidad que han ido adquiriendo UML (Unified Modeling Language) y MDA (Model Driven Architecture) en los últimos años, existe en el mercado una gran variedad de herramientas de modelado de diagramas UML.  Con lo cual, seleccionar una herramienta CASE (Computer-Aided Software Engineering) para UML se ha convertido en una tarea ardua.

¿Qué podemos esperar de una herramienta CASE (Computer-Aided Software Engineering) para UML? lo primero que podemos esperar de una herramienta es que facilite la tarea de dibujar diagramas, su corrección sintáctica, y la coherencia entre los distintos diagramas. Esta tarea se ve obstaculizada desde el primer momento por los problemas que presenta el mismo estándar de UML, que no habiendo alcanzado su plena madurez, presenta todavía inconsistencias y lagunas importantes

Herramientas UML
Herramientas gráficas. Las herramientas meramente gráficas son aquéllas que proporcionan algún tipo de ayuda para dibujar diagramas UML Herramientas sintácticas. Las herramientas sintácticas son aquéllas que, en general, sólo permiten dibujar diagramas correctos según las reglas notacionales de UML (o al menos lo intentan). Por tanto, suponen una ayuda mayor para el usuario respecto a las herramientas meramente gráficas. Herramientas semánticas. El tercer grupo lo constituyen las herramientas semánticas, es decir, aquellas que tratan de garantizar la construcción de un modelo que esté correctamente expresado en diagramas que además sean coherentes entre sí. Aunque en algunos casos la puntuación pueda ser inferior a la obtenida por herramientas
de los otros grupos, es dentro de esta categoría donde encontramos las que con propiedad pueden llamarse herramientas CASE para UML.

Dimensiones considerables con respecto a las herramientas CASE
Integración con herramientas ofimáticas (como copiar y pegar los diagramas en documentos de texto).
·         Posibilidad de trabajo multiusuario (para que los diversos implicados en un proyecto puedan acceder simultáneamente a distintas partes de un modelo).
·         Exportación en formato XMI (XML Metadata Interchange).
·         Integración dentro del entero proceso de desarrollo de software, desde la obtención de requisitos de usuario hasta la generación automática de código, estimación de esfuerzo necesario para acometer la implementación de un modelo dado, planificación, mantenimiento, pruebas, etc.
·         Reutilización de todo tipo de artefactos software (no sólo código fuente o ejecutable, sino también modelos de análisis o diseño, definición de pruebas, etc., e incluso requisitos).

Algunas Herramientas CASE son las siguientes:
Rational Rose 2002 Enterp. Ed.
Visible Analyst
Argo UML
Objecteering Personal Ed.
Visual UML Standard Ed.
Poseidon for UML
Visual Paradigm for UML Comm. Ed.
Object Domain R3 Eval. Ed.
Together Designer Comm. Ed.
seCAKE
Enterprise Architect
Visio 2003 Profesional
MagicDraw UML Enterp. Ed.

Recuperado de:
Gonzalo Génova Fuster, José Miguel Fuentes Torres, María Cruz Valiente Blázquez (mayo-junio 2006). Tecnología de objetos secciones técnicas. Evaluación comparativa de herramientas CASE para UML desde el punto de vista notacional Obtenido en octubre, 2011, de Depto. de informática, Universidad Carlos III de Madrid

UML Lenguaje Unificado de Modelado

Tratamiento de Requisitos en Propuestas para la Web

El desarrollo de sistemas web agrupa una serie de características que lo hacen diferente del desarrollo de otros sistemas (Koch, 2001). Por un lado, hay que tener en cuenta que roles muy diferentes de desarrolladores participan en el proceso: analistas, clientes, usuarios, diseñadores gráficos, expertos en multimedia y seguridad, etc. Por otro lado, la existencia en estos sistemas de una importante estructura de navegación obliga a un desarrollo preciso de este aspecto que garantice que el usuario no se “pierde en el espacio navegacional del sistema” (Olsina, 1999). Estas ideas unidas al hecho que los sistemas web suelen tratar con múltiples medios y es esencial que ofrezcan una interfaz adecuada en cada momento, obligan a que estos aspectos propios de la web deban ser tratados de una forma especial en el proceso de desarrollo.

UML-Based Web Engineering

UML-Based Web Engineering (UWE) es una propuesta metodológica basada en el Proceso Unificado (Jacobson, Booch & Rumbaugh, 1999) y UML para el desarrollo de aplicationes web (Hennicker & Koch, 2000, Koch, 2001). UWE cubre todo el ciclo de vida de este tipo de aplicaciones, centrando además su atención en aplicaciones personalizadas (adaptivas). Para este trabajo, nos interesa principalmente analizar la propuesta de captura de requisitos de UWE. Esta metodología distingue entre la tarea de enlistar requisitos, definir y validar los requisitos. El resultado final de la captura de requisitos en UWE es un modelo de casos de uso acompañado de documentación que describe los usuarios del sistema, las reglas de adaptación, los casos de uso y la interfaz. UWE clasifica los requisitos en dos grandes grupos: funcionales y no funcionales. Los requisitos funcionales tratados por UWE son:

  • Requisitos relacionados con el contenido
  • Requisitos relacionados con la estructura
  • Requisitos relacionados con la presentación
  • Requisitos relacionados con la adaptación
Requisitos relacionados con los usuarios. Además, UWE propone como técnicas apropiadas para la captura de los requisitos de un sistema web las entrevistas, los cuestionarios y los checklists y los casos de uso, los escenarios y el glosario para la definición de requisitos. Para la validación propone walk- hroughs, auditorías y prototipos.

W2000

W2000 (Baresi, Garzotto & Paolini, 2001) supone una propuesta que amplía la notación de UML con conceptos para modelar elementos de multimedia heredados de la propuesta HDM (Hypermedia Design Model) (Garzotto, Schwabe & Paolini, 1993). El proceso de desarrollo de W2000 se divide en tres etapas: análisis de requisitos, diseño de hipermedia y diseño funcional. El primero de ellos es el que resulta interesante para este trabajo. La especificación de requisitos en W2000 se divide en dos subactividades: análisis de requisitos funcionales y análisis de requisitos navegacionales. La especificación de requisitos comienza haciendo un estudio de los diferentes roles de usuario que van a interactuar con el sistema. Cada actor potencialmente distinto tendrá su modelo de requisitos de navegación y de requisitos funcionales. El modelo de requisitos funcionales es representado como un modelo de casos de uso tal y como se propone en UML. En él se representa la funcionalidad principal asociada a cada rol y las interacciones que se producen entre el sistema y cada rol. El segundo modelo consiste en otro diagrama de casos de uso pero que no representa funcionalidad sino posibilidades de navegación de cada actor. La representación gráfica es realizada con una extensión de UML.

Recuperado de:

Escuela Técnica Superior de Ingeniería Informática (2002). Ingeniería de Requisitos en Aplicaciones para la Web – Un estudio comparativo: Universidad de Sevilla. Sevilla: Autor.

Ingeniería de requisitos

Proceso de desarrollo de un sistema, sea o no para la web, el equipo de desarrollo se enfrenta al problema de la identificación de requisitos. La definición de las necesidades del sistema es un proceso complejo, pues en él hay que identificar los requisitos que el sistema debe cumplir para satisfacer las necesidades de los usuarios finales y de los clientes. El proceso de especificación de requisitos se puede dividir en tres grandes actividades (Lowe & Hall, 1999):
1- captura de requisitos
2- definición de requisitos
3- validación de requisitos
Captura de requisitos
Actividad mediante la que el equipo de desarrollo de un sistema de software extrae, de cualquier fuente de información disponible, las necesidades que debe cubrir dicho sistema (Díez, 2001). Técnicas que de forma clásica han sido utilizadas para esta actividad en el proceso de desarrollo de todo tipo de software:

  • Entrevistas: le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada.
  • JAD (Joint Application Development/Desarrollo conjunto de aplicaciones): Práctica de grupo que se desarrolla durante varios días y en la que participan analistas, usuarios, administradores del sistema y clientes (IBM, 1997).
  • Brainstorming (Tormenta de ideas): Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas. El grupo de personas que participa en estas reuniones no debe ser muy numeroso (máximo 10 personas), una de ellas debe asumir el rol de moderador de la sesión, pero sin carácter de controlador.
  • Concept Mapping: Los concept maps (Pan, Zhu & Johnson, 2001) son grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos.
  • Sketches y Storyboards: Consiste en representar sobre papel en forma muy esquemática las diferentes interfaces al usuario (sketches).
  • Casos de Uso: Aunque inicialmente se desarrollaron como técnica para la definición de requisitos (Jacobson, 1995), algunos autores proponen casos de uso como técnica para la captura de requisitos (Pan, Zhu & Johnson, 2001 y Liu & Yu, 200).
  • Cuestionarios y Checklists: Consiste en redactar un documento con preguntas cuyas respuestas sean cortas y concretas, o incluso cerradas por unas cuantas opciones en el propio cuestionario (Checklist).
  • Comparación de terminología: Uno de los problemas que surge durante la definición de requisitos es que usuarios y expertos no llegan a entenderse debido a problemas de terminología.

Definición de requisitos
  • Lenguaje natural: Resulta una técnica muy ambigua para la definición de los requisitos. Consiste en definir los requisitos en lenguaje natural sin usar reglas para ello.
  • Glosario y ontologías: La diversidad de personas que forman parte de un proyecto software hace que sea necesario establecer un marco de terminología común.
  • Escenarios: La técnica de los escenarios consiste en describir las características del sistema a desarrollar mediante una secuencia de pasos (Liu & Yu, 2001).
  • Casos de uso: Como técnica de definición de requisitos es como más ampliamente han sido aceptados los casos de uso. Actualmente se ha propuesto como técnica básica del proceso RUP (Kruchten, 1998).
  • Lenguajes Formales: Otro grupo de técnicas que merece la pena resaltar como extremo opuesto al lenguaje natural, es la utilización de lenguajes formales para describir los requisitos de un sistema.

La validación de requisitos
Tiene como misión demostrar que la definición de los requisitos define realmente el sistema que el usuario necesita o el cliente desea (Lowe & Hall, 1999).
  • Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección de la completa documentación o modelado de la definición de requisitos. Con ello solamente se puede validar la correcta interpretación de la información transmitida.
  • Auditorías: La revisión de la documentación con esta técnica consiste en un chequeo de los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir sólo una muestra es revisada.
  • Matrices de trazabilidad: Esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo (Durán, Bernáldez, Ruíz & Toro, 1999).
  • Prototipos: Algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario (Olsina, 1999).


Recuperado de:

Escuela Técnica Superior de Ingeniería Informática (2002). Ingeniería de Requisitos en Aplicaciones para la Web – Un estudio comparativo: Universidad de Sevilla. Sevilla: Autor.

Comparación entre Dia2Code, Umbrello y ArgoUML

El análisis y diseño de software juega un papel crucial en cualquier desarrollo, pero es en la programación orientada a objeto donde las actividades relacionadas con esta fase de un proyecto han alcanzado sus cotas más altas de sofisticación. Es, además, un área donde continuamente se producen avances y nuevas propuestas.
Aunque la mayoría de los diagramas de UML nos permiten mejorar la comunicación con el cliente en las fases iniciales, así como documentar y explorar funcionalidades y aspectos concretos de las clases de nuestro sistema durante su análisis y diseño, UML puede ayudarnos en las fases de desarrollo e implantación.
Se escogió la generación de código mediante tres herramientas de código abierto de las cuales se hacemos una comparación en la siguiente tabla.

Cuadro comparativo herramientas para la generación de código

Dada la información anterior, y con fines de aprovechamiento de recursos en la ejecución del proyecto, se ha escogido usar el software ArgoUML para la generación de código, los diagramas que se presentan a continuación fueron generados con ésta herramienta.
Las herramientas anteriormente mencionadas pueden encontrarse en las siguientes ligas
http://www.gnome.org/       Dia2Code
http://uml.sourceforge.net/ Umbrello              
http://argouml.tigris.org/      ArgoUML

Diagrama de casos de uso

Los casos de uso son una herramienta esencial en la toma de requisitos del sistema. Nos permiten expresar gráficamente las relaciones entre los diferentes usos del mismo y sus participantes o actores. El resultado es un conjunto de diagramas muy fácilmente entendibles tanto por el cliente, como por los analistas del proyecto. No definen todos los requisitos (por ejemplo, tipos de datos, interfaces externas, rendimiento, etc.) pero sí que representan el hilo conductor que los vincula a todos con los actores del sistema.

Se componen de los siguientes elementos:
  • Actores: representan los roles que juegan los usuarios u otros sistemas en el sistema del problema.
  • Caso de uso: son las acciones que pueden tener lugar en el sistema que queremos modelar.
  • Relaciones: indican actividad o flujo de información.
  • Límite del sistema: define el ámbito donde se produce el caso de uso que estamos representando y que va a ser tratado por el sistema.
El diagrama de casos de uso que propongo para el proyecto de simulador de conducción vehicular es el siguiente
Diagrama de casos de uso

Diagrama de clases

La realización de un diagrama de clases está en la frontera entre el análisis y el diseño. Probablemente es el diagrama UML más conocido y nos permite identificar la estructura de clases del sistema incluyendo las propiedades y métodos de cada clase.

Los elementos presentes en este diagrama son únicamente las clases, y sus relaciones:

  • Clase: se representa mediante un rectángulo dividido en tres secciones. En la parte superior deberemos indicar su nombre, a continuación sus propiedades o atributos y en la tercera sección sus métodos.
  • Asociación: representa una relación genérica entre dos clases, y su notación es simplemente una línea que las une, donde se puede indicar la multiplicidad de la relación en cada extremo (uno a uno, uno a n, n a m).
  • Composición, agregación: Si una clase está compuesta de otras, donde estas otras no pueden existir sin la primera, tendrán una relación de composición con la clase padre. Cuando simplemente una clase incluye a otra, pero la incluida tiene entidad en sí misma es agregación.
  • Dependencia: cuando una clase depende de otra en el sentido de que la usa como atributo o parámetro de algún método, puede expresarse mediante una relación de dependencia.
  • Generalización: es el equivalente a la herencia o extensión.
El diagrama de clases para el software simulador de conducción vehicular es el siguiente


Diagrama de clases


Diagrama de actividades

Son el equivalente orientado a objeto de los diagramas de flujo y los DFD del desarrollo estructurado. Su uso es principalmente la exploración y representación de la lógica comprendida en operaciones complejas, reglas de negocio, casos de uso o procesos software.
De forma similar a los tradicionales diagramas de flujo, todo diagrama de actividades tiene un punto de partida y un final. Las actividades representarán cada paso importante que se produce en el proceso que estamos modelando (puede representar un caso de uso o bien un conjunto de ellos).

A continuación el diagrama de actividades referente a este proyecto


Diagrama de actividades


Diagrama de secuencias

Modelan el flujo de la lógica dentro del sistema de forma visual, permitiendo documentarla y validarla. Pueden usarse tanto en análisis como en diseño, proporcionando una buena base para identificar el comportamiento del sistema.
Típicamente se usan para modelar los escenarios de uso del sistema, describiendo de qué formas puede usarse. La secuencia puede expresar tanto un caso de uso completo como quizá un caso concreto del mismo contemplando algunas alternativas.

Se componen de los siguientes elementos:

  • Objeto: instancia de una clase que podemos empezar a identificar como participante en la secuencia de operaciones que representa este caso de uso.
  • Actor: los actores pueden comunicarse con los objetos, por lo tanto formarán parte de este diagrama.
  • Activación: indicamos cuándo el objeto está realizando una tarea concreta.
  • Mensaje: la comunicación entre objetos y sus activaciones.
El diagrama de secuencias propuesto para el software simulador de conducción vehicular es el siguiente


Diagrama de secuencias


domingo, 23 de octubre de 2011

Capacidad del autor para abordar la investigación

Como estudiante de Ingeniería en Sistemas Computacionales de 8vo. Semestre en  el Tecnológico Regional de Querétaro  campus centro, he tenido un amplio contacto con materias relacionadas con el área de investigación, como lo son fundamentos de investigación, taller de investigación I, y actualmente taller de investigación II así como fundamentos de desarrollo de sistemas; lo que hace que tenga la capacidad de llevar un proyecto de ingeniería de software. En la parte de programación que se ocupará en el desarrollo, he recibido capacitación en lenguajes como C++, C Sharp, java, así como UML (Lenguaje Unificado de Modelado), he participado en actividades en equipo dentro de las asignaturas cursadas, concluido 284 créditos de un total de 400, además de haber terminado 5 niveles de inglés de un total de 6 que se imparten en esta institución, dadas las referencias anteriores buscaré llevar a un buen término este proyecto con fines de opción a titulación con el desarrollo de este trabajo.

Catálogo de requisitos

 
El software planeado para un simulador de conducción vehicular que recreé las calles de Querétaro así como su flujo vehicular va a contar con:
  • Pantalla al frente en la que se simule el ambiente que se percibe en el parabrisas y retrovisores
  • Interfaz que recreé las calles de Querétaro, incluyendo el sentido y ubicación, de una forma similar a una fotografía, sin tanta distorsión de cómo es en la realidad
  • Selección de Escenarios para elegir en que zona se desea manejar, que estén relacionados entre sí para hacer cambio de zona cuando se llegue al límite de esta.
  • Selección de tarea que se desea practicar, por ejemplo incorporación a vías rápidas, manejo en autopista, manejo en calles del centro, estacionado, así, por ejemplo sugerirá varias áreas donde hay que incorporarse a autopistas y practicar la tarea seleccionada
  • Simulación del flujo real de autos que se presenta en la ciudad de Querétaro, y a opción de seleccionar si se desea practicar con el tráfico real o iniciar en un nivel más básico
  • Pestaña conoce nuevas vialidades donde se informará sobre los cambios y obras recientes que se realicen en la ciudad, con opción a transitar en ellas en el simulador
  • Contará con selección de horario que se prefiera practicar, como día, atardecer, noche y lluvia. El flujo vehicular será el que presente en la realidad el horario seleccionado
  • Sugerencia de práctica de acuerdo a los errores o accidentes frecuentes que cometen los conductores, así como la zona en que suelen presentarse.
  • Modo de demostración que muestre las funciones que puede realizar el simulador mientras transita por diferentes partes de la ciudad.
  • Tutorial que de forma auditiva y apoyándose en elementos gráficos en pantalla indique las acciones que se deben de hacer al presentarse diversas situaciones como señales de tránsito, cruces de calles, incorporaciones, distancia entre vehículos, velocidad adecuada.
  • El sistema de manejo será a través de un volante, pedales, palanca de velocidades con opción a vehículo estándar o automático, asiento, cinturón de seguridad y componentes que presenta un vehículo real para controlar luces, velocímetro, kilometraje, etc.
  • Marcaje de los errores cometidos con opción a acceder al informe de errores, donde habrá una descripción más a detalle de en qué consistió el error y cómo corregirlo.
  • Opción de seguimiento de usuario, en el que se guarda el nivel de avance en el tutorial así como errores cometidos y zonas visitadas

Anexo 1. Cuestionario

Objetivo. Determinar experiencias y preferencias de la población que conduce vehículos motorizados de 4 ruedas en la ciudad de Querétaro.

1.      ¿Cómo aprendió a manejar?
       Un amigo o familiar me enseñó
       Yo solo
       Curso de autoescuela
       Otro, especifique _____________

2.      ¿Cuánto tiempo tardó en aprender a manejar?
       2 semanas o menos
       De 2 a 4 semanas
       1 a 2 meses
       3 meses o más

3.      Cómo calificaría el grado de dificultad de aprender a manejar, en escala del 1 al 10, siendo 1 muy fácil y 10 muy difícil.
Calificación _______
4.      ¿Cuál es la actividad que considera más complicada al manejar?
       Incorporaciones (Vías rápidas)
       Estacionado (En cordón, batería)
       Manejo en autopista
       Otra ___________________

5.      De haber existido un simulador de conducción vehicular cuando usted estaba aprendiendo a manejar, ¿le habría interesado? Indique en escala del 1 al 10, siendo 1 nada interesado y 10 muy interesado.
Calificación _________

Cronograma de actividades


El siguiente diagrama de Gantt muestra algunas de las actividades planeadas para la realización del proyecto de ingeniería de software

Actividades a realizar


miércoles, 19 de octubre de 2011

Objetivos

Objetivo general de Investigación.

Conocer las principales causas de los accidentes vehiculares en el estado de Querétaro, su ocurrencia y posible solución a través de un simulador vehicular.

Objetivos Específicos.

  • Investigar los efectos que tiene el uso de simuladores en el aprendizaje significativo.
  • Buscar un método que relacione movimiento, coordinación y atención de forma práctica.
  • Detectar las principales causas de los accidentes vehiculares en el estado de Querétaro.
  • Investigar si una completa educación vial puede prevenir accidentes automovilísticos.
  • Familiarizarse con la normativa de tránsito y la técnica de manejo.
  • Identificar que factores pueden corregirse con el uso de simuladores como apoyo en el manejo vehicular.
  • Juzgar los beneficios que tiene la implementación de simuladores en el examen de conducción en Querétaro.

Objetivo general de desarrollo.
Conocer cómo desarrollar un software que simule las vialidades y el flujo vehicular que hay en Querétaro, conteniendo una amplia señalización vehicular, escenarios y situaciones cotidianas, que sea de fácil distribución y accesible a la sociedad Queretana.

Objetivos Específicos de Desarrollo.

  • Investigar que elementos hay que tomar en cuenta para hacer el estudio de elaboración de un Simulador.
  • Conocer otros simuladores de conducción que ya existen y el impacto que han tenido.
  • Entender el funcionamiento de equipos controladores de juego libre como kinect.
  • Examinar el funcionamiento de software de simulación, creación de gráficos e interfaces de usuario.
  • Detectar proyectos de kinect que se relacionen con la conducción de vehículos.
  • Identificar  estudios de flujo vehicular en las calles de Querétaro.
  • Determinar cómo un software de Simulación vehicular puede ser adaptado a un equipo controlador de juego.
  • Enumerar varias opciones de lenguajes en las que se puede programar un simulador y crear la interfaz de usuario.

Referencias y fuentes documentales



lunes, 17 de octubre de 2011

Hipótesis

Dado que en Querétaro los accidentes automovilísticos se han incrementado notablemente en los últimos 10 años, siendo las principales causas de estos el no guardar distancia adecuada, exceso de velocidad, así como imprudencia o intención; todos estos errores humanos. La implementación de un simulador de conducción al que se tenga acceso para horas de práctica y de manejo correctivo, debería reducir el número de accidentes viales, generando corrección  a través de práctica, además, suponiendo que los nuevos conductores aprenden de forma empírica o por transmisión de conocimientos por parte de familiares u otros conductores, el uso de un simulador de conducción vehicular sería una manera más formal de dar instrucción a aprendices de manejo vehicular, lográndose un amplio conocimiento de educación vial y preparando a los conductores previamente antes de salir a practicar directamente a las calles, dando más seguridad al peatón y al conductor mismo.

Beneficiarios


Este proyecto de ingeniería de Software va dirigido a:
  • Aprendices de manejo
  • Conductores de vehículos particulares entre 16 y 34 años especialmente
  • SSC Querétaro (programas correctivos y de trámite de licencias)
  • Autoescuelas

miércoles, 5 de octubre de 2011

Introducción



Este es un proyecto de ingeniería de software, el cual esta motivado en buscar hacer una aportación que resulte útil a la sociedad Queretana, elaborando estudios sobre accidentes viales, y haciendo la propuesta de un simulador de conducción vehicular que pueda servir para prevenir accidentes de tránsito.

Los avances generados los compartiré con ustedes buscando un diálogo, así como la posibilidad de ser usados como fuente confiable de consulta de información; También quedará como inicio del proceso de titulación para al terminarlo totalmente y presentarlo siguiendo las normativas del Instituto Tecnológico Regional de Querétaro pueda obtener mi título profesional.

He realizado algunas investigaciones con las que propongo implementar dicho simulador de conducción vehicular, el cual funcionará simulando las calles de la ciudad de Querétaro, así como el flujo vehicular que presenta, a continuación les presento una breve descripción de este proyecto.

Dado que Querétaro ocupa el lugar numero 9 en accidentes vehiculares, y en México este tipo de accidentes es casi la tercera parte de causa de muerte en el país, además de que representan la pérdida del 4% del PIB a nivel Nacional, es necesaria la educación vial correctiva y preventiva, además las causas de accidente son casi totalmente por factor humano, por lo que son corregibles. Siendo que en Querétaro de acuerdo a la Secretaría de seguridad Ciudadana SSC ,en el 2009 como información más actual, el no guardar distancia, la velocidad excesiva y la imprudencia o intención fueron las principales causas de accidentes viales, detectamos que esto se puede erradicar con mas práctica de conducción que propicie una constante educación vial, una forma de lograrlo es a través del uso de un simulador de conducción que recree las vialidades conflictivas de Querétaro tales como 5 de febrero y Bernardo Quintana entre otras y el flujo de carros real que se presenta en las diferentes zonas urbanas, especialmente pensado para el rango de edad con mayor incidencia en accidentes vehiculares, que es de los 16 a los 34 años según datos del INEGI en 2008.

lunes, 3 de octubre de 2011

Contexto en el que se desarrollará el proyecto

Un avance significativo en el uso de simuladores de conducción en el estado, es que según las indicaciones que da la SSC, en Querétaro, el  Examen práctico de manejo será evaluado mediante un simulador de conducción, a excepción de motocicletas (licencia tipo D). Aplicable para licencia Tipo A (conducción de vehículos ligeros de uso particular) y Tipo B (conducción de vehículos pesados de uso particular).

Ya existen varios simuladores desarrollados que buscan la creación de una adecuada cultura vial y una correcta técnica de conducción, en España se está dando principal importancia a este aspecto, como lo muestra un artículo publicado en el diario electrónico la Voz de Galicia, que se emite en Galicia, España con fecha del 21 de enero del 2010; menciona que en la universidad de la Coruña en Ferro, España, se instaló temporalmente un simulador de conducción para que los alumnos pudieran practicar en distintos escenarios, como calles, carreteras secundarias o autopistas y en medio de condiciones climatológicas variadas.
El simulador además de enseñar a ser más prudentes, también enseña cómo conducir para reducir al máximo el daño al medio ambiente evitando acelerones y frenazos bruscos, con lo que consumimos y contaminamos menos, a la vez que se ahorran costos de mantenimiento de vehículo, esto lo declaró Carlos Álvarez, profesor de física y seguridad vial en el campus y coordinador de esta especie de seminario para convertirse en conductor prudente.


Como podemos notar, el objetivo que tienen los simuladores de conducción es la mejora de la seguridad y educación vial.
En España las siguientes instituciones usan simuladores de conducción de vehículos de 2 y 4 ruedas, según datos obtenidos de la página de arisoft.


Instituciones y organismos que cuentan con Simulador de conducción en España

Algunos simuladores que ya existen son los desarrollados por la firma arisoft, como es el caso de Driver Test.



Este tipo de simuladores vienen con un asiento, volante, palanca de marcha y pedales, y como lo muestra la relación de organizaciones que tienen ese simulador, solo lo adquieren instituciones, ayuntamientos, autoescuelas y algunas fundaciones.


domingo, 2 de octubre de 2011

Justificación

De acuerdo con el Consejo Nacional para la Prevención de Accidentes (CONAPRA), en un artículo publicado en el periódico electrónico libertad en marzo de 2011, anualmente 24 mil personas mueren y 40 mil quedan con discapacidad permanente tras un siniestro vial. Este consejo señala que los accidentes viales representan el 31 por ciento de las causas de muerte al año en México. Cifras bastante alarmantes siendo los accidentes viales casi la tercera parte de causa de muerte en el país, afirmaciones fundadas en declaraciones que fueron hechas por el director general de Protección y Medicina Preventiva en el Transporte (DGPMPT), José Valente Aguilar Zinser emitidas por el diario rotativo en julio del 2009.

Enfocándonos a Querétaro, datos emitidos por la Asociación Mexicana de Instituciones de Seguros (AMIS), indican que este estado ocupa el lugar número nueve en accidentes de tránsito a nivel nacional, con un registro que ronda los 11 mil siniestros vehiculares al año (cifras del 2008).

Los accidentes automovilísticos no solo traen consigo pérdidas humanas y discapacidades permanentes, si no también considerables pérdidas económicas, en Querétaro de acuerdo a cifras de la AMIS en 2008 los siniestros vehiculares tienen un costo anual de 2 mil 272 millones 824 pesos en pérdidas. Y a nivel nacional los accidentes automovilísticos representan al año el 4% del PIB Nacional; Entre los particulares, el gobierno y las compañías de seguro deben hacer frente a poco más de 160 mil millones de pesos por daños causados por accidentes.

Estadísticas realizadas por la Secretaría de Seguridad Ciudadana (SSC) de Querétaro con fecha del 2009 siendo las más recientes, muestran cual es el número de accidentes que se registran por mes en vías estatales

Se puede observar que ha habido un aumento en el promedio mensual de accidentes del año 2007 a junio del 2009.
A través de la siguiente gráfica podemos concluir que los principales motivos de accidentes automovilísticos son no guardar distancia, velocidad excesiva, imprudencia o intención entre otros
Motivos de accidentes Enero-Junio de 2009 en Querétaro de acuerdo a la SSC


Principales tipos de accidentes Enero-Junio de 2009 en el estado de Querétaro de acuerdo a la SSC.




Y en la clasificación de accidentes por tipo, nos damos cuenta que casi 2 terceras partes entran en la clasificación de accidente por choque.
Analizando las infracciones que se elaboraron de 2008 a 2009 podemos detectar que en su mayoría están enfocadas a vehículos particulares, por lo que concluimos que la realización de un software simulador de conducción es apropiado para aplicarlo a situaciones de vehículos de uso particular.




La revista electrónica libertad el 10 de  marzo del 2011 publico que El titular de la Secretaría de Seguridad Ciudadana (SSC) en Querétaro, Adolfo Vega Montoto, informó que se registran 7 accidentes en promedio por día, principalmente en la Avenida 5 de Febrero y el Boulevard Bernardo Quintana. Además en Querétaro el 52 por ciento de los accidentes automovilísticos registrados participan personas que van de los 16 a los 34 años de edad, en los cuales las principales causas que los provocan son el consumo del alcohol y la falta de distancia entre vehículos. Teniendo los anteriores datos, se delimita que la edad que requiere con mayor urgencia una solución y un material de apoyo para reforzar su técnica de conducción es la edad en la que mayor ocurrencia de accidentes vehiculares hay, siendo esta de los 16 a 34 años.
Si tenemos en cuenta que de acuerdo a las declaraciones y cifras anteriores, en la Avenida 5 de Febrero y el Boulevard Bernardo Quintana ocurren 7 accidentes en promedio por día, podemos concluir que mensualmente se dan aproximadamente 210 accidentes en esas vialidades, y los datos de la SSC nos indican que el promedio de accidentes en vías estatales en 2009 fue de 235 mensuales, podemos inferir que la mayor parte de accidentes se dan en la zona urbana de Querétaro en vías rápidas.
El software Simulador estará orientado a recrear zonas con tendencia a accidentes viales, enfocado a la ciudad de Querétaro y sus vialidades mas conflictivas. La siguiente tabla nos muestra el número de ocurrencias de accidentes anual en el estado de 1997 a 2009


Aquí notamos la cantidad de accidentes vehiculares que se tienen en todo el estado de Querétaro en los años comprendidos de 1997 a 2009, nótese cómo la cantidad de accidentes se ha triplicado en 13 años.
Con la siguiente tabla que contabiliza los accidentes de acuerdo al año y al municipio de ocurrencia en el estado de Querétaro se puede hacer una comparación de cifras en la que se observa claramente que en todos los años más de la mitad de los accidentes totales que se dan en el estado suceden en el municipio de Querétaro, datos obtenidos de pág. Web del INEGI


También podemos detectar que el número de accidentes ha aumentado considerablemente, lo que demanda una atención primordial a solucionar este aspecto.
Notemos que la mayor parte de las causas de los accidentes son producto del factor humano, como lo muestran estadísticas del INEGI, con fecha del 2009, y posteriormente un extracto de los años 2004 – 2009 (cifras nacionales).


Delimitando que en Querétaro las 3 principales causas de accidentes según la SSC (cuya gráfica se incluyó previamente) son no guardar distancia, velocidad excesiva e imprudencia o intención, se buscará realizar una educación vial preventiva y correctiva con el fin de disminuir la causa de factor humano como detonante de accidentes, enfocándose a las causas principales de accidente en Querétaro, esto a través de un simulador de conducción que recreé calles de la zona urbana de Querétaro y simule el flujo que se presenta en la ciudad, así como diferentes escenarios para practicar situaciones diversas como manejo de noche, lluvia, atardecer y selección de zona preferida.