Instituto Tecnológico de Culiacán Proyecto Integrador de Ingeniería de Software PRIMERA UNIDAD Introducción ¿ Qué es Ingeniería de Software ? • El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea fiable y funcione de manera eficiente sobre máquinas reales. (Fritz Bauer 1969) • La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software.[IEEE93] Introducción Orientación a Objetos Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas por el hombre, en los negocios y en los productos que usamos. Pueden ser clasificados, descritos, organizados, combinados, manipulados y creados. Por eso no es sorprendente que se proponga una visión orientada a objetos para la creación de software de computadora, una abstracción que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. Introducción Orientación a Objetos El término orientado a objetos significa que el software se organiza como una colección de objetos que contienen tanto estructuras de datos como comportamiento. Introducción OBJETOS BICICLETA Bicicleta Se hace una abstracción que resulta en Tam.del cuadro Tam. De la rueda marchas material Cambiar marcha() mover() reparar() Introducción Orientación a Objetos El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Estos conceptos y herramientas orientados a objetos son tecnologías que permiten que los problemas del mundo real sean expresados de modo fácil y natural. Introducción Programar es divertido, Pero desarrollar software de calidad es difícil. Entre las ideas espléndidas, los requisitos y un producto software funcionando, hay mucho más que sólo programar: Debemos realizar los planos (análisis y diseño) que definen cómo solucionar el problema para obtener un producto software. Definir el modelo arquitectónico Aplicar la ingeniería de usabilidad. Diseñar la Base de Datos Etcétera. Introducción Análisis ¿Qué es el análisis? Es el estudio de un dominio que da como resultado los modelos que describen sus características estáticas y dinámicas. Se centra en las cuestiones del “que” en lugar del “como”. ESPACIO DEL PROBLEMA Pone énfasis en una investigación del problema y los requisitos, en vez de ponerlos en una solución. “Análisis” es un término amplio, es más adecuado calificarlo como análisis de requisitos (un estudio de los requisitos) o análisis de objetos (estudios de objetos del dominio) ¿Qué es el análisis orientado a objetos? Es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema (Booch 1994) Introducción Análisis Análisis Orientado a Objetos. Se presta especial atención a encontrar y describir los objetos en el dominio del problema. Ejemplos: En el caso del sistema de renta de auto: Auto, Cliente, Aseguradora, etc. En el caso del sistema de la biblioteca: Libro, Biblioteca, Socio En el caso del sistema de vuelos: Pasajeros, Aviones,… Introducción Diseño Diseño: Pone énfasis en una solución conceptual que satisface los requisitos, en vez de ponerlo en la implementación. Diseño orientado a objetos Se presta especial atención a la definición de los objetos software y en cómo colaboran para satisfacer los requisitos. Ejemplos: ESPACIO DE LA SOLUCIÓN Objeto LIBRO Titulo GetCap(int c) Atributo Operación Una habilidad crítica en el desarrollo OO es la asignación inteligente de responsabilidades a los objetos software Introducción Análisis y Diseño Introducción Análisis y Diseño El análisis y diseño se han resumido en las freses: • Hacer lo correcto (análisis) • Hacerlo correcto (diseño) Proceso de desarrollo de software Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema de software. Requerimientos del usuario Proceso de Desarrollo de Software Sistema Software Proceso de desarrollo de software: Motivación Hoy en día la tendencia del software es hacia sistemas más grandes y complejos. Esta tendencia también ha sido influenciada por el extensivo uso del internet para intercambiar todo tipo de información. Queremos software que esté mejor adaptado a nuestra necesidades, aunque éste sea cada vez más complejo. En resumen queremos cada vez más. También lo queremos más rápido, el tiempo para construirlo es otro factor importante. Nuestra demanda de software complejo y poderoso no concuerda con el cómo será desarrollado dicho software. Hoy en día, la gente desarrolla software usando métodos que fueron usados desde hace 35 años. Proceso de desarrollo de software La comunidad de desarrollo de software necesita una manera de controlar el trabajo. Se necesita un proceso que integre las muchas facetas del desarrollo de software. Proceso de desarrollo de software Necesitamos un método común, un proceso que: Proporcione una guía para el orden de las actividades del equipo Dirija las tareas de los desarrolladores individualmente y del equipo como un todo. Especifique que artefactos deben ser desarrollados Ofrezca criterios para monitorear y medir las actividades y productos de un proyecto. El marco del Proceso Unificado (UP, del inglés Unified Process) La presencia de un proceso bien definido y bien manejado es un discriminador clave entre un proyecto productivo y exitoso y uno que no lo es. El proceso unificado, se ha convertido en un proceso de desarrollo de software de gran éxito para la construcción de sistemas orientados a objetos. El marco del Proceso Unificado El UP utiliza el lenguaje unificado para la creación de modelos (UML). De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par. Los aspectos que realmente distinguen al Proceso Unificado se capturan en tras frases claves: ■ Conducido por casos de uso ■ Centrado en la arquitectura ■ Iterativo e incremental El PU conducido por casos de uso Ejemplo: uso de un cajero automático. El usuario inserta una tarjeta, responde a las preguntas que emite el cajero en su pantalla y recibe una suma de efectivo. En respuesta a la tarjeta del usuario y sus preguntas, el sistema realiza una secuencia de acciones que provee al usuario un resultado de valor, llamado retiro de fondos. Una interacción de este tipo es un caso de uso. El PU conducido por casos de uso Un caso de uso es una pieza de funcionalidad en el sistema que da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos, construyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. El PU conducido por casos de uso Los casos de uso no solo son una herramienta para especificar los requerimientos de un sistema; también conducen su : ■ ■ ■ Diseño, Implementación y, Prueba. Es decir, los casos de uso conducen el proceso de desarrollo. El PU centrado en la arquitectura El rol de la arquitectura del software es similar en naturaleza al rol que juega la arquitectura en la construcción de un edificio. El edificio es observado desde varios puntos de vista: estructura, servicios, electricidad, etc. Similarmente, la arquitectura en un sistema de software se describe con diferentes vistas del sistema que será construido. El concepto de arquitectura del software abarca los aspectos estáticos y dinámicos del sistema. El PU centrado en la arquitectura La arquitectura está influenciada por otros factores tales como: la plataforma sobre la cual se va a ejecutar el sistema bloques reusables disponibles consideraciones de distribución sistemas heredados y requerimientos no funcionales Requerimientos no funcionales: en la ingeniería de software es un requerimiento que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requerimientos funcionales. A un sistema se le puede pedir que muestre en tiempo real la cantidad de datos de una base de datos: ése es un requerimiento funcional. En cuánto tiempo debería el sistema actualizar su verificación interna de cantidad de datos es, en cambio, un requerimiento no funcional. El PU centrado en la arquitectura ¿Cómo se relacionan los casos de uso y la arquitectura? Cada producto tiene función y forma. Uno o el otro no es suficiente. Estas dos fuerzas deben estar balanceadas par obtener un producto exitoso. En este caso la función corresponde a los casos de uso y la forma a la arquitectura. Se necesita, por lo tanto, la interacción entre los casos de uso y la arquitectura. El PU centrado en la arquitectura El arquitecto moldea el sistema en una forma. Esa forma, la arquitectura, debe ser diseñada de manera tal, que permita al sistema evolucionar, no solamente a través de su desarrollo inicial, sino a través de futuras generaciones. Para encontrar tal forma, los arquitectos deben tener un entendimiento general de las funciones claves, esto es, los casos de uso claves del sistema. El PU es iterativo e incremental Bajo este enfoque, el desarrollo se organiza en una serie de mini-proyectos cortos, de duración fija (por ejemplo, cuatro semanas) llamados iteraciones. El resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado. Cada iteración incluye sus propias actividades de análisis de requisitos, diseño implementación y pruebas. El PU es iterativo e incremental El ciclo de vida iterativo se basa en la ampliación y refinamiento sucesivos del sistema mediante múltiples iteraciones, con retroalimentación cíclica y adaptación como elementos principales que nos conducen hacia un sistema adecuado. El sistema crece incrementalmente a lo largo del tiempo, iteración tras iteración, por eso se dice que es iterativo e incremental. Proceso Iterativo Incremental: se dice que un proceso es iterativo incremental cuando en cada iteración de sus pasos se alcanza una mayor cercanía con los objetivos finales. Esto es, se añade algo nuevo de valor en cada iteración. Requisitos Requisitos Diseño Diseño Implementación & Prueba & Integración & más diseño TIEMPO Integración final & Pruebas de sistema Implementación & Prueba & Integración & más diseño La retroalimentación de la iteración N nos lle va a refinar y adaptar los requisitos y diseño de la iteración N+1. Integración final & Pruebas de sistema 4 semanas (por ejemplo) Se fija la duración de Las iteraciones El sistema crece de manera incremental El PU es iterativo e incremental El resultado de cada iteración es un sistema ejecutable, pero incompleto; no está preparado par ser puesto en producción. El sistema estaría listo después de muchas iteraciones por ejemplo, 10 o 15. El PU es iterativo e incremental La salida de una iteración no es un prototipo experimental o desechable, y el desarrollo iterativo no es prototipado. Más bien, la salida es un subconjunto con calidad de producción del sistema final. El PU es iterativo e incremental Los desarrolladores basan la selección de lo que será desarrollado en cada iteración tomando en cuenta dos factores: Primero: La iteración trata con un grupo de casos de uso que juntos amplían la utilidad del producto, según lo desarrollado hasta ahora. Segundo: La iteración se ocupa de los riesgos más importantes. Beneficios del desarrollo iterativo Mitigación tan pronto como sea posible de los riesgos altos (técnicos, requisitos, objetivos, usabilidad y demás). Progreso visible en las primeras etapas. Una temprana retroalimentación, compromiso de los usuarios y adaptación que nos lleva a un sistema refinado que se ajusta más a las necesidades reales del personal involucrado. Gestión de la complejidad, el equipo no se ve abrumado por la “parálisis del análisis” o pasos muy largos y complejos. El conocimiento adquirido en una iteración se puede utilizar metódicamente para mejorar el propio proceso de desarrollo, iteración tras iteración. EN RESUMEN Los conceptos: dirigido por casos de uso, centrado en la arquitectura y el desarrollo iterativo e incremental, son igualmente importantes. La arquitectura proporciona la estructura en la cual se guía el trabajo en las iteraciones, mientras que los casos de uso definen las metas y conducen el trabajo de cada iteración. El quitar una de estas tres ideas reduciría severamente el valor del proceso unificado. Las Fases del PU Un proyecto con el PU organiza el trabajo y las iteraciones en 4 fases fundamentales: Inicio: visión aproximada, análisis del negocio, estimaciones imprecisas de plazos y costos. Se define la viabilidad del proyecto. Elaboración: visión refinada, implementación iterativa del núcleo central de la arquitectura, resolución de los riesgos altos, identificación de más requisitos y alcance, estimaciones más realistas. Construcción: implementación iterativa del resto de requisitos de menor riesgo y elementos más fáciles, preparación para el despliegue. Las Fases del PU Transición: pruebas beta, despliegue. La fase de inicio NO es una fase de requisitos; sino una especie de fase de viabilidad, donde se lleva a cabo solo el estudio suficiente para decidir si continuar o no. La fase de elaboración NO es la fase de requisitos o de diseño, sino una fase donde se implementa de manera iterativa, la arquitectura, que constituye el núcleo central y se mitigan las cuestiones de alto riesgo. La vida del PU Cada fase esta subdividida en iteraciones Inicio Iter. #1 Elaboración Construcción Iter. # 2.. Transición Iter. #n-1 versiones Un ciclo con sus fases y sus iteraciones Iter. #n… The UP Disciplines Phases Process Disciplines Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Disciplines Configuration Mgmt Management Environment Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iterations Iter. #m Iter. #m+1 Disciplinas del PU (flujos de trabajo) Informalmente una disciplina es un conjunto de actividades (y artefactos relacionados) en un área determinada como las actividades en el análisis de requisitos. En el PU, un artefacto es el término general para cualquier producto del trabajo: código, gráficos Web, esquema de base de datos, documento de texto, diagramas, modelos, etcétera. Nos centraremos en 3 disciplinas: modelado del negocio, requisitos y diseño. Disciplinas del PU (flujos de trabajo) Modelado del negocio Una vez que los miembros del equipo de requisitos se han familiarizado con el lenguaje, el siguiente paso es: ■ construir el modelo del negocio inicial, que es una descripción de los procesos de una empresa (ejemplo: un banco incluye aceptar depósitos de los clientes, conceder préstamos a los clientes y hacer inversiones) La razón para construir un modelo de negocios es que proporciones una comprensión de los negocios del cliente como un todo, ■ con este conocimiento es posible aconsejar al cliente respecto de qué porciones del sistema de información computarizar. Disciplinas del PU modelado del negocio Ejemplo: los procesos de negocios de una empresa de servicios de banquetes incluyen: comprar los ingredientes, preparar los alimentos, servir la comida El proceso comprar ingredientes refinado ■ El encargado del servicio de banquetes ordena los ingredientes a un mayorista El mayorista entrega los ingredientes al encargado del servicios de banquetes El mayorista envía una factura al encargado de banquetes El encargado de banquetes paga la factura Disciplinas del PU modelado del negocio Pueden usarse una serie de técnicas para obtener información necesaria para construir el modelo de negocios, principalmente la entrevista. Disciplinas del PU Requisitos: análisis de requisitos para la aplicación, escritura de casos de uso e identificación de requisitos no funcionales. El objetivo de esta disciplina es asegurar que los desarrolladores construyan el sistema de información correcto, Esto se logra al describir el sistema de información objetivo de una manera suficientemente clara y precisa como para que los dos involucrados principales (cliente y desarrolladores) puedan ponerse de acuerdo en lo que debe y no debe hacer el sistema de información. Con el fin de lograr esto, lo requisitos tienen que ser comprendidos por el cliente. Una manera de lograrlo es usar el PU, porque sus diversos modelos ayudan al cliente a obtener la comprensión detallada necesaria de lo que se va a desarrollar. Disciplinas del PU Análisis El propósito de esta disciplina es examinar y refinar los requisitos. Al hacerlo se logra la comprensión detallada de los requisitos que deben tener para desarrollar correctamente un sistema de información y darle mantenimiento con facilidad. ¿por qué tener la disciplina de análisis? El punto clave es que los artefactos de la disciplina de requisitos deben expresarse en el lenguaje del cliente, es decir en un idioma natural (español, inglés, armenio,…), pero todos los lenguajes naturales de alguna manera son imprecisos y conducen a malas interpretaciones. Disciplinas del PU Análisis Ejemplo: se tiene el siguiente requisito “Un registro de partes y un registro de las planta de fabricación de las mismas se buscan en una base de datos. Si el registro contiene la letra A justo después de la Q, entonces se calcula el costo de transportar esa parte a la planta.” A primera vista ese requisito parece perfectamente claro. Pero ¿a qué se refiere el “registro” (registro de partes o registro de plantas). Con la disciplina de requisitos se formula en el lenguaje del cliente y la disciplina de análisis es un lenguaje más preciso que asegurará que las disciplinas de diseño e implementación se llevarán a cabo correctamente. Disciplinas del PU Diseño En esta disciplina se refina los artefactos del análisis hasta que el material esté en una forma en que los programadores puedan implementar. Además una serie de requisitos necesitan familiarizarse en este momento, incluyendo la elección del lenguaje de programación, así como la reutilización y los problemas de portabilidad. Disciplinas del PU Implementación El objetivo de esta disciplina es instaurar el sistema de información deseado en el lenguaje deseado. En cuanto el componente se ha codificado, el programador lo prueba, una vez que el programador está seguro de que el componente es correcto, se pasa al grupo de aseguramiento de la calidad para una prueba posterior. Disciplinas del PU Pruebas Esta disciplina es responsabilidad del grupo de aseguramiento de la calidad. Cada componente que se ha terminado se prueba, a esto se le llama prueba de unidad. Al final de cada iteración se realiza la prueba de integración. Aquí los componentes que se han completado y a los cuales se les han aplicado las prueba de unidad, se compilan y se ligan y luego se prueban con varios casos de prueba. Cuando el producto parece estar completo, se prueba en conjunto: a esto se llama prueba de producto. disciplinas y modelos en el PU requerimientos Modelo de casos de uso Análisis Modelo de análisis Diseño Modelo de diseño Modelo de distribución Implementación Modelo de implementación Prueba Modelo de pruebas Buenas prácticas del PU adicionales Lo fundamental para apreciar y aplicar el PU es el desarrollo iterativo (fijando iteraciones cortas) y adaptable. Uso de tecnologías de objetos (A/DOO Y POO). Abordar cuestiones de alto riesgo en las primeras iteraciones. Involucrar continuamente a los usuarios para evaluación, retroalimentación y requisitos. Construir en las primeras iteraciones una arquitectura que constituya un núcleo central consistente. Verificar la calidad continuamente; pruebas muy pronto, con frecuencia y realistas. Aplicar casos de uso. Modelar software visualmente (UML). Gestionar los requisitos con cuidado. Manejar peticiones de cambio y gestión de configuraciones.
