Desarrollo de Líneas de Productos de Software Desarrollo de

Transcripción

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
María Cecilia Bastarrica
Ingeniero en Informática, Universidad Católica del
Uruguay, 1991.
Magister en Ciencias de la Ingeniería, PUC Chile,
1994.
Ph.D. Computer Science and Engineering, University of
Connecticut, 2000.
Profesora Asistente, DCC, Universidad de Chile desde
marzo de 2000.
Desarrollo de Líneas de Productos de Software
2
Agenda

Reutilización de Software
Líneas de Productos de Software
Costos y Beneficios
Organización
Arquitectura Base
Desarrollo de Componentes
Ejemplos
Conclusiones
3
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.
4
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.
5
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.
6
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.
7
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.
8
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.
9
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.
10
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.
11
Concepción de
Arquitectura de Software
Academia
Industria
La arquitectura se define
explícitamente.
Comprensión conceptual de la
arquitectura. Pocas definiciones
formales.
La arquitectura se compone de
componentes y conectores como
elementos fundamentales.
Los conectores no son elementos
básicos. Se implementan con
código desarrollado ad hoc.
Definiciones formales con ADLs y La configuración total del sistema
generación automática de
se describe con lenguajes de
aplicaciones.
programación y de script.
12
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.
13
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.
14
Enfoques de Componentes
Academia
Industria
Las componentes son cajas negras.
Las componentes son grandes subsistemas
sin un claro límite y sin encapsulamiento.
Las componentes tienen pequeñas
interfaces de acceso.
Las interfaces son las de las clases que
forman la componente.
Las variaciones posibles son
configurables al instalarlas.
Las variaciones se logran con distintas
implementaciones.
Las componentes implementan
interfaces estándar y se venden en
mercados de componentes.
Las componentes son desarrolladas
internamente. Los desarrollos externos
requieren mucho trabajo de adaptación.
Énfasis en la funcionalidad.
Otras cualidades son tanto o más importantes:
performance, confiabilidad, tamaño del código,
reusabilidad, mantenibilidad.
15
Líneas de Productos de
Software
activos
externos
arquitectura
base
internos
...
producto 1
producto 2
producto n
16
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.
17
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.
18
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).
19
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.
Con LPS
1
Sin LPS
2
3
4
5
Proyecto
20
Organización
Requisitos
Patrones, Frameworks,
Estrategias de producción,
Activos pre-definidos
Ingeniería de Dominio
Requisitos
Activos
Alcance de la LPS
Plan de producción
Ingeniería de Aplicación
ACTIVOS
PRODUCTOS
Desarrollo de Activos
Alcance de la LPS
Planes de producción
Productos de la LPS
ADMINISTRACIÓN
21
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.
22
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.
23
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.
24
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
25
Arquitectura Base
CAD
Cargar Estructuras de Datos
Validar Malla de Superficie
Corregir Malla de Superficie
Estructuras
de Datos
Mejorar Malla de Superficie
Primera Malla de Volumen
“Limar” Malla de Volumen
Mejorar Malla de Volumen
Refinar Malla de Volumen
Generar Salida
FEM
26
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.
27
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.
28
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
CAD
estructuras de datos es dependiente
del CAD.
Las estructuras de datos tienen una
interfaz conocida para las otras
componentes, pero
es indiferente su
Estructuras
implementación
de Datos en
interna.
Memoria
29
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.
Base
de Datos
Las otras componentes
son idénticas a las
anteriores.
CAD
(paralelo)
(paralelo)
30
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
Estructuras
deDatos
Datosen
de
se genera una salida en
enMemoria
Memoria
un formato apropiado para
ser tomado por el
software
Refinar Malla de Volumen
Generar Salida
(Adaptivo)
FEM.
FEM
31
Producto 4
Generador de buenas
mallas de volumen
para ser usadas por
un software FEM.
Cargar
Cargar Estructuras
Estructuras de
de Datos
Datos
Estructuras
de Datos
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.
CAD
Validar
Validar Malla
Malla de
de Superficie
Superficie
Corregir
Corregir Malla
Malla de
de Superficie
Superficie
Mejorar
Mejorar Malla
Malla de
de Superficie
Superficie
“Limar” Malla de Volumen
Mejorar Malla de Volumen
Generar
Generar Salida
Salida
FEM
32
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.
33
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.
34
Referencias
Paul Clements & Linda Northrop. Software Product Lines:
Practices and Patterns. Addison Wesley, Agosto 2001.
Jan Bosch. Design and Use of Software Architectures. Adopting
and evolving a product-line approach. Addison Wesley, Mayo
2000.
Software Engineering Institute (SEI), Carnegie Mellon University. The
Product Line Practice Initiative, 2002, http://www.sei.cmu.edu/plp/.
M.López & M.C.Bastarrica. Business Case for a Product Line of
Legacy Application Data-Middleware. Reporte Técnico TR/DCC2002-3 y enviado a una conferencia recientemente.
M.C.Bastarrica. Arquitectura Base en una Línea de Productos de
Software. Enviado a una conferencia recientemente.
35
36

Desarrollo de Líneas de Productos de Software Desarrollo de

Transcripción

Documentos relacionados

Producto obtenido generalmente por la reacción

Ficha Malla Anti Granizo