Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas

1. Universidad de Los Lagos Curso Ingeniería de SoftwareINFT.1 Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas.com

2. Objetivos • Descripción de las actividades técnicas e ingenieriles que se llevan a cabo en el ciclo de vida de un producto software • Descripción de los problemas, principios, métodos y tecnologías asociadas con la Ingeniería del Software • Presentación de la importancia de los requisitos en el ciclo de vida del software • Introducción a las técnicas básicas de elicitación, documentación, especificación y prototipado de los requisitos de un sistema software • Introducción a los métodos de análisis/diseño estructurado, y los métodos de análisis/diseño orientado a objetos • Estudio y comprensión de los fundamentos del diseño de sistemas software • Aplicar de forma práctica los conceptos teóricos sobre el desarrollo estructurado y orientado a objetos

3. Motivación

4. La Ingeniería del Software dentro del currículo de los ingenieros en informática aporta la primera aproximación a la práctica real del desarrollo de software • Proyectos realizados por equipos de desarrollo • Programación a gran escala (programming in large) • Obtención (elicitación) de los requisitos • Modelos de ciclo de vida • Gestión de la configuración • Calidad del software • Mantenimiento • ……

5. ¿Ingeniería? de Software

6. Ingeniería vs Métodos Tradicionales

7. Grandes Problemas Históricos • Retraso respecto al potencial de hardware • Insatisfacción de la demanda • Bajo cumplimiento de compromisos – costos, plazos • Baja calidad y satisfacción de clientes/usuarios • Mantención de sistemas legados

8. Percepciones de la Disciplina • Ineficiencia Altos costos • Baja confiabilidad • Escasa ingeniería

9. Crisis del Software • Origina la disciplina “Ingeniería de Software” en los 60s • Síntomas típicos • funcionalidad incorrecta • costos y plazos excedidos • insatisfacción de clientes y usuarios • poca o nula visibilidad de lo que ocurre

10. Crisis del Software • Algunas causas potenciales • carácter lógico del software • formación profesional (o falta de) • entrenamiento y actualización • resistencia al cambio • Solución potencial • incorporar enfoque ingenieril en la forma de un proceso de software …

11. Crisis del Software • Algunos mitos bastantes arraigados también • estándares y procedimientos bastan • tecnología de punta basta • más gente para ponerse al día • programación inmediata • fácil acomodo de los cambios • programación: fin del trabajo • calidad: sólo del ejecutable • código es el único producto

12. Ingeniería de Software • “ Establecimiento y uso de principios con caracteres de ingeniería apropiados para obtener, eficientemente, software confiable, que opere eficaz y eficientemente en máquinas reales “ Concepto se acuñó en 1968, en Conferencia de la OTAN en Alemania , con la intención de que mediante el uso de filosofías y paradigmas de disciplinas ingenieriles establecidas se resolviera la denominada crisis del software

13. Ingeniería de Software • Objetivos • maximizar calidad • maximizar productividad • minimizar riesgos

14. Ingeniería de Software • Implicancias • mejores técnicas de control de calidad • mejores herramientas y métodos • Todo en la forma de proceso de software adecuado al tipo de problema que se resuelve y que permitan gestionar de mejor manera los principales riesgos relevantes para todos los stakeholders (involucrados o afectados)

15. Proceso de Software Para Gestionar Riesgos

16. Proceso de Software Operación Desarrollo de software Análisis Diseño Construcción y Pruebas Unitarias Pruebas Mantención Procesos de apoyo: Gestión de proyectos, Gestión de Configuración, Gestión de Requerimientos, Gestión de la Calidad, ……….

17. Riesgos de Software • Categorías - Top 10 • Métricas inadecuadas • Medición inadecuada • Presión excesiva de tiempo • Malas prácticas de gestión • Estimación imprecisa de costos • Síndrome del “silver bullet” • Requerimientos Baja calidad • Baja productividad • Cancelación de proyectos

18. Proceso de Software • Proveer un producto o un servicio, siempre consiste en seguir una secuencia de pasos, para llevar a cabo un conjunto de tareas • Las tareas se ejecutan usualmente en el mismo orden todas las veces • Un proceso es una serie de pasos que involucran actividades, restricciones y recursos, que producen una salida esperada, de algún tipo. • Un proceso involucra usualmente un conjunto de herramientas y técnicas.

19. Proceso de Software • Es importante, pues impone consistencia y estructura al conjunto de actividades • Es más que un procedimiento, es un conjunto organizado de éstos. • La estructura del proceso guía la acción, permitiendo examinar, entender, controlar y mejorar las actividades comprendidas por éste. • También es importante pues permite capturar y transmitir la experiencia, a proyectos futuros • Cada proceso puede ser descrito por una combinación de diferentes medios.

20. Un poco de Historia • El modelo usado era de codificar-corregir: • Escribir el código. • Revisar y eliminar los errores o mejorar/aumentar la funcionalidad. • A medida que el hardware aumentó sus capacidades y disminuyó sus costos, se amplió el ámbito de las aplicaciones y se masificó el uso de computadores. • Se incursionó en áreas donde los problemas no eran tan bien acotados (ej. administrativos) y el desarrollo se tornó más complejo.

21. Un poco de Historia • Aparece un problema aún mayor: había que mantener los sistemas. • Esto escapó de las manos de los usuarios- programadores, quienes ya no pudieron controlar el proceso, pues sólo dominaban su especialidad, no el desarrollo de software. • Se incorporan tópicos organizacionales y psicológicos, así como también la demanda por mayor calidad y confiabilidad.

22. Un poco de Historia • Además, ahora el desarrollo se convierte en una actividad de grupo, lo cual demanda planificar, organizar y estructurar el trabajo en torno a “proyectos”. • La comunicación entre humanos (usuario- desarrollador y desarrollador-desarrollador) se convierte en un problema. • Se hace necesario definir un “Proceso

23. Un poco de Historia • El proceso a la antigua, como “caja negra”.

24. Modelos de Proceso de Software • En la Ingeniería de Software se describen muchos Modelos de Proceso. • Unos son prescriptivos: establecen la forma en que debería progresar el proceso de software. • Otros son descriptivos: dicen la forma en que el proceso de software progresa en la realidad.

25. Algunos Modelos deProceso de Software • Modelo en Cascada. • Modelo en V. • Modelo de Prototipación. • Modelo en Espiral. • RUP Métodos Ágiles.

26. Modelo en Cascada • Es el más antiguo. • Debe completarse un estado antes de comenzar el siguiente. • Es útil para que el desarrollador visualice lo que va a hacer. • Su principal problema es que no refleja la realidad..

27. Modelo en Cascada

28. Modelo en Cascada • Análisis de Requerimientos: • Se centra e intensifica especialmente en el software • El ingeniero de software debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas • Diseño (sistema y programa): • Se enfoca en cuatro atributos: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz • El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación • Codificación: • El diseño debe traducirse en una forma legible para la maquina. Si el diseño se realiza de una manera detallada la codificación puede realizarse automáticamente

29. Modelo en Cascada • Prueba (unitario, integración, sistema, aceptación): • una vez que se ha generado el código comienza la prueba del programa. • La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados requeridos • Mantenimiento: • el software sufrirá cambios después de que se entrega al cliente, los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento

30. Modelo V

31. Modelo V • La primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integración asociado a cada una de las etapas de la mitad anterior. • Se puede identificar una ventaja principal con respecto al Modelo Cascada más simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada.

32. Modelo de Prototipación • Permite la construcción rápida del sistema (o parte de éste). • Usuario y desarrollador tienen una visión común. • Se reduce el riesgo y lo incierto del desarrollo

33. Modelo en Espiral • Se combinan las actividades de desarrollo con Análisis de Riesgo. • El modelo es de tipo iterativo: • Planificación → Análisis de Riesgo → Ingeniería → Evaluación → Planificación → • ..En cada iteración, se evalúan las diferentes alternativas y se elige una. • Los gestores del proyecto intentan eliminar o minimizar el riesgo.

34. Modelo en Espiral

35. RUP – Rational Unified Process • Su objetivo es asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. • Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones) • Cada ciclo de vida del software abarca 4 fases en el siguiente orden: concepción/planificación, elaboración, construcción y transición • La esencia de RUP es la iteración, y cada iteración resulta en un entregable preferentemente ejecutable

36. RUP – Rational Unified Process

37. Mapa Conceptual de RUP

38. Fases de RUP: Inception (Inicio) • Se establece la oportunidad y alcance el proyecto. • Se identifican todas las entidades externas con las que se trata (actores) y se define la interacción a un alto nivel de abstracción: • Identificar todos los casos de uso • Describir algunos en detalle • La oportunidad del negocio incluye: • Criterios de éxito • Identificación de riesgos • Estimación de recursos necesarios • Plan de las fases incluyendo hitos

39. Fases de RUP: Inception (Inicio) Productos: • Un documento de visión general: • Requerimientos generales del proyecto • Características principales • Restricciones • Modelo inicial de casos de uso (10% a 20 % listos). • Glosario. • Caso de negocio: • Contexto • Criterios de éxito • Pronóstico financiero • Identificación inicial de riesgos. • Plan de proyecto. • Uno o más prototipos.

40. Fases de RUP: Inception (Inicio) Hito: Objetivos del Ciclo de Vida Inicio Elaboración Construcción Transición • Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo. • Comprensión de los requerimientos plasmados en casos de uso.

41. Fases de RUP: Elaboración • Objetivos: • Analizar el dominio del problema • Establecer una arquitectura base sólida • Desarrollar un plan de proyecto • Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto • Visión de “una milla de amplitud y una pulgada de profundidad” porque las decisiones de arquitectura requieren una visión global del sistema.

42. Fases de RUP: Elaboración Productos: • Es la parte más crítica del proceso: • Al final toda la ingeniería “dura” está hecha • Se puede decidir si vale la pena seguir adelante • A partir de aquí la arquitectura, los requerimientos y los planes de desarrollo son estables. • Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre. • Se construye una arquitectura ejecutable que contemple: • Los casos de uso críticos • Los riesgos identificados

43. Fases de RUP: Elaboración Productos: • Modelo de casos de uso (80% completo) con descripciones detalladas. • Otros requerimientos no funcio-nales o no asociados a casos de uso. • Descripción de la Arquitectura del Software. • Un prototipo ejecutable de la arquitectura. • Lista revisada de riesgos y del caso de negocio. • Plan de desarrollo para el resto del proyecto. • Un manual de usuario preliminar.

44. Fases de RUP: Elaboración Hito: Arquitectura de Ciclo de Vida Inicio Elaboración Construcción Transición • Condiciones de éxito de la elaboración: • ¿Es estable la visión del producto? • ¿Es estable la arquitectura? • ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos? • ¿Es el plan del proyecto algo realista? • ¿Están de acuerdo con el plan todas las personas involucradas?

45. Fases de RUP: Construcción • En esta fase todas las componentes restantes se desarrollan e incorporan al producto. • Todo es probado en profundidad. • El énfasis está en la producción eficiente y no ya en la creación intelectual. • Puede hacerse construcción en paralelo, pero esto exige una planificación detallada y una arquitectura muy estable.

46. Fases de RUP: Construcción Productos: • El producto de software integrado y corriendo en la plataforma adecuada. • Manuales de usuario. • Una descripción del “release” actual.

47. Fases de RUP: Construcción Hito: Capacidad Operacional Inicio Elaboración Construcción Transición • Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos. • Condiciones de éxito: • ¿El producto está maduro y estable para instalarlo en el ambiente del cliente? • ¿Están los interesados listos para recibirlo?

48. Fases de RUP: Transición • El objetivo es traspasar el software desarrollado a la comunidad de usuarios. • Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos). • Incluye: • Pruebas Beta para validar el producto con las expectativas del cliente • Ejecución paralela con sistemas antiguos • Conversión de datos • Entrenamiento de usuarios • Distribuir el producto

49. Fases de RUP: Transición Objetivos: • Obtener autosuficiencia de parte de los usuarios. • Concordancia en los logros del producto de parte de las personas involucradas. • Lograr el concenso cuanto antes para liberar el producto al mercado. Inicio Elaboración Construcción Transición Producto

50. Métodos Ágiles • Interés creciente en los métodos ágiles (inicialmente llamados ligeros, lightweight) en los últimos años • enfrentamiento de requerimientos cambiantes • tiempos de desarrollo escasos • clientes y usuarios cada vez más exigentes • Caracterizados alternativamente como • antídoto a la burocracia (métodos planificados, pesados)