See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/269270189

A software process line based on the Unified Process

Conference Paper · October 2012

DOI: 10.1109/ColombianCC.2012.6398023

CITATIONS READS

3 1,972

2 authors:

Pablo Hernando Ruiz Julio Ariel Hurtado

Corporación Universitaria Comfacauca Universidad del Cauca
18 PUBLICATIONS   40 CITATIONS    91 PUBLICATIONS   501 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Diseño De Juegos Pervasivos Basados En Experiencias De Aprendizaje Sensible Al Contexto (Dispersa) View project

Workshop on Experiences and Empirical Studies on Software Reuse View project

All content following this page was uploaded by Julio Ariel Hurtado on 16 May 2015.

The user has requested enhancement of the downloaded file.

 Una Línea de Procesos de Software basada en el
Proceso Unificado
A Software Process Line Based on the Unified
Process
Pablo H. Ruiz
Grupo de investigación IDIS
Universidad del Cauca
phruiz@unicauca.edu.co
Resumen— El Proceso Unificado – UP, es un marco prescriptivo
ampliamente utilizado por la industria del software. Debido a que
el UP fue desarrollado bajo el supuesto de una aplicabilidad
universal, su definición no viene adaptada a cada organización o
proyecto específico. Varias propuestas se han delineado para
adaptar este marco a las necesidades específicas de las
organizaciones y proyectos. Aunque estas adaptaciones se han
aplicado tanto en el ámbito de la industria, como en el de la
investigación, carecen de mecanismos sistemáticos y son difíciles
de replicar. Este artículo aplica una estrategia general, pero
concreta para facilitar la adaptación sistemática del Proceso
Unificado utilizando un enfoque de línea de procesos software.
Con el fin de evaluar nuestra propuesta, se ha implementado la
disciplina de implementación del UP como una la línea de
procesos software utilizando CASPER meta-proceso, donde la
adaptación es planeada y ejecutada brindando evidencias de las
ventajas y desventajas del enfoque.
Keywords- Proceso Unificado, Adaptación de Procesos y Línea
de Procesos Software.
Abstract— Unified Process - UP, is a prescriptive framework
widely used by the software industry. Since the UP was developed
under the assumption of a universal applicability, its definition is
not match to every organization or project. Several proposals
have been outlined to adapt this framework to the specific needs
of organizations and projects. Although these adaptations have
been applied in contexts, industry and research, they do not
include systematic mechanisms and so, they are difficult to
replicate. This paper applies a general strategy, but concrete to
facilitate systematic adaptation of the Unified Process using a
software process line approach. In order to evaluate this
proposal, the UP implementation discipline has been modeled as
a software process line using CASPER meta-process providing
evidences about the advantages and disadvantages of approach.
Keywords— Unified Process, Tailoring Process and Software
Process Line.
I. INTRODUCCIÒN
La adaptación de procesos software es una tarea recurrente,
que consume tiempo y demanda conocimiento para las
organizaciones. En [1] se muestra que el 77% de las empresas
Julio A. Hurtado
Grupo Investigación IDIS
Universidad del Cauca
ahurtado@unicauca.edu.co
adaptan el proceso software de una forma implícita e
impredecible. Esto origina que la experiencia, conocimiento y
análisis involucrado en el proceso de adaptación no sea
capturado y por lo tanto, no sea compartido y reutilizado. El
Proceso Unificado - UP [4] es un marco de procesos software
aplicado a múltiples contextos de proyectos y en numerosas
organizaciones en el mundo [2]. Reportes de experiencia, libros
y publicaciones científicas indican un considerable interés en el
uso de UP en la industria mundial. Particularmente un estudio
realizado en el marco del proyecto SIMEP-SW arrojó que
cerca del 50% de las pequeñas empresas de software del sur
occidente colombiano utilizan UP como marco de referencia
[3]. UP es presentado como un marco de procesos adaptable en
[4], donde se debe considerar el tamaño del producto, el
dominio del problema, la complejidad del sistema, la
experiencia de las personas y el nivel del proceso
organizacional para efectuar su adaptación. Además, UP
incluye una guía general y manual para su adaptación, que no
explica de forma clara como los elementos del proceso deben
ser seleccionados o adaptados de acuerdo a un contexto
específico [2], [5]. De esta forma, el proceso de adaptación del
UP es propenso al error y consume tiempo. El MDE (Model
Driven Engineering) es una estrategia que se puede utilizar en
la adaptación de procesos. En [7] se presenta una estrategia
basada en MDE para definir modelos de procesos adaptables.
En ésta estrategia un modelo de procesos específico desde un
modelo de procesos general utilizando una especificación
formal del contexto específico del proyecto. En este artículo
dicha estrategia MDE es aplicada en la adaptación del modelo
de procesos del UP. Para ello, el UP es definido como una línea
de procesos - PUL soportada en la experiencia empírica de
adaptación basada en la guía presentada en [8]. La definición
de UP como una línea de procesos fue guiada por el meta-
proceso CASPER (Contex Adaptable Software Process
EngineeRing) presentado en [7], el cual sigue un enfoque de
familia de procesos y una estrategia MDE para producir
modelos de procesos software.
En la sección 2 de este artículo se describen trabajos
relacionados con las adaptaciones y mecanismos de adaptación
del Proceso Unificado reportadas por la literatura. En la
sección 3 se presenta el marco general del Proceso Unificado
como una línea de procesos canónica, mientras un caso
especifico es detallado en la sección 4 utilizando la experiencia
ganada durante el desarrollo de la guía [8] en la adaptación de
la disciplina de implementación del Proceso Unificado. En la
sección 5, se presentan las conclusiones y trabajo futuro.
II. TRABAJO RELACIONADOS
Algunos trabajos definen formas para mejorar la adaptación
del UP a situaciones específicas [2], [5], [6]. Herramientas de
soporte como EPFC 1 y RMC 2 han sido desarrolladas por la
comunidad y la industria para soportar el proceso de adaptación
de una forma organizada basada en el concepto de
configuración. Sin embargo, estos métodos son todavía
limitados porque la adaptación no es sistemática y depende de
la experiencia del ingeniero de procesos, lo que la hace poco
repetible y por tanto susceptible al error humano. Aunque
existen diversos acercamientos para la adaptación de procesos
como los presentados en [7] éstos son acercamientos generales,
existe poca evidencia de su aplicación a procesos de software
establecidos y ampliamente conocidos y aplicados por la
industria, como es el caso del Proceso Unificado - UP. Existe
evidencia empírica sobre adaptaciones del UP, es el caso de
procesos como: Agile UP (AUP) [18], Basic Unified Process
(BUP) [19], Open Unified Process (OpenUP), Open Unified
Process Basic (OpenUP/Basic) [20] y Enterprise Rational
Unified Proceses (EUP) [21]. Estas adaptaciones y extensiones
de UP, deben aún ser adaptados para cubrir las necesidades de
las diferentes organizaciones y proyectos, puesto que siguen
teniendo un alcance muy amplio. Concretamente el Proceso
Unificado en su disciplina de ambiente brinda una guía de
ajuste para la adaptación [4], donde se identifican factores
como elementos relevantes que pueden influir y guiar la
adaptación del proceso. En este mismo enfoque de adaptación
se encuentra la guía de adaptación del Proceso Unificado a
contextos específicos de proyectos en el ámbito de pequeñas
organizaciones presentado en [8]. Sin embargo, este enfoque
carece de planificación y resulta complejo debido a los
cuidados en la selección de elementos por la dependencia que
estos tienen sobre otras partes del proceso. En [6] se propone
un enfoque basado en la definición de un meta-modelo en la
que se extiende el meta-modelo de RUP (Rational Unified
Process) incluyendo nuevos elementos y relaciones necesarias
para permitir la adaptación del proceso. El anterior enfoque se
orienta a la definición de un proceso adaptable, pero no define
los mecanismos para lograr la adaptación, es decir, no tiene en
cuenta información del contexto de las organizaciones o
proyectos específicos para tomar las decisiones en la
adaptación.
Un modelo genérico para la adaptación es presentado en
[23], donde la adaptación se hace sobre la base de las
características del proyecto utilizando un modelo de
comparación de características el cual tiene como fin recuperar
y reutilizar posibles partes de procesos previamente definidos.
1
Eclipse Process Framework Composer (EPFC) website
http://www.eclipse.org/epf/
2
Rational Method Composer (RMC) website http://www-
01.ibm.com/software/awdtools/rmc/s
No obstante el proceso es adaptado en forma manual. Esta
adaptación fue evaluada en una empresa de desarrollo de
software en la que se adaptó la disciplina de planificación y
gestión de RUP. En [1] se propone un marco conceptual
dirigido a las empresas y equipos de desarrollo de software
para asistir el método de adaptación de procesos, presenta un
caso de estudio de aplicación de su propuesta en una empresa
en la cual se ha adoptado RUP como proceso organizacional.
En este caso se evidencia el uso de información de contexto
para conducir la adaptación, sin embargo, esta no es
sistemática.
III. APLICANDO CASPER PARA GENERAR PUL
El proceso de software se define como un conjunto de
actividades, métodos, prácticas y transformaciones que las
personas usan para desarrollar y mantener software, como
también sus productos asociados (p.ej., planes,
especificaciones, diseños y pruebas) [9] dentro de una
planificación y presupuesto predecible [4]. Su definición
incluye un ciclo de vida y un conjunto de cuerpos de
conocimiento denominados disciplinas.
A. Enfoque de adaptación
CASPER es un meta-proceso para definir modelos de
procesos software adaptables mediante familias de procesos
[7]. Utiliza coherentemente tres enfoques principales: líneas de
procesos software, modelamiento del contexto extendiendo
modelado del proceso y se basa en transformación de modelos
para efectuar la adaptación. Las líneas de procesos gestionan el
proceso software y su variabilidad de forma sistemática,
promoviendo que los procesos software puedan ser
organizados de acuerdo a similitudes y diferencias, que
permiten una mejor adaptación a las necesidades de un
proyecto específico [22]. El modelamiento del contexto
identifica las particularidades del proyecto y/o organización
que pueden afectar la adaptación del proceso. Para la
implementación de los procesos adaptables en CASPER 3 se
han definido los meta-modelos SPCM (Software Process
Contex meta-model) para plasmar el Modelo de Contexto y
SPEM 2.0 (Software and Systems Process Engineering Meta-
model) para definir el proceso software con su variabilidad. La
variabilidad hace referencia al conjunto de puntos de variación
(opcional y alternativa) y sus variantes que se tiene planificado
para un proceso. CASPER utiliza técnicas ingeniería dirigida
por modelos - MDE como estrategia de adaptación, en la cual
el proceso software de referencia, el proceso adaptado y el
contexto son definidos como modelos, así mismo el proceso de
adaptación mismo se programa como un una transformación
declarativa en la que se aplican un conjunto de reglas. El meta-
proceso CASPER es utilizado en este estudio para estructurar e
implementar una línea de procesos canónica basada en el
Proceso Unificado. Esta línea de procesos canónica incluye una
guía de extensión con el fin de generar líneas de procesos
específicas en las organizaciones. La Fig. 1 presenta los
modelos y la estrategia general que se aplica a la generación de
procesos miembro de la familia basada en UP. La descripción
3
Información del meta-modelo SPCM se encuentra en [7] y en la
dirección web https://sites.google.com/site/softwaremetaprocess/home/casper-
tool
de los elementos que hacen parte de la línea de procesos del UP una configuración del modelo de contexto y una copia del
– PUL se describe a continuación. modelo de procesos de referencia. Mediante reglas concretas se
efectúa la transformación del modelo de procesos de referencia
B. Definición del Modelo de Contexto Canónico de PUL a un modelo de procesos adaptado de acuerdo a las
El modelo de contexto canónico definido para la línea de características puntuales del proyecto y de la organización,
procesos PUL es conforme a SPCM el cual se basa en tres plasmadas en una configuración del modelo de contexto. La
conceptos básicos: atributo de contexto, dimensión y atributo línea de procesos canónica incluye un conjunto de patrones de
de configuración de contexto. El contexto de un proyecto adaptación, los cuales serán usados como referentes para
puede variar en diferentes dimensiones específicas, por extender las transformaciones definidas en el modelo. Dichos
ejemplo: proyecto, producto, equipo. Las dimensiones incluyen patrones serán establecidos correlacionando los hallazgos
variables contextuales modeladas como atributos de contexto establecidos a partir del análisis de los procesos del modelo de
tales como tamaño de producto, duración, complejidad, tamaño referencia canónico y del modelo de contexto canónico.
del equipo de desarrollo, el conocimiento sobre el dominio de
aplicación, y la familiaridad con la tecnología utilizada, entre
otros. El modelo de contexto PUL define un conjunto
incompleto de dimensiones y atributos y valores de atributos
con el fin de que la organización extienda el modelo canónico.
Para configurar un nuevo contexto se deben seleccionar las
características propias, de la organización y/o del proyecto
específico, contenidas en el modelo de contexto. Existe
evidencia empírica en reportes y adaptaciones [8], [23] que
permitieron definir en forma preliminar este modelo de
contexto. Para la versión final es necesario lograr una
caracterización estructurada de adaptaciones, mediante
experiencias descritas en la literatura y la industria, tales como
las propuestas en [1], [2], [4], [6] [8], [23], [27] que permita
identificar las dimensiones, atributos y valores de atributos
adecuados. En la generación de procesos adaptados, el modelo
de contexto proporciona una o varias configuraciones
contextuales.

C. Definición del Proceso de Referencia Canónico de PUL
El Modelo canónico de la familia de procesos de PUL
contiene la definición de UP como el proceso de referencia y
un conjunto de diferentes variantes identificadas y
estructuradas coherentemente, y definidas conforme a SPEM
2.0. Con este modelo se pretende facilitar la reutilización y
evolución de los componentes de proceso, así como también
facilitar la adaptación mediante puntos iniciales de variación y
variantes. La creación completa de éste núcleo será obtenida de
[4], [18], [19], [20] [21], usando las técnicas [25], [26] para la
obtención del proceso núcleo y sus variantes.
El modelo de proceso canónico proporciona una versión
básica y extensible de la familia de procesos para desarrollo de
software basada en el UP y una guía de extensión a las
necesidades de la organización.
D. Definición de la Estrategia de Adaptación Canónica del
PUL
La transformación de modelos es un proceso mediante el cual
se hace la adaptación del modelo de proceso de referencia a un
modelo de procesos adaptado de acuerdo a las características
del proyecto y de la organización plasmadas en la
configuración del modelo de contexto. Para realizar la
transformación de modelos es necesario definir reglas de
adaptación, las cuales son definidas haciendo un análisis de
cómo se relacionan los atributos del modelo de contexto con
las variantes del modelo de proceso. En la ejecución de la
adaptación la transformación de modelos recibe como entradas
Fig. 1. Modelo de Línea de UP- PUL
IV. VALIDACIÓN PRELIMINAR: DEFINICIÓN DE LA
DISCIPLINA DE IMPLEMENTACIÓN PUL-I
En esta sección se muestra cómo se implementa la
disciplina de implementación en el UP – denominada PUL-I
como una forma de validar conceptual y técnicamente la
propuesta de PUL. Esta disciplina ha sido modelada como
parte del proceso UP e incluye además, la incorporación de una
práctica no propia del proceso, considerando el caso típico al
considerar que las organizaciones que han adoptado el proceso
unificado conservan aún sus prácticas nativas o incorporan
prácticas de otros procesos.
A. Modelo de Contexto de PUL-I
Se ha definido de forma preliminar las dimensiones,
atributos y valores de atributos que resultan relevantes para la
adaptación de ésta disciplina de acuerdo a parte de la
información de contexto manejada en [8], [23]. Los elementos
del modelo de contexto de la línea de procesos se ilustran en la
fig. 2.
B. El modelo de referencia de PUL-I
En esta sección se define de forma preliminar el proceso de
implementación de UP, ver fig. 3, es un proceso definido en
SPEM 2.0 el cual está basado en la especificación hecha por
[4] e incluye las siguientes tareas principales: Estructurar el
Modelo de Implementación, Plan de integración, Implementar
componentes, Integrar cada subsistema e Integrar el sistema.
Fig. 2. Modelo de Contexto UP-I
La actividad Estructurar el Modelo de Implementación
tiene como propósito constituir el modelo de implementación
para asegurar una fácil implementación e integración. En la
construcción de este modelo se tiene como resultado un
conjunto de subsistemas a implementarse que pueden ser
desarrollados independientemente. La actividad Plan de
integración tiene como propósito prever la integración de los
subsistemas, enfocándose principalmente en el orden que
deben ser integrados. La actividad Implementar componentes
tiene como propósito efectuar parte de la implementación de
los componentes para que de esta forma sean integrados. La
actividad Integrar Cada Subsistema tiene el propósito integrar
los subsistemas para crear una versión coherente y nueva de un
subsistema más complejo y por último la actividad Integrar el
Sistema tiene el propósito de realizar la integración de los
subsistemas principales para crear una nueva versión del
sistema general.
Fig 3. Proceso de Implementación.
C. El modelo de variabilidad de PUL-I y su alcance
Para establecer la variabilidad del proceso se utiliza la
notación descrita en [23], ver figura 4. El primer elemento de la
notación hace referencia a que una entidad 4 del proceso es
opcional, la segunda notación indica que la entidad del proceso
es obligatoria y la tercera notación indica alternativas diferentes
para desarrollar la entidad del proceso.
Fig. 4. Notación para identificar las características del proceso.
La variabilidad identificada en el proceso de
implementación se muestra en la Fig. 5. Hemos usado
estereotipos de SPEM 2.0 para representar de manera
específica las características del proceso en forma similar a [7].
Establecer el alcance de la línea de procesos en CASPER
requiere buscar las relaciones entre los atributos de contexto y
puntos de variabilidad y las variantes del proceso.
Fig 5. Modelo de características del Proceso de Implementación.
Las actividades Plan de integración e Integrar Cada
Subsistema son opcionales para el desarrollo de proyectos
pequeños puesto que el modelo de implementación resultado
de la actividad Estructurar el Modelo de Implementación estará
compuesto por un conjunto pequeño de subsistemas a
implementarse, de tal forma que la planeación de la integración
de los subsistemas y la integración de cada subsistema no sea
necesaria. Es decir estas dos actividades son recomendadas
para grandes sistemas en los cuales hay más cantidad de
recursos utilizados donde la empresa debe seguir un proceso
más riguroso. La actividad Implementar Componentes tiene
dos alternativas para su desarrollo TDD ó Diseñar e
Implementar Componentes. TDD resulta ser de gran ayuda
para desarrollos donde la experiencia técnica es alta, debido a
que es un método de implementación que requiere que el
equipo de desarrollo tenga interiorizadas de manera adecuada
esta práctica para que su aplicación sea exitosa. En el enfoque
tradicional descrito mediante la actividad Diseñar Implementar
Componentes primero se espera a tener el componente o pieza
de software implementado para hacer las pruebas, es un
enfoque más guiado y establecido por pasos secuenciales
fáciles de seguir por un equipo con menos experiencia.
4
Entidad del proceso: Hace referencia a cualquier elemento que haga
parte del proceso software como actividad, tarea, proceso.
 El modelo de proceso con variabilidad resultante después Subsistema del proceso de implementación no harán parte del
del análisis de características del proceso de Implementación se proceso adaptado.
presenta en la fig. 6.

D. Reglas de adaptación
Para que la adaptación en la línea de procesos se realice de
manera automática es necesario definir reglas de adaptación
que permitan relacionar los elementos de la configuración del
modelo de contexto con las variantes del proceso. Para ello
debemos usar la información del alcance que relaciona los
valores de los atributos de contexto y las características de los
procesos. Las reglas de adaptación deben tomar la decisión
sobre cuales elementos del proceso harán parte del proceso
adaptado dependiendo de los valores que tome los atributos de
contexto. El código de la fig. 7, corresponde solo a una regla de
opcionalidad definida en ATL para la actividad Plan de
integración. De igual manera se definió la regla
correspondiente a la opcionalidad de la actividad Integrar
Cada Subsistema. La fig. 8 muestra el código de
implementación de la regla ATL que se ejecuta cuando es
necesario hacer una selección entre TDD o Diseñar e
Implementar Componente. La adaptación del proceso se realiza
mediante la configuración del modelo de contexto y la
ejecución de las reglas de adaptación. La tabla 1, muestra un
ejemplo de configuración de modelo de contexto. Como la Fig 6. Proceso de Implementación con variabilidad
configuración del modelo de contexto, especifica que el
atributo Tamaño del Proyecto tiene el valor “pequeño”,
entonces la actividad Plan de integración e integrar Cada

Fig. 7. Regla de Adaptación de opcionalidad

Fig. 8. Regla de Adaptación de selección

TABLA 1. CONFIGURACIÓN DEL MODELO DE CONTEXTO configuración del modelo de contexto especificado en la Tabla
Atributo de Contexto Valor
1 arrojará como resultado el proceso adaptado de la fig. 8.
Tipo de proyecto Extensión
E. Resultados y Discusión
Experiencia en el proyecto Baja
En este caso se presenta la implementación de un
Tamaño del equipo Pequeño
fragmento del Proceso Unificado siguiendo el enfoque de línea
de procesos. Para generar las respectivas instancias sé
utilizaron los meta-modelos suministrados por CASPER y se
De la misma manera el atributo de contexto experiencia utilizo Eclipse Indigo con EMF 5 – Eclipse Modeling
técnica tiene valor “alta”, entonces la actividad TDD hará parte
del proceso adaptado en lugar de Diseñar e Implementar
Componentes. La ejecución de la reglas de adaptación bajo la 5
EMF website http://download.eclipse.org/tools/emf
Framework y ATL6 SDK - ATLAS Transformation Language
SDK. Específicamente, la implementación del modelo de
contexto, utilizando SPCM definido por CASPER, tuvo un
esfuerzo bajo (3 horas-persona). La implementación del
modelo de características también demandó un esfuerzo bajo (3
horas-hombre), mientras el modelo de proceso de referencia
tuvo un esfuerzo medio (8 horas-persona). La implementación
de las reglas de Tailoring en ATL resultó notablemente
dificultosa en esta experiencia dado que involucró la
asimilación de nuevos conceptos traídos del MDE, elementos
propios del lenguaje ATL y la complejidad de relacionar
adecuadamente los atributos de contexto y las variabilidades
con un esfuerzo notablemente grande (18 horas-persona). De
tal forma que diseñar la estrategia de adaptación demandó el
56,25% del esfuerzo total de la construcción de la línea de
procesos.
Fig. 8. Proceso de implementación adaptado.
A pesar de éstos resultados tan favorables la identificación
de las características del proceso que extienda la organización
será una tarea ardua, debido a que es preciso tener en cuenta
evidencia empírica de los ajustes realizados a los procesos al
interior de las organizaciones. Para el modelo canónico las
evidencias deben ser cuidadosamente evaluadas desde la los
reportes de la literatura científica. Sin embargo, una vez
disponible la variabilidad del proceso reducirá la tarea de
adaptación del proceso al limitarse a definir sólo una situación
específica.
La identificación de los elementos del modelo de contexto,
adecuados para el UP, es de vital importancia al igual que la
identificación de las características del modelo de procesos.
Debido a que nos permitirán establecer la relación e influencia
que tienen estos dos modelos para así lograr una adaptación
adecuada. Las relaciones e influencia entre estos modelos se
plasman mediante reglas de Tailoring. Esta experiencia en la
adaptación mediante esta primera versión de la línea de
procesos ha sido más satisfactoria que previas adaptaciones
manuales de este proceso en similares condiciones debido a su
planeación y soporte técnico. Si bien ha habido un esfuerzo
mayor en la definición de la línea respecto a la definición de un
proceso único (4 veces más de esfuerzo), ahora se cuenta con
6
ATL website http://www.eclipse.org/downloads/
una definición adaptable, en la que no se requiere un esfuerzo
considerable (menor a 1 hora) para generar uno de 8 procesos
posibles, generando así una reducción del esfuerzo en el 50%.
Hay que considerar además que es más manejable evolucionar
un solo proceso de referencia a evolucionar 4 procesos
independientes. Adicionalmente, dado lo parcial del modelo,
los puntos de variación identificados fueron pocos y así el
número de procesos derivables bajo, lo cual no ocurrirá en la
familia canónica completa.
V. CONCLUSIONES Y TRABAJO FUTURO
En este artículo se presenta una propuesta de adaptación del
Proceso Unificado como una línea de procesos software guiada
por la ingeniería de modelos siguiendo CASPER meta- método
donde la adaptación es planeada y ejecutada utilizando una
estrategia generativa, resultando en una solución costo-efectiva
de adaptación. Para generar la línea de procesos canónica
basada en el Proceso Unificado se requiere identificar la
variabilidad del proceso, la cual es una actividad que requiere
tiempo, experiencia, y es compleja, donde se debe tener en
cuenta procesos previamente adaptados, así como algunas
prácticas propias de las empresas. Al modelar la variabilidad y
alcance de la variabilidad de una sola disciplina del UP, no se
pueden analizar las dependencias que estas decisiones guarden
con otras decisiones de adaptación del proceso y por tanto
pueden resultar inconsistentes. Así, como trabajo futuro se
tiene, profundizar en la definición completa y consistente de
los elementos que harán parte de la línea de procesos canónica,
como el modelo de contexto, el modelo de procesos, el
alcance, las reglas de adaptación y guía de extensión para su
aplicación por parte de las organizaciones. Dada la
complejidad resultante de las reglas ATL, se hace necesario
identificar y suministrar un conjunto de patrones de
transformación que faciliten al ingeniero de procesos
implementar las reglas de tailoring de una forma más práctica y
menos propensa a errores. Esto reduciría notablemente el
esfuerzo en la implementación de las adaptaciones del Proceso
Unificado que las organizaciones puntualmente requieran.
VI. AGRADECIMIENTOS
El trabajo de Pablo H. Ruiz ha sido financiado
parcialmente por el SSP de LACCIR S1110LAC006. El
trabajo de Julio A. Hurtado ha sido parcialmente financiado
por el proyecto Fondef D09I1171 de Conicyt, Chile y el
proyecto IF-002-11, CINTEL, Colombia.
REFERENCIAS
[1] C. Patel, S. Cesare, N. Lacovelli, A. Merico, “A Framework for Method
Tailoring: A Case Study”. 2nd OOPSLA Workshop on Method
Engineering for Object-Oriented and Component-Based Development.
2004.
[2] G. Hanssen, F. Bjornson, H. Westerheim, “Tailoring and Introduction of
the Rational Unified Process.” P. Abrahamsson et al. (Eds.): EuroSPI
2007, LNCS 4764, pp. 7–18, Springer-Verlag Berlin Heidelberg. 2007.
[3] J. Hurtado, F. Pino, J. Vidal . “Sistema Integral para el Mejoramiento
de los Procesos de desarrollo de Software en Colombia SIMEP-SW”.
2006.
[4] I. Jacobson., G. Booch, J Rumbaugh, “Unified Software Development
Process”, Addison- Wesley. 1999.
[5] J. Hartmann, L. Fontoura, R. Price, “Using Risk Analysis and Patterns [27] G. Hanssen, H. Westerheim, F. Bjørnson, “Using Rational Unified
to Tailor Software Processes”. Instituto de Informática – Universidade Process in an SME - A Case Study”. In: Richardson, I., Abrahamsson,
Federal do Rio Grande do Sul (UFRGS). 2005. P., Messnarz, R. (eds.) Software Process Improvement. LNCS, vol.
[6] E. Pereira, R. Bastos, T. Oliveira, “A Systematic Approach to Process 3792, Springer, Heidelberg. 2005
Tailoring”. International Conference on Systems Engineering and
Modeling. ICSEM. 2007.
[7] J. Hurtado, A. Quispe, M. Bastarrica, S. Ochoa, “ A MDE Production
Strategy for Software Process Lines”. International Conference on
Software and Systems Processes. 2011.
[8] P. Ruiz, C. Maya, L. Pantoja, J. Hurtado, “Guía de Adaptación del
Proceso Unificado a Proyectos Específicos para las Pymes
Desarrolladoras de Software”.V Congreso Colombiano de
Computación. 2010.
[9] M. Ginsberg, L. Quinn, “Process Tailoring and the software Capability
Maturity Model”.Technical report, Software Engineering Institute (SEI).
USA. 1995
[10] D. Bustard, F. Keenan, “Strategies for Systems Analysis: Groundwork
for Process Tailoring”. Engineering of Computer-Based Systems ECBS,
12th IEEE International Conference and Workshops. 2005..
[11] D. Fei, L. Tong, “Tailoring Software Evolution Process”. Eighth ACIS
International Conference on Software Engineering, Artificial
Intelligence, Networking, and Parallel/Distributed Computing. 2007.
[12] Y. II-Chul., M. Sang-Yoon, B. Doo-Hwan. “Tailoring and Verifying
software Process”. IEEE. apsec, p. 202, Eighth Asia-Pacific Software
Engineering Conference (APSEC'01). 2001.
[13] P. Funk, “Reuse, Validation and Verification of System Development
Processes”. Proceedings to the First International Workshop on the
Requirements Engineering Process, IEEE Computer Society. 2000.
[14] Y. Ahn, H. Ahn, S. Park, “Knowledge and case-based reasoning for
customization of software processes - a hybrid approach”. International
Journal of Software Engineering and Knowledge Engineering, Vol. 13,
No. 3,. pp. 293-312. 2003.
[15] P. Killisperger, M. Stumptner, G. Peters, G. Grossmann, “Meta Model
Based Architecture for Software Process Instantiation”. ISSN 0302-
9743 Volume 5543/2009. Book: Trustworthy Software Development
Processes ISBN 978-3-642-01679-0 Pages 63-74. Springer-Verlag
Berlin Heidelberg. 2009.
[16] B. Simidchieva, L. Clarke, L. Osterweil, “Representing Process
Variation with a Process Family”. In qing Wang, Dietmar Pfahl, and
David M. Raffo, editors, ICSP´2007, volumen 4470 of LNCS,pages
109-120. 2007.
[17] J. Hurtado, C. Bastarrica, “Process Model Tailoring as a Means for
Process Knowledge Reuse”. In Proceedings of the 2nd Workshop on
Knowledge Reuse (KREUSE’2009),Falls Church Virginia, USA. 2009.
[18] Agile UP (AUP): Disponible en Web::
http://www.ambysoft.com/unifiedprocess/agileUP.html
[19] R. Balduino, “Basic Unified Process: A Process for Small and Agile
Projects”. Rational Unified Process Content Developer, IBM.
[20] Open Unified Process (OpenUP) y Open Unified Process Basic
(OpenUP/Basic): Disponible en Web:
http://epf.eclipse.org/wikis/openup/
[21] Enterprise Rational Unified Proceses (EUP). Disponible en Web:
http://www.enterpriseunifiedprocess.com/
[22] D. Rombach, “Integrated Software Process and Product Lines”. ISSN
0302-9743 Volume 3840/2006. book Unifying the Software Process
Spectrum. ISBN 978-3-540-31112-6.Pages 83-90. 2005
[23] C. Coelho, “MAPS: Modelo de Adaptación de proceso software”.
Master' Thesis. Federal University of Pemambuo – UFPE. 2003.
[24] K. Kang, S. Kim, J. Lee, K. Kim, E. Shin, M. Huh. “FORM: A feature
oriented reuse method with domain-specific reference architectures”.
Annals of Software Engineering, 5(1):143–168, Jan. 1998.
[25] A. Ocampo, F. Bella, & J. Münch. “Software process commonality
analysis”. In Software Process: Improvement and Practice. Special issue
on ProSim 2004, The 5th International Workshop on Software Process
Simulation and Modeling, Edinburgh, Scotland, vol. 10, 273.2005.
[26] H Washizaki, “Building software process line architectures from bottom
up”. In J. Münch & M. Vierimaa, eds., Product-Focused Software
Process Improvement, LNCS, 415-421, Springer. 2006

View publication stats