Este documento presenta un modelo de madurez de procesos de arquitectura (APMM) para evaluar la madurez de la arquitectura en el desarrollo de líneas de productos de software. El APMM define niveles de madurez y declaraciones de procesos clave para seis actividades de arquitectura. El modelo ayuda a las organizaciones a determinar la madurez actual de sus procesos de arquitectura de líneas de productos de software y cómo mejorar.

1. 
Abstract— In this document will explain about Software
Architecture as area important in the software engineering
community, in general this work contributes creation the
establishment of a comprehensive and unified strategy for the
process maturity evaluation of software product line engineering
Palabras claves— Arquitectura de software, ingeniería de
software, modelo de madurez, metodología, evaluación
I. INTRODUCTION
RQUITECTURA de software es una área de investigación
clave en la comunidad de ingeniería de software, debido al
su importante papel en la creación de software de alta calidad.
La tendencia de desarrollar líneas de productos en lugar de un
solo producto, ha hecho que la línea de productos de software
una opción viable en la industria.
Arquitectura en la línea de productos de software es
considerado como uno de los componentes cruciales en las
líneas de productos resultantes de compartir una arquitectura
común. La creciente popularidad de las líneas de productos de
software exige una evaluación de madurez de procesos en la
metodología. En consecuencia, este trabajo se presenta un
modelo de madurez de los procesos de arquitectura para la línea
de productos de software. [1]
II. LÍNEA DE PRODUCTOS DE SOFTWARE DE VENCIMIENTO:
VISTA GLOBAL
La línea de productos de software es un concepto
relativamente nuevo en la historia de desarrollo de software y
negocios. Mucho esfuerzo se ha generado en un paradigma de
la industria. La evaluación de procesos de la línea de software
es relativamente una nueva área de investigación en la que,
hasta ahora muy poco se ha hecho. Actualmente, los
investigadores de la academia de la industria están tratando de
desarrollar una forma de medir la madurez de un
A. ModelosPrevios
Uno de los propósitos de CMMI fue unir en forma coherente
varios modelos que eran utilizados en conjunto dentro de una
organización y que generaban repetición de contenido
provocando que el proceso de mejora llevado a cabo en la
organización fuera más difícil y costoso. Estos modelos
integrados porCMMI, que serán descritos a continuación y que
se ilustran en la Figura 1, eran modelos enfocados en
el desarrollo desistemas software (SW-CMM), en la ingeniería
de sistemas (SECM) y en el desarrollo de productos integrados
(IPD-CMM).
Ilustración 1Modelos Previos a CMMI
III. LA ARQUITECTURA DEL MODELO DE MADUREZ DE
PROCESOS DE INGENIERÍA DE LA LÍNEA DE PRODUCTOS DE
SOFTWARE
La APMM de SPL Engineering pretende establecer una
estrategia integral para evaluar la dimensión de la arquitectura
del proceso de SPL. Se describe la metodología de evaluación
del proceso del SPLA y determina la madurez actual del
proceso de desarrollo del SPLA en una organización. Además,
está estructurado para determinar cómo la arquitectura de
diversas actividades se realizan en el proceso de desarrollo de
SPL.
Un modelo de madurez de los procesos de
arquitectura de software de ingeniería de la línea de
productos
Leonardo Medina, Ingeniería de Software, Sistemas 8G1, Quito- Ecuador
A

2. IV. LA ARQUITECTURA DEL MODELO DE MADUREZ DE
PROCESOS DE INGENIERÍA DE LA LÍNEA DE PRODUCTOS DE
SOFTWARE
El concepto de la clasificación es importante para definir los
niveles de madurez del proceso de software en las metodologías
de evaluación. Muchos de los marcos de evaluación de procesos
de software populares, como CMM y bootstrap, utilizar el
proceso de clasificación para definir los niveles de madurez. La
tabla 2 ilustra el marco de la APMM. Cada nivel de madurez
incluye un conjunto de declaraciones que cubren todo el
proceso de arquitectura de seis actividades utilizadas en este
estudio. El número de declaraciones varía para cada nivel de
madurez para cada arquitectura y la actividad de los procesos.
Durante el resto de este documento, las abreviaturas para cada
proceso clave actividad será utilizado.
A. APA.X.Y
APA = La arquitectura de la actividad de los procesos.
X = Nivel de madurez (un entero)
Y = Proceso de arquitectura Actividad Número (entero)
B. S.I.J.K
S = Declaración
I = Nivel de madurez (un entero)
J = Proceso de arquitectura Actividad Número (entero)
K = Declaración Número (entero)
1) Base de productos configurables (Nivel 5)
APA.5.1
 S.5.1.1 Ingeniería de dominio del dominio de la
unidadde ingenieríatiene accesoa información
de recursos internos y externos y utiliza ambos
mecanismosformalese informalesparadifundir
el aprendizaje y conocimiento dentro de la
organización.
 S.5.1.2 un equipo conjunto del dominio y las
unidades de ingeniería de aplicación supervisar
la sincronización de las actividades en ambos
departamentos.
 S.5.1.3 del negocio y las unidades de ingeniería
de dominio coordinar la supervisión de planes y
estrategias de comercialización.
 S.5.1.4 el dominio de las actividades de
ingeniería de apoyo a la ejecución de planes
estratégicos institucionales.
APA.5.2 Administración de requisitos & Modelado
 S.5.2.1 los requisitos del SPLA incluyen el
segmento de mercado específicos.
 S.5.2.2 Los requisitos del SPLA se revisan con
regularidadyse actualizancuandoesnecesario.
 S.5.2.3 los requisitos acomodar los atributos de
calidad del SPLA.
APA.5.3 Arquitectura
 S.5.3.1 de análisisyevaluaciónde laorganización
es mejorar continuamente el proceso de
evaluación del SPLA y está experimentandocon
métodos innovadores.
 S.5.3.2 proporciona las funciones y
responsabilidades de los individuos y grupos en
analizar el SPLA están bien definidos y
documentados.
 S.5.3.3 La organización aprende de sus
experiencias y evita la repetición de errores en
su evaluación del SPLA.
APA.5,4 La homogeneidad Management
 S.5.4.1 la comunalidad Management permite la
máximacantidadde reutilizaciónde softwareen
la organización.
 S.5.4.2 La organización realiza periódicamente
revisionesdel mercado,yutilizaloscomentarios
del cliente para actualizar elementos comunes
entre productos sucesivos.
 S.5.4.3 Todos losproductosresultantesdel SPLA
comparten una base común.
APA.5,5 La variabilidad Management
 S.5.5.1 de la organización es mejorar
continuamente el proceso de gestión de la
variabilidad entre los distintos productos.
 S.5.5.2 Los requisitos variables de la línea de
productosestánbiendefinidosydocumentados.
 S.5.5.3 La organización realiza periódicamente
revisionesdel mercado,yutilizaloscomentarios
de los clientes para introducir características
variablesensucesivasel desarrollo del producto.
 S.5.5.4 la variabilidad entre productos ayuda a
retener clientes regulares y tiene tendencia a
atraer nuevos clientes.

3. APA.5,6 La arquitectura de gestión de artefactos
 S.5.6.1 los objetos arquitectónicos se revisan
periódicamente, actualizados y comunicados a
los desarrolladores.
 S.5.6.2 La organizacióntiene unbienestablecido
el plan de gestión del cambio para introducir y
gestionar los cambios en los objetos
arquitectónicos.
C. Rating método
Umbral de variabilidad Management (PT_VMAPA) y nivel de
madurez de la arquitectura (LMA). Cada uno de estos términos
se examina en detalle más adelante.
CMM (capability maturity model), 1993.
 Organización: SEI (Software Engineering
Institute)
 Información: http://www.sei.cmu.edu
 Estructura
 Niveles:
 Inicial
 Repetible
 Definido
 Gestionado
 Optimizado
 Áreas de proceso
MODELOS
 CMMi (capability maturity model Integration), 2001.
V. REFERENCIAS
[1] F. &. C. Ahmed, The Software Product Line
Architecture: An Empirical Investigation of Key, 50(11)
1098-1113, 2008.