Ingeniería de Software

Evolución
1. 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.
  1. ¡¡Prueba y Error!!
  2. Para esta época el coste del hardware era extremadamente superior al software
  3. Se consideraba que el ingeniero de software solía ser el mismo que el de hardware
  4. Solo el programador conocía y entendía su código.
2. 1970 Surge la multi-programación y los sistemas multi-usuario.
  1. Aparece el concepto Hombre-Máquina
  2. Nace la primera generación de gestión de bases de datos
  3. Codifica y corrige
    1. Los errores tenían que ser corregidos apenas se detectaban fallas, y los programas cambiaban al cambiar los requisitos
    2. 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
      1. Por esto, nace el término de Ingeniería del Software, en una conferencia financiada por la OTAN
3. 1980, es caracterizada por su productividad y escabilidad de sistemas de desarrollo.
  1. La industria del software se convierte en la cuna de la economía mundial
  2. Las técnicas de desarrollo del software (4Gls) incrementan la productividad a través de la programación por el usuario.
  3. Se introduce la tecnología de la programación orientada a objetos (POO) a través de multiples lenguajes de programación.
  4. Se crea el primer módulo de madurez de capacidad de procesos (SW-CMM)
4. 1990, la orientación a objetos se extiende a las fases de análisis y diseño.
  1. Se implementa el lenguaje de modelado (UML)
  2. Se genera el 1er proceso comercial de desarrollo orientado a objetos (RUP)
  3. Se define el modelo en espiral para el desarrollo basado en análisis de riesgos
  4. Se define el desarrollo de software iterativo e incremental.
  5. 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.
  6. La usabilidad de sistemas se convierte en el foco de atención e investigación.
5. En la actualidad los temas atañen a la agilidad en el desarrollo y el valor para el cliente.
  1. Dispositivos como celulares, PDAs entre otros, se involucran en el ciclo de vida.
  2. Se incrementa la programación de software empaquetado.
  3. Se incrementa el desarrollo dirigido por modelos y se integra el desarrollo de software con el de sistemas.
  4. La conectividad global por parte del internet evoluciona la economía.
  5. 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.
  6. 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.
  7. Manifiesto ágil, como intento de simplificar la complejidad de las metodologías existentes
6. 1960, la época de los famosos códigos espaguetti"
  1. Ideas como "reutilización de código" y "arquitectura de software" se van planteando
  2. Se impulsa la programación estructurada
  3. Se cita por primera vez el término fábrica de software
Crisis del Software
1. 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.
  1. 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.
  2. 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.
  3. La mala especificación de los requerimientos de software es de las principales causas de los problemas de los sistemas basados en software.
2. En Colombia
  1. 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.
  2. Existía una ausencia casi total de investigación y de estimulo a la creatividad y la innovación.
  3. El individualismo y la falta de solidaridad no facilitan el trabajo en grupo ni las construcciones colectivas.
3. Uno de los principales problemas que ocasionaron esta crisis, es la utilización de la metodología derivada de programar-corregir
4. 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.
  1. Esto ocasiona que haya una gran cantidad de proyectos que fallen, sobrepasando los costos y los tiempos. Y así, clientes insatisfechos.
5. Ante esto, gracias al proceso unificado (UP) y en particular (RUP) el desarrollo por ciclos es una buena estrategia de construcción de software.
6. El proceso de software por equipos (TSP) también basa su estrategia en ciclos incrementales.
Los mitos
1. Los requerimientos son claros desde el principio.
  1. “se deben tener todos los requerimientos del sistema claramente definidos antes de empezar el proyecto para que éste sea exitoso”.
    1. 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
    2. 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.
2. Los diseños se pueden elaborar de manera completa y validarse antes de la construcción.
  1. “diseñar completamente antes de empezar a programar para que sea más efectiva la labor de programa- ción y más independiente”.
    1. Es imposible hacer un diseño completo y detallado para un conjunto de requerimientos incompletos y ambiguos.
    2. Diseñar es todo un proceso de tomar decisiones sobre cómo romper en partes (componentes, módulos, objetos, aspectos y servicios)
3. El proceso de construcción es predecible
  1. 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?
    1. 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.
    2. 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.
4. hay gente bien entrenada y especializada para la realización de las distintas labores.
  1. 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?
    1. 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.
5. “se deben tener todos los requerimientos del sistema claramente definidos antes de empezar el proyecto para que éste sea exitoso”.

Próximo

Descrição

Resumo de Recurso

Semelhante

	Criado por ANDRES CAMILO YANEZ ESCOBAR aproximadamente 4 anos atrás