Primera Fase (1945-1955):
• Programar no es una tarea diferenciada del diseño de una máquina
• Uso de lenguaje máquina y ensamblador
• El desarrollador desempeña el rol de usuario
Segunda Fase (1955-1965)
• Aparecen multitud de lenguajes, por ejemplo: Cobol, PL/I, Simula 67
• Era posible hacer casi todo
• Programación orienta da a función
Tercera Fase (1965-1970)
• Desarrollo interminable de grandes programas
• Ineficiencia, errores, coste impredecible
• Nada es posible
Cuarta Fase. (1970-1980)
• Fundamentos de programación
• Verificación de programas
• Metodologías de diseño
• Programación orientada a módulos
• El desarrollador ya no cumple el rol de usuario
• Actividad de grupo
• Metodología en cascada
Quinta Fase. El diseño es el problema (1980-?)
• Entornos de programación
• Especificación formal
• Programación automática
• El usuario se incorpora en el proceso de desarrollo
• Inicio de aplicaciones basadas en Internet
• Relevancia de las interfaces de usuario
Esta disciplina surge a finales de los años 60, en el medio de la llamada "Crisis del Software" donde los proyectos de desarrollo eran inacabables, existía una enorme ineficiencia, los costos eran impredecibles y generalmente, aquellos que llegaban al final, (fuera de los tiempos estimados) ofrecían soluciones que ya los usuarios no necesitaban, por no mencionar lo difícil que resultaba el poder darles mantenimiento. Entonces, se decidió seguir el ejemplo de la "Ingeniería Civil", la cual ya tenia cientos de años progresando exitosamente, puesto que en programación se aplica el mismo principio que en la construcción de un edificio: poner simplemente ladrillos y cemento (echar código) no es suficiente. Su elaboración consta de diversos pasos antes de comenzar con la fase de construcción, tales como el diseño arquitectónico, la albañilería, la fontanería, el diseño eléctrico, y durante este período se calculan los presupuestos y los plazos.
La ingeniería de software requiere la gestión de proyectos para que se pueda desarrollar una aplicación en el plazo previsto y con el presupuesto establecido que sea satisfactoria para el cliente (el concepto de calidad). A partir de ese entonces, surgirían en las décadas siguientes, mucha cantidad de modelos de desarrollo, empezando por el tradicional Cascada, luego incorporando mejoras con el modelo espiral, y eventualmente se concebirían metodologías incrementales pesadas como la bien conocida Proceso Unificado o ágiles como XP.
Sin embargo independientemente de su naturaleza, todas siguen en mayor o menor medida los siguientes pasos o fases:
· Requerimientos del software: la obtención, análisis, especificación y validación de los requerimientos para el software.
· Diseño de software: diseño del software, generalmente llevado a cabo con herramientas CASE y el uso de lenguajes de diseño como el UML.
· Desarrollo/implementación de software: es la construcción del software empleando lenguajes de programación.
· Testeo/prueba del software.
· Mantenimiento del software: solución de los problemas del software ya desarrollado
La ingeniería del software, en comparación con otras ramas de la ingeniería aún se encuentra muy joven, en los tiempos actuales aún se está buscando una forma clara de definirla o trabajarla y la búsqueda de estándares que lleven a un mejor perfeccionamiento en el desarrollo del software. De ahí las continuas interrogantes de considerarla ingeniería o no. Algunos autores consideran que sí, que aún se está en la etapa de establecimiento de bases, otros por el contrario no la califican como tal por falta de técnicas y conocimientos generales que se apliquen en el desarrollo del software.
Uno de los problemas actuales que enfrenta la ingeniería del software es el problema de la estimación. Aunque existen muchas teorías y técnicas al respecto, en la práctica ha resultado terriblemente difícil hacer buenas estimaciones de los proyectos de software.
Una de las grandes desventajas de las metodologías de desarrollo tradicionales o pesadas es precisamente la facilidad con la que el tiempo de desarrollo del proyecto se expande. Hasta cierto punto este problema se ha mejorado con las metodologías ágiles ya que estas se “deshacen” un poco de la formalidad y permiten ir directamente a la acción. Sin embargo, no resuelven el problema de la estimación, solo hacen más expedito el proceso de desarrollo. En ese sentido, vale la pena reflexionar y pensar que, del mismo modo en el que las metodologías de desarrollo han evolucionado a lo largo de los años (de pesadas a ágiles), las técnicas y herramientas para la estimación de proyectos de software también deben evolucionar.
En respuesta al problema de la estimación un grupo de personas han desarrollado el Evidence-Based Scheduling (Planificación Basada en la Evidencia). Este tipo de planificación plantea que, en lugar de hacer estimaciones iniciales y al final (cuando las estimaciones no se cumplen) preguntar ¿que paso?, se pueden usar los datos históricos de cada desarrollador para hacer simulaciones (usando el método de Monte Carlo) que permitan obtener estimaciones más precisas. De esta forma el gerente del proyecto podrá, por ejemplo, consultar la probabilidad de que el proyecto esté listo para la fecha planteada y tomar las decisiones que le permitan cumplir con este objetivo. El Evidence-Based Scheduling no es ampliamente usado, pero el planteamiento central es lo que llama la atención: usar métodos estadísticos para hacer estimaciones más cercanas a la realidad.
Fuentes:
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
http://es.kioskea.net/contents/genie-logiciel/genie-logiciel.php3
http://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3
http://en.wikipedia.org/wiki/Software_engineering
http://www.acis.org.co/fileadmin/Revista_102/columnista.pdf
http://www.fogcreek.com/fogbugz/evidence-based-scheduling/
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software
Actividades en la IS - Modelos de desarrollo de software. Prof. Pedro Bonillo
No hay comentarios:
Publicar un comentario