Please enable JavaScript.
Coggle requires JavaScript to display documents.
Fábricas de Software y Lineas de productos - Coggle Diagram
Fábricas de Software y Lineas de productos
Madurez y evolución
Iniciación
Evolucionaria:
Paso a paso, en la medida que el negocio va cambiando y necesitando.
Revolucionaria:
Se desarrolla la linea de productos y sus componentes basados en un super-conjunto de requerimientos y requerimientos futuros predichos.
Niveles de madurez de Lineas de Productos
(Nivel 2.5) Población de productos:
Extiende el conjunto de productos que pueden ser derivados de los artefactos de la linea de productos compartidos.
(Nivel 3) Linea de Productos de Software (SPL):
Se explotan las características comunes de manera natural en artefactos compartidos. Funcionalidad específica para productos se desarrolla como una derivación de producto.
(Nivel 2) Plataforma:
Se empieza a desarrollar y mantener productos basados en una plataforma con funcionalidad común a todos los productos o aplicaciones.
(Nivel 3.5) Programa de linea de productos:
Específico para sistemas muy grandes. Consiste en una arquitectura de software que es definida para todo el sistema y especifica los componentes que hacen el sistema. Varios o todos de los componentes son lineas de productos de software. El resultado de esto es un sistema que puede ser configurado.
(Nivel 1) Infraestructura estandarizada:
Se estandariza la infraestructura basada en los tipos de productos desarrollados. Ejemplos: Sistema operativo, motor de base de datos, frameworks.
(Nivel 4) Base de productos configurable:
Se desarrollan productos en un dominio relativamente estable y se derivan muchas instancias de productos. La organización tiende a favorecer el desarrollo de artefactos configurables que proveen todas las funciones necesarios para los productos.
(Nivel 0) Productos independientes:
Cada producto se hace por aparte y no comparte nada con los otros.
Artefactos de Linea de productos
Componente
(Nivel 2) Implementaciones de multiples componentes:
Para un componente de la arquitectura, existen multipes implementaciones del componente, pero cada implementación es compartida por más de un producto.
(Nivel 3) Implementacion de componentes configurables:
Sólo una implementación de un componente es usada, pero esta es altamente configurable ya que toda la variabilidad ha sido identificada en la implementación del mismo.
(Nivel 1) Especificado:
Se especifica la interfáz de los componentes definidos por la arquitectura.
Productos derivados
(Nivel 2) Productos basados en plataforma:
Acercamiento minimalista donde sólo se tienen componentes compartidos si estos se usan en todos los productos capturando la funcionalidad común de todos los productos. Como la funcionalidad es tan común, no se necesita implementar mucha variabilidad.
(Nivel 3) Base de productos configurable:
Acercamiento maximalista donde todas, o casi todas, las funcionalidades implementadas por cualquiera de los miembos de la linea de producción, está capturada por los artefactos compartidos de la linea de producto. Los productos se derivan de la configuración de sus elementos.
(Nivel 1) Conformidad con la arquitectura:
Productos que estan conformes a la arquitectura especificada por la línea de productos. Un producto sólo puede ser considerado miembro de la línea de productos si al menos cumple las especificaciones de la arquitectura subespecificada.
Arquitectura de Software
(Nivel 2) Especificada:
Se especifican tanto las funcionalidades comunes como las variables y las diferencias entre los productos en la arquitectura.
(Nivel 3) Reforzada:
La arquitectura captura todo lo que es común y variable hasta el punto en el que ningún producto necesita, ni es permitio, cambiar la arquitectura en su implementación. Todos los produtos usan la arquitectura como está y explota los diferentes punto de variación para implementar requerimientos específicos.
(Nivel 1) Subespecificada:
Un primer paso en la adopción evolucionaria. Se definen aspectos comunes entre los productos pero se evita la especificación de las diferencias. Marco de referencia básico.
Modelos organizacionales
Unidades de negocio:
Existen varios equipos especializados en cada una de las unidades de negocio. Los equipos comparten activos reutilizables.
Unidad de ingeniería de dominio:
Este modelo se sugiere para implementar lineas de productos. Se tiene una unidad de ingeniería de dominio encargada del diseño, desarrollo y evolución de activos reutilizables. Adicionalmente, se tienen unidades de negocio responsables de desarrollar y evolucionar productos basados en los activos comúnes construidos por la unidad de ingeniería de dominio.
Departamento de desarrollo:
Todo el desarrollo esta concentrado en un único departamento de desarrollo. El equpo de trabajo no es especializado y puede ser asignado a diferentes proyectos dependiendo de la necesidad.
Unidades de ingeniería de dominio jerárquicas:
En los casos en que se tiene una línea de producto jerárquica, también se hace necesario tener unidades de ingeniería de dominio jerarquica.
Evaluación de familia de productos de software
Modelo BAPO
Autores:
Modelo desarrollado por el proyecto ITEA ESAPS (Engineering Software Arquitectures, Processes and Platforms for system family engineering)
Descripción:
Es un modelo de evaluación del estado de una compañia en cuanto a su madurez en la implementación de familias de productos de software.
4 dimensiones de negocio
Relacionadas entre sí
Negocio (Business)
Aspectos a evaluar
Visión:
Qué tan bien apunta la organización a un futuro en el que la ingeniería de la familia de productos de software encaje.
Objetivos:
Qué tan bien determina la organización sus metas futuras, dirigidas a comercializar y vender lo que produce la ingeniería de la familia de software.
Identidad:
Qué tan bien la organización ha fomulado una identidad relacionada con la ingeniería de la familia de software.
Plan estratégico:
Qué tan bien la organización planea la familia de negocio y su desarrollo.
Niveles de estructura
3. Extrapolar:
El negocio esta
extrapolando
de los resultados de la ingeniería de la familia de software. Tiene influencia el desarrollo de la familia de software en beneficio del negocio.
4. Proactiva:
El negocio es
proactivo
en la planeación y manejo de la ingeniería de la familia de software y las metas del negocio para obtener mejores resultados.
2. Conciencia (Awareness):
El negocio está conciente de la ingeniería de la familia de software. Sin embargo no conoce los intrumentos adecuados para influenciar y usarlos para beneficiar el negocio.
5. Estratégica:
La ingeniería de la familia de software es un activo
estratégico
para alcanzar las metas del negocio.
1. Reactiva:
El negocio no tiene influencia activa sobre la ingeniería de la familia de software. En cambio,
reacciona
dependiendo de la situación.
Descripción:
Dimensión encargada con la habilidad de una organización de manejar, predecir, y direccionar el costo y las ganancias del desarrollo de software.
Arquitectura
Descripción:
Difiere significativamente de arquitecturas tradicionales de un sólo desarrollo de producto. Es esencial para detectar, diseñar, y modelar las partes variables y comunes de la ingeniería de la familia de software
Aspectos a evaluar
Calidad del producto:
La calidad de un conjunto de productos, como un todo, a bajos niveles es típicamente un accidente ya que toda la atención está puesta en proveer la funcionalidad adecuada. A más alto el nivel, el manejo de calidad es manejado de manera más explicita en la arquitectura.
Niveles de reuso:
Indica la cantidad de esfuero relativo que es gastado en producir activos compartidos reutilizables, cuando se comparan con la aplicación o producto de ingeniería.
Arquitectura de la familia de productos de software:
Puede existir en varios niveles. El invel determina qué es compartido y qué no en los productos producidos.
Manejo de variablidad de software:
A niveles bajos, el manejo de variabilidad se enfoca principalmente en soportar uniónes de componentes en tiempo de compilación y tiempo de linkeo. A más altos niveles, el ciclo de vida completo es tenido en cuenta para determinar cuando se introduce y une una variabilidad y los mecanismos usados para esto.
Niveles de estructura
3. Plataforma de software:
La arquitectura de la familia de software define una
plataforma de software
que se usa como base para el desarrollo de productos de software.
4. Productos variantes:
La arquitectura de la familia determina la construcción de
productos variantes
.
2. Infraestructura estandarizada:
La arquitectura de la familia se enfoca en la
estandarización de infraestructura
.
5. Productos autoconfigurables:
la arquitectura de la familia define reglas penetrantes que permiten habilitar la selección automática de activos para
configurar productos
.
1. Desarrollo independiente de productos:
No hay ingeniería de familia de software. En cambio, los productos se
desarrollan independientemente
.
Organización
Descripción:
La dimensión organizacional tiene que ver con la manera en que la organización es capáz de lidiar con relaciones complejas y sus muchas responsabilidades.
Aspectos a evaluar
Cultura:
Cuáles son los valores compartidos relacionados con la ingenieria de familias de software: Enfoque interno o coperativo, conservados vs innovador, enfocado en proceso vs productos.
Roles y responsabilidades:
Que can bien la organización maneja las distintas responsabilidades y sus relaciones: roles generales vs especializados.
Distribución geográfica:
Qué tan compleja es la distribución geográfica de la organización: Proyectos locales, departamentos, bordes entre compañias.
Ciclo de vida del producto:
El tipo de sistemas que se producen en relación con las características del ciclo de vida del producto. Qué tan largo es el ciclo de vida, el ritmo de las generaciones, y el tipo de mantenimiento empleado.
Niveles de estructura
3. Grupo o división de negocio:
La ingeniería de la familia de software toma lugar sobre varias lineas de borde dentro de
grupos de negocio
o
división
de producto, responsable de productos de negocio relacionados.
4. Interdivisiones o intercompañias:
La ingeniería de la familia de software toma lugar entre varias
divisiones
y
compañias
, con confianza mutua, cada una con su propia responsabilidad comercial que pueden incluso entrar en conflicto.
2. Orientado a lineas de negocio:
La ingeniería de familia de software toma lugar dentro de varias unidades de una línea de negocio, responsable de un conjunto de productos.
5. Negocio abierto (Software libre):
La ingenieria de la familia de software no está restringida a una colección de compañías que tienen confianza entre ellas. Esto involucra a cualquiera que vea ventaja en unirse.
1. Orientado a unidad:
La ingeniería de familia de software toma lugar dentro de una única y pequeña
unidad
de desarrollo.
Proceso
Descripción:
Esta dimensión hace enfasis en el proces, los roles, los productos de trabajo, y las correspondientes responsabilidades y relaciones dentro del desarrollo del software
Aspectos a evaluar
Predictibilidad:
Qué tan predecible es un desarrollo de software.
Repitabilidad:
Qué tan repetible es el proceso de desarrollo.
Cuantificabilidad:
Qué tan cuantificable es un desarrollo de software.
Niveles de estructura
3. Definido:
Los procesos cumplen con estándares.
4. Manejado cuantitativamente:
Los procesos tienen un seguimiento cuantitativo y son mejorados.
2. Manejado:
Existen procesos planeados disponibles.
5. Optimizado:
Los procesos son continuamente monitoreados y mejorados basados en los datos cuantitativos
1. Inicial:
No hay un proceso manejado ni estable. El desarrollo se hace de manera ad hoc.
CMM
EIA/IS 731
CMMI
ISO 15504
ISO 900X
