Ingeniería del Software I 1er. Cuatrimestre 2002 Martina Marré martina@dc.uba.ar
Organización 3 tipos de clase: teórica, práctica, taller 3 grupos de docentes un cronograma material en la WEB 2002 2
Aprobación de la materia Correlativas aprobadas! Promoción: Aprobar los parciales (más info en la práctica) Aprobar las entregas de taller (más info en el taller) Aprobar el coloquio final 2002 3
Ingeniería del Software I Introducción
Definiciones de Ingeniería del Software (IS) Boehm: La aplicación práctica del conocimiento científico al diseño y construcción de programas y la documentación asociada requerida para desarrollar, operar y mantenerlos. IEEE: Modo sistemático de desarrollo, operación, mantenimiento y retiro del software... 2002 5
Una más Conjunto de teorías, métodos e instrumentos (tecnológicos y organizativos) que permiten producir aplicaciones con las características de calidad deseadas Cuáles teorías, métodos e instrumentos? Qué es una aplicación? Producir una aplicación? Qué son las calidades deseadas? 2002 6
Qué es una aplicación? Producto software No sólo es código... También muchos documentos asociados!: todo lo producido durante el proceso por el cual se desarrolla el software 2002 7
Qué significa producir una aplicación? El proceso de desarrollo del software Es la manera en que los requerimientos son trasladados en productos software 2002 8
Calidad no es un término absoluto Ejemplo: restaurant de calidad Fin último: satisfacción del cliente Definición La totalidad de características de un producto o servicio que se refieren a su habilidad para satisfacer necesidades establecidas o implicadas. 2002 9
Calidad es relativa Puntos de vista de la calidad distintos tipos de usuario distintos usuarios La calidad depende del producto que estamos construyendo La calidad es una combinación de calidades básicas 2002 10
Para qué definir la Calidad de un Producto Objetivo IS: Construir un producto de calidad Guías de qué se quiere, para diseñadores, testers,... Evaluar la calidad de un producto 2002 11
Calidad de proceso Modelos (CMM, Spice, ISO9000, DoD, nuclear, aeroespacial,...) Relación entre proceso y producto??? Un buen proceso de desarrollo debe permitir entregar software de calidad dentro del presupuesto y a tiempo 2002 12
Calidades externas vs. internas Externas: son las que son observables por un observador externo que examina el producto (o el proceso) como si fuera una caja negra Internas: son las que pueden ser observadas examinando la estructura interna del producto (o proceso) como si fuera una caja transparente 2002 13
Características de calidad funcionalidad confiabilidad usabilidad mantenibilidad... 2002 14
Corrección funcional Un software es funcionalmente correcto si se comporta de acuerdo a las especificaciones de las funciones que debe proveer se asume que existe una especificación equivalencia entre software y su especificación 2002 15
Limitaciones En general... Las especificaciones de sistemas medianosgrandes no son completas No se logra verificar todo Cómo garantizamos la corrección de la verificación? Y nunca garantiza que se implementen los requerimientos deseados 2002 16
Confiabilidad (reliability) Informalmente, el software es confiable si el usuario puede depender de él Formalmente, es la probabilidad de que el software opere según lo esperado en un cierto período de tiempo garantía de confiabilidad vs. disclaimer 2002 17
Robustez Un software es robusto si se comporta razonablemente aún en circunstancias no definidas en la especificación 2002 18
Performance Eficiencia, precisión, seguridad (security), tiempo de respuesta... 2002 19
Usabilidad Facilidad de uso por parte de los usuarios 2002 20
Mantenibilidad Reparabilidad: corrección de defectos con poco trabajo: buen diseño modular information hiding documentación Evolucionabilidad: buena documentación design for change Anticipar el cambio! 2002 21
y... Hay muchas más calidades Es difícil acordar qué calidad es más importante (distintos usuarios pueden tener distintas visiones) Puede ser difícil implementar varias calidades a la vez 2002 22
Cómo obtener un producto de calidad? Hace unos años Lo importante era que ande No existían prácticas consensuadas La búsqueda de la bala de plata que solucione todos los problemas del software 2002 23
Cómo obtener hoy un producto de calidad No existe la bala de plata F. Brooks: No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, 4/87 dificultades esenciales (complejidad, conformidad, modificabilidad, invisibilidad) dificultades accidentales 2002 24
Cómo obtener hoy un producto de calidad No sólo que ande Responsabilidad profesional Prácticas consensuadas (best practices), como en otras disciplinas 2002 25
De dónde salen estas prácticas? Asociaciones profesionales Centros especializados Profesionales prestigiosos Trabajos especializados Como en otras disciplinas, comienza a existir un conocimiento profesional establecido (que no quiere decir que sea perfecto) 2002 26
Ingeniería del Software I Proceso de Desarrollo del Software
Desarrollo centrado en modelos Desarrollar software es transformar modelos Necesidades de los usuarios Proceso 1 Proceso de Desarrollo de Software Modelo 1 Proceso n Software nuevo o modificado Proceso 2 Modelo 2 2002 28
Uso de modelos Representaciones simplificadas de cosas reales Usados desde hace años en otras ramas de la ingeniería, más maduras que la nuestra Se construyen para entender mejor 2002 29
Ejemplos de modelos Maquetas Planos Ecuaciones Prototipos Simulación por computadora Gráficos informales 2002 30
Modelar no es un fin Es un medio para construir mejor Si es más barato construir y corregir los errores sobre el producto, modelar no tiene sentido Es mucho mejor ver el producto software que un modelo, pero terminar un producto y tirarlo si no es lo que yo quería es un poco caro... Corregir errores es más eficiente si se lo hace en etapas tempranas del desarrollo 2002 31
Variedad de modelos Es conveniente conocer distintos tipos de modelos Si la única herramienta que uno conoce es un martillo, todo parece un clavo Distintos problemas o partes de un problema requieren distintas técnicas de modelado 2002 32
Etapas del desarrollo del software División del desarrollo en etapas Una etapa se define a partir de la existencia de un producto (artefacto, documento, etc.), que resulta de esa etapa modelo Una vez que una etapa está completa, sus productos sirven como base a las etapas subsiguientes 2002 33
Qué debe hacer el software? Quién sabe qué debe hacer el software? La persona para la cual se desarrollo el software: el usuario Intercambio de información entre el desarrollador y el usuario final el desarrollador debe comprender qué desea el usuario Análisis completo de los problemas del usuario, funcionales y no funcionales (es decir, calidades) Acordar qué debe ofrecer el sistema 2002 34
Análisis de requerimientos El producto es un documento sobre requerimientos descripción de qué debe hacer el software, sin decir nada de cómo debe hacerlo En 2/3 de los fracasos en desarrollo de software, los requerimientos fueron fuente principal de problemas US General Accounting Office GAO/IMTEC Dec. 92 2002 35
Búsqueda de una solución Cómo implementar los requerimientos? Solución Proyecta cómo implementar la solución Problema: Gran salto de los requerimientos al código El diseño debe ser PREVIO a la codificación 2002 36
Arquitectura y Diseño El producto es una descripción de componentes e interfaces entre componentes (varios niveles) Cada componente debe tener una descripción funcional, y debe estar en relación con las ideas plasmadas en los requerimientos 2002 37
Implementando la solución La información documentada hasta el momento debería permitir a cada programador realizar su tarea Sin embargo, usualmente aparecen preguntas Distintas formas de resolver Siempre documentar lo resuelto (y no mediante un comentario en el código!!) El producto de esta fase es el software ejecutable 2002 38
Control de Calidad Proceso (no es una etapa) que Empieza junto al análisis de requerimientos Continúa durante todo el desarrollo de software Detección temprana No se puede volver para atrás y agregar calidad Para el momento que te das cuenta que tenés un problema de calidad, ya es tarde 2002 39
Costo de corrección de errores 20000 15000 150 0 0 10000 5000 200 50 0 12 0 0 5000 0 Analisis Diseño P r ogr amación P r ueba del Sistema Instalación Fuente: B. Boehm, Software Engineering Economics Prentice Hall, 1981. Fase del Proceso 2002 40
Prevención de la migración de errores Recordemos: más de la mitad de los errores se introducen en la etapa de análisis de requerimientos Detectando los errores en la misma fase en la que se introducen, se reduce el costo de corregirlos 2002 41
Técnicas de control de calidad: revisiones Discusión con el objetivo de validar una etapa del desarrollo Permite avanzar sobre fases sucesivas del desarrollo con una objeto validado y consensuado Ejemplos: Revisión por pares (peer reviews) Recorridas de código (walkthroughs) Inspecciones de código - M. Fagan 2002 42
Técnicas de control de calidad: Testing Verificación dinámica (i.e., involucra la ejecución del código) de la adecuación del sistema a los requerimientos funcionales y no funcionales 2002 43
Limitación del testing Puede demostrar la presencia de errores, nunca su ausencia [Dijkstra] entonces, el testing NO puede probar que el software funciona Sin embargo sí permite encontrar problemas un programa de test efectivo previene la migración de errores 2002 44
Documentación Por qué documentar? Acordar lo que se va a hacer Con el usuario Entre pares Entender lo que se hizo antes Asunciones hechas Etapas de mantenimiento 2002 45
Modelos del Ciclo de Vida del Software Aparecen cuando la ausencia de método para el desarrollo se hace insostenible 2002 46
Cascada (B. Boehm 70) Factibilidad Análisis y Especificación de requerimientos Diseño Programación y test Integración y test Testing Mantenimiento 2002 47
Modelos Evolutivos Anticipan la (necesaria) evolución de la aplicación Cascada Prototipación 2002 48
Espiral (B. Boehm) Determinación de objetivos, alternativas, vínculos I II Evaluación de alternativas Identificación y resolución de riesgos Planificación fase sucesiva IV III Desarrollo y verificación 2002 49
Ingeniería del Software I Etapas (básicas) para el desarrollo de una aplicación de software requerimientos y especificación arquitectura y diseño [implementación] control de calidad: testing y revisiones 2002 50
Tarea para el hogar Para el lunes 25/3 Formar grupos de taller Exactamente 4 personas 2002 51