Ingenieria de softwrae vol1 v4 2
- 1. Objetivos de la unidad 1 – Definir qué es la ingeniería de software y explicar su importancia – Presentar los diferentes modelos de proceso de software – Definir el concepto de requerimientos del software – Enumerar las actividades de análisis de requerimientos – Describir las funciones y componentes de una SRS – Discutir algunos tipos de métricas de software, tales como, métricas orientadas al tamaño, métricas orientadas a función – Definir las diferentes actividades para llevar a cabo el análisis de riesgo
- 2. Objetivos – Discutir el planeamiento y cronograma de un proyecto de software – Describir los términos de control de calidad y aseguramiento de calidad, en el contexto del software – Presentar los diferentes niveles de prueba – Explicar los métodos involucrados en el proceso de prueba unitaria – Establecer los enfoques involucrados en la prueba de integración – Presentar los deferentes componentes de la prueba del sistema
- 3. Unidad 1: Fundamentos de Ingeniería de Software
- 4. Objetivos de Aprendizaje • Explicar el software como un producto y proceso • Definir la ingeniería de software y explicar su importancia • Discutir las ventajas y desventajas de diversos modelos de proceso de software • Discutir acerca de los Modelos Evolutivos y Secuenciales
- 5. Introducción • La ingeniería de software provee metodologías y técnicas que ayudan a desarrollar sistemas de software a tiempo • La ingeniería de software asegura que el desarrollador cumpla con las expectativas de calidad y presupuesto • Las metodologías de la ingeniería de software fomentan un enfoque sistemático a lo largo del ciclo de vida del software
- 6. Características del SoftwareRobusto Reutilizable Eficiente Utilizable Mantenible Evolutivo Confiable Portable Características del Software
- 7. Tipos de Aplicaciones de Software Ingeniería y Científicas Negocio Incorporadas Sistema Computadoras Personales e Individuales Tiempo Real Tipos de Aplicaciones de Software
- 8. Proceso de Software Un proceso se define como: • Una serie de operaciones usadas en la creación de un producto • El conjunto de tareas, que tienen que ser realizadas para generar un producto de software de alta calidad • Aquello que se sigue para construir el producto de software ACTIVIDAD 1 TAREA 1TAREA 1 TAREA X• • • PROCESO ACTIVIDAD n• • •
- 9. Características del Proceso de Software Facilidad de Mantenimiento Robustez Rapidez Comprensión Facilidad de Verificación Confiabilidad Facilidad de Soporte Facilidad de Aceptación Visibilidad Facilidad de Adaptación Características del Proceso de Software
- 10. Fases del Proceso de Desarrollo de Software • Fase de Definición: - Ingeniería de información - Planeamiento del proyecto de Software - Análisis de requerimientos • Fase de Desarrollo: - Diseño de Software - Codificación - Prueba • Fase de Mantenimiento
- 11. Categorías de Modelos de Procesos de Software • Modelo Secuencial Lineal • Modelo de Creación de un Prototipo • Modelo Evolutivo • Modelo de Métodos Formales • Sistema Ensamblado de Componentes Reutilizables
- 12. Modelo de Cascada Ingeniería de Sistema Análisis de Requerimientos Diseño Codificación Prueba Mantenimiento
- 13. Modelo de Cascada Ventajas: – Posibilita un orden máximo en el proceso de implementación – Proporción una plantilla estructurada para la ingeniería de software Desventajas: – El cliente debe proporcionar todos los requerimientos de una sola vez – Es difícil para los usuarios anticipar si el sistema final va a satisfacer sus requerimientos – Cualquier cambio que se haga durante la implementación puede causar confusión. – La versión de trabajo puede verse sólo en una etapa posterior.
- 14. Modelo de Desarrollo Rápido de Aplicación Período Corto de Tiempo Equipo 3 Especificaciones Parciales Diseño Codificación Pruebas Lanzamiento Equipo 3 Equipo 1 Equipo 2 Especificaciones Parciales Diseño Codificación Pruebas Lanzamiento Especificaciones Parciales Diseño Codificación Pruebas Lanzamiento Especificaciones Parciales Diseño Codificación Pruebas Lanzamiento Uso de 4GT y componentes reutilizables Modelar el Negocio
- 15. Modelo de Creación de un Prototipo Obtener Requerimientos Diseño Rápido Prototipo Evaluar Prototipo Refinar Requerimientos Lanzamiento e Ingeniería
- 16. Modelo de Creación de un Prototipo • Ventajas: – Ocurre un desarrollo rápido sin detalles de la entrada y salida – Los clientes pueden ver muy pronto la salida de alguna forma – Hay la oportunidad de modificar los requerimientos tempranamente en el proceso de desarrollo • Desventajas: – El cliente puede tomar el prototipo como el producto final. – Puede resultar que el proceso de desarrollo del producto tome mucho tiempo – Los desarrolladores no están seguros de qué hacer con el prototipo
- 17. Modelo Incremental PruebasCodificación Diseño Incremental Análisis Incremental Análisis Parcial Retroalimentación del Incremento Anterior Inicio del proyecto Inicio del mantenimiento Fin del lanzamient o del producto Lanzamiento del 1er incremento Estudio del Sistema y Análisis de Requerimientos Ingeniería de Sistemas e Información Diseño Restringido Codificación Pruebas Lanzamiento del 2do incremento Diseño Incremental Análisis Incremental Codificación Pruebas Lanzamiento del 3er incremento Retroalimentación Retroalimentación Diseño Incremental Análisis Incremental Codificación Pruebas Lanzamiento incremento final Retroalimen- tación de todos los Usuarios
- 18. Modelo Espiral Análisis de Riesgo Ingeniería del Software Codificación, Prueba y Lanzamiento Evaluación y Retroalimentació n del Cliente Comunicación con el Cliente Planificación del Proyecto
- 19. Modelo Espiral Ventajas: – Las últimas iteraciones tienen más probabilidad de tener una versión final rápidamente – Este modelo se puede usar aún después de que el software es entregado – Usa el prototipo como un mecanismo de reducción de riesgo Desventajas: – Demanda una experiencia considerable de valoración del riesgo por parte del cliente – Los clientes son generalmente aprensivos de si el enfoque evolutivo puede ser controlado o no.
- 20. Modelo de Ensamblado de Componentes • Considerar el diseño e identificar los componentes que pueden ser reutilizados • Seleccionar los componentes requeridos de la librería o repositorio • Retocar los componentes seleccionados de ser necesario • Construir componentes adicionales para ayudar a realizar el diseño en la etapa de la iteración • Ensamblar los componentes para ayudar a la entrega del producto en la etapa de iteración • Adicionar los nuevos componentes creados en la librería o repositorio • Completar la iteración actual del componente ensamblador
- 21. Técnicas de Cuarta Generación (4GTs) • Involucran las características del software en un alto nivel de abstracción • Diversas herramientas se utilizan para generar el código fuente • Se denominan también 'generadores de aplicaciones’ • Existen varios entornos de desarrollo de software que soportan 4GT
- 22. Resumen • Se explicó el software como un producto y un proceso • Se definió qué es la ingeniería de software y explicar su importancia • Se discutieron las ventajas y desventajas de los diversos modelos de procesamiento de software • Se presentaron los Modelos Evolutivos • Se discutieron las Técnicas de Cuarta Generación
- 23. Unidad 2: Especificación de los Requerimientos de Software
- 24. Objetivos de Aprendizaje • Discutir la naturaleza y la importancia de los requerimientos • Definir los requerimientos de software y el término SRS • Describir las actividades del análisis de requerimientos • Describir el proceso del análisis de requerimientos • Describir las funciones y componentes de una SRS • Discutir los diferentes atributos de una SRS bien redactada
- 25. Requerimientos del Software • Requerimiento es una “condición o capacidad requerida por un usuario para resolver un problema o para alcanzar un objetivo” • La fase de requerimientos inicia cuando: - Un problema existe y quizás requiere una solución basada en software - Hay un alcance para crear un software basado en una idea
- 26. Análisis del Problema y Descripción del Producto • El análisis del problema busca una comprensión completa del problema y comprende: - Tormenta de ideas - Dirigir entrevistas con los involucrados con el sistema - Obtener información de las personas familiarizadas con el entorno del sistema • La descripción del producto, describe la conducta externa del software en un documento
- 27. Pasos de la Ingeniería de Requerimientos Levantamiento de Requerimientos Análisis de Requerimientos Refinamiento de Requerimientos Negociación de Requerimientos Especificación de Requerimientos Modelado de Sistema Validación de Requerimientos Administración de Requerimientos
- 28. Levantamiento de Requerimientos • Proceso de recibir un conjunto de requerimientos de: - el cliente - el usuario - la gerencia • Las preguntas a responder en este proceso son: ¿Cuáles son los objetivos del sistema o producto? ¿Qué debe ser alcanzado por el producto o sistema? ¿Cómo ayuda el sistema o producto en las necesidades del negocio? ¿Cómo se usará el sistema o producto en el día a día?
- 29. Problemas en el Levantamiento de Requerimientos Límites del Sistema Indefinidos Problema de Alcance Detalles Innecesarios Problemas en el Levantamiento de Requerimientos Mala apreciación del entorno de trabajo Mala comunicación Problema de Volatilidad Problema de Comprensión Clientes Inseguros de sus Necesidades Pobre Dominio del Conocimiento Cambia en el Tiempo Número de Requerimientos Requerimientos Volatiles en sí Mismos
- 30. Análisis de Requerimientos • Los requerimientos se analizan para ser categorizados y organizados. • Como una guía se tienen preguntas tales como: 1. ¿Cada requerimiento es consistente? 2. ¿Existen suficientes detalles para cada uno de los requerimientos? 3. ¿Hay un alcance bien definido que proporciona un límite a cada requerimiento? 4. ¿Está el conjunto de todos los requerimientos completo y libre de ambigüedad?
- 31. Especificación de Requerimientos Una Especificación de Requerimiento puede involucrar uno de los siguientes: • Documento escrito • Modelo gráfico • Modelo formal (base matemática) • Casos de uso • Prototipos
- 32. Modelar el Sistema • Modelar el sistema es un paso recomendado para lograr un buen entendimiento del sistema • Para sistemas que están siendo abordados por primera vez, se recomienda que sean modelados • Modelar el sistema es un análisis más profundo del mismo
- 33. Validación de Requerimientos Completitud Consistencia Correspondencia a ciertos estándares No-ambigüedad Aspectos que Aseguran la Validación de Requerimientos
- 34. Administración de Requerimientos • Trata de un conjunto de actividades conectadas con el control, identificación y rastreo de requerimientos durante la implementación • Se ocupa de los cambios en los requerimientos • Se estudia también bajo el tópico de Administración de la Configuración
- 35. Aplicaciones del SRS Una SRS (Especificación de Requerimientos de Software) es un documento que contiene una descripción completa de la conducta externa de un producto La SRS la escribe la organización de desarrollo, su propósito es: • Proporcionar medios de comunicación entre clientes, usuarios, analistas y diseñadores • Constituir una base para las actividades de prueba y verificación del sistema • Controlar la evolución del sistema
- 36. Contenido de la SRS • Una SRS debe incluir una descripción concisa, de la totalidad de la interfaz externa del sistema con su ambiente, incluyendo otros software, puertos de comunicación , hardware y usuarios • Incluye dos tipos de requerimientos: • De comportamiento • De no comportamiento
- 37. Atributos de un SRS de Alta Calidad Rastreable Integra Comentada No Ambigua Comprensible Consistente Correcta Verificable Atributos de un SRS de Alta Calidad
- 38. Resumen • Se discutió la naturaleza e importancia de los requerimientos • Se definieron los requerimientos de software y el término SRS • Se describieron las actividades para el análisis de los requerimientos • Se describió el proceso de análisis de requerimientos • Se describieron las funciones y componentes de una SRS • Se explicaron los diferentes atributos de una SRS bien redactada
- 39. Unidad 4: Diseño de Software
- 40. Objetivos de Aprendizaje • Explicar brevemente el proceso de diseño • Explicar los enfoques top-down y bottom-up • Discutir los principios y objetivos del diseño • Discutir los conceptos de cohesión y acoplamiento
- 41. Introducción • El diseño de software busca planear una solución para un problema especificado en la SRS • Es el primer paso para avanzar del dominio del problema al dominio de la solución • Es la primera de tres actividades técnicas en el proceso de ingeniería de software • Comienza poco tiempo después del análisis y la especificación de requerimientos
- 42. Resultados del Proceso de Diseño • Diseño de datos • Diseño arquitectónico • Diseño de interfaz • Diseño de componentes
- 43. Características de un Buen Diseño • El diseño debe implementar todos los requerimientos de la SRS • Para los desarrolladores y ´testers´ debe ser fácil entender el diseño • El diseño debe cubrir todos los aspectos de implementación del software (funcional, comportamiento y flujo de datos)
- 44. Enfoques de Diseño Top-Down y Bottom-Up Top Down: - Enfoque orientado en niveles, comienza con una descripción de alto nivel - Refina su visión paso a paso - El sistema se fragmenta en módulos más pequeños y de más bajo nivel Bottom Up: - Enfoque que identifica un conjunto básico de módulos y sus interrelaciones - El beneficio principal es permitir la evaluación de sub-módulos durante el desarrollo
- 45. Conceptos Básicos de Diseño Modularidad Refinamiento Arquitectura Abstracción Conceptos Básicos de Diseño
- 46. Abstracción Es el proceso mediante el cual el diseñador se concentra sólo en aquellos aspectos que son relevantes, e ignora los detalles irrelevantes Los niveles más altos de abstracción esconden los detalles que no son importantes en ese nivel Los niveles más bajo revelan mayores detalles En los niveles más bajo de abstracción, una solución se presenta de tal manera que puede ser implementada directamente
- 47. Refinamiento Es básicamente una forma de elaboración El refinamiento ayuda al diseñador a revelar detalles de bajo nivel a medida que progresa su diseño de niveles simple a complejos Modularidad El software puede ser dividido en componentes individuales llamados módulos. Dividir un programa en muchos módulos diferentes lo simplifica
- 48. Arquitectura del Software Diferentes modelos para representar la arquitectura del software: • Modelos estructurales • Modelos de marcos de trabajo • Modelos dinámicos • Modelos de proceso • Modelos funcionales
- 49. Diseño Modular • El diseño modular es una de las metodologías de diseño más usadas • La implementación del diseño modular ayuda a: Reducir la complejidad en el proceso de diseño A ejecutar el cambio Permitir una implementación más sencilla
- 50. Tipos de Módulos • Módulo secuencial • Modulo incremental • Módulo paralelo
- 51. Independencia Funcional • Desarrollar módulos con funciones singulares • Desarrollar módulos que no tengan una tendencia hacia una interacción extra con otros módulos • En el software cada módulo se debe ocupar de una sub-función específica de requerimientos • La interfaz de cada módulo debe verse simple, desde otras partes del la estructura del programa
- 52. •Es la propiedad por la cual las cosas que son similares se mantienen juntas •Un módulo se considera completamente cohesivo sólo si realiza una única función o tarea •Se debe aspirar un alto grado de cohesión •Bajos niveles de cohesión son contraproducentes para propósitos de diseño Cohesión
- 53. Acoplamiento • El acoplamiento es la medida de interconexión entre diferentes módulos dentro de una estructura de software • Depende de: - La complejidad de la interfaz entre dos módulos diferentes - La manera en que se hace una referencia al módulo - La manera en que los datos se pasan a través de la interfaz
- 54. Resumen • Se explicó el proceso de diseño en pocas palabras • Se explicaron los enfoques top-down y bottom-up • Se discutieron los principios y objetivos del diseño • Se discutieron los conceptos cruciales de cohesión y acoplamiento
- 55. Unidad 5: Planeamiento del Software
- 56. Objetivos de Aprendizaje • Describir los diferentes pasos que tiene el planeamiento de un proyecto • Discutir las diferentes actividades que abarca el análisis de riesgos • Explicar la administración del riesgo • Discutir el planeamiento y cronograma de un proyecto de software • Describir el planeamiento organizacional
- 57. Introducción • La administración de un proyecto tiene tres fases: Planeamiento Monitoreo y control Análisis de culminación • El planeamiento del proyecto es la responsabilidad más grande de la administración del proyecto • Para desarrollar un plan para desarrollar software, los objetivos de un proyecto deben ser cumplidos exitosamente y eficientemente
- 58. Planeamiento de un Proyecto Estimación Análisis de Riesgo Cronograma Decisiones de adquisición Reingeniería Planeamiento Organizacional
- 59. Administración del Riesgo Administración del Riesgo Análisis del Riesgo Identificación del Riesgo Proyección del Riesgo Evaluación del Riesgo
- 60. Análisis de Riesgo • Riesgo se refiere a las posibilidades que pudieran afectar el costo, la calidad o el cronograma de un desarrollo de software • Factores como el método de implementación u operación de un programa/aplicación, el tipo de herramientas usadas, el número de personal involucrado, etc.
- 61. Identificación del Riesgo Los riesgos se agrupan generalmente bajo varias categorías como: • Riesgos de proyecto • Riesgos técnicos • Riesgos de negocio
- 62. Proyección del Riesgo • Medir la probabilidad de ocurrencia del riesgo • Listar el conjunto de problemas que se necesita manejar si el riesgo ocurre • Hacer un estimado del impacto del riesgo en el proyecto en cuestión • Evaluar el nivel de confiabilidad con el cual se ha proyectado el riesgo
- 63. Evaluación del Riesgo • Definir niveles de referencia de riesgo para un proyecto • Construir una relación entre los factores individuales, versus riesgo, probabilidad de riesgo, e impacto de riesgo y niveles de referencia individuales • Tener un conjunto de puntos de quiebre que definirá la región de culminación • Entender la manera en la que las combinaciones de riesgos afectarán un nivel de referencia
- 64. Administración y Monitoreo de Riesgos Identificación del Riesgo Análisis del Riesgo Planificación del Riesgo Monitoreo del Riesgo Lista de Riesgos potenciales Lista de Riesgos con prioridades Plan de contingencia y prevención del Riesgo Evaluación del Riesgo
- 65. Cronograma del Proyecto de Software • El cronograma de un proyecto de software puede hacerse de dos maneras La fecha límite para la publicación del producto / programa ya ha sido fijada y la compañía desarrolladora tiene que distribuir el esfuerzo en un espacio de tiempo específico Los períodos de tiempo aproximado han sido dados, pero la compañía desarrolladora fija la fecha de finalización • La certeza en el cronograma algunas veces juega un rol más importante que la certeza en los costos
- 66. Relación Trabajo-Personas • A medida que el tamaño del proyecto se incrementa, más se necesitará más personas para alcanzar el resultado final en un periodo de tiempo dado • Si el proyecto esta retrasado, incrementar el número de programadores seguramente acelerará el proceso • Incrementar en el número de desarrolladores también incrementará los canales de comunicación dentro del sistema, y por lo tanto incrementa la complejidad de los procesos de comunicación
- 67. Paralelismo y Definición de Tareas • Los proyectos de desarrollo de software son usualmente tomados en paralelo cuando más de una persona está involucrada en el proceso de desarrollo • La base para tareas paralelas es el análisis, especificación y la revisión resultante de los requerimientos • Una vez que los requerimientos han sido identificados y revisados, las actividades de diseño y planeamiento de pruebas se llevan en paralelo
- 68. Distribución de Esfuerzo • El esfuerzo de distribución de un proyecto está dirigido sólo por las características de ese proyecto particular • Generalmente el análisis de requerimiento constituye sólo un 10 a 25 % del esfuerzo del proyecto • El esfuerzo del planeamiento del proyecto es usualmente sólo 2 a 3 % del total de esfuerzo del proyecto • El esfuerzo gastado en prototipo o análisis usualmente se incrementa en proporción directa al tamaño y complejidad del proyecto
- 69. Diferentes Modelos para Cronogramas • Los dos métodos más comúnmente usados para los cronogramas de desarrollo de software son: Evaluación del Programa y Técnica de Revisión (PERT) Método de la Ruta Crítica (CPM)
- 70. Decisiones de Adquisición • El software puede ser comprado o licenciado • El software puede ser comprado y luego personalizado a las necesidades • El software puede ser también hecho a la medida dando el desarrollo a un contratista externo
- 71. Re-ingeniería • Ciertas aplicaciones de software pueden haber sido desarrolladas con un diseño en particular • Las diferentes adiciones y actividades de mantenimiento podrían haber afectado el diseño original • Tales aplicaciones son difíciles y costosas de mantener • Es posible rediseñar tal sistema de software y desarrollarlo de nuevo
- 72. Plan del proyecto del software • Estimación del costo • Cronogramas e hitos • Plan del personal • Aseguramiento de la calidad de software • Plan de la administración de configuración • Plan de monitoreo del proyecto • Administración del riesgo
- 73. Administración de Configuración Controlar los cambios y documentación relacionada Documentar las características funcionales y físicas de los elementos de configuración Guardar y reportar la información requerida para la administración efectiva de elementos de configuración Auditar elementos para verificar la conformidad con las especificaciones, diagramas, documentos de control de interfaces y requerimientos contractuales
- 74. Herramientas de Administración de la Configuración • Administración de la configuración del software basada en archivo • Administración de la configuración del Software basada en repositorio del proyecto • Administración de Configuración del Software basada en transparencia del archivo
- 75. Ventajas de la Administración de la Configuración • Implementar un buen proceso y sistema de SCM, usado correctamente ahorrará dinero • Muchas compañías adoptan prácticas de SCM porque desean poder controlar y dirigir el proceso complejo lo mejor que pueden • Los gastos incluyen gastos en eliminar errores, rediseño, correcciones
- 76. Resumen • Se describieron los diferentes pasos que tiene el planeamiento de un proyecto • Se discutió acerca de las diferentes actividades que abarca el análisis de riesgos • Se explicó la administración del riesgo • Se discutió acerca del planeamiento y cronograma de un proyecto de software • Se describió el planeamiento organizacional • Se explicó la administración de la configuración