Ingenieria De Software

Computación Y Sistemas

Ingeniería de software Yassin. A

Es la aplicación de la ingeniería al software, ya que integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería.

Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet.

Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software.

Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados.

Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, sin perjuicio de lo anterior el programador debe hacer sus propias pruebas.

Hay una gran forma de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas.

Software, Metodología, Técnica, Modulo, Organizar, Programación, Informática, Diseño, Código Ingeniería.

Introducción

Sobre finales de los 70, comienzo de los 80 (del siglo XX), surgió toda una revolución en el mundo del desarrollo de software.

En aquellos tiempos, hacer cualquier aplicación requería mucho mucho esfuerzo, sin herramientas visuales, mucha gente, muchas pruebas, muchos medios, lo cual no quiere decir que ahora sea fácil, pero lo que yo puedo hacer ahora solo, necesitaba hace 10 años de unas 3 personas para hacerlo.

Las empresas, los desarrolladores, se dieron cuenta de que mantener ese ritmo, con aplicaciones monstruosas, con muchísimo código, tanto que al cabo de unos meses ya no se sabia ni como funcionaba, necesitaba una solución.

Veámoslo de otra forma, por si no he sabido explicarme bien:

Departamento de informática de una empresa, no menos de 5 programadores, en lenguajes tales como C, algún Pascal o quizás un cobol, nada visual, monitores en fosforo verde... una vida muy dura.

Comienza el proyecto, líneas y líneas de código, pruebas, más pruebas, y... comienzan las prisas: Los usuarios quieren YA la aplicación. Por lo tanto, los programadores comienzan a modificar la aplicación (a veces un conjunto de aplicaciones que forman un sistema) como pueden, a toda prisa. No hay tiempo para documentar, y pasan unos cuantos meses.

A estas alturas, los jefes de equipo ya no saben bien en donde están: Saben que su aplicación es muy grande, que cuesta mucho esfuerzo mantenerla, y que es la mejor , pero realmente, no saben como de grande, ni cuanto se modifica cada semana.

Tampoco pueden detectar bien los desarrollos que han sido más complicados de los que no lo son. Y quizás mas importante, como no tienen ninguna medida del proyecto, no pueden aplicar la experiencia para estimar nuevos tiempos de desarrollos.

Esta era la situación, y sigue siéndolo. Las herramientas han mejorado, pero la valoración del proyecto continúa

...