Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Tomado de:

Presentación del tema: "Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Tomado de:"— Transcripción de la presentación:

1 Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Tomado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

2 Definición (1993) La aplicación mecanismos sistemáticos, disciplinados, y cuantificables para el desarrollo, operación y mantención de software; esto es la aplicación de la ingeniería al 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 La aplicación del arte del desarrollo software junto con las ciencias matemáticas y computadores para diseñar, construir, y mantener programas computacionales eficientes y económicos que logran sus objetivos.

3 Estado del arte en Ing. De Software ¿Es una ciencia rigurosa con fuertes fundamentos matemáticos? ¿Es una campo técnico bien desarrollado con mucho de disciplina de ingeniería? O está realmente en un estado primitivo... A lo más una serie de “mejores prácticas”, desarrolladores de software construyen software y si éstos funcionan entonces nosotros estudiamos como ellos lo hicieron. Si éstos funcionan por un largo tiempo entonces estudiamos sus procesos de software aún más cuidadosamente.

4 Construcción de una casa para “fido” Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples

5 Construcción de una casa Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

6 Construcción de un rascacielos

7 Herramientas (Ej: Rational Rose) Proceso (Metodologías Ej: ITIL, Extreme Programming, RUP: Rational Unified Process) Notación (UML) Claves en Desarrollo de SI Calidad: Ej: CMM

8 Sistema Computacional Proceso de Negocios Orden Item envío “El modelado captura las partes esenciales del sistema ” Abstracción - Modelado Visual (MV)

9 Interfaz de Usuario (Visual Basic, Java,..) Lógica del Negocio (C++, Java,..) Servidor de BDs (C++ & SQL,..) Múltiples Sistemas Componentes Reutilizados Manejar la complejidad “Modelar el sistema independientemente del lenguaje de implementación” Promover la Reutilización Notación (Visual) - Beneficios

10 ¿Por qué la Orientación a Objetos? Proximidad de los conceptos de modelado respecto de las entidades del mundo real Mejora la captura y validación de requisitos Acerca el “espacio del problema” y el “espacio de la solución” Modelado integrado de propiedades estáticas y dinámicas del ámbito del problema Facilita construcción, mantenimiento y reutilización Podríamos dar muchas razones pero hay problemas..

11 “...Los conceptos básicos de la OO se conocen desde hace dos décadas, pero su aceptación todavía no está tan extendida como los beneficios que esta tecnología puede sugerir” Problemas en OO

12 … Problemas en OO Un objeto contiene datos y operaciones que operan sobre los datos, pero... Podemos distinguir dos tipos de objetos degenerados: Un objeto sin datos (que sería lo mismo que una biblioteca de funciones) Un objeto sin “operaciones”, con sólo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondería con las estructuras de datos tradicionales) Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos

13 Proceso de Desarrollo de SW

14 El proceso de desarrollo “Completo” Se da en un contexto y dependiendo el texto o investigador destaca más o menos etapas. El más completo que he visto incluye: Al desarrollo es a lo que normalmente se la da más énfasis en la literatura. SueñoLanzamientoInvestigaciónDesarrolloSoporte Tiempo

15 Requisitos nuevos o modificados Sistema nuevo o modificado Proceso de Desarrollo de Software ¿Qué es un Proceso de Desarrollo de SW? Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable SueñoLanzamientoInvestigaciónDesarrolloSoporte Tiempo

16 Áreas cubiertas por la Ing. de Solftware La Ingeniería del Software estudia todos los aspectos involucrados en el desarrollo de software, entre los cuales se encuentran: Etapas de un Proyecto de software Paradigmas / enfoques para enfrentar el desarrollo del proyecto de software (Cascada, Interativo incremental) Tiempo y Costos Aspectos tecnológicos Gestión de Proyectos

17 Etapas de un proyecto de Software Etapas / Hitos escenciales rqueridos en un proyecto de desarrollo de software: Oportunidad de Negocio (Hito) Levantamiento Incial de Requerimientos (Dominio del problema) Entendimiento inicial de la problemática a resolver Reuniones con Cliente Especificación inicial de requerimientos Confección de Propuesta Estimación de esfuerzos y planificación del proyecto. Uso de técnicas (COCOMO) y estadisticas de proyectos similares al que se dessarrollará, entrevistas a personas con experiencia en proyectos similares al que se desarrollará Definición del alcance del proyecto Costos Análisis OO (Dominio del problema) Casos de Uso – análisis dinámico Modelos Conceptuales – análisis estático Diseño preliminar de interfaces (web, GUI, comandos, voz)

18 Etapas de un proyecto de Software (cont) Arquitectura (Dominio de la Solución) Especificación de la tecnología a utilizar (J2EE,.NET) Especificación de Patrones de Diseño Diseño (Dominio de la Solución) Diseño de Interfaces (web, gui, comandos, voz) Realización de diagramas de secuencia Realización de diagramas de clases Construcción / Codificación Entendimiento real del diseño ( solución) a programar Programación eficiente y optima del código fuente Comentar en forma entendible y razonable el código fuente Construcción de programa de “TEST” Prueba unitaria del desarrollador mediante un programa de “TEST” Pruebas Unitarias Realización de plan de pruebas Pruebas Integradas Realización de plan de pruebas

19 Etapas de un proyecto de Software (cont) Capacitación a Usuarios Confección de Manuales de Usuario Reuniones con usuario final Puesta en Producción Confección de plan de puesta en producción Marcha Blanca Garantía Resolución de Incidencias

20 Planificar y Evaluar Proyectos... ¿Podré cumplir con los plazos? ¿Estaré dentro de lo presupuestado? ¿El “cliente” quedará satisfecho? Las Metodologías pueden ser la ayuda que necesitamos, si podemos usarlas correctamente !!

21 Procesos, Metodologías

22 ¿Qué es una Metodología... Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente.

23 Las ágiles más conocidas... XP (Programación Extrema) La familia Cristal de Cockburn Código Abierto ASD (Desarrollo de Software Adaptable) SCRUM FFD (Desarrollo Manejado por Rasgos) DSDM (Método de desarrollo de sistema dinámico) RUP (Rational Unified Process) Yo no conozco todas, pero vale la pena conocer al menos una. Aquellas en rojo son la más populares.

24 Metodologías en área TI Más detalles aquí.

25 Apostando por RUP...

26 Desarrollo de software: Características de RUP... Guiado y Manejado por Casos de Uso Centrado en la Arquitectura Iterativo e Incremental Desarrollo Basado en Componentes Utilización de UML Proceso Integrado

27 Principales metodologías en el tiempo Tiempo Modelo Tradicional de Cascada Tiempo Definición de Requerimientos Análisis & Diseño Implementación y Test Unitarios Construcción/Pruebas t t Iteración 1Iteración 2Iteración 3 P C A&D R P C R P C R Modelo Iterativo Incremental Integración y test del sistema Operación y mantención

28 Tiempo Esfuerzo Necesario por Actividad TransiciónElaboraciónConstrucciónConcepción Iteración Preliminar.... Iteración 1 Iteración 2.... Iteración n Iteración n+1 RUP Define Fases de Desarrollo... Análisis & Diseño Construcción Pruebas Distribución Requerimientos Áreas de trabajo (Workflow) A & D C P D R C P D R C P D R C P D R

29 ConcepciónElaboraciónConstrucciónTransición Compromiso de recursos para fase elaboración Hito Objetivos, visión Hito Arquitectura Hito Capacidad Operacional Aceptación del cliente Liberación Producto Tiempo Importancia de los Hitos en RUP...

30 Mejores Prácticas de RUP... Controle los Cambios Administre los Requerimientos Use Arquitectura de Componentes Modele Visualmente Verifique Calidad Desarrolle Iterativamente

31 Un Ejemplo: Comparar con V-Model (Motorola)

32 Pruebas funcionales Pruebas de desempeño Gestión de requisitos Gestión de cambios y configuración Ingeniería de Negocio Ingeniería de datos Diseño de interfaces Rational Unified Process 1998 RationalObjectory Process 1996-1997 Objectory Process 1987-1995 Enfoque Ericsson UML Rational Unified Process (RUP)

33 Otra visión similar con más Actividades

34 Disciplinas o áreas de trabajo Modelado del Negocio Requisitos Análisis y Diseño Implementación Pruebas Despliegue, distribución Entorno Gestión de configuración y cambios Gestión del proyecto Primarios De Apoyo

35  Deployment Set  Project Management Set  Configuration & Change Management Set  Environment Set  Business Modeling Set  Requirements Set  Analysis & Design Set  Implementation Set  Test Set... Elementos en RUP Artefactos Es el Resultado parcial o final que es producido y usado durante el proyecto. Son las entradas y salidas de las actividades Un artefacto puede ser un documento, un modelo o un elemento de modelo Conjuntos de Artefactos

36 Características Esenciales de RUP Proceso Dirigido por los Casos de Uso Proceso Iterativo e Incremental Proceso Centrado en la Arquitectura

37 Requisitos Capturar, definir y validar los casos de uso Realizar los casos de uso Verificar que se satisfacen los casos de uso Análisis & Diseño Implementación Pruebas Casos de Uso integran el trabajo Proceso dirigido por los Casos de Uso

38 Caso de UsoRealización de AnálisisRealización de Diseño Caso de Prueba X «trace» Pruebas Funcionales Pruebas Unitarias [The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]... Proceso dirigido por los Casos de Uso

39

40  El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes  En el ciclo de vida iterativo en cada iteración se reproduce el ciclo de vida en cascada a menor escala  Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes Proceso Iterativo e Incremental

41 Análisis Diseño Codific. Pruebas e Integración n veces... Proceso Iterativo e Incremental Las actividades se encadenan en una mini- cascada con un alcance limitado por los objetivos de la iteración

42 ... Proceso Iterativo e Incremental Cada iteración comprende: Planificar la iteración (estudio de riesgos) Análisis de los Casos de Uso y escenarios Diseño de opciones arquitectónicas Codificación y pruebas. La integración del nuevo código con el hecho en iteraciones anteriores se hace gradualmente durante la construcción Evaluación de la entrega de ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos) Preparación de la entrega (documentación e instalación del prototipo)

43 Enfoque Cascada Enfoque Iterativo e Incremental Proceso Iterativo e Incremental

44 Grado de Finalización de Artefactos... Proceso Iterativo e Incremental

45 Proceso Centrado en la Arquitectura La arquitectura de un sistema es la organización o estructura de sus partes más relevantes Un arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo Architecture InceptionElaborationConstruction Transition

46 Fases del Ciclo de Vida  El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto  Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones  Las fases son: Inicio o Estudio de oportunidad Elaboración Construcción Transición

47 ...Fases del Ciclo de Vida  Inicio o Estudio de oportunidad (inception) Define el ámbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto  Elaboración Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura básica Se planifica el proyecto considerando recursos disponibles

48 ...Fases del Ciclo de Vida Construcción El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programación y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentación

49 ...Fases del Ciclo de Vida Transición Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la información anterior Estas tareas se realizan también en iteraciones

50 15% 10% 15% 30% 15% Preliminary Iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 InceptionElaborationConstructionTransition Una iteración en la fase de elaboración Requisitos Diseño Implementación Pruebas Análisis Esfuerzo respecto de las Workflows

51 Preliminary Iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 InceptionElaborationConstructionTransition Una iteración en la fase de elaboración Requisitos Diseño Implementación Pruebas Análisis Esfuerzo: 5%20% 65% 10% Duración: 10%30% 50% 10%...Esfuerzo respecto de las Fases

52 Dos lecciones importantes El tiempo es independiente del contexto. Ahorrar una semana la comienzo de un proyecto es tan bueno como ahorrarla al final. Una semana es una semana. Es mucho más fácil ahorrar tiempo al inicio del proyecto (cuando los entregables son menos claros). Conclusión: Pronto hay que tener claro el proyecto del ramo.

53 Idea relacionada: Patrones de Diseño Es una solución a un problema general de diseño. Tiene la forma de un conjunto de clases que inter- actúan. Las clases requieren personalización al caso específico (partes en blanco)

54 Ejemplo: Patrón Observador Modelo, vista, controlador Vista Modelo Controlador