Desarrollo de Líneas de Productos de Software

Transcripción

1 Centro Experimental de Ingeniería de Software Departamento de Ciencias de la Computación Facultad de Ciencias Físicas y Matemáticas Universidad de Chile Desarrollo de Líneas de Productos de Software María Cecilia Bastarrica

2 María Cecilia Bastarrica Ingeniero en Informática, Universidad Católica del Uruguay, Magister en Ciencias de la Ingeniería, PUC Chile, Ph.D. Computer Science and Engineering, University of Connecticut, Profesora Asistente, DCC, Universidad de Chile desde marzo de Desarrollo de Líneas de Productos de Software 2

3 Agenda Reutilización de Software Líneas de Productos de Software Costos y Beneficios Organización Arquitectura Base Desarrollo de Componentes Ejemplos Conclusiones Desarrollo de Líneas de Productos de Software 3

4 Desarrollo Tradicional de Software Se desarrolla un único producto o aplicación por vez. Énfasis en productos entregables y plazos. Mantenimiento y evolución no son parte del desarrollo inicial. Problemas típicos: Desarrollos en tiempo y presupuesto desmedido. Calidad del sistema inadecuada. El costo de mantenimiento llega al 80% de todo el ciclo de vida del producto. La competitividad del producto va decreciendo con los cambios. Desarrollo de Líneas de Productos de Software 4

5 Reutilización de Software Reutilizar mejor que desarrollar! Las aplicaciones se construyen componiendo piezas de software ya desarrolladas, usadas y probadas. Permite reducir drásticamente el costo de desarrollo y mantenimiento. Mejora la calidad del software. Reduce los riesgos involucrados en todo desarrollo. Es más fácil administrar los proyectos. Es una estrategia muy promisoria. Desarrollo de Líneas de Productos de Software 5

6 Ejemplos de Reutilización Hurgar código (copiar & pegar). Sistemas operativos. Compiladores. Bibliotecas de clases. Patrones de diseño. Sistemas distribuidos, ej. CORBA, COM, etc. Interfaces gráficas (GUI). Reutilización de diseño (expertise). Frameworks orientadas a objetos. Sistemas administradores de bases de datos (DBMS). Generadores de aplicaciones. Desarrollo de Líneas de Productos de Software 6

7 Enfoques de Reutilización Oportunística: el ingeniero de software reutiliza piezas de software que se ajustan al problema actual y las incorpora en el nuevo software. Planificada: la organización pone especial énfasis en el desarrollo de artefactos reutilizables que proporcionan las abstracciones apropiadas, con el nivel de variabilidad apropiada y que encajan en una estructura de más alto nivel. La reutilización oportunística no funciona en la práctica. Desarrollo de Líneas de Productos de Software 7

8 Enfoques de Reutilización Bottom-up: las componentes reutilizables, una vez desarrolladas o rehabilitadas, se agregan a una colección de activos posiblemente muy grande. Los ingenieros de software buscan entre estos activos para encontrar las piezas más apropiadas. Top-down: los activos se desarrollan y se presentan como partes que encajan en una estructura de más alto nivel. Los activos se ajustan a una interfaz predefinida y exigida. La reutilización bottom-up no funciona en la práctica. Desarrollo de Líneas de Productos de Software 8

9 Líneas de Productos de Software Definición: Una línea de productos de software es un conjunto de aplicaciones construidas en forma planificada a partir de un conjunto de activos comunes y que satisfacen las necesidades de un segmento del mercado. Desarrollo de Líneas de Productos de Software 9

10 Activos de Software Son todos los artefactos producidos durante el desarrollo del software y que son potencialmente reutilizables. Ejemplos: arquitectura base, patrones de diseño, componentes de software, manuales de usuario, especificación de requisitos, planes de producción, planes de pruebas, etc. Desarrollo de Líneas de Productos de Software 10

11 Arquitectura Base Arquitectura de Software es la definición de las componentes que forman el sistema, las propiedades externamente visibles de esas componentes y las relaciones entre las mismas. Arquitectura Base de una LPS corresponde a la definición de la arquitectura general que describe todos los componentes que podrían potencialmente formar parte de la línea de productos de software y su interrelación. La arquitectura base define y limita el alcance de la LPS. Desarrollo de Líneas de Productos de Software 11

12 Concepción de Arquitectura de Software Academia La arquitectura se define explícitamente. La arquitectura se compone de componentes y conectores como elementos fundamentales. Definiciones formales con ADLs y generación automática de aplicaciones. Industria Comprensión conceptual de la arquitectura. Pocas definiciones formales. Los conectores no son elementos básicos. Se implementan con código desarrollado ad hoc. La configuración total del sistema se describe con lenguajes de programación y de script. Desarrollo de Líneas de Productos de Software 12

13 Desarrollo de Componentes Las componentes de software son uno de los activos más claramente reutilizable. Existe una fuerte tendencia a desarrollar software basado en componentes. Las LPS dan un marco para el desarrollo y uso planificado de las componentes de software. Tecnologías de definición de componentes: ActiveX, JavaBeans, CCM, etc. Desafíos del desarrollo basado en componentes: almacenamiento, clasificación y búsqueda. Desarrollo de Líneas de Productos de Software 13

14 Formas de Reutilización de Componentes Reuso de componentes a lo largo de las distintas versiones de una aplicación. Esto sabemos hacerlo. Reuso de componentes en varias versiones de un software y en distintos productos. Estamos trabajando en esto. Reuso de componentes en varias versiones, diversos productos de software y en distintas organizaciones. Estamos lejos de este nivel de madurez. Desarrollo de Líneas de Productos de Software 14

15 Enfoques de Componentes Academia Las componentes son cajas negras. Las componentes tienen pequeñas interfaces de acceso. Las variaciones posibles son configurables al instalarlas. Industria Las componentes son grandes subsistemas sin un claro límite y sin encapsulamiento. Las interfaces son las de las clases que forman la componente. Las variaciones se logran con distintas implementaciones. Las componentes implementan interfaces estándar y se venden en mercados de componentes. Énfasis en la funcionalidad. Las componentes son desarrolladas internamente. Los desarrollos externos requieren mucho trabajo de adaptación. Otras cualidades son tanto o más importantes: performance, confiabilidad, tamaño del código, reusabilidad, mantenibilidad. Desarrollo de Líneas de Productos de Software 15

16 Líneas de Productos de Software activos arquitectura base externos internos... producto 1 producto 2 producto n Desarrollo de Líneas de Productos de Software 16

17 Beneficios de LPS Productividad Sistemas grandes y complejos pueden desarrollarse con menor tiempo y esfuerzo. Menor tiempo para tener un producto en el mercado. Costos Cada nuevo producto sólo requiere desarrollar unas pocas partes nuevas. Personal calificado y caro es pagado una única vez y su trabajo se reutiliza. Desarrollo de Líneas de Productos de Software 17

18 Más y Más Beneficios Facilidad de Administración. Reducción del riesgo. Menor trabajo a ser planificado y controlado. Calidad. Activos probados dan garantías de calidad y buen funcionamiento. Familiaridad de los usuarios con interfaces, manuales, mecanismos de interacción, facilitan el aprendizaje y disminuyen los errores. Desarrollo de Líneas de Productos de Software 18

19 Costos de LPS Desarrollar activos genéricos, configurables, robustos, documentados, portables y probados es más caro que hacer un desarrollo ad hoc. Antes de obtener los beneficios de la LPS uno debe tener una base de activos con estas características. Lograr el cambio de paradigma en las prácticas profesionales es un gran reto: mejores activos no aseguran un mejor producto (hoy), mejores activos posibilitan la reutilización (mañana). Desarrollo de Líneas de Productos de Software 19

20 Costos de Inicio de una LPS A quién se le asignan los costos de la puesta en marcha de la LPS? Datos empíricos: Costo Weiss: Payoff point: 2 a 3 productos. Jacobson: Payoff point 1,5 a 3,0 productos. Sin LPS Con LPS Proyecto Desarrollo de Líneas de Productos de Software 20

21 Organización Requisitos Patrones, Frameworks, Estrategias de producción, Activos pre-definidos Requisitos Activos Alcance de la LPS Plan de producción Ingeniería de Dominio Ingeniería de Aplicación ACTIVOS Desarrollo de Activos Alcance de la LPS Planes de producción PRODUCTOS Productos de la LPS ADMINISTRACIÓN Desarrollo de Líneas de Productos de Software 21

22 Desafíos para la Ingeniería del Dominio Cada componente debe tener una interfaz definida y estándar independientemente de su implementación interna. Los resultados de usar una componente con una implementación deben ser equivalentes a usar otra implementación de la misma componente. Definir claramente las interfaces y la funcionalidad de cada una de las componentes anticipándonos a posibles productos no previstos originalmente. Documentar todas estas decisiones y cumplirlas. Desarrollo de Líneas de Productos de Software 22

23 Desafíos de la Ingeniería del Producto Adaptar las necesidades de los clientes a las posibilidades de la LPS. Ser capaz de integrar productos útiles (casi) exclusivamente con las componentes disponibles. Ceñirse a la estructura de la arquitectura base para todos los productos. Realizar pruebas de integración y del sistema, suponiendo que cada componente satisface su especificación. Desarrollo de Líneas de Productos de Software 23

24 Desafíos de la Administración Decidir tempranamente la arquitectura base que permita desarrollar la mayor cantidad de productos distintos con mínimas restricciones. Decidir qué productos vale la pena desarrollar primero. Los primeros productos cargarán con los costos de desarrollo de los activos. Encontrar nichos de mercado que nos hagan obtener un mayor beneficio a partir de los activos disponibles y una mínima actividad de integración. Desarrollo de Líneas de Productos de Software 24

25 Ejemplo: Generación y Manejo de Mallas Geométricas Estamos desarrollando una línea de productos para la generación, manejo y refinamiento de mallas geométricas tridimensionales, tanto de superficie como de volumen. El manejo de mallas tridimencionales es complejo. Desarrollar estas aplicaciones es muy caro porque requiere: sofisticados algoritmos y estructuras de datos, personal altamente calificado, procesos de integración y pruebas rigurosos. Parece una buena idea usar LPS Desarrollo de Líneas de Productos de Software 25

26 Arquitectura Base CAD Cargar Estructuras de Datos Validar Malla de Superficie Estructuras de Datos Corregir Malla de Superficie Mejorar Malla de Superficie Primera Malla de Volumen Limar Malla de Volumen Mejorar Malla de Volumen Refinar Malla de Volumen Generar Salida FEM Desarrollo de Líneas de Productos de Software 26

27 Algunos Productos Potenciales Desde el punto de vista de la funcionalidad: Módulo para que un producto CAD genere buenas mallas de volumen. Módulo para que un software FEM pueda refinar/desrefinar una malla de volumen en forma adaptiva o interactiva. Software independiente para generar y mejorar mallas de superficie. Software independiente para refinar/desrefinar mallas de volumen. Desarrollo de Líneas de Productos de Software 27

28 Más Productos Desde el punto de vista de la implementación: Manejar los datos en estructuras de memoria o bien manejarlos en una base de datos. Implementar algoritmos secuenciales o paralelos de generación o refinamiento de las mallas de volumen. Generar mallas de volumen a partir de mallas de superficie generadas por diferentes productos CAD. Desarrollo de Líneas de Productos de Software 28

29 Producto 1 Módulo para mejorar mallas de superficie generadas por un CAD particular. Se manejan los datos en estructuras de memoria. Solamente la componente de cargar estructuras de datos es dependiente del CAD. Las estructuras de datos tienen una interfaz conocida para las otras componentes, pero es indiferente su implementación interna. Estructuras de Datos en Memoria CAD Cargar Estructuras de Datos Validar Malla de Superficie Corregir Malla de Superficie Mejorar Malla de Superficie Desarrollo de Líneas de Productos de Software 29

30 Producto 2 Módulo para generar mallas de volumen a partir de una gran malla de superficie. Se usa una base de datos con idéntica interfaz que las estructuras de memoria. Se usan algoritmos paralelos para corregir la malla de superficie y para generar la malla de volumen. Las otras componentes son idénticas a las anteriores. Base de Datos CAD Cargar Estructuras de Datos Validar Malla de Superficie Corregir Malla de Superficie (paralelo) Mejorar Malla de Superficie Primera Malla de Volumen (paralelo) Desarrollo de Líneas de Productos de Software 30

31 Producto 3 Refinar adaptivamente la malla de volumen de un software FEM particular. Se usan las estructuras de datos en memoria. Luego de refinar la malla se genera una salida en un formato apropiado para ser tomado por el software FEM. Refinar Malla de Volumen (Adaptivo) Estructuras de de Datos en en Memoria Generar Salida FEM Desarrollo de Líneas de Productos de Software 31

32 Producto 4 CAD Generador de buenas mallas de volumen para ser usadas por un software FEM. Estructuras de Datos Cargar Estructuras de Datos Validar Malla de Superficie Corregir Malla de Superficie El cliente puede ser cualquier ingeniero que trabaje con CAD y FEM y quiera obtener resultados de mejor calidad. La implementación de cada componente podría ser a gusto del consumidor. Mejorar Malla de Superficie Primera Malla de Volumen Limar Malla de Volumen Mejorar Malla de Volumen Generar Salida FEM Desarrollo de Líneas de Productos de Software 32

33 Trabajo en Curso La definición de la arquitectura base es un aspecto crucial en el éxito de la línea de productos. La forma de definir esta arquitectura no es estándar y estamos definiéndola formalmente. La especificación formal de cada una de las componentes con sus interfaces aseguran la intercambiabilidad necesaria para las líneas de productos. Aún faltan aspectos esenciales como el control de configuración y la formalización de procedimientos de prueba de integración. Desarrollo de Líneas de Productos de Software 33

34 Conclusiones Paradigma muy promisorio. Marco metodológico para la reutilización. Fábrica de software. Exige políticas de más largo plazo. Las ganancias son evidentes en productividad, calidad y costos de los desarrollos. Desarrollo de Líneas de Productos de Software 34

35 Referencias Paul Clements & Linda Northrop. Software Product Lines: Practices and Patterns. Addison Wesley, Agosto Jan Bosch. Design and Use of Software Architectures. Adopting and evolving a product-line approach. Addison Wesley, Mayo Software Engineering Institute (SEI), Carnegie Mellon University. The Product Line Practice Initiative, 2002, M.López & M.C.Bastarrica. Business Case for a Product Line of Legacy Application Data-Middleware. Reporte Técnico TR/DCC y enviado a una conferencia recientemente. M.C.Bastarrica. Arquitectura Base en una Línea de Productos de Software. Enviado a una conferencia recientemente. Desarrollo de Líneas de Productos de Software 35

36 Desarrollo de Líneas de Productos de Software 36