Una WebQuest consiste en investigación guiada, con recursos principalmente procedentes de Internet, que obliga a la utilización de habilidades cognitivas elevadas, prevé el trabajo cooperativo y la autonomía de los alumnos e incluye una evaluación auténtica. Cada vez son más utilizadas como recurso didáctico por los profesores, puesto que permiten el abordaje de habilidades de manejo de información, propias del Modelo curricular cognitivo respondiendo así a la meta educativa del aprender a conocer postuladas por la Unesco frente al desafío de educar en una sociedad altamente informatizada.
Una WebQuest se construye alrededor de una tarea atractiva que provoca procesos de pensamiento superior. Se trata de hacer algo con la información. El pensamiento puede ser creativo o crítico e implicar la resolución de problemas, enunciación de juicios, análisis o síntesis. La tarea debe consistir en algo más que en contestar a simples preguntas o reproducir lo que hay en la pantalla. Idealmente, se debe corresponder con algo que en la vida normal hacen los adultos fuera de la escuela. (Starr, 2000b:2)
Una WebQuest tiene la siguiente estructura:
Introducción
Tarea
Proceso
Recursos
Evaluación
Conclusión
Autores
Para desarrollar una WebQuest es necesario crear un sitio web que puede ser construido con un editor HTML, un servicio de blog o incluso con un procesador de textos que pueda guardar archivos como una página web.
No hay que confundir una webquest con "caza del tesoro". Una "caza del tesoro" tiene también utilización como recurso educativo pero es más sencilla. En ella se plantean una serie de preguntas sobre un tema que se pueden contestar visitando unos enlaces de otras páginas relacionadas con el tema. Muchas veces se hace una pregunta principal al final para comprobar los conocimientos adquiridos sobre el tema.
Existe además un sitio que divulga experiencias utilizando WebQuests en http://www.vivenciapedagogica.com.br, también orientado a propuestas con el trabajo de esta metodología, incluyendo el uso de nuevas tecnologías y herramientas comunicativas.
El puerto paralelo de la IBM PC y AT fue diseñado para comunicarse sólo con la impresora y este estándar se conoce como la interface de impresora Centronics. La interface Centronics permite transmitir 8 bits a una impresora a la vez sobre un conjunto de 8 líneas de datos D0 - D7. Deben estar presentes otras señales para sincronizar el flujo de datos entre la PC y la impresora.
Las dos señales de sincronización más importantes son las líneas STROBE' y BUSY. Cada vez que la computadora quiere enviar un byte de datos a la impresora, primero checa el estado de la línea BUSY (es una señal de entrada de la impresora). Si BUSY es bajo, la computadora pone un nuevo dato en las ocho líneas de datos y también envía un pulso bajo en la línea STROBE'. Tan pronto como la impresora ve que STROBE' se va a bajo, asegura el byte y pone la línea BUSY en alto. La impresora deja BUSY en alto hasta que procesa el dato y después regresa a bajo a BUSY cuando esta lista para aceptar otro dato.
El intercambio de señales entre la computadora y la impresora es un ejemplo clásico de un handshake de dos vías. El dispositivo que recibe dice "estoy listo para manejar otro byte ahora" (BUSY = bajo), el dispositivo que envía dice "Aquí esta un dato" (el pulso STROBE'), y el dispositivo receptor responde "Voy por el" (BUSY = alto). La sincronización de handshake del flujo de datos es necesario porque la computadora puede sacar datos a través del puerto paralelo a una razón de 100-200 Kbs y la impresora no puede hacerlo.
Aplicaciones del software para ingeniería.Entre las aplicaciones mas factibles del software en la ingenieria se encuentran: - Simulacion de circutos digitales y analogicos (circuit maker), un claro ejemplo de software para esto es el FluidSim (simulacion de circuitos hidrahulicos y neumaticos) de Festo, Multisim (comprobacion de circuitos electronicos), etc.- Diseño de circutos impresos (PCB maker) este tipo de software es utilizado para la realizacion de layouts e impresion de los mismos en tablas denominadas PCB o vaquelitas(pizarra cubierta de cobre).- Carga o configuracion de PIC (DesignWorkslite , Nopp)- Osciloscopio virtual (Spice)
Impacto del software en las áreas ingenieria electrónica Es claro y evidente como el software es muy utilizado en diferentes areas de la ingenieria, presente en casi todo o al menos en un 70% del proceso de produccion de cualquier gran empresa.
Entre las mejoras resultantes de utilizar software en cualquier area de proceso son: - Mejor resultado en el diseño de circuitos, ya que mediante la utilizacion de softwares podemos deducir fallas en cualquier circuito y eliminarlas y asi construirlo fisicamente sin error alguno. - La utilizacion de softwares tambien elimina la cantidad de desperdicio ya que podemos utilizar este para el diseno correcto y sin errores utilizando medidas exactas. - Podemos programar todo tipo de controladores.- Deteccion de voltajes o señales utilizando softwares para las computadoras, que comparan senales o voltajes ejemplos: osciloscopios virtuales, multimetros, etc. En los EEUU, el software contribuyó a 1/4 de todo el incremento del PIB durante los 90's (alrededor de 90,000 millones de dólares por año), y 1/6 de todo el crecimiento de productividad durante los últimos años de la década (alrededor de 33,000 millones de dólares por año). La ingeniería de software contribuyó a $1 billón de crecimiento económico y productividad en esa década. Alrededor del globo, el software contribuye al crecimiento económico en formas similares, aunque es difícil de encontrar estadísticas fiables. La ingeniería de software cambia la cultura del mundo debido al extendido uso de la computadora. El correo electrónico (E-mail), la WWW y la mensajería instantánea permiten a la gente interactuar en nuevas formas.
Debido ala falta de fuentes de poder en los laboratorios de ingeniería nos vimos en la necesidad de realizar un proyecto, el cual tiene como objetivo abastecer los laboratorios de ingeniería con las fuentes necesarias para que cada alumno trabaje de manera profesional y eficiente.
Para esto instalaremos una fuente tipo AT con un switch de encendido y apagado, simplemente tomaremos dicha fuente y la colocaremos en un espacio desocupado de la mesa, como se muestra acontinuacion en las imagenes.
Las dos fuentes que podremos encontrarnos cuando abramos un ordenador pueden ser: AT o ATX Las fuentes de alimentación AT, fueron usadas hasta que apareció el Pentium MMX, es en ese momento cuando ya se empezarían a utilizar fuentes de alimentación ATX. Las características de las fuentes AT, son que sus conectores a placa base varían de los utilizados en las fuentes ATX, y por otra parte, quizás bastante más peligroso, es que la fuente se activa a través de un interruptor, y en ese interruptor hay un voltaje de 220v, con el riesgo que supondría manipular el PC. También destacar que comparadas tecnológicamente con las fuentes ATX, las AT son un tanto rudimentarias electrónicamente hablando. En ATX, es un poco distinto, ya que se moderniza el circuito de la fuente, y siempre está activa, aunque el ordenador no esté funcionando, la fuente siempre está alimentada con una tensión pequeña para mantenerla en espera. Una de las ventajas es que las fuentes ATX no disponen de un interruptor que enciende/apaga la fuente, si no que se trata de un pulsador conectado a la placa base, y esta se encarga de encender la fuente, esto conlleva pues el poder realizar conexiones/desconexiones por software. Existe una tabla, para clasificar las fuentes según su potencia y caja. - Sobremesa AT => 150–200 W Semitorre => 200–300 W Torre => 230–250 W Slim => 75–100 -- W Sobremesa ATX => 200–250 W No obstante, comentar, que estos datos son muy variables, y unicamente son orientativos, ya que varía segun el numero de dispositivos conectados al PC.Conexión de Dispositivos En Fuentes AT, se daba el problema de que existian dos conectores a conectar a placa base, con lo cual podia dar lugar a confusiones y a cortocircuitos, la solución a ello es basarse en un truco muy sencillo, hay que dejar en el centro los cables negros que los dos conectores tienen, asi no hay forma posible de equivocarse. En cambio, en las fuentes ATX solo existe un conector para la placa base, todo de una pieza, y solo hay una manera de encajarlo, así que por eso no hay problema Existen dos tipos de conectores para alimentar dispositivos: El más grande, sirve para conectar dispositivos como discos duros, lectores de cd-rom, grabadoras, dispositivos SCSI, etc… Mientras que el otro, visiblemente más pequeño, sirve para alimentar por ejemplo disqueteras o algunos dispositivos ZIP. Instalación de una fuente ATXPara instalar una fuente de alimentación ATX, necesitaremos un destornillador de punta de estrella. Empezaremos por ubicar la fuente en su sitio, asegurando que los agujeros de los tornillos, coinciden exactamente con los de la caja. Una vez hecho esto, procederemos a atornillar la fuente. Acto seguido, conectaremos la alimentación a la placa base con el conector anteriormente comentado, y realizaremos la misma tarea con el resto de los dispositivos instalados. Un punto a comentar, es que solo hay una manera posible para realizar el conexionado de alimentación a los dispositivos, sobretodo, NUNCA debemos forzar un dispositivo. Tras realizar todas las conexiones, las revisaremos, y procederemos a encender el equipo.
*Paso 1. Analizamos que es lo que se necesita, en este caso será el encendido manual y apagado automático por tiempo.
*Paso 2. Mediante un diagrama se va diseñando el timmer el cual consta de dos resistencias un capasitor y un led.
*Paso 3. Ya con el material seleccionado lo colocamos en un protoboard y tomas una fuente de voltaje para el circuitos.
*Paso 4. una vez armado el circuito en su respectivo protoboard lo asemos funcionar.
*Paso 5. si el circuito salio tal y como lo esperábamos podemos adaptarlo o incorporarlo a lo que desees controlar mediante el tiempo por ejemplo a una banda transportadora a una linea de producción. Y si no funciona o hay fallas nos regresaremos al paso 2 y seguir en orden hasta el último paso.
Método científico y metodología del diseño de software
Método científico
Observación es aplicar atentamente los sentidos en un objeto
Inducción efecto de extraer, a partir de determinadas observaciones o experiencias particulares
Hipótesis Planteamiento mediante la observación siguiendo las normas establecidas por el método científico
Verificación solo se examina si es correcto o no el experimento
Refutación o aceptación si la verificación fue aceptada el experimento término si no se realiza una retroalimentación hasta continuar con la hipótesis
Metodología del diseño de software
Análisis del problema Es una similitud entre observación e inducción porque en el se plantea el problema y para ello tuvo que ver una observación previa
Diseño preeliminar-Programación-Implementación es un anteproyecto el cual puede ser considerada como hipótesis por que a partir de ella se lleva acabo la experimentación
Prueba si es aceptada el experimento termina que es muy similar a la refutación yo aceptación
Las fases en las que hay que desarrollar un proyecto, son básicamente Requisitos, análisis, diseño preliminar, diseño detallado, codificación y pruebas.
REQUISITOS
Los requisitos son una lista de cosas que queremos que haga nuestro programa. Lo normal es que recopilemos dicha lista hablando con todas las personas que podamos: usuarios de nuestro programa, expertos en el tema de que trata el programa, etc.
Normalmente la gente con la que hablemos nos dará los requisitos de una forma vaga y desordenada. Es labor nuestra ordenarlos (por temas, por dificultad, por importancia para los usuarios, etc.) y asegurarnos de que son claros.
Para asegurarnos de que un requisito es claro, debemos saber qué persona lo ha propuesto y por qué lo ha propuesto, qué es lo que cree exactamente que vamos a hacer en nuestro programa cuando nos ha dicho ese requisito.
ANÁLISIS
Durante el análisis vamos a definir más claramente qué es lo que va a hacer nuestro programa. Debemos hacer varias cosas principalmente:
Identificar actores. En lenguaje UML, actores son los usuarios y cualesquiera otros sistemas con los que se pueda comunicar nuestro programa. En nuestro programa de ajedrez, un actor sería el usuario que va a jugar al ajedrez. Le llamaremos "jugador". También se indicaba como requisito que pueda aprender aperturas. La persona que le va a enseñar aperturas a nuestro programa podría ser otro actor, al que podemos llamar "maestro". Una misma persona puede ser varios actores. Por ejemplo si alguien compra nuestro programa de ajedrez, a veces puede jugar y otras veces puede enseñarle aperturas. Es la misma persona, pero el papel que desempeña en cada caso es distinto.
Identificar casos de uso. Un caso de uso es algo que un actor quiera hacer con nuestro sistema. Por ejemplo, un caso de uso para un "jugador" es "jugar una partida". Está claro que el jugador quiere nuestro programa para jugar una partida de ajedrez. Otro posible caso de uso es "análisis de un tablero". El "jugador" pone las piezas en determinada posición y quiere que el ordenador le dé una lista de posibles movimientos, etc. En resumen, debemos obtener una lista de cosas que los actores van a querer hacer con nuestro sistema. Deben ser cosas grandes y no meternos en los detalles. "Mover una pieza" no sería un caso de uso, sino una parte de "jugar una partida". De aquí saldría un diagrama UML de casos de uso.
Detallar casos de uso. En un texto vamos poniendo varios puntos. En cada punto ponemos sentencias del estilo "el usuario hace tal cosa y el programa hace tal otra". Es decir, explicamos por escrito, desde el punto de vista del usuario, qué es lo que tiene que hacer y qué es lo que va a hacer el ordenador.
En el caso de uso se detalla una situación normal, sin fallos ni situaciones raras. Al final debería ponerse una pequeña lista con los posibles fallos o situaciones anormales.
Advertir que en ningún caso nos hemos metido a detallar cómo va a hacer algo nuestro programa, solamente qué es lo que va a hacer.
Siguiendo los esquemas UML, podemos incluso hacer por cada caso de uso un diagrama de secuencia en el que los objetos implicados son el actor (el "jugador") y nuestro programa, sin meternos dentro de él.
También en este paso podemos ir empezando a pensar en cómo van a ser las pantallas de la interfase de usuario, de nuestro programa.
DISEÑO PRELIMINAR
Aquí ya empezamos a pensar en cómo vamos a hacer las cosas.
En el diseño preliminar tratamos de establecer la arquitectura de nuestro programa. La arquitectura es un esquema de en qué módulos/paquetes vamos a dividir nuestro programa, qué librerías. Si el programa es suficientemente grande, quizás vaya en varios ejecutables, una arquitectura cliente/servidor, etc.
Viendo los casos de usos, deberíamos ver qué cosas podemos hacer comunes o como librerías aparte, que podamos reutilizar.
Dentro de estos paquetes, podemos ir pensando más subpaquetes, etc.
En este punto y con los casos de uso en general, debemos tener cuidado. Según una crítica generalizada a los casos de uso, estos llevan a un diseño funcional y no a uno orientado a objetos. Debemos tratar de pensar en objetos y almacenarlos juntos en la misma librería cuando estén muy relacionados entre sí, no en funciones. Por ello es buena idea tratar de agrupar las clases del diagrama de clases del negocio en paquetes y tratar de desarrollar la arquitectura a partir de ellas.
Es importante en este paso definir las interfaces y relaciones entre paquetes. Para ello puede servir de ayuda hacer los diagramas de secuencia de los casos de uso mostrando los actores, los paquetes y los mensajes entre ellos. Según vayan creciendo los diagramas de secuencia por aquello de ir entrando en detalles, podremos ir extrayendo subcasos de uso, como "mover pieza", "elegir color", etc.
DISEÑO DETALLADO
En el diseño detallado ya se entra a nivel de clases y métodos. Por cada paquete que hayamos extraído en el paso anterior y siguiendo siempre los casos de uso, debemos ir detallando las clases que vamos a implementar y los métodos que van a tener. Detallamos aun más los casos de uso y las interfaces de las clases.
En este punto pueden ser de ayuda los patrones de diseño. La gente que ha ido diseñando a lo largo de la historia, se ha encontrado con problemas (¿cómo hago que la clase A se entere que la clase B ha cambiado sin necesidad de que B vea a A?, ¿En qué clase pongo el método que suma las clases A y B? ¿Como me aseguro que de esta clase sólo se haga una instancia?, etc.)Algunos de dichos problemas salen con mucha frecuencia (como los indicados de ejemplo) y se han establecido soluciones "Standard", que funcionan bien. Dichas soluciones se llaman patrones. No está de más leer algo sobre patrones de diseño orientados a objetos para tener una lista de "soluciones" a aplicar.
Hay incluso patrones a nivel de arquitectura. Es bastante conocido, por ejemplo, el patrón separación modelo-vista. En nuestro caso "modelo" sería el conjunto de clases que juegan al ajedrez. "Vista" sería el conjunto de clases que "pintan" la partida en la pantalla. Hacer esa separación en dos módulos, hace que nuestro módulo de ajedrez sea reaprovechable, incluso si cambiamos de entorno de ventanas (de Windows a ms-dos o de ms-dos a unix). Eso sí, es imprescindible que sólo la "vista" vea al "modelo" y nunca al revés. Si lo hacemos al revés y queremos llevarnos nuestro "modelo" juego de ajedrez, tendremos que llevarnos también parte de la "vista".
IMPLEMENTACIÓN Y PRUEBAS
Pues a ello. Hay muchas cosas que se podrían contar aquí, pero no son de diseño.
De las pruebas podemos decir que hay que escribir los "casos de prueba". Básicamente son como la descripción de los casos de uso, pero indicando datos concretos que el operador va a introducir y qué resultados exactos debe dar nuestro programa.
DESARROLLO ITERATIVO E INCREMENTAL
En casi todas las metodologías que he leído, se habla de hacer el sistema en varias iteraciones. Es decir, hacer un poco de requisitos, un poco de análisis, un poco de diseño, un poco de codificación y pruebas y vuelta a empezar.
Hay varios motivos para realizar esto así:
No eternizarse en un paso. Por mucho análisis que hagamos, nunca estaremos seguros de haber acabado y siempre se nos ocurrirán más cosas. Ídem para el diseño. Siguiendo este método, nos fijaríamos unos plazos para cada cosa y haríamos lo siguiente:
Obtener los máximos requisitos posibles en el tiempo fijado. Ordenarlos y fijarnos en los más importantes.
Obtener los máximos casos de uso y actores posibles. Ordenarlos por importancia (más importantes para el usuario, más difíciles de implementar o que ayuden a definir lo máximo posible la arquitectura) y detallar sólo los primeros en la lista.
Obtener la arquitectura para esos primeros casos de uso.
Diseño detallado para esos primeros casos de uso, siempre con un plazo.
Codificar y probar.
Vuelta a empezar con los requisitos (¿han cambiado?, ¿hay nuevos?), los casos de uso (buscar más casos de uso, detallar los siguientes en importancia), etc.
Cada uno de estos pasos hay que detenerlo cuando creamos que tenemos algo que puede funcionar. No hay que tratar de dejarlo perfecto. Cada vez que pasemos al siguiente paso, encontraremos fallos en el paso anterior. Hay que ir arreglándolos de forma que al final todo quede coherente.
Ir haciendo versiones intermedias de nuestro programa. Cuando hayamos implementado varios casos de uso (que son los más importantes), podemos hacer una versión para enseñar al cliente. Es mejor que ponga las pegas y sugerencias ahora que no cuando ya lo hayamos terminado todo. Este punto es especialmente útil cuando el cliente no sabe muy bien qué es lo que quiere.
El software propetiario en este caso microsoft es una de las mejores opsiones de compra por que la empresa cuenta con mucha experiencia inovando al mundo. El software propetario es mucho mejor que un sofware libre por que cuenta con licensias legales, ademas de que el software propetiario esta libre de virus, algo que no podras encontrar en un software libre.
Una de las mejores ventajas de trabajar con sofware propetiario es que tiene soporte para todo tipo de hardware. Ademas el sofware propetario te ofrese garantia en caso de que el producto que compraste tenga algunos problemas; esto es algo que un software jamas te va a ofreser.
Microsoft es una empresa de comfianza, de garantia y satisfaccion al cliente, es mudialmente reconosida por su calidad en su trabajo y en su producto. LLevado de la mano de "Bill Gates(http://es.wikipedia.org/wiki/Bill_Gates), ha sabido llevar y liderar la empresa con mano firme la empresa microsoft.
"Esta empresa es un claro ejemplo de software propetiario y sus ventajas".
