Ingeniería del Software I

Transcripción

1 Ingeniería del Software I 1er. Cuatrimestre 2002 Martina Marré martina@dc.uba.ar

2 Organización 3 tipos de clase: teórica, práctica, taller 3 grupos de docentes un cronograma material en la WEB

3 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

4 Ingeniería del Software I Introducción

5 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

6 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?

7 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

8 Qué significa producir una aplicación? El proceso de desarrollo del software Es la manera en que los requerimientos son trasladados en productos software

9 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

10 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

11 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

12 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

13 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

14 Características de calidad funcionalidad confiabilidad usabilidad mantenibilidad

15 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

16 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

17 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

18 Robustez Un software es robusto si se comporta razonablemente aún en circunstancias no definidas en la especificación

19 Performance Eficiencia, precisión, seguridad (security), tiempo de respuesta

20 Usabilidad Facilidad de uso por parte de los usuarios

21 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!

22 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

23 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

24 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

25 Cómo obtener hoy un producto de calidad No sólo que ande Responsabilidad profesional Prácticas consensuadas (best practices), como en otras disciplinas

26 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)

27 Ingeniería del Software I Proceso de Desarrollo del Software

28 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

29 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

30 Ejemplos de modelos Maquetas Planos Ecuaciones Prototipos Simulación por computadora Gráficos informales

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 Costo de corrección de errores Analisis Diseño P r ogr amación P r ueba del Sistema Instalación Fuente: B. Boehm, Software Engineering Economics Prentice Hall, Fase del Proceso

41 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

42 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

43 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

44 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

45 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

46 Modelos del Ciclo de Vida del Software Aparecen cuando la ausencia de método para el desarrollo se hace insostenible

47 Cascada (B. Boehm 70) Factibilidad Análisis y Especificación de requerimientos Diseño Programación y test Integración y test Testing Mantenimiento

48 Modelos Evolutivos Anticipan la (necesaria) evolución de la aplicación Cascada Prototipación

49 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

50 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

51 Tarea para el hogar Para el lunes 25/3 Formar grupos de taller Exactamente 4 personas