¿Por qué necesitamos la Ingeniería del Software?

Posted by admin on July 23, 2012

Para entender la necesidad de que la ingeniería de software, debemos hacer una pausa breve para mirar hacia atrás en la historia reciente de la informática. Esta historia nos ayudará a entender los problemas que comenzó a ser evidente en los años sesenta y principios de los setenta, y las soluciones que han llevado a la creación del campo de la ingeniería de software. Estos problemas fueron mencionados por algunos como “la crisis del software”, llamado así por los síntomas del problema. La situación podría también ha llamado “La Barrera de la Complejidad”, llamado así por la primera causa de los problemas. Algunos se refieren a la crisis del software en tiempo pasado. La crisis está lejos de terminar, pero gracias al desarrollo de muchas técnicas nuevas que ahora se incluyen bajo el título de ingeniería de software, que han hecho y continúan haciendo progresos.

En los primeros días de cálculo de la preocupación fundamental era la construcción o la adquisición del hardware. Software que se esperaba casi a cuidar de sí mismo. El consenso sostuvo que el “hardware” es “difícil” para cambiar, mientras que el “software” es “suave”, o fáciles de cambiar. De acuerdo, la mayoría de la gente en la industria de planificar cuidadosamente el desarrollo de hardware, pero dio la previsión considerablemente menor a la de software. Si el software no funciona, se cree, sería bastante fácil de cambiar hasta que se hizo el trabajo. En ese caso, ¿por qué hacer el esfuerzo de planificar?

El costo del software ascendieron a una fracción tan pequeña del coste del hardware que nadie considera que es muy importante para administrar su desarrollo. Todos, sin embargo, vio la importancia de la producción de programas que eran eficientes y corrió rápido porque este ahorro de tiempo en el hardware costoso. Tiempo que la gente se supone que ahorra tiempo de máquina. Hacer que el proceso de las personas eficientes, dio prioridad a poco.

Este enfoque resultó satisfactoria en los primeros días de la computación, cuando el software es simple. Sin embargo, como la informática madurado, los programas se volvieron más complejos y los proyectos se hicieron más grandes mientras que los programas habían sido ya rutinariamente se especifica, por escrito, operados y mantenidos todos por la misma persona, los programas comenzaron a ser desarrollados por equipos de programadores para satisfacer las expectativas de otra persona.

El esfuerzo individual dio paso a trabajo en equipo. La comunicación y coordinación, que fue una vez en dentro de la cabeza de una persona tuvo que ocurrir entre las cabezas de muchas personas, por lo que todo el proceso mucho más complicado. Como resultado, la comunicación, gestión, planificación y documentación se tornó crítica.

Considere esta analogía: un carpintero puede trabajar solo para construir una casa sencilla para sí mismo, sin más que un concepto general de un plan. Él o ella podría arreglar las cosas o hacer ajustes según avanzaban los trabajos. Así es como los primeros programas fueron escritos. Pero si la casa es más elaborado, o si se construye para otra persona, el carpintero tiene que planear con más cuidado cómo la casa se va a construir. Los planes deben ser revisados ​​con el dueño del futuro antes de que comience la construcción. Y si la casa va a ser construida por carpinteros muchos, todo el proyecto sin duda tiene que ser planificado antes del inicio de modo que como un carpintero construye una parte de la casa, otro no está construyendo al otro lado de una casa diferente. Programación se convierte en un elemento clave para que los contratistas de cemento vierte las paredes del sótano antes de que los carpinteros iniciar el encuadre. Como la casa se vuelve más complejo y más trabajo de la gente tiene que ser coordinada, planos y planes de manejo son obligatorios.

Como los programas se volvieron más complejos, los primeros métodos utilizados para hacer planos (diagramas de flujo) ya no eran satisfactorias para representar a esta mayor complejidad. Y así se hizo difícil para una persona que necesitaba un programa escrito para transmitir a otra persona, el programador, justo lo que quería, o para los programadores de transmitir a los demás lo que estaban haciendo. De hecho, sin mejorar los métodos de representación que se hizo difícil, incluso para un programador para realizar un seguimiento de lo que él o ella está haciendo.

Los tiempos necesarios para escribir los programas y sus costos empezaron a exceder a todas las estimaciones. No era inusual para los sistemas que cuestan más del doble de lo que se había estimado y tomar semanas, meses o años más de lo esperado en completarse. Los sistemas puestos a disposición del cliente con frecuencia no funciona correctamente debido a que el dinero o el tiempo se había agotado antes de que los programas podrían llegar a funcionar como se pretendía originalmente. O el programa era tan compleja que cualquier intento de solucionar un problema producido más problemas que lo arreglen. Mientras que los clientes finalmente vio lo que estaban recibiendo, a menudo cambiado de opinión sobre lo que querían. Por lo menos un gran proyecto de software de sistemas militares costando varios cientos de millones de dólares fue abandonada debido a que nunca se podría hacer para que funcione correctamente.

La calidad de los programas también se convirtió en una gran preocupación. Mientras que las computadoras y sus programas se utilizaron para las tareas más vitales, como equipo de apoyo en el seguimiento la vida, la calidad del programa adquirió un nuevo significado. Como habíamos incrementado nuestra dependencia de los ordenadores y en muchos casos ya no podía vivir sin ellos, hemos descubierto lo importante que es que funcionen correctamente.

Haciendo un cambio dentro de un programa complejo resultó ser muy costoso. A menudo, incluso para conseguir el programa para hacer algo un poco diferente era tan fuerte que era más fácil tirar el viejo programa y empezar de nuevo. Esto, por supuesto, era costoso. Parte de la evolución en el enfoque de ingeniería de software fue de aprendizaje para desarrollar los sistemas que se construyen lo suficientemente bien como la primera vez para que los cambios simples se puede hacer fácilmente.

Al mismo tiempo, el hardware era cada vez menos costoso. Los tubos fueron sustituidos por los transistores y los transistores fueron sustituidos por los circuitos integrados hasta el micro-ordenadores que cuestan menos de tres mil dólares se han convertido en varios millones de dólares. Como una indicación de cómo el cambio rápido se estaba produciendo, el costo de una cantidad dada de computación disminuye a la mitad cada dos años. Teniendo en cuenta este reajuste, los tiempos y costos para desarrollar el software ya no eran tan pequeños, en comparación con el hardware, que puede ser ignorada.

A medida que el costo del hardware se desplomó, el software continuó siendo escrito por los seres humanos, cuyos salarios estaban aumentando. El ahorro derivado de las mejoras de productividad en el desarrollo de software a partir de la utilización de ensambladores, compiladores, y los sistemas de gestión de bases de datos no se proceda lo más rápidamente el ahorro en costes de hardware. En efecto, los costes actuales de software no sólo ya no puede ser ignorada, se han convertido en más grande que los costes de hardware. Algunos desarrollos actuales, como nonprocedural (cuarta generación) idiomas y el uso de la inteligencia artificial (quinta generación), muestran una promesa de aumentar la productividad de desarrollo de software, pero sólo estamos empezando a ver su potencial.

Otro problema era que en los programas anteriores eran a menudo antes de que se entiende plenamente lo que el programa tenía que hacer. Una vez que el programa había sido escrito, el cliente comenzó a expresar su descontento. Y si el cliente no está satisfecho, en última instancia, el productor, también, era infeliz. Con el correr de los desarrolladores de software aprendido a diseñar con papel y lápiz exactamente lo que pensaba hacer antes de empezar. Entonces podrían revisar los planes con el cliente para ver si cumplían con las expectativas del cliente. Es más simple y menos costosa de hacer cambios a esta versión de papel y lápiz que hacerlas después de que el sistema ha sido construido. Uso de una buena planificación hace que sea menos probable que los cambios tendrán que hacerse una vez que el programa haya finalizado.

Desafortunadamente, hasta hace algunos años un buen método de representación existente para describir satisfactoriamente los sistemas tan complejos como los que se están desarrollando en la actualidad. La única representación clara de lo que el producto se verá como fue el producto terminado. Los desarrolladores no pueden mostrar a sus clientes lo que ellos estaban planeando. Y los clientes no podían ver si lo que el software era lo que querían, hasta que fue finalmente construido. Entonces era demasiado caro para cambiar.

Una vez más, tenga en cuenta la analogía de la construcción de edificios. Un arquitecto puede dibujar un plano de planta. El cliente por lo general pueden obtener una cierta comprensión de lo que el arquitecto ha planeado y dar retroalimentación en cuanto a si es apropiado. Los planos son relativamente fáciles para el gran público de entender porque la mayoría de la gente está familiarizada con los dibujos que representan objetos geométricos. Los conceptos del arquitecto y el cliente comparten comunes sobre el espacio y la geometría. Sin embargo, el ingeniero de software debe representar para el cliente un sistema que implica la lógica y el procesamiento de la información. Debido a que aún no tiene un lenguaje de conceptos comunes, el ingeniero de software debe enseñar a un nuevo lenguaje para el cliente antes de que puedan comunicarse.

Además, es importante que este lenguaje sea simple para que pueda ser aprendido rápidamente.

Categories: Software

Comments are closed.