I.I. IntroducciónIntroducciónII.II. Pasos del Método CientíficoPasos del Método Científico

1. Identificación de una anomalía.1. Identificación de una anomalía.2. Recolección de datos significativos.2. Recolección de datos significativos.3. Análisis de los mismos.3. Análisis de los mismos.4. Elaboración de una explicación o la hipótesis.4. Elaboración de una explicación o la hipótesis.5. Predicción de eventos futuros con base en la hipótesis.5. Predicción de eventos futuros con base en la hipótesis.6. Elaboración de experimentos para comprobar las predicciones.6. Elaboración de experimentos para comprobar las predicciones.7. Modificación de la hipótesis y repetición de los pasos anteriores.7. Modificación de la hipótesis y repetición de los pasos anteriores.8. Conversión de la hipótesis en teoría.8. Conversión de la hipótesis en teoría.

III.III. Ejemplos de aplicación del método científico en ingeniería.Ejemplos de aplicación del método científico en ingeniería.IV.IV. La Definición del Problema.La Definición del Problema.V. El Método de Ingeniería.

1. La Identificación del problema.2. Recopilación de la Información Necesaria.3. Búsqueda de Soluciones Creativas.4. Paso de la Idea a los diseños Preliminares5. Evaluación y Selección de la Solución Optima.6. Preparación de Informes, Planos y Especificaciones7. Puesta en práctica del diseño

Sesión 2

Cada disciplina emplea métodos diferentes para alcanzar los resultados que persigue. Los métodos usados dependen del tipo de situación que se vaya a resolver.

En ingeniería, la solución de los problemas abiertos que se plantean exige un método similar al que se ha explicado en unidades anteriores. Sin embargo, en muchas situaciones los problemas que debe afrontar el ingeniero se escapan de la esfera a la que está acostumbrado; el comportamiento anormal de un computador en algunas situaciones no puede resolverse aplicando el método de diseño en ingeniería. Aquí no hay nada que optimizar, se debe encontrar la causa que origina el problema. El ingeniero debe abandonar su casco de seguridad y ponerse la bata blanca del científico para abordar este tipo de problemas y encontrar la solución

El hecho de que el ingeniero deba comportarse a veces como un científico, introduce obligatoriamente al ingeniero en los métodos que usan otras disciplinas para conseguir sus resultados. En este caso se van a dar algunos pasos del método científico, empleado en las ciencias naturales para encontrar las causas de los fenómenos naturales, o de situaciones asimilables.

1.1. Identificar una AnomalíaIdentificar una Anomalía La percepción de que existe un problema. Unos cuerpos en lugar de hundirse como lo hacen los demás, flotan en el agua. Dos piedras de distinto tamaño caen con la misma velocidad al ser soltadas desde

determinada altura. El agua hierve a distinta temperatura en la cima de una montaña que al nivel del mar

Como puede apreciarse, la fase inicial de la aplicación del método científico o del método de diseño es muy parecida, el ingeniero se da cuenta de que ciertos hechos son anormales. En el caso del científico, las situaciones que el conocimiento actual no puede explicar. Tanto el ingeniero como el científico van en busca de las causas.

Ejemplo 1 (programa de computador)Cuando un programa de computador es mercadeado por una empresa pasa por

varias pruebas que buscan posibles errores en el mismo. Es muy probable que durante un tiempo el programa funcione bien; pero después de unos meses o años empiezan a fallar. Para hallar la o las causas de estos errores es necesario reportarlos indicando los efectos indeseables observados, en qué circunstancias aparecieron, configuración del equipo utilizado, etc. Parecidos informes pasarán otros usuarios con similares o distintas observaciones. Una vez recibidos suficientes datos se procede a la etapa del análisis para encontrar consistencias entre los diferentes hechos anotados que apunten a las causas de los errores.

Ejemplo 2 (Computador Moon)Un ingeniero de sistemas se encontraba trabajando en la interfaz de un computador MOON, cuando detectó el siguiente incidente:Mientras se desplazaba a lo largo de la ventana de la memoria el programa se estropeó y varias ventanas se abrían mientras otras se cerraban, lo cual era un hecho inusual. Incluso, enalgunas ocasiones, el programa desaparecía. El usuario perdía totalmente el control y tomaba varios minutos en pararlo. Era necesario restaurar todas las ventanas y en este proceso se podían perder muchos minutos y datos valiosos. Lo normal en este caso es que el usuario pudiera desplazarse por la ventana sin que el programa se volviera loco o empezaran a abrirse y cerrarse ventanas al azar. El ingeniero debe buscar por qué la ventana se comporta de manera tan irregular.

Ejemplo 3 (Aviones Comet)En las primeras épocas de la aviación con equipos jet ocurrieron múltiples accidentes; los aviones se desintegraban en el aire y era difícil conocer las causas de los accidentes porque los restos de los aviones no permitían reunir suficiente evidencia para llegar a conclusiones sólidas. Los ingenieros de la empresa inglesa constructora de los aviones Comet se preguntaban cuál era la causa de los accidentes.

2.2. Recolección de datos significativosRecolección de datos significativos Significa todo aquello que, a juicio científico, pueda tener relación con las

anomalías que están investigándose. Debe realizarse un plan de trabajo con el objeto de efectuar una búsqueda sistemática de la información requerida.

Comparar con otros entornos, buscar casos similares en épocas diferentes son algunas de las técnicas utilizadas regularmente en esta fase de la aplicación.

Deben anotarse todas las situaciones estudiadas con todos los detalles del caso; en este momento no se sabe todavía con exactitud lo que está buscándose, por lo que nada puede descartarse a príori.

Se podría afirmar que en este momento se prefiere pecar por exceso que por defecto.

Ejemplo 1 (Programa de computador)Cuando se presentan problemas en un programa deben anotarse todas las

condiciones en las cuales ocurre la falla: configuración del equipo, qué otros programas se estaban usando simultáneamente, qué operación se ejecutaba en el instante de la falla, contenido de los registros de la CPU, efectos visibles del problema, datos de entrada, entre otros. Con toda esta información los ingenieros de sistemas de la empresa que diseñó el programa podrán reconstruir la situación que originó el problema y detectar las posibles causas

Ejemplo 2 (Computador Moon)

Inicialmente no se habían anotado algunos parpadeos en la barra de menú de la ventana del equipo MOON.

Ejemplo 3 (Aviones Comet)

Todos los restos del avión Comet de la BOAC se recogían en los lugares de los accidentes, se volvían a armar en grandes hangares para reconstruir lo más fielmente posible la estructura del avión. Se analizaban los mensajes de las cajas negras para recoger información que diera una pista sobre las posibles causas; se analizaba minuciosamente cada una de las partes del avión en busca de algo que permitiera acercarse a la causa que originó el accidente; se analizaba la información recogida de los testigos de los accidentes; etc.

3. Análisis de los Datos3. Análisis de los Datos Una vez se recogen los datos (nunca se sabe, inicialmente, si son

suficientes), empieza a analizarse lo obtenido y se relaciona con los efectos visibles para encontrar relaciones causa efecto entre los mismos. De esta manera se descartan muchos datos que no tienen ninguna relación y se concentra la atención en los que, a primera vista, pueden conducir al descubrimiento de las causas del problema.

Ejemplo 1 (Programa de computador)Si el problema en un programa de cómputo tiene que ver con la impresión de un

documento, se analizarán todos los programas y drivers que están relacionados con esta parte; se descartarán, inicialmente, los restantes programas que manejan otros recursos del computador. Hay que recordar que la programación modular moderna permite delimitar fácilmente la parte del programa responsable de algunos errores.

Si el problema se presenta cada vez que se ejecuta una rutina de comunicación de datos, se empezará por examinar todo lo relacionado con la parte de comunicaciones: drivers de los puertos seriales, configuración de los puertos RS 232, entre otros.

Ejemplo 2 (Computador Moon)Inicialmente se sospechó que el buffer del teclado era el responsable de los extraños comportamientos de la pantalla; pero al realizar determinadas pruebas con el teclado se observó que el equipo aceptaba datos del teclado sin ningún problema. Por tanto, se concluyó que el problema radicaba en alguna rutina que tenía que ver con la presentación de la barra de menú de la ventana activa.

Ejemplo 3 (Aviones Comet)

En el caso de los primeros jets comerciales, la atención se centró en el fuselaje y en las alas, pues allí se encontraron finas fisuras en partes del fuselaje del avión y en las alas. Una investigación de las turbinas reveló que éstas funcionaban perfectamente cuando el avión se estrelló, lo cual indicaba que no eran, en primera instancia, las causantes de los accidentes.

4. Elaboración de la Hipótesis4. Elaboración de la Hipótesis

Una vez analizados los datos y establecidas algunas relaciones entre posibles causas y los efectos visibles, debe plantearse la explicación del problema o, en términos más científicos, hay que elaborar la hipótesis.

Ejemplo 1 (Programa de computador)En el caso de los problemas relacionados con el mal funcionamiento de la impresora

que se encuentra conectada a un computador, la hipótesis de trabajo, una vez analizados los datos disponibles, es la siguiente: el cable que une la impresora con el puerto paralelo no es el adecuado, o está estropeado.

Ejemplo 2 (Computador Moon)El buferth del teclado del equipo moon se llenaba rapidamente perdiendo un carácter

o dos , lo que originaba una perdida en el sincronismo, co el consiguiente caos con el despliegue de las ventanas .

Ejemplo 3 (Aviones Comet)Una vez observadas las fisuras en el fuselaje de uno de los jets

accidentados se llegó a esta conclusión: la causa de los accidentes se debió a la fatiga en los materiales que se usaron para la construcción de los aviones.

5. Predicción de eventos5. Predicción de eventos ¿Qué sigue después de la hipótesis? Comprobar que es cierta. Si el

ingeniero demuestra que su explicación del fenómeno es ajustada, puede seguir adelante con el diseño. Para comprobar que es cierto debe hacer dos cosas:

Generar una serie de hechos que pueden derivarse del modelo. Comprobar experimentalmente que esos hechos se cumplieron, lo que

demuestra que su modelo funciona.Ejemplo 1 (Programa de computador)En el caso del computador conectado con un cable defectuoso a su

impresora, deberá predecirse que al cambiar éste, la impresión de los documentos se efectuará normalmente.

Ejemplo 2 (Computador Moon)Si el problema del equipo MOON era que el buffer se llenaba rápidamente, el efecto

sobre otras ventanas abiertas debería ser similar. Es decir abriendo las otras ventanas y tecleando tan rápido como pudiera debería rebosar el buffer y producir comportamiento errático en las ventanas abiertas.

Ejemplo 3 (Aviones Comet)El uso de estos materiales debería corregir los defectos hallados en los aviones

accidentados. Pero antes de usarlos en equipo real, era necesario predecir los efectos que el uso de los nuevos materiales tendría en los modelos a escala que se deberían construir previamente; el modelo teórico predeciría el comportamiento del fuselaje ante combinaciones adecuadas de velocidades y vientos en el túnel de prueba.

6. Elaboración de Experimentos6. Elaboración de Experimentos

Estos ejemplos le muestran al estudiante de ingeniería que en muchas ocasiones va a enfrentarse con situaciones en las cuales va a tener que actuar como científico; no se trata de averiguar el cómo. La pregunta es por qué ocurren determinadas cosas. Evidentemente el método empleado para llegar a la respuesta es distinto.

Ejemplo 1 (Programa de computador)Al cambiarse el cable de la impresora por uno nuevo pudo observarse que la

impresora empezó a trabajar normalmente. La predicción había funcionado correctamente. En este

caso la comprobación no se llevó a cabo entre series de datos: funciona o no funciona.

Ejemplo 2 (Computador Moon)Cuando se probó con otras ventanas de la interfaz gráfica del equipo MOON,

se pudo observar que al escribir a toda velocidad con el teclado no ocurría nada anormal en las ventanas: funcionaban correctamente. Por tanto la hipótesis de que el buffer al llenarse perdía caracteres y originaba la pérdida de sincronismo, era falsa. Se precisaba buscar otra hipótesis. En este caso, los datos para comparar eran de verdadero o falso, funcionaba o no funcionaba.

Ejemplo 3 (Aviones Comet)Las pruebas efectuadas sobre maquetas en los laboratorios de ensayo demostraron que los nuevos materiales ofrecían mayor resistencia a la fatiga. Pruebas llevadas a cabo en prototipos, en situaciones controladas, confirmaron los datos hallados en los laboratorios: se había encontrado un material que era tan ligero como los originales pero mucho más resistentes a los esfuerzos. Aquí sí hubo necesidad de comparar largas series de datos estadísticos que se debieron analizar minuciosamente para llegar a las conclusiones anteriores. La experimentación dio el visto bueno final a los hallazgos analíticos.

7. Modificación de la Hipótesis7. Modificación de la Hipótesis Cuando los resultados experimentales no concuerdan con las predicciones es

necesario evaluar todo el proceso. Si las diferencias son mínimas es posible que mediante ligeras modificaciones de la hipótesis se alcancen los resultados esperados. Pero si las diferencias son notables es preciso trabajar nuevamente todo el proceso, comenzando con la recopilación de datos. Algo falló: no se tuvieron en cuenta algunos aspectos que, con seguridad, aparecerán en una segunda revisión más cuidadosa.

Ejemplo 1 (Programa de computador)Si al conectar el cable entre la impresora y la CPU no se hubiera obtenido la impresión esperada, se habría utilizado otro cable, sospechando que el anterior tenía algún desperfecto. Si tampoco hubiera funcionado habría sido necesario revisar todo el proceso desde el principio buscando síntomas a los que no se hubiera prestado atención al principio.

Ejemplo 3 (Aviones Comet)Si en el caso de los primeros aviones jet, los Comet, se hubieran cambiado los materiales del fuselaje y de las alas y se hubieran seguido presentando los accidentes, habría sido necesario encontrar nuevas pistas que condujeran a la causa original del problema.

Ejemplo 2 (Computador Moon)El caso del computador MOON es el único que presenta una hipótesis inicial que no funcionó. El ingeniero debió regresar a su equipo y provocar la falla; notó un parpadeo en la barra de menú, que anteriormente no se había tenido en cuenta. De acuerdo con los expertos, el parpadeo se origina por el refresco de la ventana que se lleva a cabo cinco veces por cada movimiento del cursor. La segunda hipótesis apunta en la dirección de que el programa que interpreta las entradas de las teclas y del curso está tan ocupado que pierde alguna de las entradas. Si se elimina todo el código redundante que rodea a este interpretador no se perderían entradas del teclado y el problema no se presentaría. Se eliminó todo el código redundante, el que no era indispensable y el problema no se volvió a presentar La segunda hipótesis había funcionado.

1. En Ingeniería de SistemasUn ingeniero de sistemas nota que cuando entran más de diez usuarios al sistema de cómputo de la universidad, éste empieza a trabajar de una forma muy lenta. Al retirarse algunos de estos usuarios, el sistema vuelve a recobrar su velocidad deseada. Para descubrir la causa de esta anomalía el ingeniero comienza a tomar datos durante una semana a distintas horas del día: número de usuarios, tipo de tareas que desarrollan, tiempo de respuesta del sistema, memoria libre, etc. Hasta ahora está identificando la anomalía (pobre tiempo de respuesta), recolectando hechos (los datos que recoge el ingeniero). El análisis de los mismos, usando las herramientas apropiadas, apunta en la dirección de que hace falta más memoria RAM y que el disco posiblemente está quedándose pequeño. Con esta información el ingeniero describe el modelo que explica el mal funcionamiento del equipo: el sistema operativo, más el programa de base de datos dejan tan poca memoria a los usuarios que cuando el número de éstos crece excesivamente, la memoria disponible no alcanza para mantener a los usuarios permanentemente en memoria. Debe mandarlos a la zona de swappinq del disco a esperar a que se libere memoria; este trasporte entre disco y memoria hace que el tiempo de respuesta se vuelva demasiado largo. Adicionalmente, el disco parece haber alcanzado su límite de eficiencia, lo cual agrava el problema. Hay que tener en cuenta que hasta ahora no hay nada comprobado; simplemente se lanza una suposición en forma de modelo explicativo de la situación. Si el modelo es correcto, el ingeniero se encuentra a un paso de la solución.

1. En Ingeniería ElectrónicaEn la fabricación de discos duros para computadores se observaba que una gran cantidad presentaba un número de sectores dañados que superaba lo normal y aceptable, lo cual hacía que el porcentaje de rechazados fuera excesivo, con las consiguientes pérdidas económicas. Se creó un grupo de trabajo conformado por ingenieros electrónicos, ingenieros mecánicos y por físicos. Se recogieron datos a lo largo de un período muy largo registrando tipos de disco, lugar de fabricación, lugar de uso, materiales empleados, y demás. Se hicieron pruebas en el laboratorio sobre cumplimiento de especificaciones eléctricas, mecánicas, etc. Se analizaron con el microscopio superficies dañadas para detectar algún patrón común; en fin, se hicieron toda clase de pruebas para poder llegar a elaborar una hipótesis que explicara la anomalía observada. Se pudo constatar que el número de unidades dañadas aumentaba en ciertas épocas del año, cuando las radiaciones solares eran más intensas. Analizando más en detalle esta posibilidad, se llegó a la conclusión de que efectivamente ésta podría ser la causa del problema presentado.