Para estar verdaderamente comprometido, debes considerar atentamente las alternativas y decidir que esto es algo que tú puedes hacer y harás. Cuando te ordenan que debas hacer algo, no se tratará de un compromiso personal. En efecto, cuando a las personas se le ordena hacer cosas, a menudo, se sientes amenazadas y enfadadas, entonces no lo toman como un compromiso personal.
El verdadero acuerdo es la característica más importante de un compromiso personal. Las partes deben ponerse de acuerdo sobre qué hacer, cuando se terminará y qué es lo que se dará a cambio.
Un verdadero compromiso es tanto contractual como personal, y requiere un acuerdo voluntario y explícito entre dos o más partes sobre:
Qué se hará.
Los criterios para determinar que está hecho.
Quién lo hará.
Cuándo se hará.
La retribución que se dará a cambio.
Y quién proporcionará esa retribución.
Responsabilidad para hacer compromisos.
Además, para una mejor gestión y mayor responsabilidad en tus compromisos debes:
Analizar el trabajo antes de aceptar el compromiso: Ambas partes deben establecer el compromiso de buena fe. Tú estás personalmente comprometido y realmente pretendes hacer el trabajo y la otra parte está dispuesta a proporcionarte la evacuada remuneración a cambio. Con frecuencia los compromisos software están basados en algo más que esperanzas. Cuando ambas partes pretenden verdaderamente llevarlo a cabo, con buenas intenciones no se proporciona una base razonable para un buen acuerdo.
Apoyar el compromiso con un plan: Para un trabajo de cualquier tamaño, la forma de hacerse responsable de un compromiso, es hacer en primer lugar un plan para el trabajo. La planificación implica algún esfuerzo, pero no es necesario que sea muy grande. En efecto, si has tenido experiencia en hacer planes formales, puedes normalmente realizarlo.
Documentar el compromiso: Aunque esto puede parecer obvio, no lo es. Hay un mal entendido común de que las personas honestas solo necesitarán unas pocas palabras y un apretón de manos. Pero las palabras a menudo con mal interpretadas. Después de que dos personal se comprometen oralmente, tienen a menudo, problemas de comprometerse por escrito. Esto significa que sus compromisos originales eran superficiales e irreales. El segundo problema tiene que ver sobre qué harán ambas partes si surgen problemas, esta en efecto es la principal razón de muchos contratos. No necesitas un contrato cuando las cosas funcionan de acuerdo a lo planificado, lo necesitas cuando hay problemas.
Si eres incapaz de cumplir el compromiso, díselo inmediatamente a la otra parte e intenta minimizar el impacto sobre esa persona: Cuando hayas aprendido a gestionar tus compromisos, casi siempre los cumplirás. Desdichadamente, aun con los mejores planes, el trabajo ocasionalmente será más complejo de lo que esperabas o puede surgir algo impredecible.
Es importante aprender a gestionar los compromisos para no romperlos u olvidarlos.
Importancia de gestionar compromisos.
La principal razón para gestionar tus compromisos, es para no dejarlos pasar u olvidados. El trabajo de los ingenieros tiene muchos compromisos. Participan en revisiones, escriben informes, asisten a reuniones, hacen correcciones de programas y actualizan módulos de programas. Pueden tener que: Documentar diseños, responder a llamados de los clientes, reunirse con los vendedores o participar en comisiones. Por lo que es necesario aprender a gestionar los compromisos para no romperlos u olvidarlos.
Otra razón para gestionar los compromisos, es la de ayudarte cuando el trabajo que necesites hacer, exceda el tiempo disponible. Si planificas tu trabajo, no deberías excederte del tiempo con frecuencia, pero puede ser un problema ocasional aun cuando hagas los compromisos de forma responsable. En situaciones como esta, identifica rápidamente aquellos compromisos que corren el riesgo de romperse y notifícalo inmediatamente a las otras partes.
Consecuencias de no gestionar los compromisos.
Hasta que no aprendas a gestionar tus compromisos, a menudo te enfrentaras a algunas de las siguientes situaciones desagradables:
El trabajo requerido excede del tiempo disponible: Frecuentemente tendrás más que hacer de lo que puedas realizar. Si no guardas una lista de tus compromisos, puedes obtener nuevos compromisos cuando no deberías hacerlo.
Fallar al enfrentarte a los compromisos: A menudo, los trabajos de desarrollo de software son más complejos de los que se espera. Cuando no tienes una forma ordenada de establecer compromisos, es probable que asumas que el trabajo es más sencillo de lo que realmente es.
Prioridades mal colocadas: cuando se están desbordando las personas a menudo, haden las prioridades basándose en lo que debe hacerse primero, es vez de lo que es más importante. Cuando se tiene que hacer más de lo que realmente puedes hacer, es natural trabajar sobre la siguiente cosa que debes hacer. Desafortunadamente, resolver la amenaza inmediata, es frecuentemente una estrategia errónea. Por lo que aplazar o dejar algunas de las tareas inmediatas, puede ser adecuado para hacer los trabajaos más importantes que vienen después.
Pobre calidad de trabajo: Trabajando presionados, los ingenieros del software, a menudo, sienten la presión para hacer recortes. Es cuando los descuidos y errores tontos son más probables, y cuando la atención y la calidad es más necesaria. Cuando el tiempo se reduce, los ingenieros deberían tener un cuidado especial para evitar errores. Desafortunadamente, la experiencia demuestra que son en estas circunstancias cuando los ingenieros y directores, probablemente, dedican menos tiempo a hacer revisiones, inspecciones o pruebas completas.
Perdida de confianza: Si frecuentemente faltas a tu compromiso la gente lo notará. Sabrán que cuando te comprometes a algo, a menudo, no cumples tu palabra. Tal reputación es difícil de reparar y afectará a tus notas, tu prestigio en el trabajo, tu sueldo e incluso a tu seguridad en el puesto de trabajo.
Perdida de respeto a tus opiniones: Cuando las personas no confían en lo que tú dices, no es probable que te pidan opinión y es más seguro que te insistan en que tú trabajes con programaciones que no sean razonables.
El activo más importante que puede tener un ingeniero del software es su reputación para cumplir los compromisos. Para que las personas confíen en tu palabra, necesitas exponer tu plan de trabajo y entonces hacer lo que dices.
La forma de gestionar compromisos.
Para gestionar adecuadamente los compromisos, comienza haciendo una lista de los compromisos que tienes. Observa la fecha de cada compromiso y la cantidad de tiempo que necesitaras.
Para gestionar los compromisos en ingeniería del software, es importante recordar varios hechos de la vida del negocio del software:
Si te estás retrasando, tu planificación continuara retrasándose a no ser que hagas algo diferente.
Intentarlo más duramente no ayudará. Recuerda que ya estuviste intentándolo con bastante esfuerzo.
Si no sabes exactamente donde estás en el proyecto y cuanto trabajo te queda, sin lugar a dudas estas en un problema.
Cuando tu éxito dependa de la suerte seguramente no la tendrás.
Cuando tus estimaciones están equivocadas, casi siempre son muy bajas.
Casi todos los cambios implican mas trabajo.
Es importante trabajar enérgicamente para cumplir los compromisos, pero si no, puedes terminar el trabajo con unas pocas horas de esfuerzo extra, enfréntrate al problema y trátalo con responsabilidad.
La gestión de las programaciones:
Haces programaciones con el objetivo de cumplir con tus compromisos. Una programación es necesaria cuando tienes varios compromisos de trabajo al mismo tiempo. Con pequeños proyectos o tareas, puedes acabar una tarea antes de comenzar la siguiente. Esta estrategia es factible para unas pocas tareas, cuando hay tiempo suficiente para completarlas todas, y cuando son cortas y sencillas para acabarlas fácilmente. Cuando los proyectos sean cada vez más grandes, será más importante cuidar la programación de tu tiempo. Los ingenieros de alguna manera pueden encajar muchas de sus tareas en sus programaciones diarias sin olvidar o menospreciar cualquiera de ellas, por ello, debes alternar las tareas, haciendo una durante un tiempo y pasando entonces a la siguiente.
El diagrama de Gantt.
Una programación es una lista ordenada por tiempos de eventos planificados, generalmente presenta un formato denominado como Diagrama de Gantt (Anexo 9) y tiene los siguientes elementos claves:
En la parte superior del diagrama están las fechas. Dependiendo del grado de detalle deseado, la línea de tiempos, se puede dividir en días, semanas, meses o años. También puede estar en horas si lo deseas.
La columna ID contiene un número de identificación para cada tarea.
En la columna Nombre, están los nombres de las tareas a realizar. Están normalmente enumeradas en el orden en la cual esperas hacerlas.
En el cuerpo del diagrama, las barras muestran las fechas previstas de comienzo y fin para cada tarea.
En la parte inferior está el nombre del proyecto, el autor de la programación y la fecha en que se hizo.
Varios puntos de control se muestran mediante pequeños óvalos (ID´s 2, 5, 7, 9 y 14
¿Cómo hacer una programación de un proyecto?
Para un proyecto de cualquier tamaño, el primer paso para hacer una programación es analizar el trabajo con bastante detalle para identificar las distintas tareas que lo componen. A continuación, estimar el tamaño para cada alguna de estas pequeñas tareas y determinar la cantidad de trabajo que probablemente necesitarán. Finalmente, registra cada tarea en el Diagrama de Gantt con una barra, para mostrar cuando comienza y acaba.
Cuando elabores programaciones para trabajar que implican a varias personas, necesitas seguir algunos pasos adicionales:
Asegúrate que cada individuo conozca las tareas que tiene que hacer.
Obtén un compromiso de fecha para cada una de estas tareas.
Identifica las interdependencias entre las tareas. ¿Qué información necesita cada persona antes, para ser capaz de realizar el trabajo y de quién le tiene que llegar esa información?
Documenta cada una de estas interdependencias.
Revisa la programación propuesta y las interdependencias con todas las personas implicadas, asegúrate de que no haya conflictos, desacuerdos o malentendido.
Revisa la programación para asegurarte de que cubra todas las tareas necesarias para completar todo el trabajo.
Aunque, necesitarás más pasos para elaborar programaciones en grandes proyectos de software, estos principios básicos te ayudarán a hacer planes para tu trabajo personal o para proyectos con equipos pequeños que impliquen a tus compañeros de clase o colegas.
Puntos de control.
En la planificación de cualquier proyecto, por pequeño que sea, es importante dividir el trabajo en varias partes que pueden ser estimadas y planificadas. Cada una de estas partes se puede tratar como elemento de la programación. Es decir, cuando se completa cada parte, se ha realizado un determinado grado de progreso. Estos puntos de control que son medibles, se llamar puntos de control o hitos. Los hitos son una parte importante de la planificación y gestión de proyectos.
Un hito es un punto que, objetivamente, se puede identificar en un proyecto. Un ejemplo, sería la terminación de alguna actividad específica del proyecto o una acción importante. Cuando un plan incluye varios hitos, cada uno con una fecha de terminación planificada, puedes ver fácilmente si estás dentro del programa o estás retrasándote.
Para ser útiles, los hitos deben ser claros y no ambiguos. Es decir, un punto de control debe ser una acción específica que se hace o no se hace. Algunos ejemplos de puntos de control son:
Has terminado y entregado un trabajo trimestral.
Has elaborado y documentado el plan para escribir un programa, utilizando un formato normalizado de planificación.
Has revisado el plan de desarrollo con tu profesor y has hecho las modificaciones sugeridas.
Has completado y documentado un diseño de un programa, utilizando un formato de diseño específico.
Has impactado, compilado y corregido un programa hasta que se compile sin errores.
Hay muchos ejemplos de puntos de control concretos que son adecuados para los propósitos de la planificación. El requisito clave, es que la terminación de cada punto de control se puede verificar objetivamente.
Las informaciones generales que no conducen a un criterio verificable no puede utilizarse como puntos de control:
Algunos ejemplos de puntos de control no adecuados son:
Has hecho un plan para escribir un programa.
Has diseñado un programa.
Se ha completado el 90% de la planificación.
Sugerencias para el establecimiento de puntos de control.
En la realización de un plan, establecer puntos de control para cualquier proyecto implica unas pacos horas de trabajo. Intenta identificar varios puntos de control durante una semana. Por ejemplo, si un trabajo se supone dos semanas, establece al menos dos puntos de control y preferiblemente 4 o 5. Escoge un número de punto de control coherente con la cantidad de trabajo requerido. Más de un punto de control para una tarea que requiere de 3 a 4 horas sería excesivo. Para tareas de menos de cinco horas de duración, gestiona la tarea como u a unidad completa. Con estas condiciones, la gestión de proyecto reduce el tiempo de gestión. Conforme vayas dedicando las horas necesarias, irás aproximando el trabajo a lo programado. Deberías, permitir siempre un tiempo reducido de seguridad para cada tarea, para el caso de que te lleve más tiempo del esperado.
Conceptos relacionados con pruebas de software.
Debido a la incapacidad humana de trabajar y comunicarse de forma perfecta en la generación de estos artefactos suelen cometerse errores. Por ejemplo: Que se especifiquen de forma incorrecta los requerimientos funcionales del software, este error si no se corrige a tiempo se arrastraría a las actividades posteriores: Análisis,
diseño y programación. No detectar y eliminar este error traería como consecuencia la obtención de un producto que no es el que necesita realmente el usuario. Vale señalar que en el análisis, el diseño y la programación pueden aparecer errores nuevos. Por ello, es necesario que el proceso de desarrollo esté acompañado por una actividad que garantice la calidad del producto, esta es la prueba de software.
La creciente inclusión del software como une elemento más de muchos sistemas y la importancia de los costos asociados a un fallo del mismo, ha motivado la creación de pruebas más minuciosas y bien planificadas. No es raro que una organización invierta el 40% del esfuerzo de un proyecto en la prueba. En casos extremos, por ejemplo, el control del tráfico aéreo y de reactores nucleares, puede gastarse de 3 a 5 veces más que en el resto de los pasos juntos.
¿Qué es una prueba?
La prueba del software es un conjunto de actividades que se lleva a cabo sistemáticamente, que puede planificarse por adelantado y ejecutar una vez construido el código para la revisión final de las especificaciones, del diseño y de la codificación del software.
Roles asociados.
Aunque los usuarios finales y otros trabajadores pueden realizar las pruebas de un software, existen algunos roles que se asocian directamente con las pruebas como son:
1. Diseñador de prueba: Planifican, diseñan y evalúan los resultados de la prueba.
2. Ingeniero de componentes: Responsables de la elaboración de los componentes de prueba para los procedimientos que puedan ser automatizados.
3. Ingeniero de pruebas de integración: Realizan las pruebas de integración.
4. Ingeniero de pruebas de sistema: Realizan las pruebas del sistema.
Objetivos de las Pruebas de software.
1 La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.
2. un buen caso de prueba es aquel que tuene una alta probabilidad de mostrar un error no descubierto hasta entonces
3. Una pruebe tiene éxito si descubre un error no detectado hasta entonces
Mitos alrededor de las pruebas:
Si fuéramos buenos programadores, nos concentráramos, empleáramos lenguajes apropiados, no habría errores que buscar. Es decir, existen errores porque somos malos en lo que hacemos. Por la tanto una prueba es un reconocimiento de nuestros fallos y es exitosa si no descubre errores.
El que desarrolla el software no debe entrar en el proceso de prueba.
El software debe ser "puesto a salvo" de extraños que puedan probarlo despiadadamente.
Los encargados de la prueba solo aparecen en el proyecto cuando comienzan las etapas de prueba.
Rompiendo los mitos:
Las pruebas se realizan para garantizar la calidad del software, descubriendo errores. La prueba es exitosa si saca sistemáticamente a la luz diferentes tipos de errores empleando la menor cantidad de tiempo y esfuerzo.
Glen Myers establece una serie de reglas que sirven como objetivos de la prueba:
La prueba es un proceso de ejecución de un programa con la intención de descubrir errores.
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
Una prueba tiene éxito si descubre un error no detectado hasta entonces.
La prueba no puede asegurar la ausencia de defectos; solo puede demostrar que existen defectos en el software.
Cada una de las personas que desarrolla alguna actividad debe probar el artefacto generado en ella, aunque exista un equipo independiente de prueba.
Debe garantizarse la calidad desde las primeras fases de desarrollo.
Los usuarios finales pueden probar el software.
Clasificación de los tipos de pruebas.
- Prueba de validación:
Tras la culminación de algunas pruebas realizadas y estando el software completamente ensamblado como un paquete y ya se hallan encontrado y corregido errores en la interfaz entonces puede comenzar una serie final de pruebas del software:
La prueba de validación
Se puede definir de muchas formas pero la más simple es que la validación se consigue cuando el software funciona de acuerdo con las expectativas del cliente. Estas expectativas están definidas como Especificación de requisitos del software la cual contiene una sección denominada criterios de validación. La información contenida en esta sección es la base de esta prueba. Como en otras etapas de prueba, la validación permite descubrir errores, pero su enfoque está en el nivel de requisitos o sea aspectos que son necesarios para el usuario final.
Dicha prueba se lleva a cabo mediante una serie de pruebas de cajas negras que demuestran que se cumplen todos los requisitos.
Procedimiento:
Un plan de pruebas traza la clase de pruebas que se han de llevar a cabo
Un procedimiento de pruebas define los casos de prueba específicos para descubrir los errores de acuerdo con los requisitos
Entonces se verifica que se alcancen todos los requisitos funcionales y los de rendimiento, que la documentación sea correcta y otros requisitos como la portabilidad, la compatibilidad, la recuperación de errores y la facilidad de mantenimiento del software.
Posibles resultados alcanzados:
1-Las características de funcionamiento o rendimiento están de acuerdo con las especificaciones y son aceptables
2- Se descubre una desviación de las especificaciones y se crea una lista de deficiencias. Las desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden corregir antes de la terminación planificada. A menudo es necesario negociar con el cliente un método para resolver las deficiencias.
Pruebas de interfaces gráficas de usuarios (IGUs).
Las interfaces graficas de usuarios (IGUs) presentan interesantes desafíos para los ingenieros del software debido a los componentes reutilizables provistos como parte de los entornos de desarrollo de las IGU, la creación la creación de la interfaz de usuario se ha convertido en menos costosa en tiempo y mas exacta. Al mismo tiempo, la complejidad de las IGUs ha aumentado originando mas dificultad en al diseño y ejecución de los casos de pruebas.
Técnicas de pruebas.
1-Pruebas de caja blanca
La prueba de caja blanca se basa en el diseño de Casos de Prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener
Casos de Prueba que:
1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada modulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.
Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran por ciento el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.
2-Pruebas de caja negra:
La prueba de Caja Negra se centra principalmente en los requisitos funcionales del software. Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. En ellas se ignora la estructura de control, concentrándose en los requisitos funcionales del sistema y ejercitándolos.
La prueba de Caja Negra no es una alternativa a las técnicas de prueba de la Caja Blanca, sino un enfoque complementario que intenta descubrir diferentes tipos de errores a los encontrados en los métodos de la Caja Blanca.
Cualquier producto de ingeniería puede ser probado mediante una de estas técnicas:
1. Conociendo la funcionalidad específica para la cual fue diseñado el producto, se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa. Pruebas de caja negra. 2. Conociendo el funcionamiento del producto se pueden desarrollar pruebas que aseguren que "todas las piezas encajen", o sea, que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada. Pruebas de caja blanca.
Introducción a las Pruebas unitarias.
Una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.
La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.
Características:
Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:
Automatizable: No debería requerirse una intervención manual. Esto es especialmente útil para integración continua.
Completas: Deben cubrir la mayor cantidad de código.
Repetibles o Reutilizables: No se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.
Independientes: La ejecución de una prueba no debe afectar a la ejecución de otra.
Profesionales: Las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.
Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.
Ventajas:
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas:
Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización, puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores).
Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.
Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos.
Los errores están más acotados y son más fáciles de localizar: Dado que tenemos pruebas unitarias que pueden desenmascararlos.
Limitaciones:
Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software.
Introducción a la ingeniería de requisitos.
En la ingeniería de sistemas y la ingeniería de software la Ingeniería de requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
En la ingeniería de requisitos principalmente se identifican dos aspectos muy importantes, el primero que es el propósito del sistema que se va a desarrollar y el segundo, el contexto en el que será usado.
La Ingeniería de Requerimientos en si cumple un papel primordial en el proceso de construcción y producción de un software, es decir que, estará basado en función de las necesidades planteadas por los clientes en un nivel muy general, donde se descubre, documenta, analiza y se define los servicios o componentes de lo que se desea producir, además de las restricciones que tendrá el producto o software. Su principal tarea consiste en la definición del proceso a seguir en la construcción de un software, y de facilitar la comprensión de lo que el cliente requiera. La obtención correcta de los requerimientos puede llegar a describir con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento de un sistema.
De tal manera que, basarse en la extracción de requisitos y sobre todo que sean correctos, lo único que se pretende en la construcción no solo de grandes sistemas software sino también simples, es la de minimizar los problemas relacionados al desarrollo de sistemas, claro está en proporción a la realidad de cada proyecto, con lo que se logra reducción de tiempo en la construcción, reducción de errores, y los más importante no solo para el cliente sino también para el desarrollador, evita gastar dinero más de lo planeado y determinado para el proyecto.
Procedimientos para el levantamiento de requisitos o necesidades de una aplicación informática.
Desde un punto de vista conceptual, las actividades son de 5 clases.
Obtener requisitos: A través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
Analizar requisitos: Detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
Documentar requisitos: Igual que todas las etapas, los requisitos deben estar debidamente documentados.
Verificar los requisitos: Consiste en comprobar el correcto funcionamiento de un requisito en la aplicación
Validar los requisitos: Comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.
Técnicas para el levantamiento de requisitos o necesidades.
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.
Entrevistas:
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallas. Las entrevistas pueden ser personales o grupales.
Talleres:
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.
Forma de contrato:
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.
Objetivos medibles:
Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.
Prototipos:
Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.
Casos de uso:
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.
A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
Los diseñadores tienden a reutilizar el código de los prototipos por temor a "perder el tiempo" al comenzar otra vez.
Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.
Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.
El guión.
Para la elaboración de un producto informático que realmente satisfaga las necesidades de los usuarios se requiere del cumplimiento de determinados principios entre los cuales se encuentra el que justamente resuelva un problema de la realidad. Un paso importante de este proceso es la realización de un trabajo de mesa donde un equipo compuesto por guionistas, diseñadores, psicólogos, programadores y también pedagogos (para el caso del software educativo) trabajen en colaboración para que el producto tenga la calidad requerida. La documentación fundamental la constituye el guión, que no es más que la descripción detallada de una obra.
Estructura del guión. Roles asociados.
Nombre.
Planteamiento del objetivo.
Tipo de software.
Contenido.
Método.
Medio.
Evaluación.
Diagrama de flujo.
Diseño de la interfaz.
Diagrama de la ayuda.
Soporte técnico.
Bibliografía.
Descripción de los pasos.
Nombre:
Un estudio de algunos nombres comerciales de productos de software muestra que en ellos está presente muchas veces un juego de palabras (LANTASTIC, FONTASY, SatisFAXtion) o una palabra corta que identifica en esencia el producto.
Algunas empresas de software han aplicado (y aplican) reglas más o menos estrictas al escoger el nombre de un producto. Por ejemplo, cuando Charles H. Moore creó el FORTH, pensó originalmente ponerle FOURTH (cuarto), pero IBM no aceptaba nombres de más de 5 letras. Esta tendencia, es la que se ha mantenido, impuesta por intereses comerciales y en nada han tenido que ver los propósitos pedagógicos, no obstante sin que ello sea una regla rígida se recomienda:
Usar nombres simples (cortos).
Expresar en síntesis el área educativa que contempla.
No se debe menospreciar la importancia que pueda tener el nombre del producto, y no dejar para el final, qué nombre se le dará. No se pretende exagerar la importancia de esto, pero sí hay que decir que un nombre corto y que sugiera el tema siempre tiene más posibilidad de ser fijado por los estudiantes.
Objetivo:
Se recomienda que aparezca en el software de manera explícita desde un inicio para garantizar que sea un elemento orientador. Debe ser formulado con toda claridad y precisión del conocimiento asociado con él. Su alcance estará en correspondencia con la función didáctica y con las habilidades profesionales. De ser posible este debe ser presentado en forma de texto y en una locución. Generalmente esto conviene presentarlo en la primera pantalla de ayuda y no como una presentación a la cual siempre se acceda al comenzar el programa, pues resultaría aburrido encontrárselo siempre a cada paso.
Tipo de software:
Tanto el guionista como el programador deben conocer el tipo de software que será diseñado a fin de tener en cuenta sus particularidades. De igual manera debe declararse en las indicaciones. Esto permite fortalecer la cultura informática de los alumnos asociada a este elemento.
Actualmente, la Informática como medio de enseñanza, cuenta con una amplia gama de programas que pueden ser empleados con múltiples enfoques, con propósitos específicos.
Estas características del software, posibilitan la clasificación de los mismos en dependencia de su función. Es usual encontrar en la literatura las clasificaciones siguientes:
Tutoriales: Constituye un programa especializado en la enseñanza de un dominio especifico del conocimiento, apoyándose para ello en el diálogo con el estudiante, en la consolidación de un conjunto de aspectos esenciales que por su complejidad requieren de un nivel de abstracción que permita la representación adecuada del conocimiento.
Entrenadores: Diseñado con el propósito de contribuir al desarrollo de una determinada habilidad, intelectual, manual, o motora, en el estudiante que lo utiliza por lo que profundizan en las dos fases finales del aprendizaje: Aplicación y retroalimentación. Se parte de que los estudiantes cuentan con los conceptos y destrezas que van a practicar.
Repasadores: Diseñado con el propósito de contribuir a repasar determinados contenidos estudiados con anterioridad.
Evaluadores: Para producir propiamente las evaluaciones y para aplicarlas.
Simuladores: Se interactúa con un micro mundo en forma semejante a la que se tendría en una situación real para lograr el conocimiento. Aunque en la práctica este micro mundo puede resultar una simplificación del mundo real, el alumno resuelve problemas, aprende procedimientos, llega a entender las características de un fenómeno o aprende que acciones debe tomar en diferentes circunstancias.
Libros electrónicos: Los libros electrónicos constituyen aplicaciones que hoy se están desarrollando con vistas a múltiples propósitos, y en particular, para el apoyo del proceso e enseñanza – aprendizaje.
Características:
• Navegación a través del contenido.
• Selección de acuerdo a sus necesidades.
• Nivel de interacción que le facilite el aprendizaje.
• Respuesta del sistema ante determinadas acciones.
• Medio ambiente agradable de trabajar.
• Información precisa y concreta.
Juegos Instructivos: Permiten aprender jugando. Proporcionan un medio ambiente para facilitar el aprendizaje, donde el estudiante encuentra un reto entretenido con un componente instructivo.
Tipos de juegos:
• Aventuras.
• Tableros.
• Combate.
• Psicomotores y acertijos.
• Lógicos y patrones.
• Roles.
• Palabra
Sistema experto: Constituyen una parte materializada de la inteligencia artificial. Representa las características asociadas con la inteligencia humana, entendimiento del lenguaje natural, aprendizaje, razonamiento, resolución de problemas, etc.
Hiperentorno de aprendizaje: El medio didáctico "Software Educativo a tu alcance", elaborado por el Departamento de Software Educativo del Ministerio de Educación, aborda el concepto de Hiperentorno de Aprendizaje, definiendo que es un "sistema informático basado en tecnología hipermedia que contiene una mezcla o elementos representativos de diversas tipologías de software educativo, tutorial, entrenador, juego didáctico, simulador, entre otros".
En realidad no debe pensarse que son excluyentes entre sí, por el contrario, para responder a una estrategia pedagógica determinada, puede confeccionarse un software que integre características de varios de ellos como esta última tipología, el Hiperentorno de Aprendizaje.
Contenido:
Considerar en la elaboración del contenido los siguientes aspectos:
Concepción pedagógica, ideológica y política.
Nivel científico.
Actualidad.
Vocabulario.
Definir los contenidos que respondan a la profesionalización, fundamentalización, interdisciplinariedad y sistematización.
Estructurarlo de acuerdo a los niveles de asimilación y al tiempo.
Secuencia lógica que permita mantener el discurso, la dramatización y el mensaje.
Método:
En la confección del guión el método que se utilice también se comporta como la vía para alcanzar el objetivo y con independencia de las clasificaciones de métodos existentes recomendamos que el estudiante transite en su interacción con el software por métodos reproductivos, productivos y hasta un cierto nivel de creatividad. Esto debe propiciarse al estudiante:
1. Presentándole situaciones problémicas y estudio de casos reales o simulados de la profesión con distintos grados de complejidad que le permitan el tránsito por los diferentes niveles de asimilación.
2. Simulaciones de procesos: Que le permitan reflexionar acerca de las causas y efectos obtenidos a fin de lograr una sistematización del conocimiento y el desarrollo de habilidades profesionales.
3. Hipertextos e hipermedias: Que posibiliten la integración y síntesis de la información y a la vez que favorezca la construcción de su conocimiento con flexibilidad a través de su navegación por el mismo.
Medio:
Los recursos multimedia serán los catalizadores del proceso de aprendizaje. Ellos permiten incrementar los canales de comunicación, son encargados de favorecer la redundancia en el mensaje. En este aspecto se definirán los recursos a utilizar como pueden ser:
1. Figuras que ilustren los procesos o permitan crear escenarios de la actividad profesional que se trate.
2. Textos asociados al contenido.
3. Fotografías o imágenes que ilustren el objeto de estudio o los elementos asociados más importantes.
4. Grabación sonora que refuerce la información visual.
5. Vídeos asociados a los procesos fundamentales de la actividad profesional objeto de estudio.
6. Animaciones que impriman dramatismo al contenido que se presenta.
Evaluación:
Este es el proceso donde se comprueba y valora todo lo aprendido por el alumno. Incluye tanto el aspecto cognitivo como el afectivo. Por lo cual en la ETP debe tenerse en cuenta:
1. Aleatoriedad de las preguntas.
2. Presentar disyuntivas de carácter ético-profesional.
3. Evaluar lo más importante del contenido y aquello que el alumno no debe dejar de saber.
4. Representar los resultados alcanzados.
5. Obligar a la retroalimentación.
6. Aplicar instrumentos de autoevaluación (test), en el tránsito de un módulo de contenido a otro.
7. Estimular los logros parciales y finales alcanzados.
Tanto en la retroalimentación como en la explicación debe utilizarse un lenguaje coloquial, de respeto que favorezca la interacción y autoestima del estudiante.
Diagrama de flujo:
Se refiere a la secuencia de escenas (textual o gráfica) del software. Para cada pantalla se definirá el orden y posición en que aparecerán los diferentes elementos: Figuras, vídeos, animaciones, efectos sonoros y demás elementos que la integrarán. Podemos describir la arquitectura del sistema en mayor grado de detalle a base de expandir el diagrama de contexto en una jerarquía de diagramas de flujo.
Cada subsistema del diagrama de contexto puede dar lugar a un diagrama de flujo, donde se describirá el sistema en mayor detalle, descomponiéndolo en nuevos subsistemas relacionados mediante flujos de información. Cada subsistema ocupa una región del diagrama dependiendo de cuál sea su función (adquisición de datos, salida de datos, interfaz, etc.).
Un detalle importante es que debe mantenerse la consistencia entre los diagramas de distinto nivel. Al expandir un determinado subsistema en un diagrama de flujo, los flujos de información que conectan dicho subsistema con otros o con agentes externos, deben figurar también (coincidiendo en número, sentido y nombre) en el diagrama de flujo resultado de dicha expansión. Estos flujos de información, tendrán un extremo libre, el que los conectaba con subsistemas que quedan fuera del ámbito del nuevo diagrama de flujo.
Diseño de la interfaz:
En este paso se concreta lo fundamental del guión. Consiste en describir cada pantalla con todos los elementos que la constituyen, es decir, contenido, medios y métodos.
Se recomienda que se describan una sola vez los botones de servicio (imprimir,) y los botones para la navegación (inicio, anterior, siguiente, salir) que va a tener la aplicación, haciendo las aclaraciones pertinentes en cuanto a las pantallas en que no estén presentes todos, como puede ser la primera que reflejará la presentación del software y donde no tienen que estar todos los botones.
Diagrama de la ayuda:
Por la importancia que representa la ayuda de un software para lograr una efectiva comunicación y navegación por él se requiere considerar: El flujo de la información que presenta, su contenido el que debe ser claro y sintético, así como la uniformidad del diseño.
Se precisa tener en cuenta tanto; La ayuda para navegar por el software como la ayuda asociada al contenido.
Es necesario además considerar para cada momento las teclas o botones disponibles y presentarla siempre en una misma área de la pantalla.
Como se ha planteado anteriormente, muchas veces las necesarias especificaciones para el sistema de ayuda quedan poco claras, teniéndose previsto solamente que haya "algún tipo de ayuda" disponible. Este es un aspecto que requiere un análisis cuidadoso y una definición muy clara de qué se quiere lograr.
Es necesario hacer, dentro del sistema de ayuda previsto, una distinción entre la Ayuda de navegación por el sistema y la Ayuda sobre el tema de estudio al que se dedica el software. La Ayuda de navegación por el sistema es la información sobre cómo se maneja el propio software, cómo se escogen sus opciones, cómo se puede recibir ayuda en un momento determinado, etc. Este tipo de ayuda (y la información que proporciona) es independiente del tema tratado. La Ayuda de navegación por el sistema siempre existe en alguna forma, más o menos explícita, aunque en ocasiones se reduzca a la simple información presentada en pantalla diciendo que: "tal tecla hace tal cosa".
Por supuesto que la estructura del sistema de ayuda está estrechamente relacionada con el tipo de software y los objetivos a lograrse con él. En programas del tipo "tutor inteligente" se ha previsto y planteado siempre la ayuda mediante "sugerencias" o "pistas" que ayuden al estudiante a lograr un enfoque adecuado del problema a resolver. Por supuesto la ayuda debería prever (en este caso) que el estudiante pueda acceder a la posible respuesta si definitivamente no lograr asimilar las sugerencias. Podría pensarse en la posibilidad de que el sistema de Ayuda sobre el tema (no la Ayuda de Navegación del Software) se dividiera en (por ejemplo) "Info" y "Sugerencia" en el caso de los programas tutores.
Si se trata de un juego, uno de los factores que podrían afectar la puntuación obtenida podría ser la cantidad de veces que el alumno tuvo que recurrir a la ayuda. Ello podría constituir un acicate para lograr que el alumno "piense con su propia cabeza".
Soporte técnico:
Indicar el tipo de equipamiento con que se cuenta a fin de que el programador conozca los recursos que puede utilizar y sobre qué plataforma podrá "correr" el programa.
Bibliografía:
Se recomienda hacer una ficha bibliográfica de los materiales consultados y que sirvieron de base para conformar el contenido del software y presentarla como una opción del mismo con la finalidad de que el estudiante interesado tenga los referentes para poder profundizar sobre la temática, objeto de estudio.
Roles asociados:
Autor de Contenido:
Confecciona el proyecto de MultiMedia.
Crea o define los contenidos textuales que va a tener la MultiMedia.
Participa en la búsqueda y selección de la información audiovisual.
Confecciona el guión del contenido.
Guionista:
Participa en la confección del proyecto de MM de ser necesario.
Participa en la definición de las pautas funcionales y navegacionales de la MultiMedia de ser necesario.
Define y concreta la conceptualización del esquema de navegación de la MultiMedia.
Participa en la organización y etiquetado de la información audiovisual.
Define la secuencia de pantallas.
Participa en la confección del guión del contenido.
Confecciona el guión técnico de la MultiMedia.
Editor:
Garantiza la corrección y ajuste con las normas editoriales de todo contenido textual que aparezca en la MultiMedia.
Algunos estándares para el diseño de interfaz y de navegación.
Debe tenerse especial cuidado al concebir la interfaz que tendrá el software educativo. Entendemos por interfaz el componente del software que posibilita la interacción y el intercambio de información usuario – aplicación. Debe concebirse de modo que sea lo más amigable posible, con un fundamento educativo muy ajustado al universo estudiantil para el que está concebido.
Una interfaz amigable se caracteriza por:
Facilidad de navegación por el software.
Creatividad en el diseño.
Lo cual propicia la actividad intelectual del estudiante, alivia la carga de tareas repetitivas y se logra mayor efectividad en el uso del tiempo disponible para el tema en sí.
La tendencia actual es a favorecer las interfaces gráficas, ya que permiten una interacción más intuitiva con el software y aumentan las posibilidades de animación.
Si bien es verdad que normalmente se piensa en "pantallas", ello no debe abarcar solamente lo que se "ve", sino todo el ambiente de trabajo. "Escenario" quizás sea un término más adecuado, pues en efecto se debe tener en cuenta también el posible fondo musical (y sonidos de evento), animaciones colaterales y las posibilidades de interacción con el software.
Aquí se presentan dos posibilidades:
La interfaz es la misma durante todo el tiempo de utilización del software
La interfaz varía en dependencia de la opción que se esté desarrollando, del nivel de complejidad con que se traten los contenidos en cada momento, etc.
La primera posibilidad caracteriza a los software sencillos o de objetivos más limitados en su alcance.
La interacción con el software a través de las ventanas de entrada de información se facilita y es más intuitiva cuando se aplica el mismo color a información del mismo tipo.
Del mismo modo la identificación de diferentes tipos de información se facilita si se usan diferentes colores.
Asimismo, debe ocurrir algún suceso durante el tiempo que el estudiante dedica a meditar su respuesta, que no es solo la implementación de un contador para controlar el tiempo.
Hay algunos aspectos muy importantes a tener en cuenta cuando se piensa en la interfaz de trabajo:
¿Cómo trabajar con los gráficos?
¿Cómo trabajar los textos?
¿Cómo usar el color?
El aspecto animación.
Uso del sonido
Vídeos
Veamos cada una en detalle.
¿Cómo trabajar con los gráficos? En ocasiones se presenta una pantalla de gráficos donde no es fácil determinar qué objetivo se persigue: ¿Apoya el gráfico a la explicación, o la explicación apoya al gráfico? Esto es algo que debe quedar bien definido. Un gráfico complicado debiera siempre construirse por partes, solapando paso a paso las líneas en pantalla, aprovechando la mayor cantidad de elementos de animación posibles. Otra opción importante es que el alumno pueda decidir cuánto tiempo permanecerá el gráfico (en general, cualquier información relevante) en pantalla.
¿Cómo trabajar los textos? Hay que hacer una rigurosa selección de los textos que aparecerán en cada pantalla, deben ser los mínimos imprescindibles que contengan a la vez la mayor cantidad de información. La forma de presentar estos textos debe cumplir una serie de características, como son:
El área de textos no debe exceder de un tercio de la pantalla.
El corrimiento (scrolling) del texto hacia arriba debe ser evitado, pues desvía la atención y hace perder el hilo de lo que se está manejando. Además, en muchas ocasiones se hará entonces necesario retroceder para volver a leer un párrafo que no se entendió bien. Hacemos la aclaración de que esto se refiere exclusivamente a software educativo; nada se opone a un texto largo con tales características en otro tipo de documento (por ejemplo, un README.TXT).
Si se usan plecas, no conviene poner más de 6 simultáneamente (y no conviene tampoco "arrastrar" información de una pantalla a otra, de modo que la cantidad total de plecas no debe pasar de ahí) y cada una de ellas de dos líneas como máximo.
Se debe usar pocas fuentes (fonts) de letras. El puntaje y el estilo pueden usarse para indicar jerarquía de términos y conceptos.
La indentación es de gran ayuda para distribuir la información, pues contribuye a destacar lo esencial. Un texto aislado en el centro de la pantalla puede resaltar una conclusión o característica fundamental.
Se recomienda el doble espaciado, por contribuir a la mayor legibilidad del texto.
Escriba el texto de forma normal con minúsculas y limitar el uso de mayúsculas; esto favorece la legibilidad del texto.
El Hipertexto es una forma no secuencial de presentar y acceder a información relacionada, es decir enlaza información vinculada conceptualmente. Se considera una estructura análoga a un grafo o red semántica en la cual los nodos representan porciones discretas de información y las aristas los enlaces o relaciones entre las anteriores. El Hipertexto es recomendable cuando la información buscada exija de conceptos previos, resultados a considerar, nuevos artículos sobre el tema en cuestión o cuando la información puesta en juego sea mucha. Una gran ventaja del Hipertexto es el alto nivel de interacción que se obtiene, y que el enlace es instantáneo. El Hipertexto puede ser una solución válida para resolver los problemas de guión causados por los textos largos. Al incluirse gráficos, sonido y otros medios en el Hipertexto surge el concepto de hipermedia. Tanto el Hipertexto como la hipermedia dotan al estudiante de una mayor flexibilidad y control individual en el aprendizaje sobre la materia objeto de estudio.
¿Cómo usar el color? Aunque este aspecto no necesita ser detallado en el Guión Multimedia, sino que corresponde al diseñador, es bueno que se tengan en cuenta las siguientes consideraciones:
El color en el texto debiera funcionar solamente como aspecto redundante y no como parte fundamental de la información, es decir, para enfatizar la idea principal, el concepto, etc.
Otro recurso es el parpadeo (blinking) de palabras en el texto. Usarse con extrema mesura y dejarse solo para lo que requiera una atención inmediata (por ejemplo, un mensaje urgente).
No es aconsejable el uso de más de 4 colores simultáneamente.
Tener siempre en cuenta el orden de receptividad por el ojo humano. La receptividad de los colores es, por orden:
Rojo.
Naranja.
Amarillo.
Verde.
Azul.
Magenta o violeta
También muy importantes son las combinaciones de colores. Las más visibles son, por orden:
Negro/Amarillo.
Rojo/Blanco.
Azul fuerte/blanco.
Negro/Blanco.
Blanco/Negro.
Rojo/Verde y viceversa.
Las combinaciones más visibles son aquellas que tienen el fondo más claro y el texto más oscuro. Según una investigación realizada por especialistas españoles, el fondo verde es el que menos problemas, debidos a la adaptación cromática, introduce en la percepción del color, y los fondos azules y rojos introducen dificultades selectivas de discriminación del color en algunas zonas del espectro. Ellos señalan que sus conclusiones son especialmente aplicables a la informática educativa cuando utiliza colores en mapas.
El aspecto animación: La animación en un software educativo le da vida, y es un elemento que incita al alumno a seguir utilizándolo. Un ejemplo interesante de software sencillo pero atrayente por los elementos de animación que armoniza es el popularmente llamado "Mono" creado por la empresa japonesa KONAMI para los teclados inteligentes de 8 bits. Sin grandes pretensiones, anima a los niños a seguir jugando (realizando operaciones aritméticas) por lo atractivo de su animación. Es conveniente cambiar de plano en la presentación de vez en cuando, modificar el punto de vista. También es adecuado introducir elementos nuevos. Recuerde que debe estar ocurriendo algo mientras el estudiante medita la respuesta. Otro aspecto que cae dentro de la animación es la existencia de "zonas calientes" dentro de la pantalla, zonas donde un clic del ratón activa una secuencia de animación de algún elemento. Ello es un recurso muy útil en el caso de niños, pues incita a explorar las posibilidades del software, reduciendo el margen para el aburrimiento o el cansancio. Debe tratarse de que esta secuencia no sea siempre la misma, buscándose aleatoriedad.
Uso del sonido: Un sonido breve sirve para atraer la atención sobre algún cambio que se produzca, y rompe la monotonía de un contenido difícil. No necesita ser demasiado fuerte: Un sonido suave de campanillas como el llamado de atención en los sonidos de Office 97 es suficiente para alertar al estudiante. El sonido de fondo de una aplicación es otro aspecto que debe ser meditado. El uso adecuado del sonido puede ayudar a marcar el ritmo de trabajo con el software, imprimiendo dinamismo.
Si bien el sonido puede marcar el ritmo con el software, no debe ser demasiado repetitivo. Pueden, por ejemplo, usarse variaciones sobre un tema, o tratarse variaciones de tonalidad. Un ejemplo lo constituye el sonido de fondo del juego Konami de "Las momias". La secuencia es lo suficientemente larga para no repetirse en un buen trecho, y en consecuencia no cansa.
Por supuesto que también debe ser posible desactivar temporalmente el sonido.
Un fondo musical cada vez más vivo y animado puede acompañar las acciones a medida que el estudiante se acerca a la solución de un problema que requiere ciertas destrezas o respuestas rápidas. Esto favorece una mayor identificación del estudiante con el software, especialmente en el caso de niños
Es preferible un sonido suave, de melodía fácil, si se trata de un software de consulta o que requiera reflexión, como ocurre en "Descubriendo Nuestro Entorno" del Centro de Estudios CESoftAD.
Vídeos: La presentación de fragmentos de vídeo es una magnífica posibilidad que brinda la multimedia. Un fragmento de vídeo o una simulación pueden apoyar y reforzar una explicación, ayudando a esclarecer puntos oscuros en una cadena de razonamiento, independientemente del atractivo visual que representen.
Resumiendo:
Al planificarse la interfaz se debe ser lo más explícito posible, con una mentalidad si se quiere cinematográfica. Debe tratarse de concebir la interfaz como un todo.
Creemos importante destacar que si bien no corresponde estrictamente en el guión multimedia en esta etapa especificar las piezas musicales o cuáles sonidos en particular se usarán, sí debe hacerse alguna sugerencia al respecto.
Las cuestiones del diseño sí serán luego puntualizadas por el diseñador.
Análisis de guiones para la elaboración de software
A continuación te mostramos un ejemplo de guión para que sea analizado y observen como se materializa lo estudiado anteriormente. Otro ejemplo de guión puede ser consultado en los anexos (Anexo 10)
Titulo: Salud Web
Objetivo: Este software contribuirá a la formación de valores en alumnos y profesores en materia de Salud Escolar para que sean capaces de asumir una actitud responsable ante la salud personal y colectiva. La información que se brinda posibilitara el desarrollo de trabajos e investigaciones científicas que potencien el enriquecimiento teórico, práctico y metodológico del trabajo de la Promoción y Educación para la Salud en el ámbito escolar.
Tipo de Software: Hiperentorno de aprendizaje
Diseño de la interfaz
Pantalla principal
Educación sexual.
Educación anti-tabáquica, antialcohólica y antidroga.
Prevención de accidentes y educación vial.
- Comunicación y convivencia.
Medicina tradicional y natural.
Imagen: im1 (grupo de jóvenes)
Debajo de la imagen aparecerá a dos columnas el siguiente texto.
La salud ha estado siempre entre los objetivos a lograr por el hombre. En 1977 en la Asamblea Mundial de la Salud, se insta por sus participantes a lograr la meta de Salud para Todos para el inicio del nuevo milenio, de igual forma en la conferencia de Ottawa en 1987 se establecen conceptos estratégicos acerca de cómo lograr esta meta sobre la base, de que la promoción de la salud constituye un pilar en la conquista de la misma.
La promoción de salud no se puede ver solamente enmarcada al sistema asistencial y preventivo de salud sino vinculada a una acción mancomunada de toda la población a partir de la voluntad política del estado y con participación de las distintas instancias nacional, provincial, municipal utilizando cada uno de los espacios que estas ofrecen.
En nuestro país, estas metas, trazadas en estos eventos de los organismos de las Naciones Unidas, fueron cumplidas y sobre cumplidas mucho antes de las fechas acordadas y en muchos casos, la contribución de nuestro país con otros han constituido un factor importante en la mejoría de la salud en los mismos.
La acción de la escuela, la familia, la comunidad es decisiva en el logro de este propósito, siendo la escuela sin lugar a duda quien mayores posibilidades tiene para la promoción y educación de la salud.
La Promoción y Educación para la Salud, dentro de los objetivos de la educación en nuestro sistema, ocupa un papel preponderante dada la necesidad de lograr, a partir del Proceso Pedagógico, el desarrollo Bio-Psico-Social adecuado del estudiante propiciándoles los instrumentos, los medios, para conservar y fomentar su salud personal.
En las Universidades pedagógicas, conlleva, además, la preparación del futuro maestro, profesor, capaz de fomentar la formación de hábitos, de habilidades, de una cultura en la preservación y aumento de la salud en los alumnos con los cuales desarrollará su labor profesional.
Para el resto de las pantallas se mantiene el diseño siguiente:
Nota: La barra superior tendrá un color diferente para cada tema.
Pantalla 2
Barra superior de color azul
Área de título: Higiene Personal y Colectiva.
Contenido:
Hábitos de higiene personal: aseo, higiene buco dental, alimentación, descanso y sueño, hábitos posturales, práctica sistemática de ejercicios físicos, deportes y gimnasia. Recreación y disfrute del tiempo libre. Higiene mental.
Higiene colectiva.
Régimen de vida.
Higiene del medio ambiente. Saneamiento ambiental. Salud y desarrollo sostenible.
Vida en colectivo: Formación ciudadana. Relaciones interpersonales. Comunicación afectiva. Convivencia. Hábitos de cortesía. Enfermedades transmisibles y no transmisibles.
Área de imagen
Imagen: Im2 (Familia)
Pantalla 3
Barra superior de color naranja
Área de título: Conozca el contenido de la Educación Sexual
Contenido:
? Sexo y sexualidad. La sexualidad como parte de la personalidad.
? Identidad de género. Rol de género.
? Orientación sexual.
? Dimensiones y cualidades de la sexualidad.
? El amor como base de las relaciones interpersonales y de las relaciones sexuales. Autoestima.
? La sexualidad y la formación de valores.
? Salud sexual y reproductiva. Planificación familiar. Métodos anticonceptivos.
? El embarazo precoz. Causas y consecuencias, Cómo evitarlo.
? Embarazo no deseado. Causas y consecuencias.
? Infecciones de transmisión sexual. (ITS)
? Estabilidad de la familia.
? La violencia y sus manifestaciones.
? La sexualidad en la tercera edad.
Área de imagen: Im3 (Una pareja)
Pantalla 4
Barra superior de color verde
Área de título: Educación Nutricional e Higiene de los alimentos.
Contenido:
Alimentación y nutrición. Diferencias.
Grupos básicos de alimentos. Importancia.
Régimen y frecuencia alimentaria.
Necesidades nutricionales en las diferentes etapas de la vida. Consecuencias de la malnutrición.
Cadena alimentaria. Manipulación higiénica de los alimentos.
Enfermedades transmitidas por alimentos. Etiología.
Control sanitario del agua de consumo. Calidad y cantidad. El agua como alimento fundamental en la dieta.
Hábitos alimentarios y de mesa.
Vías que contribuyen a mejorar la alimentación y nutrición.
Área de imagen: Im4. (Grupo de frutas)
Pantalla 5
Barra superior de color carmelita
Área de título: Educación antitabaquica, antialcohólica y antidroga
Contenido:
Componentes del tabaco. Sus efectos en el organismo humano.
Componentes químicos del alcohol.
Consecuencias para la salud del hábito de fumar y del consumo excesivo de alcohol. Su comportamiento como droga.
Definición de fumador pasivo. Riesgos para su salud. Derecho al reclamo de no agresión a su salud.
Cómo se establece el hábito de fumar y de beber.
Métodos para dejar de fumar y de beber.
El alcoholismo como un problema familiar y social.
Quién es un alcohólico.
Relación entre tabaquismo, alcoholismo, sexo y sexualidad.
Área de imagen: Im5 (Foto tabaco)
Pantalla 6
Barra superior de color amarillo
Área de título: Prevención de Accidentes Y Educación Vial.
Contenido:
Definición de accidentes y de peligros potenciales de accidentes.
Percepción del riesgo. Medidas para la prevención. Tipos de accidentes.
Educación vial.
Los accidentes en la morbilidad y mortalidad en el ámbito escolar.
Consecuencias, personales, familiares, sociales y económicas de los accidentes.
Área de imagen: Im5 (Foto Policías y autos)
Pantalla 7
Barra superior de color verde oscuro
Área de título: Medicina Tradicional Y Natural
Contenido:
Concepción. Antecedentes históricos. Sus diferentes variantes. Importancia y uso.
Medicina verde (fitofármacos).
Apifármacos.
Peloides o fangos medicinales.
Aguas sulfurosas y termales.
Tratamientos con cera.
Acupuntura.
Digitopuntura.
Homeopatía Belleza y salud.
Área de imagen: Im5 (Foto Hospital)
Pantalla 8
Barra superior de color azul cielo
Área de título: Comunicación Y Convivencia.
Contenido:
Autoestima: sentirse miembro de una familia, aceptarse uno mismo, vivir conscientemente, sentirse igual en la diferencia, reconocer las propias capacidades, sentirse apreciado, valorar la diversidad, afirmar los propios derechos.
Afrontar los desafíos y merecer la confianza ajena, ser consecuente, vivir conscientemente, afrontar los fracasos, valorar el esfuerzo, aprender a conseguir metas, experimentar poder.
Manejar tensiones: resolver conflictos, solicitar ayuda, afrontar la crítica injusta, buscar ayuda, dosificar el esfuerzo, aprender a relajarse, compartir las preocupaciones expresar las emociones.
Relacionarse: acoger a los amigos, responder asertivamente, aprendiendo a decir NO, a cumplir los compromisos, merecer la confianza ajena, saber escuchar, dispensar buen trato, buscar ayuda, confiar en alguien.
Tomar decisiones: calcular los riesgos, superar las presiones, asumir los errores, meditar sobre las consecuencias, decidir reflexivamente, reflexionar antes de actuar, según los propios valores, escoger por uno mismo, resistir las presiones, reacción ante la violencia, buscar y alcanzar acuerdos. La violencia intra y extra familiar y sus consecuencias. Tipos de violencia.
Área de imagen: Im5 (Foto tabaco)
Pantalla 9
Barra superior de color Gris
Área de título: Noticias
Contenido:
Área de imagen: Im5 (animación noticias)
Pantalla 10
Barra superior de color Gris
Área de título: Descargas
Diagrama de flujo:
Leyenda
1. Es la página principal, en la cual se vinculan todas las demás.
(2… 9). Los ejes temáticos del Programa Director de Promoción y Educación para la Salud. Que se muestran a continuación.
10. Es la página de noticias (acerca de la Salud).
| Página siguiente |