Fundamentos de Ingeniería de Software [Modelos]

Transcripción

1 Fundamentos de Ingeniería de Software [Modelos] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-I Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 1 / 59

2 Modelos de proceso de software Modelos de proceso de software I Un proceso de software es una secuencia de actividades que conducen a la elaboración de un producto de software. El desarrollo puede ser desde cero o extendiendo y modificando software ya existente. Actividades básicas de un proceso de software. Especificación del software. Definir el alcance del proyecto. Clientes Ingenieros. Desarrollo del software. Diseño y Programación. Ingenieros. Validación del software. Pruebas. Ingenieros + Clientes. Evolución del software. Estar al día con las necesidades del cliente. Ingenieros + Clientes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 2 / 59

3 Modelos de proceso de software Modelos de proceso de software II Las descripciones de los procesos deben considerar: El producto final. Diseño de software arquitectura del software. Roles/Funciones. Responsabilidades y funciones de los involucrados en el proyecto. Precondiciones y postcondiciones. Declaraciones válidas de actividades/módulos del proceso. Se analizarán los siguientes modelos de proceso de software: En cascada. Royce En espiral. Barry Bohem Incremental. Orientado a la reutilización. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 3 / 59

4 Modelos de proceso de software Modelo en cascada I Modelo en cascada Se denomina modelo en cascada por que cada fase del modelo conduce a otra. También se conoce como ciclo de vida del software. Consiste de cinco fases. Análisis y definición de requerimientos. Diseño del sistema y del software. Implementación y pruebas de unidad. Integración y pruebas del sistema. Operación y mantenimiento. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 4 / 59

5 Modelos de proceso de software Modelo en cascada Modelo en cascada II Análisis y definición de requerimientos Se debe definir el alcance del proyecto -servicios, restricciones, metas- mediante consultas/entrevistas con el cliente y usuarios del sistema. Se debe establecer un documento de especificación de requisitos que servirá como referencia de lo que se debe hacer. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 5 / 59

6 Modelos de proceso de software Modelo en cascada Modelo en cascada III Diseño del sistema y del software Se establecen los requerimientos hardware y/o software del sistema global. Se deben describir a detalle los componentes principales del software y las relaciones entre ellos. Lo anterior debe quedar plasmado en un documento del diseño del software. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 6 / 59

7 Modelos de proceso de software Modelo en cascada IV Modelo en cascada Implementación y pruebas de unidad Se lleva a cabo la programación del diseño del sistema. Se deben realizar prototipos y pruebas sobre estos, que permitan detectar y corregir errores. La pruebas consisten en verificar que cada componente cumpla con su especificación. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 7 / 59

8 Modelos de proceso de software Modelo en cascada Modelo en cascada V Integración y pruebas del sistema Los componentes se integran a fin de formar el sistema global. Se debe verificar el funcionamiento del nuevo sistema acorde a los requerimientos establecidos. Se libera la nueva versión al cliente para sus usuarios también realicen pruebas. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 8 / 59

9 Modelos de proceso de software Modelo en cascada VI Modelo en cascada Operación y mantenimiento Una versión final del sistema queda instalada y puesta en práctica. Los errores que resulten deben ser corregidos. Las mejoras requeridas deben ser realizadas. El sistema debe ser flexible para adecuarse a nuevos requerimientos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 9 / 59

10 Modelos de proceso de software Modelo en cascada VII Modelo en cascada Ventajas La organización y actividades de las fases se encuentran bien definidas. Funciona bien para proyectos donde se encuentran bien definidos los requerimientos y el software que se desea. La planificación es sencilla pues existe una secuencia bien definida de los pasos del proceso de software. La calidad del producto final es alta. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 10 / 59

11 Modelos de proceso de software Modelo en cascada Modelo en cascada VIII Desventajas Las iteraciones pueden ser costosas. Lleva demasiado tiempo atravesar por todo el ciclo. Algunas fases pueden quedar pendientes. Las actualizaciones pueden ser costosas. Si el proyecto es muy grande, su revisión completa puede implicar mucho tiempo. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 11 / 59

12 Modelo en espiral I Modelos de proceso de software Modelo en espiral Es un modelo evolutivo. El modelo se puede visualizar como una espiral donde cada iteración es un conjunto de actividades. Las nuevas actividades se eligen en función de la iteración anterior. Cada giro se puede visualizar como una nueva versión del sistema. Es un enfoque más práctico. Existen diversas variantes de este modelo: Bohem, seis regiones, ganar-ganar. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 12 / 59

13 Modelos de proceso de software Modelo en espiral Modelo en espiral II Modelo de Bohem Planificación. En la primera iteración se realizan la recolección de requisitos y la planificación del proyecto. Después, la planificación puede ir cambiando en base a los comentarios del cliente. Análisis de riesgo. En la primera iteración se realiza el análisis de riesgo basado en los requisitos iniciales. Después, este se adecua a la reacción del cliente. Ingeniería. Una nueva versión del sistema es liberada. Evaluación del cliente. El cliente pone a prueba el sistema incluso puede poner la versión en producción. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 13 / 59

14 Modelos de proceso de software Modelo en espiral III Modelo en espiral Modelo de seis regiones Comunicación con el cliente. Se realiza la recolección de requisitos. Planificación. Planificación del proyecto -recursos, tiempo, etc.-. Análisis de riesgo. Análisis de riesgo basado en los requisitos. Tareas donde se ponen en claro los riesgos técnicos y todo lo relacionado al proyecto. Ingeniería. Construir toda la arquitectura del sistema. Construcción y adaptación. Programar, probar, instalar y dar soporte al usuario. Evaluación del cliente. Obtención de la reacción del cliente. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 14 / 59

15 Modelos de proceso de software Modelo en espiral IV Modelo en espiral Modelo ganar-ganar o teoría W [Boehm y Ross, 1989] Conjunto de precondiciones. Comprender la forma en que las personas quieren ganar. Establecer expectativas por parte de los implicados. Adecuar las tareas. Proceso de software. Establecer un plan realista. Planificar el proyecto. Identificar y gestionar los riesgos donde todos pierden o unos pierden y otros ganan. Mantener implicadas a las personas. Producto software. Adecuar el producto a las condiciones de éxito de los usuarios. Considerar a las personas que daran mantenimiento y soporte. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 15 / 59

16 Modelos de proceso de software Modelo en espiral V Modelo en espiral Ventajas Es un enfoque más realista en el desarrollo de sistemas. Es un modelo adaptativo. Existe mayor comunicación entre el desarrollador y el cliente. Durante la evolución del software se tienen diferentes prototipos. Se eliminan errores y al final se queda la mejor versión. Son mejores desarrollar con base en orientación a objetos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 16 / 59

17 Modelos de proceso de software Modelo en espiral Modelo en espiral VI Desventajas Es difícil sostener y programar las interecciones con el cliente. Se requiere de gran habilidad para la evaluación de riesgos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 17 / 59

18 Modelos de proceso de software Modelo incremental I Modelo incremental Como el modelo en espiral, este también es un modelo evolutivo. La idea es diseñar una implementación inicial y exponerla a los comentarios del usuario. La implementación pasa a través de varias versiones hasta llegar a un sistema final. Cada incremento o versión incorpora algunas de las funcionalidades que requiere el cliente. Las pimeras versiones incluyen las funciones más importantes. El cliente puede desde el inicio si lo que se desarrolla es lo que realmente requiere. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 18 / 59

19 Modelos de proceso de software Modelo incremental Modelo incremental II Bosquejo de descripción Se realiza un documento informal que contiene las principales funcionalidades deseables en el sistema. Este documento servirá como base para la especificación en forma. Especificación Contiene todos los requerimientos del cliente. El documento va evolucionando conforme avanza el proyecto y se adecua a los nuevos requerimientos por parte del cliente. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 19 / 59

20 Modelos de proceso de software Modelo incremental Modelo incremental III Desarrollo Se realiza la implementación con base en los requerimientos de cada iteración. Los errores encontrados en la iteración anterior son corregidos y se agrega la nueva funcionalidad. Validación El cliente evalúa la versión actual del sistema y proporciona las nuevas prioridades a los desarrolladores. Los desarrolladores obtienen retroalimentación constante por parte del cliente a través de las múltiples demostraciones del software. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 20 / 59

21 Modelos de proceso de software Modelo incremental IV Modelo incremental Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 21 / 59

22 Modelos de proceso de software Modelo incremental V Modelo incremental Ventajas Menor costo de desarrollo, pues la documentación es revisada y actualizada más frecuentemente. Es más fácil obtener retroalimentación del cliente. Para el cliente son más palpables los avances realizados a través de las demostraciones de software. La entrega de un software útil - aunque posiblemente no terminado- hacia el cliente se realiza en menor tiempo. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 22 / 59

23 Modelos de proceso de software Modelo incremental Modelo incremental VI Desventajas Las entregas deben ser frecuentes con el objetivo de poder medir el avance. Si no se cuenta con el suficiente personal trabajando sobre el proyecto puede resultar contraproducente. Si el software no tiene bases fléxibles los cambios pueden degradar el sistema. La incorporación de demasiados cambios puede resultar más difícil y costoso. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 23 / 59

24 Modelos de proceso de software Modelo orientado a la reutilización Modelo orientado a la reutilización I Algunos productos de software son desarrollados reutilizando diseños y/o componentes. Es una estrategia propuesta por Douglas McIlroy (Laboratorios Bell - AT&T Bell Laboratories and Bell Telephone Laboratories-) en Este modelo puede ir de la mano con otros modelos de software. Los componentes basados en reutilización pueden ser modificados para expander su funcionalidad. Componentes típicos a reutilizarse: Servicios Web. Disponibles de forma remota. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 24 / 59

25 Modelos de proceso de software Modelo orientado a la reutilización Modelo orientado a la reutilización II Colecciones de objetos. Que se agregan como parte de un marco de componentes (NET, J2EE, Compuware). Sistemas de software indipendientes. De uso específico. Consiste de seis etapas: Especificación de requerimientos. Análisis de componentes. Modificación de requerimientos. Diseño del sistema con reutilización. Desarrollo e integración. Validación del sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 25 / 59

26 Modelos de proceso de software Modelo orientado a la reutilización Modelo orientado a la reutilización III Hewlett-Packard ha tenido éxito utilizando esta filosofía. Libro: Software reuse: Architecture process and organization for business success. Ivar Jacobson, Martin Griss, Patrik Jonsson, ACM Press, Martin Gris de Hewlett-Packard, Ivar Jacobso de Ericsson, Patrik Jonsson de Rational Software Corporation (Suecia). Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 26 / 59

27 Modelos de proceso de software Modelo orientado a la reutilización Modelo orientado a la reutilización IV Análisis de componentes Se realiza una búsqueda de los componentes más adecuados para cumplir con los requerimientos. Pocas veces la coincidencia es exacta. Modificación de requerimientos Se replican los componentes y se modifican para adecuarse a los requerimientos. La modificación puede consistir en ligeros cambios o extensión de la funcionalidad. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 27 / 59

28 Modelos de proceso de software Modelo orientado a la reutilización Modelo orientado a la reutilización V Diseño del sistema con reutilización Se diseña el marco conceptual o se modifica uno existente. Se debe denotar la diferencia entre los componentes reciclados y los nuevos. Desarrollo e integración Se hacen la implementaciones necesarias. Se realiza la integración de los componentes para la creación del producto final. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 28 / 59

29 Modelos de proceso de software Modelo orientado a la reutilización Modelo orientado a la reutilización VI Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 29 / 59

30 Modelos de proceso de software Modelo orientado a la reutilización Modelo orientado a la reutilización VII Ventajas Confiabilidad creciente. El software reutilizable ha sido probado más veces. Reducción de riesgo de proceso. Se conoce ya el costo del software existente. Intervención de especialistas. No se reinventa la rueda y los componentes encapsulan el conocimiento de varios expertos. Cumplimiento de estándares. Las aplicaciones presentan los mismos formatos de menús para los usuarios. Desarrollo acelerado. El software llega más rapido al mercado. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 30 / 59

31 Modelos de proceso de software Modelo orientado a la reutilización Modelo orientado a la reutilización VIII Desventajas Costos crecientes de mantenimiento. Si no se tiene acceso al código fuente no se podrán resolver incompatibilidades con el sistema. Falta de herramientas. Puede ser que los componentes no sean flexibles. No aceptación del software existente. No se tiene confianza sobre el software ya existente y siempre se desea rescribir con la intención de mejorar. Difícil comprensión y adaptación de los componentes a reutilizar. Los desarrolladores deben conocer todos los componentes y sus requerimientos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 31 / 59

32 Actividades del proceso de software Actividades del proceso de software I Un proceso de software debe considerar la relación entre las actividades técnicas, colaborativas y administrativas con el objetivo de especificar, diseñar, implementar y probar un producto de software. Los desarrolladores de software se apoyan de múltiples herramientas para la creación de software. Editores de diseño. Diccionarios de datos. Compiladores. Depuradores. (Debugger) Software para la construcción del sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 32 / 59

33 Actividades del proceso de software Actividades del proceso de software II La combinación de estas herramientas se conoce como Ambiente de Desarrollo Interactivo -Integrated Development Environment IDE-. Eclipse. Ver C, C++, Java, ActiveState Komodo. Ver IntelliJ IDEA. Ver Oracle JDeveloper. Ver. 11g. NetBeans. Ver Microsoft Visual Studio. Ver MyEclipse. Ver Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 33 / 59

34 Actividades del proceso de software Actividades del proceso de software III WinDev y WebDev. Ver Uniface. Ver Actividades que automatizan los IDE s: Modelos de sistemas gráficos. Generación de código a partir de los modelos de sistemas gráficos. Producción de interfaces de usuario a partir de descripciones del usuario. Depuración del programa. Traducción automatizada de programas escritos. Estudiaremos las 4 principales actividades del proceso. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 34 / 59

35 Actividades del proceso de software Especificación del software I Especificación del software La especificación del software -requerimientos- consiste en comprender y definir los servicios que requiere el sistema. Además se deben identificar las restricciones sobre la operación y el desarrollo del sistema. Los errores en esta etapa conducen a problemas en el futuro. El objetivo es elaborar el documento de requerimientos que cumplirá el sistema. Tal documento puede presentar dos niveles de abstracción: detallado del sistema y de usuario. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 35 / 59

36 Actividades del proceso de software Especificación del software Especificación del software II Estudio de factibilidad Las necesidades del usuario se cubren con las tecnologías actuales?. Costo-beneficio sujeto a restricciones presupuestales y de tiempo. Se decidirá si se continúa o no con un análisis más detallado. Obtención y análisis de requerimientos Consiste en derivar los requerimientos en base a sistemas existentes, necesidades de los usuarios, análisis de las tareas, entre otros. Desarrollar prototipos puede ayudar a entender lo requerido. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 36 / 59

37 Actividades del proceso de software Especificación del software Especificación del software III Especificación de requerimientos Consiste en plasmar en un documento la información recopilada. Se contemplan los requerimientos del usuario y los del sistema. Validación de requerimientos Se verifica que los requerimientos sean realistas, coherentes y completos. Se corrigen los posibles errores encontrados en el documento. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 37 / 59

38 Actividades del proceso de software Especificación del software IV Especificación del software Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 38 / 59

39 Actividades del proceso de software Desarrollo e implementación I Desarrollo e implementación Esta estapa consiste en convertir las especificaciones en un sistema real. Un diseño de software implica describir la estructura del software a implementar, los componentes, las estructuras de datos a utilizar, las interfaces y los algoritmos. A los que realizan esta labor se le conoce como Arquitectos de Software -Software Architect-. Se parte de un diseño inicial que puede ser modificado o incrementado. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 39 / 59

40 Actividades del proceso de software Desarrollo e implementación II Desarrollo e implementación Se debe considerar que el software puede interactuar con otros sistemas. Sistema operativo Bases de datos Middleware Aplicaciones Si el sistema procesa ciertos datos entonces en el diseño del sistema se deben describir tales datos. Las herramientas de software permiten generar esqueletos a partir de diseños. Cada programador sigue su propia filosofía de desarrollo. Facíl Dfifícil Difícil Fácil Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 40 / 59

41 Actividades del proceso de software Desarrollo e implementación Desarrollo e implementación III Cada programador debe desarrollar pruebas del código que desarrollo y en su caso depurarlo. Es importante considerar múltiples casos de prueba. Diseño arquitectónico Se identifica la estructura global del sistema, los principales componentes y sus relaciones. Diseño de la base de datos Se crea el modelo -ER- de la base de datos y como será su representación física. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 41 / 59

42 Actividades del proceso de software Desarrollo e implementación Desarrollo e implementación IV Diseño de interfaz Se definen la interfaces entre los componentes. Los componentes deben ser como cajas negras para otros componentes. Si ya se cuenta con las especificaciones de la interfaz, los componentes se pueden desarrollar de forma concurrente. Diseño de componentes Se diseña el funcionamiento de cada componente. Cada programador se encarga del cómo teniendo siempre en cuenta el qué. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 42 / 59

43 Actividades del proceso de software Desarrollo e implementación V Desarrollo e implementación Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 43 / 59

44 Actividades del proceso de software Validación de software I Validación de software La validación del software consiste en probar que un sistema cumple tanto con sus especificaciones como con las espectativas del cliente. La principal técnica de validación consiste en utilizar datos ficticios para probar el sistema. Generalmente las pruebas van de lo particular a lo general. Defectos a un nivel global puede implicar el volver a verificar componentes ya revisados. Este es un proceso totalmente iterativo. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 44 / 59

45 Actividades del proceso de software Validación de software Validación de software II Prueba de desarrollo Es un proceso realizado por los programadores. Cada componente se prueba de forma independiente. Existen herramientas que automatizan este proceso o bien pueden ser creadas las propias. JUnit in Action, Petar Tahchiev, Felipe Leme, Vincent Massol and Gary Gregory, 2nd Ed Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 45 / 59

46 Actividades del proceso de software Validación de software Validación de software III Pruebas del sistema El objetivo es descubrir errores de las interacciones entre los componentes. También se busca verificar que el sistema cumple con los requerimientos funcionales. Puede consistir de varias etapas. Pruebas de aceptación El sistema se pone a prueba con datos reales. Los datos reales suelen revelar problemas no detectados con los datos ficticios. Permiten observar el rendimiento global del sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 46 / 59

47 Actividades del proceso de software Validación de software IV Validación de software Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 47 / 59

48 Actividades del proceso de software Evolución del software I Evolución del software El software, a diferencia del hardware, puede ser modificado más facilmente. Es necesario que el software se adapte a las condiciones actuales: Avances tecnológicos. Cambios en el proceso de negocio. Cambios en los sistemas operativos o incluso el hardware. Nuevas necesidades del cliente. Raras veces el software creado es invariante a lo largo de su ciclo de vida. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 48 / 59

49 Actividades del proceso de software Evolución del software II Evolución del software Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 49 / 59

50 El Proceso Unificado El Proceso Unificado El Proceso Unificado Racional -Rational Unified Process RUPfue creado por Philippe Kruchten en Su antecesor es fue el Rational Objectory Process de Este es un modelo híbrido que considera la buena práctica en especificación y diseño y esta de acuerdo con la entrega de prototipos y entrega incremental. Este modelo puede ser utilizado según tres enfoques: Dinámico. Resalta las fases del modelo en el tiempo. Cliente. Estático. Presenta las actividades que se establecen para el proceso. Desarrolladores. Práctico. Sugiere buenas prácticas a utilizar durante el proceso. Desarrolladores. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 50 / 59

51 El Proceso Unificado Fases del Proceso Unificado Fases del Proceso Unificado I Inicio Consiste en modelar el problema del cliente/empresa. Se deben identificar todas las entidades externas (personas y sistemas) que interactuarán con el sistema. Se deben identificar los requisitos necesarios para resolver el problema. Se valora la aportación del sistema al cliente/empresa. Se establece el alcance del proyecto. Pueden generarse algunas estimaciones imprecisas. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 51 / 59

52 El Proceso Unificado Fases del Proceso Unificado Fases del Proceso Unificado II Elaboración Se desarrolla la comprensión del problema. Se resuelven los altos riesgos. Puede que se encuentren más requisitos y se redefina el alcance. Las estimaciones se vuelven más realistas. Se establece un marco conceptual arquitectónico del sistema. Se establecen los casos de uso UML, el diseño arquitectónico y la planificación del proyecto. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 52 / 59

53 El Proceso Unificado Fases del Proceso Unificado Fases del Proceso Unificado III Construcción Consiste en el diseño, programación y pruebas del sistema. Al finalizar esta etapa debe entregarse un software funcionando y la documentación asociada. Transición Consiste en liberar la versión a los usuarios para que la usen en el entorno real. Es una fase costosa y problemática. La documentación del sistema debe ir completamente acorde a éste. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 53 / 59

54 El Proceso Unificado Actividades de ingeniería del Proceso Unificado Actividades de ingeniería del Proceso Unificado I Modelado del negocio Se modelan los procesos del negocio utilizando los casos de uso de la empresa. Requerimientos Se identifican los actores del sistema y se desarrollan los propios casos de uso. Análisis y diseño Se crea y documenta el diseño del sistema mediante modelos arquitectónicos, de componentes, de objetos y de secuencias. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 54 / 59

55 El Proceso Unificado Actividades de ingeniería del Proceso Unificado Actividades de ingeniería del Proceso Unificado II Administración del proyecto Debe existir una planificación que cumpla con las restricciones de costo y tiempo. Además se deben cubrir las necesidades y expectativas del cliente. Entorno Se porporcionan al equipo de desarrollo las herramientas adecuadas al producto que se desea crear. Implementación Se implementan y estructuran los componentes del sistema. La generación automática de código puede acelerar esta actividad. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 55 / 59

56 El Proceso Unificado Actividades de ingeniería del Proceso Unificado Actividades de ingeniería del Proceso Unificado III Pruebas Son un proceso iterativo que va de la mano con la implementación. Administración de la configuración Consiste de varias actividades: Se realiza el ensamblaje de los componentes, librerías, datos y la compilación para crear el ejecutable del sistema. Se realiza la administración de los cambios así como de las versiones. Despliegue Se libera el producto hacia los usuarios. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 56 / 59

57 El Proceso Unificado Actividades de ingeniería del Proceso Unificado Actividades de ingeniería del Proceso Unificado IV Tomado de Unificado Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 57 / 59

58 El Proceso Unificado Buenas prácticas del Proceso Unificado Buenas prácticas del Proceso Unificado I Desarrollo de software de manera interactiva Realizar el desarrollo en base a las prioridades del cliente. Gestión de requerimientos Documentar explícitamente los requerimientos y realizar los cambios necesarios sobre estos. Evaluar el impacto de cambios en el sistema antes de aceptarlos. Usar arquitecturas basadas en componentes Estructurar la arquitectura del sistema en base a componentes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 58 / 59

59 El Proceso Unificado Buenas prácticas del Proceso Unificado Buenas prácticas del Proceso Unificado II Software modelado visualmente Utilizar modelos UML para refresentar procesos en la fases y actividades de ingeniería del Proceso Unificado. Verificar la calidad del software Asegurar que el software cumple con los estándares de calidad establecidos en la empresa. Controlar los cambios al software Gestionar los cambios mediante un controlador de versiones. Además se deben documentar los procedimientos y todo lo necesario para la configuración del sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 59 / 59