Ingeniería de Software

Ingeniería de Software

1. Evolución

   • 1940 y 1950 el desarrollo de software se realizaba sin planificación. El software se creaba, se ejecutaba y ante los fallos se depuraba. La estructura del diseño era implícita, y no existía la documentación.
     • ¡¡Prueba y Error!!
     • Para esta época el coste del hardware era extremadamente superior al software
     • Se consideraba que el ingeniero de software solía ser el mismo que el de hardware
     • Solo el programador conocía y entendía su código.
   • 1970 Surge la multi-programación y los sistemas multi-usuario.
     • Aparece el concepto Hombre-Máquina
     • Nace la primera generación de gestión de bases de datos
     • Codifica y corrige
       • Los errores tenían que ser corregidos apenas se detectaban fallas, y los programas cambiaban al cambiar los requisitos
       • Dado que existían muchas fallas, los desarrollos sobrepasaban el tiempo y los costos, haciendo que el software fuera poco flexible, y esto ocasiona el fenómeno de la CRISIS DEL SOFTWARE
         • Por esto, nace el término de Ingeniería del Software, en una conferencia financiada por la OTAN
   • 1980, es caracterizada por su productividad y escabilidad de sistemas de desarrollo.
     • La industria del software se convierte en la cuna de la economía mundial
     • Las técnicas de desarrollo del software (4Gls) incrementan la productividad a través de la programación por el usuario.
     • Se introduce la tecnología de la programación orientada a objetos (POO) a través de multiples lenguajes de programación.
     • Se crea el primer módulo de madurez de capacidad de procesos (SW-CMM)
   • 1990, la orientación a objetos se extiende a las fases de análisis y diseño.
     • Se implementa el lenguaje de modelado (UML)
     • Se genera el 1er proceso comercial de desarrollo orientado a objetos (RUP)
     • Se define el modelo en espiral para el desarrollo basado en análisis de riesgos
     • Se define el desarrollo de software iterativo e incremental.
     • El software era privado, por lo tanto surge la necesidad de crear proyectos que impulsen la creación de software libre y código abierto.
     • La usabilidad de sistemas se convierte en el foco de atención e investigación.
   • En la actualidad los temas atañen a la agilidad en el desarrollo y el valor para el cliente.
     • Dispositivos como celulares, PDAs entre otros, se involucran en el ciclo de vida.
     • Se incrementa la programación de software empaquetado.
     • Se incrementa el desarrollo dirigido por modelos y se integra el desarrollo de software con el de sistemas.
     • La conectividad global por parte del internet evoluciona la economía.
     • La tecnología digital está transformando a las organizaciones de negocio. Afectan directamente la decisión de los administrativos, la planificación, y a la producción.
     • Actualmente se dispone de lenguajes de programación más sofisticados, procesos de desarrollo más maduros, y las aplicaciones que actualmente se desarrollan son mucho más complejas.
     • Manifiesto ágil, como intento de simplificar la complejidad de las metodologías existentes
   • 1960, la época de los famosos códigos espaguetti"
     • Ideas como "reutilización de código" y "arquitectura de software" se van planteando
     • Se impulsa la programación estructurada
     • Se cita por primera vez el término fábrica de software

2. Crisis del Software

   • A medida que crecen las técnicas de desarrollo de software, la exigencia de la calidad del mismo también aumenta. Ocasionando así una espiral de costos del software.
     • Ocasionando así una escasez de ingenieros de software. En 1991 se estimó que hubo un déficit de un millón de profesionales de software que no cumplían con las exigencias.
     • Si la especificación de requisitos es incorrecta, incompleta o es ambigua, por muy bien que se desarrolle el software posteriormente, resultado final será pobre.
     • La mala especificación de los requerimientos de software es de las principales causas de los problemas de los sistemas basados en software.
   • En Colombia
     • Debido al incremento de facultades, programas y denominaciones, es fácil no comprender el verdadero campo de ingeniero. Esto causó que se requira formar un nuevo tipo de ingeniero.
     • Existía una ausencia casi total de investigación y de estimulo a la creatividad y la innovación.
     • El individualismo y la falta de solidaridad no facilitan el trabajo en grupo ni las construcciones colectivas.
   • Uno de los principales problemas que ocasionaron esta crisis, es la utilización de la metodología derivada de programar-corregir
   • Con la aparición de internet, se implementaron los requerimientos no funcionales. Tales como la escabilidad, la seguridad, tolerancia a fallas, el manejo transaccional entre otros. Todos estos hacen de la construcción de software un reto.
     • Esto ocasiona que haya una gran cantidad de proyectos que fallen, sobrepasando los costos y los tiempos. Y así, clientes insatisfechos.
   • Ante esto, gracias al proceso unificado (UP) y en particular (RUP) el desarrollo por ciclos es una buena estrategia de construcción de software.
   • El proceso de software por equipos (TSP) también basa su estrategia en ciclos incrementales.

3. Los mitos

   • Los requerimientos son claros desde el principio.
     • “se deben tener todos los requerimientos del sistema claramente definidos antes de empezar el proyecto para que éste sea exitoso”.
       • Es normal que el cliente y los usuarios no sepan los detalles de lo que quieren. También es normal que una vez la aplicación esté en uso, aparezcan nuevas posibilidades o se cuestionen los requerimientos
       • Lo correcto es manejar pocos requerimientos a la vez para lograr una mayor focalización. Comenzar centrándose en lo que le da valor al cliente.
   • Los diseños se pueden elaborar de manera completa y validarse antes de la construcción.
     • “diseñar completamente antes de empezar a programar para que sea más efectiva la labor de programa- ción y más independiente”.
       • Es imposible hacer un diseño completo y detallado para un conjunto de requerimientos incompletos y ambiguos.
       • Diseñar es todo un proceso de tomar decisiones sobre cómo romper en partes (componentes, módulos, objetos, aspectos y servicios)
   • El proceso de construcción es predecible
     • No puede de ser predecible. ¿Cómo preveer cuántas veces el cliente va a cambiar de opinión? ¿Cómo prever en qué momento nos vamos a dar cuenta que al diseño le faltaba considerar la escabilidad?
       • cuando no hay claridad en los requerimientos y no se puede tener completos los diseños, es una falacia pretender planificar en detalle el proyecto.
       • El plan inicial debe contener la estrategia, pero por cada ciclo es necesario disponer de un plan con más detalle y luego por cada semana, el detalle necesario como para que se pueda hacer seguimiento, ver avance. Sobre los planes cortos no debería haber re-planeación. Se realiza en forma permanente, conduce a que se pierda la oportunidad de analizar el estimado contra lo real y, lo más importante, la oportunidad de aprender.
   • hay gente bien entrenada y especializada para la realización de las distintas labores.
     • Es difícil conseguir personas bien entrenadas y especializadas en las distintas tecnologías, metodologías y procesos. Tampoco están claro los roles, ¿Quién analiza es capaz de programar? ¿Quién dirige el proyecto sabe de dirección de proyectos o de las tecnologías que se usan? ¿Quién diseña prueba? ¿El que programa habla con el cliente?
       • Se ha vuelto muy complicado encontrar gente calificada que pueda construir aplicaciones utilizando las últimas tecnologías. Y por otro, los desarrolladores que manejan las últimas tecnologías típicamente son los recién egresados que no tienen aún experiencia para enfrentar problemas.
   • “se deben tener todos los requerimientos del sistema claramente definidos antes de empezar el proyecto para que éste sea exitoso”.