Seleccion de Servidores

Selección de servidores de
aplicaciones como parte del diseño

de una arquitectura de software
multicapas aplicando una
metodología multicriterio
Andrés Leonardo Rojas Duarte
Universidad Nacional de Colombia

Facultad de Ingeniería, Departamento de Sistemas e Industrial
Bogotá, Colombia
2015
Selección de servidores de
aplicaciones como parte del diseño
de una arquitectura de software
multicapas aplicando una
metodología multicriterio
Andrés Leonardo Rojas Duarte
Trabajo final presentado como requisito parcial para optar al título de:
Magister en Ingeniería de Sistemas y Computación
Director:
PhD. Félix Antonio Cortés Aldana
Codirector:
PhD. Yoan Pinzón
Línea de Investigación:
Investigación de Operaciones
Toma de Decisiones
Universidad Nacional de Colombia

Facultad de Ingeniería, Departamento de Sistemas e Industrial
Bogotá, Colombia
2015
A mi madre, hermanas y sobrina por ser una
constante motivación y apoyo.
Agradecimientos
En esta sección quiero agradecer a:
 Los profesores de la Universidad Nacional de Colombia: PhD. Félix Cortes Aldana

y PhD. Yoan Pinzón, por su constante apoyo y guía la cual sirvió para estructurar
y desarrollar este trabajo de la mejor forma posible.
 A mi familia por ser una inspiración y motivación para mi desarrollo personal,
profesional y académico.
 A los ingenieros M.Sc. Camilo Andrés Varela León, M.Sc. Oscar Guillermo
Mellizo Angulo y M.Sc. Luis Horacio Riveros Ardila, por su participación activa en
el desarrollo de este trabajo.
Resumen y abstract V
Resumen
Para la definición de la arquitectura de aplicaciones empresariales el patrón
recomendado a seguir es la división en varias capas: datos, lógica de negocios y
clientes. Cada una de las capas, tiene un conjunto de responsabilidades bien definidas
las cuales son soportadas por un conjunto de componentes específicos. En el caso de la
capa de negocio, uno los componentes son los servidores de aplicaciones. En el
mercado existe una gran lista de este tipo de componentes, los cuales tienen un gran
número de funcionalidades y características que son mejorados constantemente, esto
combinado con los múltiples criterios que deben ser considerados para su selección y las
opiniones de los decisores, hacen que la selección del servidor de aplicaciones más
adecuado sea un problema del tipo multicriterio.
En este documento se presenta la aplicación de una metodología de análisis multicriterio,

que tiene como objetivo principal, la selección del servidor de aplicaciones más
adecuado para dar soporte a los procesos de negocios de una entidad estatal
colombiana la cual se encuentra en proceso de actualización tecnológica.
Para la selección del servidor de aplicaciones se realizó una revisión del estado del arte
de los procesos de selección de software siguiendo un enfoque sistemático, con el
objetivo de determinar las metodologías y los conjuntos de criterios utilizados durante
dichos procesos. Posteriormente se definió el proceso de selección como un problema
de análisis de multicriterio estableciendo la respectiva matriz de decisión. El problema de
selección se solucionó mediante la ponderación de la importancia relativa de los criterios
mediante la metodología AHP (Analytic Hierarchy Process). Durante todo el proceso de
la aplicación de la metodología, se involucró activamente a los expertos de la empresa
involucrada en el proceso de actualización
Palabras clave: Análisis multicriterio, AHP, procesos de negocio, servidores de

aplicaciones, selección de software, evaluación de software.
VI Selección de servidores de aplicaciones como parte del diseño de una arquitectura
de software multicapas aplicando una metodología multicriterio
Abstract
For the definition of the architecture of business applications, the recommended pattern
to follow is the division in several layers: data, business logics and clients. Each of the
layers has a set of well defined responsibilities, which are supported by a set of specific
components. In the case of the business layer one of those components are the
application servers. In the market there is a long list of this type of components, which
has several functionalities and features that are improved constantly, this combined with
the multiple criteria to be considered during the selection process and the different
opinions of the decision makers, make the selection of the most suitable application
server a multiple criteria problem.
In this paper the application of a multicriteria methodology is presented, with the main
objective of selecting the most suitable application server, to give support for the business
process of a colombian state entity in a process of technological upgrade.
For the selection of the application server a systematic review of the state of art of
software selection process was conducted, in order to find the methodologies and criteria
used in that type of processes. The next step was to define the selection process as
multicriteria analysis problem through the definition of the decision matrix. The selection
problem was solved weighting the criteria importance with AHP (Analytic Hierarchy
Process). Throughout the entire process of implementing the methodology, experts were
actively involved.
Key words: Multicriteria analysis, AHP, business processes, application servers,

software selection, software evaluation.
Contenido VII
Contenido
Pág.
Resumen .......................................................................................................................... V
Lista de figuras ............................................................................................................... IX
Lista de tablas ................................................................................................................. X
Lista de Símbolos y abreviaturas .................................................................................. XI
Introducción .................................................................................................................... 1
1. Revisión del estado del arte .................................................................................... 5

1.1 Metodología ..................................................................................................... 5
1.1.1 Preguntas de investigación ................................................................... 6
1.1.2 Definición del proceso de búsqueda...................................................... 6
1.1.3 Criterios de Inclusión ............................................................................. 7
1.1.4 Recolección de datos y análisis de datos .............................................. 7
2. Estudio de caso ...................................................................................................... 32

2.1 Descripción de FSW ...................................................................................... 32
2.2 Proceso de Toma de Decisiones en FSW...................................................... 33
2.3 Perfil de los expertos ..................................................................................... 34
2.4 Descripción de EEC ....................................................................................... 35
2.5 Descripción del caso ...................................................................................... 36
3. Criterios de Selección ............................................................................................ 39

3.1 Objetivos........................................................................................................ 40
3.2 Alternativas .................................................................................................... 41
3.3 Consecuencias .............................................................................................. 42
3.4 Transacciones ............................................................................................... 43
3.5 Criterios ......................................................................................................... 44
4. Valoración de los criterios de selección ............................................................... 47

4.1 Valoración de criterios técnicos ..................................................................... 47
4.2 Valoración de criterios funcionales................................................................. 51
4.3 Valoración de criterios de documentación...................................................... 53
5. Solución del problema de decisión ....................................................................... 55

5.1 Representación Jerárquica del Problema de Decisión ................................... 55
5.2 Prioridad de los criterios ................................................................................ 56
5.3 Valoración de las alternativas ........................................................................ 62
6. Conclusiones .......................................................................................................... 66
7. Trabajos Futuros .................................................................................................... 68
A. Anexo: Propuesta de trabajo final ......................................................................... 69
B. Anexo: Articulo COGESTEC 2014 ......................................................................... 91

VIII Selección de servidores de aplicaciones como parte del diseño de una
arquitectura de software multicapas aplicando una metodología multicriterio
C. Anexo: Articulo Inge@UAN ..................................................................................108
D. Anexo: Etiquetas para clasificación de documentos del estado del arte .........115
Bibliografía ...................................................................................................................118
Contenido IX
Lista de figuras
Pág.
Figura 1. Arquitectura multicapa de una aplicación basada en tecnologías Web .............. 2
Figura 2. El proceso MCDA .............................................................................................. 4
Figura 3. El proceso de revisión sistemática de la literatura ............................................. 5
Figura 4. Cantidad de publicaciones de selección de software por año ............................ 9
Figura 5. Cantidad de publicaciones en selección de software por metodología ............ 11
Figura 6. Distribución de las áreas de aplicación de la metodología AHP....................... 13
Figura 7. Etapas de la metodología AHP ........................................................................ 13
Figura 8. Jerarquía para la selección de la tecnología de banda ancha más adecuada
para la Universidad Nacional de Colombia Sede Bogotá................................................ 14
Figura 9. Matriz de comparación por pares .................................................................... 15
Figura 10. Matriz de comparación por pares reducida .................................................... 16
Figura 11. Etapas de la metodología TOPSIS ................................................................ 20
Figura 12. Representación de un problema de decisión, como una red de elementos ... 24
Figura 13. Súper matriz de una red de decisión ............................................................. 25
Figura 14. DAR............................................................................................................... 33
Figura 15. Arquitectura procesos de negocio EEC ......................................................... 36
Figura 16. Configuración en JMeter de la cantidad de peticiones para obtener las
calificaciones de los criterios técnicos. ........................................................................... 48
Figura 17. Configuración en JMeter de las peticiones SOAP para obtener las
calificaciones de los criterios técnicos ............................................................................ 49
Figura 18. Estructura jerárquica de la selección del servidor de aplicaciones más
adecuado para EEC ....................................................................................................... 56
Figura 19. Prioridades consolidadas de los criterios globales ......................................... 57
Figura 20. Prioridades asignadas por los expertos a los criterios globales ..................... 58
Figura 21. Prioridades locales consolidadas de los criterios técnicos. ............................ 59
Figura 22. Prioridades locales asignadas por los expertos a los criterios técnicos ......... 59
Figura 23. Prioridades locales consolidadas de los criterios funcionales ........................ 60
Figura 24. Prioridades locales asignadas por los expertos a los criterios funcionales .... 60
Figura 25. Prioridad global de los criterios de selección ................................................. 61
Figura 26. Valoración de las alternativas utilizando la matriz normalizada por el método
del máximo ..................................................................................................................... 65
Figura 27. Valoración de las alternativas utilizando la matriz normalizada por el método
de la sumatoria ............................................................................................................... 65
X Selección de servidores de aplicaciones como parte del diseño de una
Lista de tablas
Pág.
Tabla 1. Etiquetas para clasificación de documentos ........................................................ 8
Tabla 2. Publicaciones en selección de software por país ................................................ 9
Tabla 3. Metodologías para selección de software y publicaciones................................. 11
Tabla 4. Escala de calificación por pares ........................................................................ 15
Tabla 5. Valores aleatorios de CI .................................................................................... 17
Tabla 6. Escala difusa de comparación por pares ........................................................... 23
Tabla 7. Grupos de criterios por publicaciones................................................................ 27
Tabla 8. Tipos de software sometidos a selección .......................................................... 30
Tabla 9. Ventajas de una arquitectura multicapas ........................................................... 38
Tabla 10. PROACT Objetivos. ........................................................................................ 40
Tabla 11. PROACT Alternativas ...................................................................................... 41
Tabla 12. PROACT Escala para análisis de consecuencias............................................ 42
Tabla 13. PROACT Tabla de Consecuencias ................................................................. 42
Tabla 14. PROACT Tabla de Transacciones .................................................................. 43
Tabla 15. Criterios Técnicos............................................................................................ 45
Tabla 16. Criterios Funcionales ....................................................................................... 46
Tabla 17. Características de los datos utilizados en las pruebas para obtener los valores
de los criterios técnicos. .................................................................................................. 47
Tabla 18. Características técnicas máquinas virtuales utilizadas en la ejecución de las
pruebas para obtener las calificaciones de los criterios técnicos ..................................... 49
Tabla 19. Tiempo promedio de almacenamiento de los servidores de aplicaciones ........ 50
Tabla 20. Consumo Promedio de Memoria de los servidores de aplicaciones ................ 51
Tabla 21. Consumo promedio de CPU de los servidores de aplicaciones ....................... 51
Tabla 22. Valoración soporte para herramientas de desarrollo de los servidores de
aplicaciones .................................................................................................................... 52
Tabla 23. Valoración cumplimiento de estándares para herramientas de desarrollo de los
servidores de aplicaciones .............................................................................................. 52
Tabla 24. Valoración facilidad de administración de los servidores de aplicaciones ........ 53
Tabla 25. Valoración documentación disponible de los servidores de aplicaciones ........ 54
Tabla 26. Prioridad global de los criterios de selección ................................................... 61
Tabla 27. Matriz de decisión. .......................................................................................... 62
Tabla 28. Matriz de decisión con todos los criterios con tendencia a maximizar ............. 63
Tabla 29. Métodos de Normalización .............................................................................. 63
Tabla 30. Matriz de decisión normalizada por el método del máximo .............................. 64
Tabla 31. Matriz de decisión normalizada por el método de la sumatoria........................ 64
Tabla 32. Listado de etiquetas utilizadas para clasificar los documentos del estado del
arte ............................................................................................................................... 116
Contenido XI
Lista de Símbolos y abreviaturas

Abreviaturas
AHP Analytic Hierarchy Process

ANN Artificial Neural Network
ANP Analytic Neural Process
ASW Arquitecto de Software
C&C Component and Connector
CBR Case-Based Reasoning
CI Consistency Index
CMMI Capability Maturity Model Integration
CoI Coquet Integral
COTS Commercial Off-The-Shelf
CPU Central Processing Unit
CR Consistency Ratio
CRM Customer Relationship Management
DAR Decision Analysis and Resolution
DSS Decision Support System
EEC Entidad Estatal Colombiana
EMR Electronic Health Record
ERP Enterprise Resource Planning
ESB Enterprise Service Bus
FAHP Fuzzy Analytic Hierarchy Process
FLR Fuzzy Linear Regresion
FSW Fábrica de Software
GUI Graphical User Interface
HKBS Hybrid Knowledge Based System
IDS Ingeniero de Desarrollo
IDSA Ingeniero de Desarrollo Autor
IEEE Institute of Electrical and Electronics Engineers
IWPC IEEE International Workshop on Program Comprehension
JEE Java Enterprise Edition
JGC Java Garbage Collector
JVM Java Virtual Machine
Measuring Attractiveness by a Categorical Based Evaluation
MACBETH Technique
MAS Multi-media Authorizing System
MCDA Multiple-criteria decision analysis
MCDM Multiple Criteria Decision Making
XII Selección de servidores de aplicaciones como parte del diseño de una
MRP Manufacturing Resource Planning

Preference Ranking Organization Method for Enrichment
PROMETHEE Evaluations
PROACT PRoblem Objectives Alternatives Consequences
QFD Quality Function Deployment
RBR Rule-Based Reasoning
SaaS Software-as-a-Service
SEI Software Engineering Institute
SOAP Simple Object Access Protocol
STACE Social-Technical Approach to COTS Evaluation
TOGAF The Open Group Architecture Framework
TOPSIS Technique for Order Performance by Similarity to Ideal Solution
WA Weighted Average
WMS Warehouse Management System
ZOGP Zero-One Goal PROGramming
Introducción 1
Introducción
Aunque como afirman Baragry, J., & Reed, K. (1998), Clements, P. et al. (2010), Garlan,
D., & Shaw, M. (1994) y Gorton, I (2011), no existe una definición plenamente aceptada
de arquitectura de software las existentes se pueden clasificar en dos tipos: estructurales
y de toma de un conjunto de decisiones.
El primer grupo de definiciones considera a la arquitectura de software como una

abstracción de nivel superior de los componentes de un sistema y sus interacciones, los
cuales definen la estructura y comportamiento de un sistema. En este tipo definiciones se
encuentran las agrupadas por SEI (2015) y las propuestas en estándares como IEEE
(2000).
De acuerdo con SEI (2015) el diseño de la arquitectura de software debe ser la base
primordial para la construcción de un sistema, por lo que su definición debe ser clara, lo
cual se logra mediante la definición de vistas (Clements, P. et al. (2010), IEEE (2000) y
SEI (2015)). Una vista es la definición de un conjunto de elementos de un sistema y sus
interacciones (Clements, P. et al. (2010)).
Kruchten, P. (1995) define cuatro tipos de vista para un sistema: lógica, de procesos,
física y una vista de despliegue. La vista lógica determina la funcionalidad del sistema. La
vista de procesos es la vista dinámica del sistema, representa los procesos que lo
componen y sus interacciones. La vista física muestra la relación entre los componentes
y su relación con el hardware en el que son desplegados. Los componentes que forman
parte del sistema y las dependencias entre sí, son definidos mediante la vista de
despliegue.
Como menciona Clements, P. et al. (2010) una vista es el resultado del seguimiento de
conceptos de diseños bien definidos o estilos arquitectónicos, los cuales se dividen en
tres grandes grupos: estilos modulares, de tipo C&C y de distribución. Los estilos
modulares definen las unidades de implementación del sistema. Los estilos C&C
documentan las unidades de ejecución. Los estilos de distribución definen las relaciones
2 Selección de servidores de aplicaciones como parte del diseño de una
entre los componentes software y no software, respecto a su ambiente de desarrollo y de

ejecución.
Dentro del tipo de estilos C&C se encuentran los estilos por capas. Los cuales definen
agrupaciones lógicas de componentes de acuerdo con sus responsabilidades o
ambiente de ejecución (Clements, P. et al. (2010)). Existen varios tipos de sistemas que
implementan este tipo de estilo dentro de los que se encuentran los sistemas de
protocolos de comunicación, sistemas operativos, bases de datos (Garlan,D., & Shaw, M.
(1994)) y aplicaciones basadas en tecnologías web (Clements, P. et al. (2010)).
En el caso de las aplicaciones basadas en tecnologías web, se sugiere la

implementación de un modelo multicapas (Clements, P. et al. (2010)), definido por las
capas de acceso a datos, lógica de negocio y la capa cliente. En la capa de acceso a
datos, se agrupan los componentes que procesan las peticiones de modificación de
datos de soporte del sistema, uno de los componentes de esta capa son los servidores
de bases de datos. En la capa de lógica de negocios se implementan los métodos que
modifican los datos del negocio, esta capa esta soportada por un servidor de
aplicaciones. Finalmente en la capa de cliente, se implementan aplicaciones que
permiten al usuario final interactuar con los procesos de negocio implementados en la
capa de lógica de negocios.
Figura 1. Arquitectura multicapa de una aplicación basada en tecnologías Web. Adapto de Clements,
P. et al. (2010)
Introducción 3
El segundo grupo de definiciones de arquitectura de software la consideran como el

resultado de la toma de un conjunto de decisiones durante el ciclo de vida del proyecto
(Bosc (2004), Kruchten, P. (2004) y Tyree & Ackerman (2005)). Dentro del tipo de
decisiones que se deben tomar se encuentran las decisiones de existencia, de propiedad
y ejecutivas (Kruchten, P. (2004)). Las decisiones de existencia determinan los
componentes que deben o no formar parte de un sistema. A su vez se subdividen en
decisiones estructurales (creación de componentes o capas de componentes) o de
comportamiento (definición de la forma en la que los componentes interactúan entre sí).
Las restricciones y guías del diseño, se definen mediante las decisiones de propiedad.
Las decisiones ejecutivas están determinadas por el contexto de la solución a
implementar, lo que afecta la metodología de desarrollo, el entrenamiento de las
personas involucradas en el proceso y el tipo de herramientas o tecnologías a usar.
En el caso de la selección de software o herramientas que dan soporte a una solución, se

requiere de una combinación simultanea de factores mutuamente excluyentes (Stamelos,
I., & Tsoukias, A. (2003)). Este tipo de procesos se torna complejo debido a la gran
cantidad de productos de software disponible, los continuos avances y mejoras en las
tecnologías de la información, la existencia de incompatibilidades entre varios tipos de
software y hardware, la dificultad en la evaluación de las diferencias funcionales de los
sistemas y por la falta de experiencia y conocimiento técnico de los involucrados en los
procesos de selección (Lin, H.-Y., Hsu, P.-Y., & Sheen, G.-J. (2007)).
Los factores que hacen que un proceso de decisión en el contexto de la definición de la

arquitectura de un sistema sea complejo, junto a un gran número de personas
involucradas y la definición de criterios que son mutuamente incompatibles, hacen que
este tipo de procesos sean un problema del tipo MCDM, los cuales pueden ser
abordados mediante la aplicación de las técnicas propuestas por el MCDA, el cual, de
acuerdo con Belton, V. & Stewart, T. (2002) tiene como objetivo principal “ayudar a los
decisores para comprender el problema, sus juicios y el de las demás personas
involucradas, a organizar y recolectar la información necesaria, para guiarlos en la
identificación de un curso de acción”.
Según Belton, V. & Stewart, T. (2002) el MCDA puede considerarse como un marco de
referencia de apoyo para la solución de problemas complejos, dicho marco está
conformado por las etapas que se muestran en la Figura 2.
Figura 2. El proceso MCDA. Adaptado de Belton, V., & Stewart, T. (2002)
De acuerdo con Belton, V. & Stewart, T. (2002) durante la etapa de estructuración del
problema, los involucrados en el proceso de decisión definen la complejidad del problema
y establecen las guías básicas para su solución. La etapa de definición tiene como
objetivo extraer la información necesaria del problema que permitirá establecer los
parámetros de su evaluación, en esta etapa se establece cuáles son los posibles cursos
de acción y los criterios bajo los que se rige su evaluación. En la etapa de resultados se
analizan los resultados de la evaluación de las alternativas y se organiza la información,
de manera que se pueda establecer el curso de acción que solucionará de la forma más
adecuada el problema identificado.
En este trabajo se presenta la aplicación de una metodología multicriterio, en el proceso

de selección del servidor de aplicaciones más adecuado para dar soporte a los procesos
de negocio de una entidad estatal la cual se encuentra en proceso de actualización
tecnológica. La estructura del documento se encuentra orientada al desarrollo de los
cuatro objetivos específicos definidos en la propuesta del trabajo, por lo tanto las
secciones del documento son: la revisión de estado del arte, la definición del caso de
estudio, la definición de los criterios de selección, la definición de las fuentes de los
valores de los criterios definidos y la solución del problema de decisión.
Revisión del estado del arte 5
1. Revisión del estado del arte

En este capítulo se presenta la revisión del estado del arte siguiendo una metodología de
revisión sistemática de la literatura de los procesos de selección de software, definiendo
así la base académica para la solución del problema de selección del servidor de
aplicaciones más adecuado para la entidad estatal en proceso de actualización
tecnológica.
Como resultado se muestran las metodologías y criterios más usados dentro de los
procesos de selección de software.
1.1 Metodología
Para el desarrollo del estado del arte se siguió una metodología de revisión sistemática
de la literatura propuesta por Kitchenham, B. (2004), la cual tiene como objetivo principal
“definir un método que permita la evaluación y la interpretación de toda la investigación
relevante a una pregunta de investigación específica, un área de investigación o un
fenómeno de interés”. La metodología propuesta por Kitchenham, B. (2004), se resume
en la Figura 3.
Planificación Ejecución Presentación de la

revisión
•Identificación de •Identificación de
la necesidad de la investigación
la revisión •Selección de
•Desarrollo de un estudios
protocolo de prinicipales
revisión •Aseguramiento
de la calidad
•Extracción y
análisis de datos
Figura 3. El proceso de revisión sistemática de la literatura. Adaptado de Kitchenham, B. (2004)

Para el desarrollo de este trabajo se siguieron las etapas del proceso de ejecución:
identificación de la investigación, selección de estudios, extracción y análisis de datos.
Para la definición de la investigación se establecieron las preguntas de investigación y el
proceso sistemático de búsqueda de la información.
1.1.1 Preguntas de investigación

El objetivo principal de la revisión del estado del arte que se presenta en este documento,
es determinar las metodologías más usadas en procesos de selección de software, así
como los criterios más utilizados para evaluar las alternativas, por lo tanto las preguntas
definidas para la ejecución de la revisión son las siguientes:
 PI1. ¿Es la selección de software un área de investigación continuamente activa?

 PI2. ¿Cuáles son las metodologías de selección de software más utilizadas?
 PI3. ¿Cuáles son los criterios de selección de software más utilizados?
 PI4. ¿Cuáles son los tipos de software evaluados en un proceso de selección?
A cada una de las preguntas se ha asignado un código de forma tal que puedan ser
referenciadas dentro del documento. El código definido corresponde a las siglas PI (por
Pregunta de Investigación) junto a un número entero secuencial.
1.1.2 Definición del proceso de búsqueda
El proceso de búsqueda tuvo como primera etapa la definición de las ecuaciones de

búsqueda las cuales están orientadas a dar respuesta a las preguntas de investigación
definidas para el proceso, las ecuaciones de búsqueda utilizadas fueron:
 Software selection
 Software evaluation
 Software selection criteria
 Selección de software
 Evaluación de software
Posteriormente se definieron las fuentes de búsqueda en las cuales se ejecutó de forma

manual las anteriores ecuaciones. Las fuentes definidas son las siguientes:
 IEEE Explorer (IEEE)

 ScienceDirect (SD)
 Catalogo de publicaciones de la Universidad Nacional de Colombia (UNAL)
 Catalogo de publicaciones de la Universidad de los Andes (UNIANDES)
 Catalogo de publicaciones de la Universidad Javeriana (UJAVERIANA)
Las ecuaciones de búsqueda “Selección de software” y “Evaluación de software”, solo

fueron aplicadas en las fuentes de datos UNAL, UNIANDES y UJAVERIANA, las
ecuaciones restantes se ejecutaron sobre todas las fuentes.
1.1.3 Criterios de Inclusión
Los artículos que se sometieron a estudio fueron incluidos, debido a que definían una
metodología para la selección de software o se seguía una metodología previamente
establecida.
En el caso de los criterios, los artículos seleccionados se incluyeron debido a que

definían un conjunto de criterios genéricos o un conjunto de criterios relacionados
directamente con el tipo de software evaluado.
1.1.4 Recolección de datos y análisis de datos
Como resultado de la ejecución de las ecuaciones de búsqueda definidas para el estudio,

se encontraron 54 documentos los cuales fueron importados en la herramienta
bibliográfica Mendeley, la cual permite la definición de etiquetas para poder filtrar de
forma sencilla una colección de referencias.
Para la clasificación de los documentos analizados en la revisión, se definieron etiquetas

que los permiten clasificar por país, criterios de selección, metodologías seguidas o
propuestas, tipo de software sometido a evaluación y el año de las publicaciones. Las
etiquetas utilizadas se relacionan en la Tabla 1 de este documento. El listado completo
se relaciona en el Anexo D de este documento.
Etiqueta Descripción
Etiqueta en la que se agrupa el país de la institución del autor principal
country-[country]
del articulo. Por ejemplo: country_colombia.
Etiqueta para agrupar los documentos en los que se definen o aplican
criteria_selection
criterios de selección.
criteria_selection- Etiqueta para definir un grupo de criterios de selección especifico. Por
[criteria_selection] ejemplo: criteria_selection-functionality.
Etiqueta para clasificar documentos que aplican una metodología de
methodology
selección de software.
methodology- Etiqueta para clasificar documentos que aplican una metodología
[methodology] especifica. Por ejemplo: methodology-ahp.
software_type- Etiqueta para determinar el tipo de software que se somete a evaluación.
[software_type] Por ejemplo: software_type-erp.
Permite definir el año de publicación del documento analizado. Por
year-[year]
ejemplo: year-2015.
Tabla 1. Etiquetas para clasificación de documentos. Elaboración Propia.
En esta sección del documento se da respuesta a las preguntas de investigación

definidas, analizando los datos obtenidos al clasificar los documentos aplicando las
etiquetas definidas.
PI1. ¿Es la selección de software un área de investigación continuamente activa?
Para dar respuesta a esta pregunta se analizó la cantidad de documentos publicados por
año y por país, los cuales se encuentran resumidos en la Figura 4 y en la Tabla 2 de
este documento.
7
6
5
4
3
2
1
0
1996
2010
1988
1989
1991
1995
1999
2000
2002
2003
2004
2005
2006
2007
2008
2009
2011
2012
2013
2014
2015
Figura 4. Cantidad de publicaciones de selección de software por año. Elaboración propia.
País Publicaciones
Alemania Ossadnik, W., & Lange, O. (1999).
Alghamdi, A. S. et al (2010).
Arabia
Siddiqui, Z. et al (2011).
Australia Maxville, V. et al (2009).
Chau, P. Y. K. (1995).
Huang, X. et al (2013).
China Jianhua, H. J. H. et al (2010).
Lai, V. S. et al (2002).
Ngai, E. W. T. et al (2005).
Chipre Andreou, A. S., & Tziakouris, M. (2007).
Cortés, J. A. Z. et al (2012).
Colombia
Jaime, G. (2013).
Carvallo, J. P., Franch, X., Quer, C., & Catalunya, U. P. De. (2007).
Illa, X. B., Franch, X., & Pastor, J. A. (2000).
España Morera, D. (2002).
P, V. F., & Chalmeta, R. (2005).
Xavier Franch and Juan Pablo Carvallo. (2003).
Cochran, J. K., & Chen, H.-N. (2005).
Collier, K. et al (1999).
Gorton, I. et al (2003).
Estados Unidos Le Blanc, L. A., & Tawfik Jelassi, M. (1989).
Li, Y., & Thomas, M. A. (2014).
Nelson, B. L. et al (1991).
Verville, J., & Halingten, A. (2003).
Grecia Stamelos, I. et al (2000).
Hong-Kong Chau, P. Y. K. (1995).
Bhargava, N. et al (2013).
Godse, M., & Mulik, S. (2009).
Jadhav, A. S., & Sonar, R. M. (2011).
India
Jadhav, A., & Sonar, R. (2008).
Misra, S. K., & Ray, A. (2013).
Tabla 2. Publicaciones en selección de software por país. Elaboración propia
País Publicaciones
Haghpanah, N. et al (2007).
Irán
L. Etaati, S. Sadi-Nezhad, A, M. (2011).
Israel Shtub, A. et al (1988).
Colombo, E., & Francalanci, C. (2004).
Italia
Minetola, P. et al (2015).
Malasia Zaidan, a. a. et al (2014).
Noruega Ayala, C. et al (2011).
Omán Sarrab, M., & Rehman, O. M. H. (2014).
Portugal Neto, A. A., & Vieira, M. (2011).
Hlupic, V., & Paul, R. J. (1996).
Reino Unido Nikoukaran, J. et al & Paul, R. J. (1999).
Nikoukaran, J., & Paul, R. J. (1999).
Lee, H. S., & Wang, M. H. (2007).
Lin, H.-Y. et al (2007).
Taiwán
Wei, C. C. et al (2005).
Wei, C.-C., & Wang, M.-J. J. (2004).
Cebeci, U. (2009).
Gürbüz, T. et al (2012).
Turquía Karsak, E. E., & Özogul, C. O. (2009).
Kilic, H. S. et al (2014).
Yazgan, H. R. et al (2009).
Zambia Kunda, D. (2003).
Tabla 2. Publicaciones en selección de software por país (continuación). Elaboración propia.
Los datos de publicaciones por año y país muestran que a partir del año 1988 y en una
forma continua hasta el 2015, existen publicaciones a nivel internacional (provenientes de
23 países diferentes), en las que se aplican metodologías que permitan seleccionar la
alternativa de software más adecuada de acuerdo al contexto en el que se desarrolla el
proceso de selección. Esto indica que los procesos de selección de software definen un
área de investigación activa, debido principalmente a las características propias de cada
uno de los procesos de selección, así como a las características funcionales de las
alternativas evaluadas, ya que estas se encuentran en una mejora constante.
PI2. ¿Cuáles son las metodologías de selección de software más utilizadas?
De acuerdo con los resultados obtenidos de la clasificación de los documentos

mediante la etiqueta methodology-[methodology], se determinó que existen varios grupos
de metodologías para selección de software, las cuales se relacionan en la Figura 5 y la
Tabla 3 de este documento.
10
8
6
4
2
0
Figura 5. Cantidad de publicaciones en selección de software por metodología. Elaboración propia.
Metodología Documentos en la que se publicó

Alghamdi, A. S., Ahmad, I., & Nasir, M. (2010)
Le Blanc, L. A., & Tawfik Jelassi, M. (1989).
AHP Ngai, E. W. T., & Chan, E. W. C. (2005).
Ossadnik, W., & Lange, O. (1999).
Shtub, A., Spiegler, I., & Kapeliuk, A. (1988).
Wei, C. C. et al (2005).
Gürbüz, T. et al (2012)
Jadhav, A., & Sonar, R. (2009)
Karsak, E. E., & Özogul, C. O. (2009).
Kilic, H. S., Zaim, S., & Delen, D. (2014).
Hibrida Kilic, H. S., Zaim, S., & Delen, D. (2015)
Kunda, D. (2003).
Misra, S. K., & Ray, A. (2013).
Morera, D. (2002).
Zaidan, a. a. et al (2014)
Hlupic, V., & Paul, R. J. (1996).
Propuestas
Nelson, B. L., et al (1991)
Neto, A. A., & Vieira, M. (2011).
Cebeci, U. (2009).
Cortés, J. A. Z., et al. (2012).
Lee, H. S., & Wang, M. H. (2007).
FAHP
Lin, H.-Y. et al (2007).
Minetola, P., et al (2015).
Wei, C.-C., & Wang, M.-J. J. (2004).
Tabla 3. Metodologías para selección de software y publicaciones. Elaboración propia.
Metodología Documentos en la que se publicó

HKBS
Li, Y., & Thomas, M. A. (2014).
Stamelos, I. et al (2000).
Haghpanah, N. (2007).
Algoritmo
Huang, X. N. (2013).
Jianhua, H. J. H. et al (2010)
ANN
Jaime, G. (2013).
ANP
L. Etaati, S. Sadi-Nezhad, A, M. (2011).
Fuzzy Cochran, J. K., & Chen, H.-N. (2005).
WA
Maxville, V. et al (2009).
Tabla 3. Metodologías para selección de software y publicaciones (continuación). Elaboración
propia.
Como se puede observar en los datos de publicaciones por metodología, los 3 tipos de
metodologías más utilizados son AHP, metodologías híbridas y FAHP. Al examinar las
metodologías que son integradas en las metodologías híbridas, la metodología AHP es la
más utilizada en dicho tipo de metodologías, esto indica que AHP es la metodología más
utilizada en los procesos de selección de software.
Metodología AHP
La metodología AHP fue propuesta por Saaty T. L. entre los años 1971 y 1975. Está
metodología tiene como objetivo principal, la derivación de calificaciones a partir de
comparaciones por pares desde aspectos discretos y continuos, considerándolos de
forma simultánea con el fin de llegar a una conclusión especifica (Saaty, R. W. (1987)).
AHP ha sido aplicado exitosamente en procesos para seleccionar la alternativa más

adecuada, evaluar un conjunto de alternativas, ejecutar análisis costo-beneficio,
establecer prioridades, desarrollo y planificación, distribución de recursos, toma de
decisiones, pronostico, medicina y QFD. La distribución de las aplicaciones de la
metodología se presenta en la Figura 6 de este documento (Vaidya, O. S., & Kumar, S.
(2006)).
QFD Medicina Pronóstico

5% 3% 3%
Costo-Beneficio
5%
Distribución de Selección
Recoursos 21%
7%
Planificación y
Desarrollo Evaluación
12% 17%
Priorización Toma de
13% Decisiones
14%
Figura 6. Distribución de las áreas de aplicación de la metodología AHP. Adaptado de Vaidya, O. S.,
& Kumar, S. (2006).
La metodología AHP define 4 etapas básicas las cuales se resumen en la Figura 7 de

este documento.
Definición del problema mediante

una representación jerárquica
Construcción de la matriz de
comparación por pares
Ejecución de Test de Consistencia
Cálculo de la Prioridad General
Figura 7. Etapas de la metodología AHP. Adaptado de Ho, W. (2008).

Definición del problema mediante una jerarquía
Para construir la jerarquía que representa de forma jerárquica el problema de selección,

se debe considerar que los elementos que pertenecen al mismo nivel de la jerarquía
deben ser homogéneos, esto es, que puedan ser comparados mediante atributos
comunes. Los elementos pertenecientes al mismo nivel de la jerarquía, deben
representar restricciones o refinamientos a los elementos de un nivel superior, de esta
forma se garantiza que la jerarquía que se construye sea consistente. (Saaty, R. W.
(1987))
En la Figura 8 de este documento se presenta una jerarquía en la que se modela un

problema de decisión, que tiene como objetivo seleccionar la tecnología de banda ancha
más adecuada para la Universidad Nacional de Colombia Sede Bogotá (Cortés Aldana,
F. A. et al (2007)).
Seleccionar la Tecnología
de Banda Ancha Más
Adecuada para la UNAL
Sede Bogotá
Criterios Tecnologicos Criterios Financieros Criterios de Calidad
Ancho de Banda Costos de Instalación Seguridad
Número de Equipos a Costos de Suscripción

Mantenimiento
Conectar Mensual
Disponibilidad equipos
proveedor
Tiempo de Instalación
Figura 8. Jerarquía para la selección de la tecnología de banda ancha más adecuada para la
Universidad Nacional de Colombia Sede Bogotá. Adaptado de Cortés Aldana, F. A. et al (2007).
Definición de la matriz de comparación por pares
El propósito de la construcción de la matriz por pares es el de definir las preferencias de

los decisores entre elementos de un mismo nivel de alternativas, generalmente se suele
utilizar la escala propuesta por Saaty, T. L. (1977), la cual se presenta en la Tabla 5 de
este documento.
Nivel de Importancia Definición

1 Los elementos comparados tienen la misma importancia.
Uno de los elementos tiene una importancia leve sobre el otro
3
elemento respecto al que se compara.
Un elemento tiene una importancia alta sobre el otro elemento con el
5
que se compara.
Un elemento tiene una importancia demostrada sobre el otro
7
elemento.
Un elemento es evidentemente más importante que el elemento con el
9
que se compara.
2, 4, 6, 8 Valores intermedios.
Si un elemento tiene alguna de las anteriores calificaciones, al
elemento con el que se compara se le asigna su valor reciproco, esto
Valores recíprocos
es , siendo , el valor de importancia asignado al elemento que se
favorece con la calificación.
Tabla 4. Escala de calificación por pares. Saaty, T. L. (1977)
Una matriz de comparación por pares de elementos, representados como ,…, y

sus pesos representados por ,…, , tiene la forma (Saaty, T. L. (1977)):
Figura 9. Matriz de comparación por pares. Saaty, T. L. (1977)

Los valores de la matriz son valores positivos, que cumplen la propiedad de reciprocidad
, debido a dicha propiedad la matriz puede ser reducida a la siguiente forma:
Figura 10. Matriz de comparación por pares reducida. Saaty, T. L. (1977)
La reducción de la matriz de comparación por pares disminuye la cantidad de
comparaciones a ejecutar al siguiente número donde , representa la cantidad de
elementos que se están comparando.
Definida la matriz de comparación por pares se pueden aplicar el método de cálculo del
vector propio y el método logarítmico de los mínimos cuadrados (Coulter, E. D. et al
(2006)), para obtener la prioridad de los elementos que se están comparando.
Ejecución del Test de Consistencia
De acuerdo con Saaty, T.L. (1977) la matriz de comparación por pares, es consistente si
cumple con la consistencia cardinal y la consistencia ordinal. La consistencia cardinal
verifica que si es mayor que , y es mayor que , entonces debe ser mayor que .
La consistencia ordinal define que si es 2 veces más importante que , y es 3 veces
más importante que , entonces debe ser 6 veces más importante que , por lo tanto si
la matriz de comparación por pares es consistente entonces debe cumplir la propiedad
.
Para determinar la inconsistencia de la matriz de comparación por pares Saaty, T.L.
(1977) definió el CI de la siguiente forma: donde , es el valor propio

máximo de la matriz de comparación por pares y es el número de elementos que son

comparados. Si la matriz es completamente consistente entonces el valor de será
cercano al valor , produciendo un valor cercano a cero.
La consistencia de la matriz de comparación por pares también se puede determinar

mediante el cálculo del CR mediante la formula , donde corresponde con un
CI de una matriz aleatoria del mismo tamaño de la matriz del problema que se está
modelando. En la Tabla 6 de este documento se presenta el listado de valores
propuestos por Saaty, T.L. (1977) para matrices aleatorias de diferentes tamaños.
1 2 3 4 5 6 7 8 9 10
0 0 0.52 0.89 1.11 1.25 1.35 1.40 1.45 1.49
Tabla 5. Valores aleatorios de CI. Saaty, T.L. (1977).
Saaty, T.L. (1977) propuso que un valor cercano a 0.1, indica que la matriz es
consistente, pero que dicho valor puede variar de acuerdo a los requerimientos del
problema que se está solucionando.
Calculo de la prioridad general
El último paso en la metodología es determinar la prioridad general de las alternativas,

mediante la combinación de los valores de cada una de las prioridades relativas con los
valores de las comparaciones por pares, la prioridad final es obtenida mediante la
sumatoria de dichos valores. (Coulter, E. D. et al (2006))
Metodologías Hibridas
En este conjunto de metodologías se clasifican aquellas en las que se sigue más de una
metodología para determinar la alternativa de software más adecuada. A continuación se
presentan las combinaciones que se encontraron como resultado de la revisión del
estado del arte.
AHP + DESMET
La metodología DESMET, es una metodología desarrollada en la década de los 90 en el

Reino Unido, con el objetivo principal de evaluar métodos asociados a la ingeniería de
software y herramientas dentro de una organización (Morera, D. (2002)).
La combinación propuesta por Morera, D. (2002), define el proceso de selección de una

herramienta de software, como un proceso de dos etapas: evaluación y toma de
decisiones.
La etapa de evaluación es ejecutada, mediante el seguimiento de 6 sub etapas básicas

de la metodología DESMET: definición de los roles y sus responsabilidades, definición de
las restricciones de tiempo y el esfuerzo necesario para la ejecución de proceso, la
definición del alcance del proceso y la definición de las alternativas a evaluar, la
definición de supuestos y restricciones, la selección de un método de evaluación, la
evaluación y presentación de resultados.
La toma de decisiones está soportada por la metodología AHP y compuesta por las sub
etapas de definición de los criterios de selección, la evaluación final de los candidatos
definidos y la selección por común acuerdo de la alternativa más adecuada.
AHP + STACE
Como lo menciona Kunda, D. (2003), STACE tiene como objetivo principal la vinculación
de aspectos sociales y técnicos durante el proceso de selección de la alternativa más
adecuada, mediante la ejecución de 4 procesos que se encuentran interrelacionados:
levantamiento de requerimientos, definición de los criterios sociales y técnicos,
identificación de las alternativas, para finalmente someterlas a evaluación.
La primera etapa de la metodología STACE, tiene como objetivo la definición de los

requerimientos de los clientes y del sistema, los cuales son definidos de forma conjunta
con los stakeholders del proyecto a partir de documentación técnica y estudios de

mercadeo.
AHP es utilizado en la segunda etapa de la metodología, con el fin definir de forma

jerárquica, los criterios técnicos y sociales bajo los que se someterán a evaluación las
alternativas.
La etapa de definición de las alternativas tiene como objetivo, definir las herramientas
que se someterán a evaluación, las cuales deberán cumplir con los requerimientos
identificados en la primera etapa de la metodología.
Finalmente la etapa de evaluación de las alternativas, determina la alternativa más

adecuada a partir de la calidad del software en términos de sus funcionalidades.
AHP + TOPSIS
De acuerdo con Yoon, K. P., & Hwang, C.-L. (1981), la alternativa más adecuada, debe
estar lo más lejano posible de una alternativa sub optima (alternativa que tiene los
puntajes más bajos posibles en cada criterio definido) y lo más cercano posible a una
alternativa optima (alternativa que tiene los puntajes más altos posibles en cada criterio
definido), por lo que la evaluación de las alternativa mediante TOPSIS, determina la
calificación de las alternativas de acuerdo a la distancia a dichas alternativas artificiales.
La metodología TOPSIS ha sido aplicada exitosamente en problemas como: la selección
de sistemas de transportes, la ubicación de fábricas, selección de robots y la
administración de residuos sólidos (Shih, H.-S. et al (2007)). Las etapas de la
metodología TOPSIS, se presentan en la Figura 11, de este documento.
decisión normalizada
pesos normalizada
Calculo de la solución
suboptima y la solución
optima
Calculo de la separación de la
distancia
Calculo de la distancia a la
solución óptima
Calificación de las
alternativas de acuerdo a la
distancia de la solución ótima
Figura 11. Etapas de la metodología TOPSIS. Zaidan, a. a. et al (2014).
Como lo propone Zaidan, a. a. et al (2014) y Misra, S. K., & Ray, A. (2013), la

metodología AHP puede ser integrada con la metodología TOPSIS, para determinar la
matriz normalizada de pesos.
TOPSIS tiene las siguientes ventajas Shih, H.-S. et al (2007): define una lógica cercana
al razonamiento humano, combina en un valor escalar la distancia a la alternativa sub
optima y la alternativa optima, puede ser automatizado de manera sencilla y permite
representar de forma gráfica las calificaciones asignadas a las alternativas evaluadas.
ANP + CoI + MACBETH
En la metodología propuesta por Gürbüz, T. et al (2012), la metodología ANP

(generalización de la metodología AHP), es utilizada para determinar el objetivo del
proceso de decisión, los criterios y sub criterios, determinar la interdependencia entre
criterios y para definir la matriz de preferencias de los criterios. La metodología
MACBETH y la integral difusa CoI, son utilizadas para determinar el nivel de

interdependencia de los criterios definidos mediante ANP.
ANP + PROMETHEE
PROMETHEE fue propuesto inicialmente por Brans (1982), como un método de

calificación, con el fin de determinar la mejor alternativa de un conjunto bien definido,
analizando los pros y contras de las alternativas consideradas. La metodología tiene tres
etapas principales: modelamiento del problema mediante una matriz, en la cual se
relacionan las alternativas con las calificaciones asignadas por decisor respecto a un
conjunto de criterios, para posteriormente comparar cada una de las alternativas respecto
a los criterios definidos y finalmente obtener la calificación general de cada una de las
alternativas sumando la multiplicación de la importancia de cada criterio con la
calificación asignada a la alternativa.(Brans, J.-P., & Mareschal, B. (2005))
En la propuesta de Kilic, H. S. et al (2015), los métodos ANP y PROMETHEE, son

combinados de tal forma, que la matriz de comparación por pares obtenidas del mediante
ANP, es la entrada para la ejecución del método PROMETHEE, mediante el cual se
obtiene un ranking de las alternativas evaluadas.
RBR + CBR
Jadhav, A., & Sonar, R. (2008), definen un sistema en el que el usuario es guiado en todo
el proceso decisión. En la primera etapa del proceso RBR, es utilizado para guiar el
usuario durante el proceso de definición de criterios y requerimientos, que la solución
más adecuada debe cumplir, estos datos se almacenan en forma de reglas del tipo IF
THEN ELSE.
CBR define el esquema bajo el cual se almacenan los paquetes de software que son
posibles alternativas a presentar al usuario. Los paquetes se almacenan como un
conjunto de criterios asociados a la calidad, el proveedor del software y con las
funcionalidades del software.
QFD + FLR + ZOGP
Karsak, E. E., & Özogul, C. O. (2009), combinan varias técnicas de forma tal que se
pueda establecer una relación entre los requerimientos de los decisores y las
características del software a seleccionar (QFD), posteriormente se establece un grado
de relación entre dichos factores mediante FLR y finalmente se elige la alternativa más
adecuada mediante ZOGP, el cual soporta varios objetivos y busca minimizar la suma de
las desviaciones del valor máximo de satisfacción por parte de los decisores.
Metodologías Propuestas
Las metodologías propuestas son aquellas que están directamente formuladas para
ajustarse al contexto en el que se desarrolla el proceso de selección, por lo que no han
sido aplicadas extensamente en otros contextos, aunque pueden ser clasificadas como
metodologías tipo MCDM, debido a que evalúan varias alternativas respecto a un
conjunto de criterios.
FAHP
FAHP es una extensión propuesta por Laarhoven, P. J. M., & Pedrycz, W. (1983), a la
metodología AHP, con el objetivo principal de integrar calificaciones difusas de las
preferencias de los decisores, debido a la facilidad con la que los seres humanos utilizan
términos como “entre 3 y 4” o “por encima de 3”, en el momento de asignar una
calificación o manifestar una preferencia respecto a un criterio o alternativa.
Las etapas de las diferentes variaciones de FAHP, son (Javanbarg, M. B. (2012)):

definición de la estructura del problema mediante una jerarquía, definición de una matriz
de comparación por pares con calificaciones difusas (números triangulares de la forma
) como las que se muestran en la Tabla 7 de este documento,
verificación de la consistencia y el cálculo de las prioridades, para finalmente determinar
las prioridades globales y determinar la clasificación de cada una de las alternativas.
Valor en la escala de
Número difuso
Saaty L.L. (1977)
1 (1,1,1)
3 (2-4)
5 (4-6)
7 (6-8)
9 (9,9,9)
2 (1-3)
4 (3-5)
6 (5-7)
8 (7-9)
Tabla 6. Escala difusa de comparación por pares. Adapto de Kilic, H. S. et al (2014)
HKBS
En este tipo de metodologías se define un sistema que se encarga de almacenar

información de los procesos de decisión, en términos de metodologías de selección,
alternativas y sus características, así como un conjunto de criterios que puede ser
utilizado para evaluar las alternativas definidas. El sistema definido tiene como objetivo
principal, la reutilización de los elementos mencionados, para así poder asistir al decisor
durante la definición y solución del problema de selección del software.
Algoritmos
Este tipo de enfoque asume el problema de selección de software, como un problema de

optimización en el que dadas las alternativas, estas deben cumplir cierta función de
optimización. Este tipo de enfoque es totalmente objetivo, ya que no involucra el juicio de
los decisores como parte del proceso de selección. En los documentos estudiados se
determinaron dos tipos de estrategias: greedy (Haghpanah, N. (2007) y Huang, X. N.
(2013)) y algoritmo genético (Haghpanah, N. (2007)).
ANN
Las técnicas basadas en ANN tienen como componente principal la definición de una red
neuronal, la cual es entrenada con datos obtenidos de los expertos o decisores que
participan en el proceso de selección de software. Este tipo de técnica permite la
combinación de aspectos cuantitativos y cualitativos de los criterios bajo los que las
alternativas son evaluadas.
Los modelos propuestos pueden ser utilizados en contextos en los cuales no exista una
diferencia significativa con respecto a los contextos para los cuales se diseñaron las
redes neuronales.
ANP
Es una generalización del método AHP propuesta por Saaty, T. L. (1996). Esta
generalización considera la dependencia entre elementos de diferentes niveles, por lo
que el problema no se modela como una jerarquía con niveles claramente definidos, sino
como una red de elementos que tienen cierto grado de dependencia mutua, como se
muestra en la Figura 12 de este documento. Los elementos que forman parte de la red,
son considerados como clúster, los cuales pueden ser del tipo origen o receptor. Los
clúster de origen son aquellos que tienen influencia sobre otros clúster. Los clúster
receptores, son aquellos que reciben la influencia de otros clúster. En la red definida,
puede existir auto referencia. Los clúster se componen por elementos que comparten
atributos, es decir que son homogéneos respecto a cierta característica.
Figura 12. Representación de un problema de decisión, como una red de elementos. Adaptado de
Saaty, T.L. (1996)
Para la definición de las prioridades de los decisores, se crea una súper matriz (Sadeghi,
M. et al (2012)), en la que cada calificación es una columna que representa la influencia
de un clúster sobre otro clúster o sobre sí mismo, por lo tanto si los clústeres que
representan el problema de decisión se definen como , y cada clúster con
elementos definidos como la súper matriz asociada a dicha red se
define como la que se muestra en la Figura 13 de este documento, donde cada elemento
, representa una sub matriz en la que el decisor establece sus prioridades. Cuando no
existe una influencia entre clústeres el valor de es cero.
Figura 13. Súper matriz de una red de decisión. Sadeghi, M. et al (2012).
Las preferencias de los decisores agrupadas en las matrices , se encuentran en la

escala propuesta por Saaty, L.L. (1977).
Definidas la estructura del problema y las calificaciones de las preferencias de los

decisores, se procede a calcular la matriz de pesos, por lo que la matriz es normalizada
por el peso del clúster y finalmente se eleva una potencia infinita ( ),

para obtener los pesos generales.
Fuzzy
Este enfoque aplica la teoría de conjuntos difusos así como el algebra de números
difusos, con el fin de determinar las fortalezas y debilidades de cada una de las
alternativas, para posteriormente solicitarle a los expertos una calificación en una escala
lingüística que es posteriormente unificada con las calificaciones de los decisores para
determinar una calificación final para cada una de las alternativas, la cual puede ser
utilizada para determinar la alternativa más adecuada.
WA
Es una técnica que determina la calificación de una alternativa, sumando las

calificaciones de las alternativas respecto a cada criterio, por lo que las prioridades de los
criterios deben ser preestablecidas previa a la determinación de la calificación final de las
alternativas.
PI3. ¿Cuáles son los criterios de selección de software más utilizados?
Como se mencionó en la sección de la metodología seguida para la elaboración del

estado del arte, se definieron etiquetas asociadas a cada categoría de criterios
identificada, de forma tal que los documentos estudiados pudieran ser clasificados en
términos de los criterios que fueron utilizados para la evaluación de las alternativas.
Los grupos identificados son documentación, funcionalidades, factores asociados al

proyecto, factores técnicos y factores asociados al proveedor. En la Tabla 8, se
relacionan los grupos de criterios identificados respecto a los documentos en los que se
utilizaron para evaluar las alternativas.
Grupo de Criterios Documentos en los que se publicó

Lee, H. S., & Wang, M. H. (2007).
Documentación
Zaidan, a. a. et al (2014)
Ayala, C. et al (2011).
Sarrab, M., & Rehman, O. M. H. (2014).
Andreou, A. S., & Tziakouris, M. (2007).
Bhargava, N. et al (2013)
Carvallo, J. P. et al (2007).
Cebeci, U. (2009).
Illa, X. B. et al (2000).
Jaime, G. (2013).
Funcionalidad Jianhua, H. J. H. et al (2010)
Kunda, D. (2003).
Lee, H. S., & Wang, M. H. (2007).
Nelson, B. L. et al (1991)
Nikoukaran, J. et al (1999).
P, V. F., & Chalmeta, R. (2005)
Wei, C. C. et al (2005).
Wei, C.-C., & Wang, M.-J. J. (2004).
Xavier Franch & Juan Pablo Carvallo. (2003).
Zaidan, a. a. et al (2014).
Cebeci, U. (2009).
Chau, P. Y. K. (1995).
Jaime, G. (2013).
Jianhua, H. J. H. et al(2010)
Factores asociados al proyecto Kilic, H. S. et al (2014).
Kilic, H. S. et al(2015)
Kunda, D. (2003).
Lin, H.-Y. et al (2007).
Morera, D. (2002).
Wei, C. C. et al (2005).
Wei, C.-C., & Wang, M.-J. J. (2004).
Tabla 7. Grupos de criterios por publicaciones. Elaboración propia.
Grupo de Criterios Documentos en los que se publicó

Alghamdi, A. S., Ahmad, I., & Nasir, M. (2010)
Andreou, A. S., & Tziakouris, M. (2007).
Ayala, C., Hauge, et al (2011).
Bhargava, N., et al (2013)
Chau, P. Y. K. (1995).
Collier, K., et al (1999).
Gorton, I. et al (2003).
Gürbüz, T. et al (2012)
Jaime, G. (2013).
Kilic, H. S. et al (2015)
Kunda, D. (2003).
Factores Técnicos L. Etaati, S. Sadi-Nezhad, A, M. (2011).
Misra, S. K., & Ray, A. (2013).
Morera, D. (2002).
Nelson, B. L. et al(1991)
Neto, A. A., & Vieira, M. (2011).
P, V. F., & Chalmeta, R. (2005)
Wei, C. C. et al (2005).
Wei, C.-C. Et al (2004).
Xavier Franch & Juan Pablo Carvallo. (2003).
Zaidan, a. a. et al(2014)
Ayala, C., Hauge et al (2011).
Bhargava, N. et al(2013)
Cebeci, U. (2009).
Chau, P. Y. K. (1995).
Gürbüz, T. et al(2012)
Factores asociados al proveedor Jaime, G. (2013).
Lee, H. S., & Wang, M. H. (2007).
Lin, H.-Y. et al (2007).
Morera, D. (2002).
Wei, C. C., Chien. et al (2005).
Wei, C.-C., & Wang, M.-J. J. (2004).
Tabla 8. Grupos de criterios por publicaciones (continuación). Elaboración propia.
Documentación
En este grupo de criterios se encuentran aquellos relacionados con la disponibilidad de

documentación asociada a aspectos funcionales del software, dentro de los que se
encuentran las ayudas inmersas en las herramientas y la disponibilidad de fuentes de
ayuda externas. Este tipo de criterios se pueden medir en términos del tamaño de las
comunidades de ayuda y la calidad de la documentación percibida por los expertos que
intervienen en los procesos de decisión.
Funcionalidad
Evalúan aspectos relacionados con las funcionalidades con las que cuentan las
herramientas evaluadas. Las funcionalidades se evalúan en términos de usabilidad y
cantidad de funcionalidades disponibles.
Factores Asociados al Proyecto
Estos criterios evalúan las alternativas respecto a aspectos relacionados con el proyecto
en el que se enmarca el proceso de decisión, son evaluadas en términos económicos y
tiempo de duración del proyecto.
Técnicos
Los criterios de tipo técnico evalúan las alternativas en aspectos como el consumo de
recursos físicos (memoria, disco duro o red), la capacidad para dar una respuesta de
forma eficiente, la capacidad de integración con sistemas externos y la capacidad de
escalamiento. Los criterios técnicos pueden ser evaluados mediante los análisis de
benchmark comparativos que estén disponibles públicamente o se puede determinar la
calificación mediante la ejecución de benchmark en ambientes controlados.
Factores Asociados al Proveedor
Estos criterios se encuentran asociados a la reputación del cliente, su tiempo en el

mercado y la experiencia de la organización con un proveedor.
PI4. ¿Cuáles son los tipos de software evaluados en un proceso de selección?
A partir de la los documentos clasificados bajo la etiqueta software_type-[software_type],

los tipos de software evaluados son: administración del conocimiento, AHP, bases de
datos, científico, COTS, COTS middleware, CRM, datawarehouse, DSS, e-business, e-
learning, EMR, ERP, ESB, ingeniería inversa, MAS, mensajería SMS, Minería de datos,
MRP, SaaS, servidores de correo, simulación, software contable, software para creación
de gráficos, websites y WMS. Una clasificación de los documentos por el tipo de software
que se somete a evaluación se presenta en la Tabla 9.
Tipo de Software Documentos en los que se evaluó

Administración del Conocimiento Ngai, E. W. T., & Chan, E. W. C. (2005).
AHP Ossadnik, W., & Lange, O. (1999).
Bases de Datos Neto, A. A., & Vieira, M. (2011).
Científico Huang, X. et al (2013).
COTS Andreou, A. S., & Tziakouris, M. (2007).
Kunda, D. (2003).
Morera, D. (2002).
COTS Middleware Gorton, I. et al (2003).
CRM Colombo, E., & Francalanci, C. (2004).
Jaime, G. (2013).
DSS Le Blanc, L. A., & Tawfik Jelassi, M. (1989).
Datawarehouse Lin, H.-Y. et al (2007).
e-business P, V. F., & Chalmeta, R. (2005).
e-learning L. Etaati, S. Sadi-Nezhad, A, M. (2011).
EMR Zaidan, a. a. et al (2014).
Tabla 8. Tipos de software sometidos a selección. Elaboración propia.
Tipo de Software Documentos en los que se evaluó

ERP Cebeci, U. (2009).
Jianhua, H. J. H. et al (2010).
Wei, C. C. et al (2005).
Wei, C.-C., & Wang, M.-J. J. (2004).
ESB Alghamdi, A. S. et al (2010).
Ingeniería Inversa Minetola, P. et al (2015).
MAS Lai, V. S. et al (2002).
Mensajería SMS Andreou, A. S., & Tziakouris, M. (2007).
Mineria de Datos Bhargava, N. and (2013).
Collier, K. and (1999).
MRP Shtub, A. et al (1988).
SaaS Godse, M., & Mulik, S. (2009).
Servidores de Correo Xavier, F., & Carvallo, J. P. (2003).
Simulación Cochran, J. K., & Chen, H.-N. (2005).
Hlupic, V., & Paul, R. J. (1996).
Nelson, B. L. et al (1991).
Software Contable Jadhav, A., & Sonar, R. (2008)
Software para Creación de Gráficos Andreou, A. S., & Tziakouris, M. (2007)
Websites Li, Y., & Thomas, M. A. (2014).
Tabla 9. Tipos de software sometidos a selección (continuación). Elaboración propia.
Estudio de Caso 32
2. Estudio de caso
Como lo afirma Runeson, P., & Höst, M. (2009), los estudios de caso son herramientas
de investigación adecuadas para la ingeniería de software, debido a que estudian
fenómenos complejos en su contexto y son realizadas por individuos o organizaciones.
Runeson, P., & Höst, M. (2009), propone como estructura básica para un estudio de caso
en el área de la ingeniería de software, la definición de los siguientes aspectos: definición
de objetivos, definición del caso, teoría o marco de referencia, preguntas de investigación
y métodos de recolección de información.
En este capítulo se presenta el desarrollo del segundo objetivo específico de este

documento: definir un estudio de caso para aplicar la metodología de análisis
multicriterio. El estudio de caso se encuentra contextualizado en el proceso de la
selección del servidor de aplicaciones más adecuado, como parte de un proceso del
diseño de la arquitectura de software para una entidad estatal colombiana.
En este capítulo se hace una presentación de la empresa encargada del proceso, la

empresa estatal colombiana y el perfil de los expertos, con el fin de contextualizar el
proceso. Posteriormente se muestran conceptos asociados a la arquitectura de software
en la que actualmente se encuentran los procesos de la entidad estatal, para luego
describir la arquitectura que se definió como parte de su proceso de actualización
tecnológica.
2.1 Descripción de FSW
FSW es una empresa colombiana fundada en el año 1977, con el objetivo de innovar y
automatizar los procesos de TI de sus clientes para generar valor y disminuir costos.
FSW cuenta con sedes en Colombia (Bogotá, Cali, Medellín, Manizales, Pereira,
Barranquilla, Bucaramanga y Tunja), y oficinas en Estados Unidos, Ecuador y Chile. Con
una planta de 900 colaboradores, dentro de los que se encuentran profesionales en
áreas de gerencia, mercadeo, ingeniería y talento humano.
Estudio de Caso 33
Las operaciones de FSW siguen las recomendaciones de la norma ISO 9001:2008 y

están valoradas con el nivel más alto en la calidad de los procesos CMMI Nivel 5, lo que
le permite garantizar un alto nivel de calidad de software a sus clientes.
Los clientes de FSW forman parte de los sectores de gobierno, salud, educación,
manufactura, financiero, comercio, tecnología, telecomunicaciones, moda y energía.
2.2 Proceso de Toma de Decisiones en FSW
Los modelos CMMI son un conjunto de mejores prácticas para el mejoramiento de los
procesos de las empresas. Dichos modelos son desarrollados por grupos de trabajo
procedentes de la industria, el gobierno y el SEI (Team, C. P. (2010)).
Al ser una empresa certificada en CMMI Nivel 5, FSW cumple con las directrices para el
área de proceso DAR. Esta área tiene como propósito la definición de un proceso formal
para el análisis de un conjunto de alternativas bajo unos criterios debidamente
establecidos (Team, C. P. (2010)).
El área de proceso DAR propuesto por CMMI es el siguiente (Team, C. P. (2010)):

establecer los criterios para evaluar las alternativas, identificar soluciones alternativas,
seleccionar métodos para evaluar alternativas, seleccionar soluciones recomendadas a
partir de las alternativas identificadas evaluándolas respecto a los criterios definidos. Los
procesos de análisis de decisiones como lo establece el CMMI, se resumen en la Figura
14 de este documento.
Seleccionar
Definir Definir las los Seleccionar
Evaluar las
criterios de alternativas médotodos una
alternativas
evaluación de solución de alternativa
evaluación
Figura 14. DAR. Adaptado de Team, C. P. (2010)

Es importante resaltar que los procesos definidos por el DAR, la caracterizan como una
metodología de análisis multicriterio, porque propone el análisis de varias alternativas y la
consideración de criterios tanto cualitativos como cuantitativos.
Los temas que son susceptibles para ser analizadas bajo la normativa CMMI
generalmente están asociados a temas técnicos y se definen durante la planificación del
proyecto.
Dentro de las situaciones que pueden ser analizados mediante DAR, se encuentran la
selección de arquitecturas o alternativas de diseño, el uso de COTS, selección de
proveedores de tecnología, ambientes de soporte o herramientas relacionadas o
ambientes de pruebas. Adicionalmente DAR puede ser utilizado para analizar decisiones
que impliquen determinar si se debe comprar o desarrollar software, o decisiones
respecto a distribución de recursos.
Como resultado final del proceso se redacta un documento en el que se relacionan las
alternativas, los criterios y los métodos usados para seleccionar las mejores alternativas.
2.3 Perfil de los expertos
En esta sección se presenta el perfil de cada uno de los expertos que intervinieron duran
te el proceso de selección del servidor de aplicaciones. Se presenta su formación
académica, su experiencia laboral en términos de años, área de trabajo y certificaciones.
Arquitecto de software (ASW). Ingeniero de Sistemas egresado de la Universidad de

los Andes, con Maestría en Ingeniería de Sistemas y Computación de la Universidad de
los Andes, cuenta con una publicación en IWPC. Cuenta con más de 12 años de
experiencia en proyectos de desarrollo de Software, es certificado en TOGAF 9 y
Professional Scrum Master. Actualmente se desempeña como Arquitecto de Software en
FSW.
Estudio de Caso 35
Ingeniero de Desarrollo Senior (IDS). Ingeniero de Sistemas egresado de la

Universidad Católica de Colombia, es estudiante de la Maestría en Ingeniería de
Sistemas de la Universidad de los Andes. IDS tiene 6 años de experiencia en el
desarrollo de software empresarial, está certificado como Oracle Certified Professional,
Java SE 6 Programmer. Actualmente se desempeña como Ingeniero de Desarrollo
Senior en FSW.
Andrés Leonardo Rojas Duarte (IDSA). Ingeniero de Sistemas egresado de la

Universidad Católica de Colombia, es estudiante de la Maestría en Ingeniería de
Sistemas y Computación de la Universidad Nacional de Colombia, autor del trabajo que
se presenta en este documento. Andrés tiene 6 años de experiencia en el desarrollo de
software empresarial, es certificado como Oracle Certified Professional, Java SE 6
Programmer y WebSphere Network Deployment 6.1 Administrator. Actualmente se
desempeña como Ingeniero de Desarrollo Senior en FSW.
2.4 Descripción de EEC
Es una Empresa Industrial y Comercial del Estado organizada como entidad financiera de
carácter especial, vinculada al Ministerio de Trabajo. EEC, se estableció como una
entidad encargada de compensar las falencias de una entidad estatal previa. Dentro de
los retos asumidos en su puesta en marcha, se encuentra el proceso de actualización de
sus procesos misionales, los cuales se relacionan a continuación:
 Diseñar y adoptar estrategias para otorgamiento de servicios adicionales o

complementarios, para uso y disfrute de sus afiliados, ahorradores, pensionados y
beneficiarios.
 Realizar las operaciones de recaudo, pago y transferencias de los recursos que
deba administrar.
 Gestionar la historia laboral y pensional de sus beneficiarios.
 Administrar la nómina de las personas a quienes se les reconozcan beneficios y
prestaciones.
 Elaborar y mantener actualizados los cálculos actuariales con el fin de cuantificar
el pasivo pensional de las mesadas actuales.
Los procesos anteriormente mencionados se encuentran relacionados con los aportes de

más de seis millones de afiliados y la ejecución de más de 900000 transacciones
mensuales.
2.5 Descripción del caso
La arquitectura bajo la que se encontraban implementados los procesos de negocio de la

EEC, se puede clasificar como una arquitectura de dos capas como se define en Sumathi
S. & Esakkirajan S. (2007), en la primera capa se encuentra el servidor de base de datos
y en la segunda capa se encuentran las aplicaciones clientes que acceden a través de
sentencias a los procesos implementados en el servidor de base de datos, la Figura 15
muestra la arquitectura mencionada.
Figura 15. Arquitectura procesos de negocio EEC. Elaboración Propia.
Como lo mencionan Sumathi S. & Esakkirajan S. (2007), la capa de datos provee un

acceso estandarizado de acceso a los datos. En el caso de la EEC, está capa es un
servidor de base de datos relacional con varias instancias de base de datos.
Estudio de Caso 37
En la capa de clientes se encuentran las aplicaciones que presentan datos a los usuarios
del sistema, brindándoles los mecanismos necesarios para que modifiquen los datos.
De acuerdo a Sumathi S. & Esakkirajan S. (2007) este tipo de arquitectura solamente es

adecuada para los casos en los que los requerimientos son estables y el número de
clientes que acceden a los procesos de negocio son moderados, adicionalmente tiene las
siguientes desventajas:
1. Dificultad de mantenimiento: esto se presenta debido a que el código del cliente

es una mezcla de código de presentación, validación y lógica de negocio.
2. Bajo rendimiento: debido a que en circunstancias en la que la concurrencia de
clientes sea alta, los tiempos de respuesta de la base de datos pueden aumentar.
3. Dificultad en la implementación de reglas de negocio complejas: ya que se debe
re desplegar el código modificado en más de una máquina cliente.
Una de las etapas de los proyectos de implementación de soluciones de software es la

definición de la arquitectura que dará soporte a la solución White (1997). El diseño de la
arquitectura se puede dividir en tres etapas: definición de los requerimientos de la
arquitectura, diseño de la arquitectura y validación de la arquitectura.
Durante la etapa de definición de los requerimientos de arquitectura se establecen las

restricciones bajo las que el diseño de la arquitectura se debe regir. La etapa de diseño
define los componentes, las responsabilidades y los modelos de interacción entre
componente. La validación de la arquitectura busca validar el diseño de forma tal que sea
cercano a los requerimientos de diseño definidos.
Una de las sub-etapas del proceso de definición del diseño de la arquitectura de software
es la elección del tipo de arquitectura que dará soporte a la solución a implementar.
Generalmente se recomienda implementar una arquitectura de varias capas como lo
define Gordon, I (2011); capa de cliente, capa web, capa de lógica de negocios y capa de
administración de datos.
Como se menciona en Sumathi S. & Esakkirajan S. (2007) la implementación de un

arquitectura de múltiples capas tiene las ventajas resumidas en Tabla 10. En la tabla se
establece una codificación del tipo “Vi” donde la letra “V” está asociada a la palabra
“Ventaja” y la letra “i” es un número secuencial asignado a cada ventaja listada, esta
codificación será utilizada en el apartado PROACT de este documento para relacionar las
ventajas de una arquitectura multicapas con los objetivos derivados a partir del
seguimiento de la metodología PROACT.
Código Ventaja Ventaja

V1 Reducción de la carga de procesamiento de la base de datos
V2 Posibilidad para el reúso de componentes y funcionalidades
Facilidad para la implementación de nuevas reglas de negocio, ya
V3 que solo se requiere de redespliegue de las nuevas
funcionalidades al nivel de la capa de lógica de negocio
Disminución en los tiempos de ejecución de los proceso de
V4
negocio
Tabla 9. Ventajas de una arquitectura multicapas. Adaptado de Sumathi S. & Esakkirajan S. (2007)
Como menciona Gordon, I (2011), la capa de lógica de negocios es soportada por un

servidor de aplicaciones el cual es un componente de software que se encarga de la
administración de la seguridad, comunicación distribuida, transacciones y persistencia
para la ejecución de la lógica de negocio de una solución de software.
Como parte del proceso de actualización tecnológica de la institución estatal, se requiere

la migración de sus procesos de negocio de una arquitectura de 2 capas a una
arquitectura multicapa, en la que sus procesos de negocio sean ejecutados en el servidor
de aplicaciones más adecuado, con el fin de poder beneficiarse de las ventajas definidas
en Sumathi S. & Esakkirajan S. (2007) para una arquitectura multicapas.
Criterios de Selección 39
3. Criterios de Selección
En este capítulo se presenta el seguimiento de la metodología PROACT, la cual permitió
definir los criterios de selección del servidor de aplicaciones más adecuado,
desarrollando de esta forma el objetivo tres del trabajo que se presenta en este
documento.
La metodología PROACT fue propuesta por Hammond et al. (1999), cuenta con 5 etapas
clave y 3 etapas complementarias. PROACT es una metodología que permite entender
el problema para así poder establecer posibles cursos de acción.
Para abordar el problema de la selección del servidor de aplicaciones más adecuado, se

siguieron las 5 etapas base del método PROACT las cuales se describen a continuación:
1. Identificación del problema: etapa en la que se define el problema de decisión

que se desea afrontar. El desarrollo de esta etapa se presenta en el Capitulo 2,
de este documento.
2. Definición de los objetivos: en esta etapa se definen los objetivos que se
desean alcanzar mediante la solución del problema definido.
3. Definición de alternativas: como resultado de esta etapa se definen los
diferentes cursos de acción sobre los cuales se debe elegir el más adecuado.
4. Evaluación de las consecuencias: esta etapa tiene como objetivo definir el nivel
de cumplimiento de los objetivos por parte de las alternativas.
5. Análisis de las transacciones: en esta etapa se determina la influencia entre
objetivos con el fin de definir prioridades entre los mismos.
3.1 Objetivos
En la Tabla 11 se presenta el listado de objetivos definidos por común acuerdo por el

grupo de expertos, teniendo presente las ventajas definidas por Sumathi S. & Esakkirajan
S. (2007) para una arquitectura multicapas y los objetivos establecidos para el proyecto
de actualización tecnológica de la entidad estatal.
En la tabla de objetivos se establece una codificación que más adelante permitirá

relacionarlos con los criterios que se deriven a partir de su análisis, el código asignado a
cada criterio tiene el formato “Oi”, donde la letra “O” se encuentra asociada a la palabra
“Objetivo” y la letra “i” es un valor numérico secuencial asignado a cada objetivo.
Código
Ventaja Código
Objetivo
Arquitectura Objetivo
Multicapa
Disminuir los tiempos de respuesta de los procesos de
V4 O1
negocio
V1 O2 Paralelizar la ejecución de los procesos de negocio
Garantizar la escalabilidad de la solución de software
V2 O3
implementada
V1 O4 Garantizar la disponibilidad de los procesos de negocio
Disminuir los tiempos de implementación de los procesos de
V3 O5
negocio en la nueva arquitectura
Disminuir los costos económicos de la implementación de la
V3 O6
solución de software
Disminuir los tiempos de mantenimiento de la solución de
V3 O7
software
Desacoplar la solución de software implementada del
V2 O8
ambiente en el que se ejecuta
Disminuir la curva de aprendizaje en la implementación la
V3 O9
solución de software
Desacoplar la plataforma seleccionada del sistema operativo
V2 O10
en el que se ejecuta
Tabla 10. PROACT Objetivos. Elaboración propia.
Como se puede observar se encuentran orientados a las metas que se esperan cumplir
mediante la solución del problema propuesto, como se propone en la metodología
PROACT. Adicionalmente de la tabla de objetivos se puede observar una tendencia
sobre tres aspectos importantes para la ejecución del proyecto: la disminución de

tiempos de respuesta de los procesos de negocio, la disminución en los tiempos de
implementación y la posibilidad de reutilizar los procesos que se implementen como parte
de la etapa de desarrollo del proyecto.
3.2 Alternativas
De acuerdo a la metodología PROACT, las alternativas definidas deben ser cursos de

acción que permitan la solución del problema definido, en este caso se pretende
seleccionar un servidor de aplicaciones que soporte los procesos de negocio de una
entidad estatal. Adicionalmente la metodología establece que dichas alternativas sean
comparables entre sí.
De acuerdo a la anterior y como parte de la definición de requerimientos de arquitectura

del proyecto, se definió que las versiones de los servidores de aplicaciones a evaluar
deben cumplir con las siguientes características: ser de licenciamiento libre y ser
servidores de aplicaciones que soporten la plataforma JEE.
Un listado inicial de alternativas se obtuvo consultando la página de compatibilidad

Oracle con la plataforma JEE, de dicha página se puede observar que existen
alternativas comerciales (Por ejemplo IBM WebSphere) las cuales no son contempladas
de acuerdo a la restricción de licenciamiento libre establecida para el proyecto. Del
conjunto de alternativas restantes se seleccionaron aquellas con las que los expertos
cuentan con más experiencia, por lo tanto las alternativas seleccionadas se muestran en
Servidor de Código Tipo

Propietario Lenguaje Versión
Aplicaciones Alternativa de Licencia
JBOSS AS A1 JBoss Org Java LGPL 2.1 7.1.1
TOMCAT A2 Apache Org Java Apache 2 7.0.61
GLASSFISH A3 Oracle Java GPL 3.1.2.2

Apache 2,
A4 Eclipse
Jetty Java Eclipse 8
Foundation
Foundation
Tabla 11. PROACT Alternativas. Elaboración Propia.
3.3 Consecuencias
En esta sección se relacionan los objetivos y las alternativas determinando si las

alternativas permiten o no alcanzar los objetivos definidos, la clasificación asignada a
cada alternativa es resultado del análisis de los expertos en el área, tomando como
criterio su conocimiento sobre la plataforma y experiencia en proyectos de desarrollo en
los que se implementaron las alternativas como ambiente de despliegue. Para determinar
el nivel de cumplimiento de los objetivos para cada alternativa se hizo uso de una
adaptación de la escala de Saaty, L. L. (1977), la cual se presenta en la Tabla 13 de este
documento.
Nivel de
Cumplimiento del Interpretación
Objetivo
1 La alternativa no cumple con el objetivo
La alternativa cumple moderadamente con el
3
objetivo
5 La alternativa cumple fuertemente con el objetivo
La alternativa cumple muy fuertemente con el
7
objetivo
9 La alternativa cumple absolutamente el objetivo
Tabla 12. PROACT Escala para análisis de consecuencias. Elaboración Propia.
Alternativa
JBoss Tomcat GlassFish Jetty
Objetivo
O1 7 7 7 9
O2 7 7 7 1
O3 9 9 9 1
O4 7 7 7 7
O5 9 9 7 7
O6 9 9 9 9
O7 7 7 7 7
O8 7 7 7 3
O9 9 9 9 7
O10 9 9 9 9
Tabla 13. PROACT Tabla de Consecuencias. Elaboración Propia.
En términos generales se puede observar que las alternativas seleccionadas cumplen

con los objetivos propuestos. La mayoría de las alternativas tienen puntajes similares a
excepción de Jetty, ya que es un servidor de aplicaciones mucho más liviano que las
demás alternativas, motivo por el cual obtiene un valor superior en el Objetivo 1. En

términos de opciones para paralelizar los procesos implementados (Objetivo 2) se
debería hacer un gran esfuerzo de desarrollo lo que influye directamente en la
escalabilidad de la solución que se va a implementar (Objetivo 3) y el desacoplamiento
de la solución del ambiente de ejecución (Objetivo 8).
3.4 Transacciones
De acuerdo a la metodología PROACT, es preciso determinar el grado en el que los

objetivos que se pretende alcanzar mediante la solución del problema influyen entre sí,
para poder determinar así preferencias sobre los objetivos.
En este apartado se compara cada uno de los objetivos entre sí mostrando el grado de
influencia que tiene cada uno sobre los demás objetivos, para la clasificación se
establece una escala cuantitativa BAJA (1), MEDIA (2) o ALTA (3), para de esta forma
poder determinar la relevancia de los objetivos durante el proceso de selección de la
mejor alternativa. La comparación entre objetivos fue elaborada por el arquitecto a cargo
del proyecto y su resultado se presenta en la Tabla 15 de este documento.
Objetivos 1 2 3 4 5 6 7 8 9 10
1 - 3 3 3 3 3 2 1 1 3
2 3 - 3 3 1 3 2 3 1 1
3 3 3 - 3 1 3 1 1 1 1
4 3 3 3 - 1 3 1 1 1 1
5 3 1 1 1 - 3 3 3 1 1
6 3 3 3 3 3 - 3 3 1 3
7 2 2 1 1 3 3 - 3 1 1
8 1 3 1 1 3 3 3 - 1 1
9 1 1 1 1 1 1 1 1 - 1
10 3 1 1 1 1 3 1 1 1 -
Tabla 14. PROACT Tabla de Transacciones. Elaboración Propia.
De la tabla de transacciones se puede concluir lo siguiente:
1. Los objetivos 1 al 4 son influyentes en un alto grado entre sí, esto es debido a que
los 4 objetivos están relacionados con la calidad percibida por los usuarios finales
de la aplicación
2. El objetivo 6 es influenciado por la mayoría de los objetivos, debido a que cada
uno de los demás objetivos tienen un impacto directo sobre los costos generados
en el proyecto.
3. El objetivo 9 no tiene una influencia directa de los demás objetivos, esto es debido
a que las personas involucradas con el desarrollo tienen la experiencia suficiente
para afrontar cambios a nivel arquitectónico.
4. El objetivo 10 solo es influenciado por los objetivos 1 y 6, ya que el cambio de
sistema operativo puede costos a nivel económico y de tiempos de respuesta.
3.5 Criterios
Como lo menciona Carney, D. J., & Wallnau, K. C. (1998), el proceso de selección de

software está directamente relacionado con el contexto de su uso, por lo que no es
posible determinar un conjunto de criterios que apliquen para la selección de cualquier
tipo de software.
De acuerdo a los objetivos que se definieron como parte del proceso de selección del
servidor de aplicaciones más adecuado y el seguimiento de la metodología PROACT, los
expertos que participaron durante el proceso, establecieron criterios que permitan
considerar el desempeño de los servidores de aplicaciones, sus funcionalidades y la
documentación disponible.
Criterios Técnicos
Para determinar los criterios técnicos, se verificaron los estudios realizados por Peña-
Ortiz, R. et al (2013) y He, X., Yang, Q., & Member, S. (2000). Los criterios técnicos
definidos se relacionan en la Tabla 16 de este documento.
Criterio Código Descripción Unidad Tendencia

Tiempo de Tiempo promedio de
almacenamiento almacenamiento de Milisegundos
C1 Minimizar
en base de registros en base de (ms)
datos datos
Memoria promedio
consumida por el
servidor de aplicaciones
Consumo de Megabytes
C2 durante el proceso de Minimizar
memoria (MB)
almacenamiento de
registros en la base de
datos
Porcentaje promedio de
consumo de CPU por
parte del servidor de Porcentaje
Consumo de aplicaciones durante el Valor entre 1
C3 Minimizar
CPU proceso de y 100
almacenamiento de (%)
registros en la base de
datos
Tabla 15. Criterios Técnicos. Elaboración propia.
Criterios Funcionales
Los criterios funcionales definidos para la evaluación de los servidores de aplicaciones,

se encuentran relacionados con aspectos que permitan la implementación de los
procesos de negocio de la EEC. Los criterios funcionales definidos se relacionan en la
Criterio Código Descripción Unidad Tendencia

Criterio en el que se considera el
Soporte para
nivel de soporte de los ambientes Escala
herramientas de C4 Maximizar
de desarrollo para los servidores de 1 a 5
desarrollo
evaluados.
Define el nivel de cumplimiento de
Cumplimiento de Escala
C5 los estándares JEE por parte de los Maximizar
estándares de 1 a 5
servidores de aplicaciones.
Este criterio califica la facilidad para
Facilidad de Escala
C6 hacer administración del servidor Maximizar
Administración de 1 a 5
de aplicaciones.
Tabla 16. Criterios Funcionales. Elaboración Propia.
La escala utilizada para determinar la calificación de los criterios funcionales, es una

escala de 1 a 5, en la que 1 es el la calificación más baja, 2 es una calificación baja
intermedia, 3 es una calificación media, 4 es una calificación medio-alta y 5 es la
calificación más alta. La escala establece valores intermedios como 1.5, 2.5, 3.5 y 4.5.
Criterios de Documentación
En este grupo de criterios se encuentra el criterio asociado a la documentación disponible

de los servidores de aplicaciones, al cual se le asignó el código C7 para ser referenciado
dentro del presente documento. La escala utilizada para calificar dicho criterio es la
escala definida para la calificación de los criterios funcionales descrita en la sección
anterior.
Valoración de los criterios de selección 47
4. Valoración de los criterios de selección
En este capítulo se da alcance al objetivo tres del trabajo desarrollado, con el fin de
establecer las calificaciones de cada una de las alternativas respecto a los criterios
establecidos en el Capitulo 3 de este documento, por lo que dada la clasificación de los
criterios, se establecieron dos tipos de fuentes: primaria y secundaria.
La fuente primaria de calificación de criterios permitió obtener las calificaciones de los

criterios técnicos, los cuales fueron medidos en ambientes controlados y aislados para
cada servidor de aplicaciones.
Mediante la fuente secundaria se obtuvieron las calificaciones de los criterios funcionales,

obteniendo los resultados del estudio publicado por RebelLabs (2013), en el cual se
establecen calificaciones para dichos aspectos, por parte de expertos con un amplio
conocimiento en los servidores evaluados en este documento.
4.1 Valoración de criterios técnicos
Como resultado de la sugerencia de uno de los expertos que participó en el proceso, se

desarrolló una aplicación J2EE, para ser desplegada en los servidores de aplicaciones
analizados. La aplicación desarrollada genera registros con datos aleatorios que
representan la información de personas (las características de los datos se presentan en
la Tabla 18 de este documento), los cuales son almacenados en una base de datos
relacional.
Dato Tipo de Dato Valor Mínimo Valor Máximo

Primer Nombre Cadena de caracteres 10 50
Segundo Nombre Cadena de caracteres 10 50
Primer Apellido Cadena de caracteres 10 50
Segundo Apellido Cadena de caracteres 10 50
Sexo Carácter (F o M) No aplica No Aplica
Edad Entero 1 94
Tabla 17. Características de los datos utilizados en las pruebas para obtener los valores de los
criterios técnicos. Elaboración Propia.
Para ejecutar el proceso de almacenamiento se publicó un servicio web del tipo SOAP,
cada invocación del servicio inicia la generación y almacenamiento de 15.000 registros.
Mediante la herramienta JMeter, se ejecutaron pruebas generando 10 peticiones en
intervalos de tiempo de 10 segundos entre cada grupo de peticiones, las peticiones se
generaron 100 veces para de esta forma almacenar un total de 15’000.000 de registros
en cada prueba. En la Figura 16 se muestra la configuración de la cantidad de usuarios y
en la Figura 17 se muestra la configuración de la petición SOAP del servicio web.
Figura 16. Configuración en JMeter de la cantidad de peticiones para obtener las calificaciones de los
49
Figura 17. Configuración en JMeter de las peticiones SOAP para obtener las calificaciones de los
La aplicación se desplegó en máquinas virtuales configuradas en Amazon AWS,

configurando una máquina por cada uno de los servidores de aplicaciones (máquinas
del tipo t2.micro) y una máquina con la base de datos relacional (máquinas virtuales del
tipo db.t2.micro) en la que se persistieron los datos, las características de las máquinas
virtuales se relacionan en la Tabla 19 de este documento. Esta arquitectura permite el
acercamiento a un ambiente real y el aislamiento de los ambientes durante las pruebas.
Cantidad de
Capacidad de
Tipo de Máquina Memoria RAM Máquinas
Almacenamiento
Configuradas
Servidor de
1 GB 1 GB 4
Aplicaciones
Base de Datos 1 GB 5 GB 4
Tabla 18. Características técnicas máquinas virtuales utilizadas en la ejecución de las pruebas para
obtener las calificaciones de los criterios técnicos. Elaboración Propia
En las siguientes secciones del documento, se presentan los métodos utilizados para
obtener los datos de los criterios C1, C2 y C3.
Tiempo de almacenamiento en base de datos
Para obtener el tiempo promedio de respuesta de almacenamiento, dentro de la

aplicación desarrollada se obtiene el tiempo previo a la generación y persistencia de los
datos, cuando el proceso finaliza se obtiene el tiempo de finalización, al cual se resta el
tiempo de inicio, la diferencia entre los dos tiempos se calcula en milisegundos. En la
Tabla 20, se muestran los valores de los tiempos de almacenamiento promedio para
cada uno de los servidores de aplicaciones.
Tiempo Promedio de
Servidor de
Almacenamiento
Aplicaciones
(ms)
GlassFish 3248,353
JBoss 6139,867
Tomcat 6187,914
Jetty 6247,376
Tabla 19. Tiempo promedio de almacenamiento de los servidores de aplicaciones. Elaboración
Propia.
Consumo de memoria
Para obtener los valores asociados al consumo de memoria, en cada una de las
máquinas virtuales se realizó monitoreo mediante la herramienta JMeter, durante la
ejecución de las pruebas. JMeter permite ejecutar por demanda el JGC de la JVM que
se está monitoreando, previo al inicio de las pruebas se ejecutó el JGC con el fin de
tener el valor real de memoria consumido durante el proceso de generación y
almacenamiento de registros por parte de cada uno de los servidores de aplicaciones
estudiados. Los valores asociados al consumo promedio de memoria durante el
proceso, se presentan en la Tabla 21 de este documento.
51
Servidor de Consumo Promedio de Memoria

Aplicaciones (MB)
Jetty 51,526
Tomcat 71,349
JBoss 87,661
GlassFish 129,847
Tabla 20. Consumo Promedio de Memoria de los servidores de aplicaciones. Elaboración Propia.
Consumo de CPU
El consumo promedio de CPU de los servidores de aplicaciones durante el proceso de

prueba, se obtuvo mediante el monitoreo con la herramienta JMeter. El consumo
promedio de CPU, representa el porcentaje de tiempo de procesamiento destinado para
el proceso asociado al servidor de aplicaciones en el que se ejecuta la prueba. En la
Tabla 22 de este documento se presentan los valores obtenidos mediante el monitoreo
de los servidores de aplicaciones.
Consumo
Servidor de
Promedio de CPU
Aplicaciones
(%)
GlassFish 19,365
Tomcat 27,688
Jetty 27,927
JBoss 28,194
Tabla 21. Consumo promedio de CPU de los servidores de aplicaciones. Elaboración Propia.
4.2 Valoración de criterios funcionales
De acuerdo a la sugerencia del arquitecto de software, que formó parte del grupo de
expertos, se definió como fuente secundaria el reporte de RebelLabs (2013), en el que se
analizan aspectos técnicos y funcionales de los servidores de aplicaciones que en este
proyecto se consideraron como posibles alternativas. A continuación se presentan las
calificaciones de los criterios funcionales teniendo como fuente el mencionado reporte.
Soporte para herramientas de Desarrollo
En este criterio se analiza el soporte de las herramientas disponibles para el desarrollo

de aplicaciones, que utilicen como ambiente de despliegue los servidores analizados. Se
considera la capacidad de interoperatibilidad entre IDEs y la facilidad para realizar
ajustes sobre las configuraciones de los servidores de aplicaciones. Adicionalmente, se
consideran aspectos asociados a la facilidad de instalación y utilización de los plugins de
interacción con los servidores de aplicaciones. En la Tabla 23 de este documento, se
presentan las calificaciones de los servidores de aplicaciones para este criterio.
Servidor de
Calificación
Aplicaciones
JBoss 4,5
GlassFish 4,5
Tomcat 4,5
Jetty 3,5
Tabla 22. Valoración soporte para herramientas de desarrollo de los servidores de aplicaciones.
RebelLabs (2013).
En este caso Jetty obtuvo el puntaje más bajo, debido a que los plugins para versiones
anteriores del servidor no tiene demasiadas funcionalidades y el soporte para la
administración del servidor es limitado (RebelLabs (2013)).
Cumplimiento de estándares
En el criterio de cumplimiento de estándares se analizan los estándares de la plataforma

JEE que cumplen los servidores de aplicaciones. En la Tabla 24 de este documento se
presentan las calificaciones asignadas para los servidores de aplicaciones.
Servidor de
Calificación
Aplicaciones
JBoss 5
GlassFish 5
Tomcat 3
Jetty 3
Tabla 23. Valoración cumplimiento de estándares para herramientas de desarrollo de los servidores
de aplicaciones. RebelLabs (2013).
53
Las calificaciones de Tomcat y Jetty fueron asignadas debido a que dichos servidores no
cumplen completamente con el stack de estándares de JEE para servidores de
aplicaciones, aunque existe la posibilidad de complementarlos mediante plugins (Por
Ejemplo OpenEJB), de acuerdo a las necesidades que se necesiten desde el punto de
vista técnico (RebelLabs (2013)).
Facilidad de Administración
La facilidad de administración califica las funcionalidades disponibles para la

administración de la configuración de los servidores de aplicaciones. En la Tabla 26 de
ese documento se presentan las calificaciones asignadas para este criterio.
Servidor de
Calificación
Aplicaciones
GlassFish 5
JBoss 4,5
Tomcat 3
Jetty 2
Tabla 24. Valoración facilidad de administración de los servidores de aplicaciones. RebelLabs (2013).
La calificación más alta se asignó a GlassFish debido a que cuenta con una consola de
administración con una GUI moderna y con las funcionalidades más completas. Jetty
obtuvo la calificación más baja debido a que no cuenta con una consola de
administración estándar, por lo que todas las tareas de administración se deben realizar
mediante la modificación directa de los archivos de configuración del servidor.
(RebelLabs (2013)).
4.3 Valoración de criterios de documentación
Documentación Disponible
El criterio de documentación disponible evalúa la calidad y disponibilidad de la

documentación de los servidores de aplicaciones evaluados. En la Tabla 25 de este
documento se presentan las calificaciones asignadas a los servidores de aplicaciones
para este criterio.
Servidor de
Calificación
Aplicaciones
Tomcat 5
JBoss 4,5
GlassFish 4
Jetty 3
Tabla 25. Valoración documentación disponible de los servidores de aplicaciones. RebelLabs (2013).
En este caso la calificación más alta es asignada a Tomcat, debido a que es el servidor
de aplicaciones con la comunidad de desarrollo más antigua y con mayor cantidad de
participación. Jetty obtiene el puntaje más bajo, debido a que no existe un listado de
expertos o empresas que brinden soporte para el servidor (RebelLabs (2013)).
Solución del problema de decisión 55
5. Solución del problema de decisión

Definido el caso de estudio, los criterios de selección y obtenidos los valores de las
calificaciones para las alternativas a evaluar, en este capítulo se procede a dar solución
al problema de decisión identificado, el cual es el objetivo especifico cuatro del trabajo
que se presenta en este documento.
Para dar solución al problema se definió la jerárquica que representa el problema de

decisión, se establecieron las prioridades de los criterios mediante comparación por
pares, se definió la matriz de decisión y finalmente se determinaron las calificaciones de
las alternativas.
5.1 Representación Jerárquica del Problema de

Decisión
La representación jerárquica del problema de selección del servidor de aplicaciones más

adecuado involucra 3 grupos de entidades: criterios globales, criterios específicos y
alternativas.
Los criterios identificados en el Capitulo 3 se clasificaron bajo las categorías: criterios

técnicos y criterios funcionales. Dentro del grupo de criterios técnicos se establecieron los
criterios específicos: tiempo de almacenamiento en base de datos, consumo de memoria
y consumo de CPU. Como criterios funcionales se definieron los criterios específicos:
soporte para herramientas de desarrollo, cumplimiento de estándares y facilidad de
administración.
En el Capitulo 3 de este documento se presentaron los servidores de aplicaciones que se

analizaron como alternativas: JBoss AS, Tomcat, GlassFish y Jetty.
La representación jerárquica de la selección del servidor de aplicaciones más adecuado

se presenta en la Figura 18 de este documento.
Tiempo de
almacenamiento en
base de datos
Criterios Técnicos Consumo de memoria
JBoss
Consumo de CPU
Tomcat
Soporte para
herramientas de
desarrollo
Seleccionar el servidor
de aplicaciones más Criterios Funcionales
GlassFish
adecuado para EEC
Cumplimiento de
estándares
Jetty
Facilidad de
administración
Documentación Disponible
Criterios Criterios
Objetivo Alternativas
Globales Especificos
Figura 18. Estructura jerárquica de la selección del servidor de aplicaciones más adecuado para EEC.
Elaboración propia.
5.2 Prioridad de los criterios
Para calcular la prioridad de los criterios los expertos de forma independiente definieron
las prioridades de los criterios mediante comparación por pares. Cada experto estableció
las prioridades de los criterios definiéndolas mediante la hoja de cálculo propuesta por
Goepel, K. D. (2013), la cual dispone de 20 hojas que permiten a los decisores establecer
sus prioridades, una hoja en la que se consolidan los juicios del los expertos que
participan en el proceso de decisión, una hoja de referencia y una hoja para solucionar el
problema mediante el método del vector propio. La herramienta propuesta por Goepel, K.
D. (2013) define un índice de consenso entre las calificaciones de los decisores, con
valores entre el 0% (cuando no existe consenso) y un valor de 100% (cuando las
preferencias de los decisores son completamente compatibles).
Las comparaciones por pares de criterios se ejecutaron de acuerdo a los criterios

globales, con el fin de reducir el número de comparaciones entre criterios. Por lo que el
número de comparaciones para los criterios técnicos y funcionales fue de 3.
Prioridad de los criterios globales
Las calificaciones asignadas por los decisores muestran una marcada preferencia por el
grupo de criterios técnicos los cuales obtuvieron un valor consolidado de 59,8%, seguido
por el grupo de criterios funcionales con un valor consolidado del 27,9% y en el tercer
lugar los criterios asociados a la documentación con un valor consolidado de 12,3%,
estos valores se presentan en la Figura 19 de este documento. El valor del índice de
consenso muestra que las prioridades de los criterios globales asignadas por los
decisores es del 88,6% con un CR del 6,0%.
59,8%
27,9%
12,3%
Criterios Técnicos Criterios Funcionales Criterios de Documentación
Figura 19. Prioridades consolidadas de los criterios globales. Elaboración propia.

En la Figura 20 se muestran las calificaciones asignadas por cada uno de los expertos a
los grupos de criterios globales.
Criterios Técnicos Criterios Funcionales Criterios de Documentación
69,6% 69%
44%
39%
22,9%
17% 19%
13%
7,5%
ASW IDS IDSA
Figura 20. Prioridades asignadas por los expertos a los criterios globales. Elaboración Propia.
Prioridad Local de los criterios técnicos
De acuerdo a las prioridades asignadas por los decisores, el criterio técnico más
relevante es el criterio C1 con un porcentaje del 55,8%, seguido del criterio C3 con el
31,1% y en el tercer lugar el criterio C2 con un porcentaje del 13,1%. Las prioridades de
los criterios de técnicos asignadas por los decisores, muestran un porcentaje de
consenso del 88,8% con un CR del 1,9%. Las prioridades consolidadas asignadas por los
decisores, se muestran en la Figura 21 de este documento.
C1 C2 C3
55,8%
31,1%
13,1%
Figura 21. Prioridades locales consolidadas de los criterios técnicos. Elaboración Propia.
los criterios técnicos.
C1 C2 C3
64%
55%
49%
44%
26% 24%
21%
11%
8%
ASW IDS IDSA
Figura 22. Prioridades locales asignadas por los expertos a los criterios técnicos. Elaboración
Propia.
Prioridad Local de los criterios funcionales
Las prioridades de los expertos muestran una marcada preferencia por el criterio
funcional C5 con un porcentaje del 65,4%, seguido por el criterio C4 con una preferencia
del 23,7% y finalmente el criterio C6 con un porcentaje del 10,9%. Las calificaciones
consolidadas tienen un nivel de consenso del 81,4% con un CR del 0,9%. Las prioridades
consolidadas de los criterios funcionales se presentan en la Figura 23 de este
documento.
C4 C5 C6
65,4%
23,7%
10,9%
Figura 23. Prioridades locales consolidadas de los criterios funcionales. Elaboración Propia.
los criterios funcionales.
C4 C5 C6
79,0%
58,0%
49,0%
37,0%
31,0%
20,0%
15,0%
7,0% 5,0%
ASW ISD ISDA
Figura 24. Prioridades locales asignadas por los expertos a los criterios funcionales. Elaboración
Propia.
Prioridad Global de los Criterios
Para calcular la prioridad global de los criterios se multiplica la prioridad local de un

criterio específico por la prioridad asignada al criterio global al que pertenece. Los valores
de las prioridades globales de los criterios se presentan en la Tabla 26 y en la Figura 25
de este documento.
Prioridad Prioridad
Criterio Global Prioridad Criterio Especifico Código
Local Global
Tiempo de
almacenamiento en C1 0,558 0,334
base de datos
Criterios Técnicos 0,598
Consumo de
C2 0,131 0,078
Memoria
Consumo de CPU C3 0,311 0,186
Soporte para
herramientas de C4 0,237 0,066
desarrollo
Criterios
0,279 Cumplimiento de
Funcionales C5 0,654 0,182
estándares
Facilidad de
C6 0,109 0,030
administración
0,123 C7 1 0,123
Documentación disponible
Tabla 26. Prioridad global de los criterios de selección. Elaboración Propia.
C1 C3 C5 C7 C2 C4 C6
33,4%
18,6% 18,2%
12,3%
7,8% 6,6%
3,0%
Figura 25. Prioridad global de los criterios de selección. Elaboración Propia.

Del resultado del cálculo de las prioridades globales de los criterios de selección, se
puede observar que los 3 criterios más importantes para los decisores son: el tiempo de
de almacenamiento en base de datos, el consumo de CPU y el cumplimiento de
estándares.
5.3 Valoración de las alternativas
Para determinar las preferencias de los decisores por las alternativas definidas, se
modeló el problema de decisión mediante una matriz de decisión, la cual relaciona las
alternativas y los criterios definidos. La matriz que representa al problema de decisión
estudiado en este documento se presenta en la Tabla 27.
Criterios de
Criterios Técnicos Criterios Funcionales
Documentación
C1 C2 C3 C4 C5 C6 C7
Alternativa (ms) (MB) (%) (Escala) (Escala) (Escala) (Escala)
Min. Min. Min. Max. Max. Max. Max.
A1
6139,867 87,661 28,194 4,5 5 4,5 4,5
JBoss
A2
6187,914 71,349 27,688 4,5 3 3 5
Tomcat
A3
3248,353 129,847 19,365 4,5 5 5 4
GlassFish
A4
6247,376 51,526 27,927 3,5 3 2 3
Jetty
Tabla 27. Matriz de decisión. Elaboración propia.
Como se observa en la matriz de decisión, los criterios se encuentran en escalas

diferentes y tendencias diferentes (Min / Max).
Para proceder a solucionar el problema de decisión definido mediante la matriz

presentada en la Tabla 27 de este documento, se deben modificar las calificaciones de
las alternativas para aquellos criterios cuya tendencia es a Minimizar. Como mencionan
Pomerol, J.-C., & Barba-Romero, S. (2012), dichos valores se deben transformar a su
reciproco inverso, la matriz de decisión modificada se presenta en la Tabla 28 de este

documento.
Criterios de
Documentación
C1 C2 C3 C4 C5 C6 C7
Alternativa (1/ms) (1/MB) (1/%) (Escala) (Escala) (Escala) (Escala)
Max. Max. Max. Max. Max. Max. Max.
A1
1/6139,867 1/87,661 1/28,194 4,500 5,000 4,500 4,500
JBoss
A2
1/6187,914 1/71,349 1/27,688 4,500 3,000 3,000 5,000
Tomcat
A3
1/3248,353 1/129,847 1/19,365 4,500 5,000 5,000 4,000
GlassFish
A4
1/6247,376 1/51,526 1/27,927 3,500 3,000 2,000 3,000
Jetty
Tabla 28. Matriz de decisión con todos los criterios con tendencia a maximizar. Elaboración Propia.
Para normalizar los valores de las calificaciones de las alternativas, se puede aplicar
alguno de los métodos relacionados en la Tabla 29 de este documento.
iésima
% del rango % del total de componente
Interpretación % del máximo
del vector
unitario
Formula
Vector Normalizado
Modulo de V Variable Variable Variable 1
¿Conserva
Si No Si No
proporcionalidad?
Tabla 29. Métodos de Normalización. Adaptado de Pomerol, J.-C., & Barba-Romero, S. (2012).
Los métodos recomendados son aquellos que conservan la proporcionalidad de los

valores, por lo tanto para valorar las alternativas definidas en este documento se
aplicarán los métodos del % máximo de y del % del total de . La matriz de decisión
normalizada por dichos métodos se presenta en la Tabla 30 y en la Tabla 31 de este
documento.
Criterios de
Documentación
Alternativa C1 C2 C3 C4 C5 C6 C7
A1
0,529 0,588 0,687 1,000 1,000 0,900 0,900
JBoss
A2
0,525 0,722 0,699 1,000 0,600 0,600 1,000
Tomcat
A3
1,000 0,397 1,000 1,000 1,000 1,000 0,800
GlassFish
A4
0,520 1,000 0,693 0,778 0,600 0,400 0,600
Jetty
Tabla 30. Matriz de decisión normalizada por el método del máximo. Elaboración Propia.
Criterios de
Documentación
Alternativa C1 C2 C3 C4 C5 C6 C7
A1
0,206 0,217 0,223 0,265 0,313 0,310 0,273
JBoss
A2
0,204 0,267 0,227 0,265 0,188 0,207 0,303
Tomcat
A3
0,389 0,147 0,325 0,265 0,313 0,345 0,242
GlassFish
A4
0,202 0,369 0,225 0,206 0,188 0,138 0,182
Jetty
Tabla 31. Matriz de decisión normalizada por el método de la sumatoria. Elaboración Propia.
Establecidas las matrices de decisión normalizadas, se procede a calcular la preferencia

de las alternativas calculándolo mediante , donde es la valoración de
una alternativa, es el peso global de cada criterio y es la valoración de la
alternativa respecto a cada criterio. Las calificaciones de las alternativas se presentan en
las Figuras 26 y 27 de este documento.
GlassFish JBoss Jetty Tomcat
0,927
0,736
0,688 0,678
Figura 26. Valoración de las alternativas utilizando la matriz normalizada por el método del máximo.
Elaboración Propia.
GlassFish JBoss Jetty Tomcat
0,316
0,245
0,233 0,226
Figura 27. Valoración de las alternativas utilizando la matriz normalizada por el método de la
sumatoria. Elaboración Propia.
De acuerdo a los resultados obtenidos al determinar la valoración de las alternativas

utilizando las dos versiones de la matriz de decisión normalizada, se puede concluir que
el servidor de aplicaciones más adecuado de acuerdo a los objetivos, las prioridades de
los criterios y las calificaciones de las alternativas respecto a dichos criterios, es
GlassFish. Este resultado es principalmente debido al desempeño de GlassFish respecto
al criterio de tiempo de respuesta de almacenamiento en base de datos.
Conclusiones 66
6. Conclusiones
En este documento se abordó el problema de selección del servidor de aplicaciones más
adecuado, para dar soporte a los procesos de negocio de una entidad estatal colombiana
en proceso de actualización, como parte de la etapa de definición de la arquitectura de
software para dar soporte a los procesos de negocio de la entidad.
Durante el proceso de selección participaron tres decisores con experiencia en el

desarrollo de aplicaciones empresariales y pertenecientes a la empresa contratada por la
entidad estatal. Durante todo el proceso de decisión se integró activamente las
preferencias y experiencia de los expertos, de esta forma los criterios establecidos para
la evaluación de las alternativas se relacionan directamente con los objetivos de la
definición de la arquitectura de software.
Como alternativas se consideraron cuatro servidores de aplicaciones: JBoss 7.1.1, Jetty

8, GlassFish 3.1.2.2 y Tomcat 7.0.61. Para determinar el servidor de aplicaciones más
adecuado, los expertos definieron siete criterios mediante el seguimiento de la
metodología PROACT (PRoblem Objectives Alternatives Consequences), como resultado
se establecieron tres conjuntos de criterios: técnicos, funcionales y asociados a la
documentación. En el grupo de criterios técnicos se definieron: tiempo de
almacenamiento en base de datos, consumo de memoria y consumo de CPU. Bajo los
criterios funcionales se agruparon: soporte para herramientas de desarrollo, cumplimiento
de estándares y facilidad de administración.
Con el fin de determinar las valoraciones globales de los criterios se aplicó la

metodología AHP (Analytic Hierarchy Process), permitiéndole a los decisores estructurar
el problema de decisión y la definición de la importancia relativa de cada uno de los
criterios establecidos para determinar la valoración global de las alternativas. Los
resultados de las comparaciones por pares establecidas por la metodología AHP,
muestran que los expertos tienen una marcada preferencia por los criterios técnicos,
principalmente por los tiempos de respuesta de los servidores de aplicaciones, lo cual se
relaciona directamente con los objetivos establecidos como parte del seguimiento de la
metodología PROACT y los propios objetivos del proyecto en el que se enmarcó el
proceso de decisión. El análisis de los índices de consistencia y consenso de las
preferencias de los decisores, muestran un alto índice de concordancia en las
Conclusiones 67
valoraciones establecidas por los decisores, a pesar de que dicho proceso fue
desarrollado por cada decisor de forma independiente.
Al calcular las calificaciones globales de las alternativas respecto a los criterios definidos,
se puede observar que el servidor de aplicaciones más adecuado es GlassFish, seguido
por JBoss, Jetty y Tomcat. GlassFish obtuvo el primer lugar, debido a su a su alto
desempeño términos de tiempo de respuesta y consumo de recursos físicos (CPU y
memoria RAM), aspectos más relevantes para los decisores y que se encuentran
relacionados directamente con los objetivos establecidos para el proyecto en el que se
enmarcó el proceso de decisión, el cual busca el mejoramiento de los procesos de
negocio de la entidad estatal colombiana desde dichos aspectos. Jetty y Tomcat, tuvieron
calificaciones inferiores debido a que dichos servidores no cumplen totalmente con los
estándares establecidos por la versión empresarial del lenguaje de programación Java.
El desarrollo del trabajo presentado en este documento, muestra que las metodologías
de análisis multicriterio pueden ser implementadas como parte de procesos de definición
de la arquitectura de un sistema, debido a que brindan a los decisores de herramientas
que les permiten comprender el problema que abordan mediante la recolección y análisis
de la información pertinente, junto a métodos que les permiten considerar
simultáneamente criterios que pueden ser mutuamente excluyentes y un amplio número
de alternativas con funcionalidades similares que son constantemente mejoradas. Por lo
que la selección de una alternativa o curso de acción, pueden ser sustentados de una
mejor forma sin verse influenciados por las preferencias de una solo decisor por una
alternativa en particular. Adicionalmente, las metodologías de análisis multicriterio
pueden ser implementadas por las empresas que siguen las recomendaciones
establecidas por modelos como el CMMI (Capability Maturity Model Integration) en su
área de proceso DAR (Decision Analysis and Resolution), ya que comparten las
siguientes etapas: establecimiento de criterios para la evaluación de las alternativas,
identificación de las alternativas, selección de los métodos para evaluar las alternativas,
evaluación de las alternativas haciendo uso de los criterios y métodos, para finalmente
seleccionar la o las soluciones recomendadas.
Trabajos Futuros 68
7. Trabajos Futuros
El seguimiento de la metodología PROACT y AHP como se ilustra en este documento,

pueden ser aplicados en procesos en los que se requiera la evaluación de servidores de
aplicaciones de la misma marca pero en diferentes versiones, como por ejemplo en
procesos que busquen determinar la versión del servidor de aplicaciones más adecuada
para un contexto específico.
Aunque los expertos definieron sus preferencias mediante una herramienta que
automatiza dicho proceso, se puede diseñar y desarrollar una herramienta que guíe a los
decisores durante todo el proceso de selección y que les permita: el seguimiento de la
metodología para definir los criterios, definición y documentación de los criterios de
valoración, consolidación de los valores de los criterios, selección de los métodos de
valoración global de las alternativas y ejecuciones de análisis de sensibilidad.
Las valoraciones de los criterios funcionales definidos, fueron obtenidas mediante la

consulta de una fuente externa. Se puede ejecutar un proceso de comparación por pares
en el que los decisores de acuerdo a su experiencia y preferencias establezcan dichas
valoraciones, para analizarlas comparándolas contra las calificaciones de las fuentes
externas.
Los objetivos establecidos como resultado de la metodología PROACT, pueden ser

generalizados de tal forma que procesos decisión similares al abordado en este
documento puedan ser agilizados en la etapa de definición de criterios.
Anexo: Propuesta de trabajo final 69
A. Anexo: Propuesta de trabajo final

Anexo: Articulo COGESTEC 2014 91
B. Anexo: Articulo COGESTEC 2014

Anexo: Articulo Inge@UAN 108
C. Anexo: Articulo Inge@UAN

Anexo: Etiquetas para clasificación de documentos del estado del arte 111
D. Anexo: Etiquetas para

clasificación de documentos del
estado del arte
Cantidad de Documentos
Etiqueta
Clasificados
country-arabia 2
country-australia 1
country–china 5
country-colombia 2
country-cyprus 1
country-germany 1
country-greece 1
country-honkong 1
country-india 6
country-iran 2
country-israel 1
country-italia 2
country-malasya 1
country-norway 1
country-oman 1
country-portugal 1
country-spain 5
country-taiwan 4
country-turkey 5
country-uk 3
country-usa 7
country-zambia 1
criteria_selection 46
criteria_selection-documentation 8
criteria-selection-functionality 31
criteria-selection-project_factors 23
criteria-selection-technical_factors 36
criteria-selection-vendor 23
methodology 44
methodology-ahp 9
methodology-algorithm 2
methodology-algorithm_genetic 1
methodology-algorithm_greedy 1
methodology-ann 2
methodology-anp 2
methodology-custom 6
methodology-fahp 7
methodology-fuzzy 1
methodology-hkbs 4
methodology-hybrid 9
methodology-hybrid_ahp_desmet 1
methodology-hybrid_ahp_stace 1
methodology-hybrid_ahp_topsis 2
methodology-hybrid_anp_ci_macbeth 1
methodology-hybrid_cbr_rbr 1
methodology-hybrid_qfd_flr_zogp 1
Tabla 32. Listado de etiquetas utilizadas para clasificar los documentos del estado del arte.
Cantidad de Documentos
Etiqueta
Clasificados
methodology-wa 2
software_type-accounting 1
software_type-ahp 1
software_type-charting_component 1
software_type-cots 6
software_type-cots_middleware 1
software_type-datamining 2
software_type-datawarehouse 2
software_type-dbms 1
software_type-dss 1
software_type-ebusiness 1
software_type-elearning 1
software_type-emr 1
software_type-erp 1
software_type-esb 10
software_type-general 2
software_type-knowledge_management 3
software_type-mail_server 1
software_type-mas 1
software_type-mrp 1
software_type-open_source 1
software_type-reverse_engineering 1
software_type-saas 1
software_type-scientific_software 1
software_type-simulation 4
software_type-sms_messaging 3
software_type-software 4
software_type-website 1
software_type-wms 1
year-1988 1
year-1989 1
year-1991 1
year-1995 1
year-1996 1
year-1999 4
year-2000 2
year-2002 2
year-2003 4
year-2004 2
year-2005 4
year-2006 1
year-2007 4
year-2008 1
year-2009 6
year-2010 2
year-2011 5
year-2012 2
year-2013 4
year-2014 4
year-2015 2
Tabla 27. Listado de etiquetas utilizadas para clasificar los documentos del estado del arte.
Bibliografía 118
Bibliografía
Alghamdi, A. S., Ahmad, I., & Nasir, M. (2010). Selecting the best alternative SOA service
bus for C4I systems using multi-criteria decision making technique. In 2010 IEEE Region
8 International Conference on Computational Technologies in Electrical and Electronics
Engineering (SIBIRCON) (pp. 790–795). IEEE. Retrieved from
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5555084
Andreou, A. S., & Tziakouris, M. (2007). A quality framework for developing and
evaluating original software components. Information and Software Technology, 49(2),
122–141. Retrieved from
http://www.sciencedirect.com/science/article/pii/S0950584906000437
Ayala, C., Hauge, Ø., Conradi, R., Franch, X., & Li, J. (2011). Selection of third party
software in Off-The-Shelf-based software development—An interview study with industrial
practitioners. Journal of Systems and Software, 84(4), 620–637. Retrieved from
Baragry, J., & Reed, K. (1998). Why is it so hard to define software architecture? In
Proceedings 1998 Asia Pacific Software Engineering Conference (Cat. No.98EX240) (pp.
28–36). IEEE Comput. Soc. Retrieved from
Belton, V., & Stewart, T. J. (2001). Multiple Criteria Decision Analysis: An Integrated
Approach.
Bhargava, N., Aziz, A., Arya, R., Prof, A., & Technology, I. (2013). Selection Criteria for
Data Mining Software : A Study. International Journal of Computer Science Issues, 10(3),
308–312.
Brans, J.-P., & Mareschal, B. (2005). Promethee Methods. Multiple Criteria Decision
Analysis: State of the Art Surveys, 163–196. http://doi.org/Doi 10.1007/0-387-23081-5_5
Brans, J.-P., Vincke, P., & Mareschal, B. (1986). How to select and how to rank projects:
The PROMETHEE method. European Journal of Operational Research, 24(2), 228–238.
Bibliografía 119
Carney, D. J., & Wallnau, K. C. (1998). A basis for evaluation of commercial software.
Information and Software Technology, 40, 851–860. http://doi.org/10.1016/S0950-
5849(98)00099-8
Carvallo, J. P., Franch, X., Quer, C., & Catalunya, U. P. De. (2007). Determining criteria
for selecting Software Components: Lessons Learned. Ieee Software, 11.
Cebeci, U. (2009). Fuzzy AHP-based decision support system for selecting ERP systems
in textile industry by using balanced scorecard. Expert Systems with Applications, 36(5),
8900–8909. http://doi.org/10.1016/j.eswa.2008.11.046
Chau, P. Y. K. (1995). Factors used in the selection of packaged software in small

businesses: Views of owners and managers. Information and Management, 29, 71–78.
http://doi.org/10.1016/0378-7206(95)00016-P
Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., … Stafford, J.
(2010). Documenting Software Architectures: Views and Beyond. Pearson Education.
Retrieved from http://books.google.com/books?id=UTZbsrA4qAsC&pgis=1
Cochran, J. K., & Chen, H.-N. (2005). Fuzzy multi-criteria selection of object-oriented
simulation software for production system analysis. Computers & Operations Research,
32(1), 153–168. Retrieved from
Collier, K., Carey, B., Sautter, D., & Marjaniemi, C. (1999). A methodology for evaluating
and selecting data mining software. In Proceedings of the 32nd Annual Hawaii
International Conference on Systems Sciences. 1999. HICSS-32. Abstracts and CD-ROM
of Full Papers (Vol. Track6, p. 11). IEEE Comput. Soc. Retrieved from
http://ieeexplore.ieee.org/articleDetails.jsp?arnumber=772607
Colombo, E., & Francalanci, C. (2004). Selecting CRM packages based on architectural,
functional, and cost requirements: Empirical validation of a hierarchical ranking model.
Retrieved September 15, 2014, from
http://www.it.iitb.ac.in/~palwencha/mtp_sec/Prashant Palwencha/lic/pap1412/selecting
CRM packages vol9no3.pdf
Cortés Aldana, F. A., García Melón, M., & Aragonés Beltrán, P. (2007). Selección de una
tecnología de banda ancha para la Universidad Nacional de Colombia. Revista de
Ingeniería E Investigación, 27(1), 132–137.
Cortés, J. A. Z., Serna, M. D. A., & Jaimes, W. A. (2012). Applying fuzzy extended
analytical hierarchy (FEAHP) for selecting logistics software. Ingeniería E Investigación,
32(1), 94–99.
Coulter, E. D., Coakley, J., & Sessions, J. (2006). The analytic hierarchy process: A
tutorial for use in prioritizing forest road investments to minimize environmental effects.
International Journal of Forest Engineering, 17(2), 51–69.
Dolan, J. G. (2008). Shared decision-making--transferring research into practice: the

Analytic Hierarchy Process (AHP). Patient Education and Counseling, 73(3), 418–25.
Retrieved from http://www.sciencedirect.com/science/article/pii/S0738399108003893
Durán, O. (2011). Computer-aided maintenance management systems selection based

on a fuzzy AHP approach. Advances in Engineering Software, 42, 821–829.
http://doi.org/10.1016/j.advengsoft.2011.05.023
Garlan, D., & Shaw, M. (1994). An Introduction to Software Architecture. Knowl. Creat.
Diffus. Util., 1(January), 1–40. http://doi.org/10.1142/9789812798039_0001
Godse, M., & Mulik, S. (2009). An approach for selecting Software-as-a-Service (SaaS)
product. CLOUD 2009 - 2009 IEEE International Conference on Cloud Computing, 155–
158. http://doi.org/10.1109/CLOUD.2009.74
Goepel, K. D. (2013). Implementing the analytic hierarchy process as a standard method

for multi-criteria decision making in corporate enterprises--a new AHP excel template with
multiple inputs. In Proceedings of the international symposium on the analytic hierarchy
process, Kuala Lumpur, Malaysia.
Gorton, I. (2011). Essential Software. Springer. Retrieved from

http://link.springer.com/book/10.1007/978-3-642-19176-3
Bibliografía 121
Gorton, I., Liu, A., & Brebner, P. (2003). Rigorous evaluation of cots middleware
technology. Computer, 36(3), 50–55. http://doi.org/10.1109/MC.2003.1185217
Gürbüz, T., Alptekin, S. E., & Işiklar Alptekin, G. (2012). A hybrid MCDM methodology for
ERP selection problem with interacting criteria. Decision Support Systems, 54, 206–214.
http://doi.org/10.1016/j.dss.2012.05.006
Haghpanah, N., Moaven, S., Habibi, J., Kargar, M., & Yeganeh, S. H. (2007).
Approximation Algorithms for Software Component Selection Problem. 14th Asia-Pacific
Software Engineering Conference (APSEC’07), 159–166.
http://doi.org/10.1109/ASPEC.2007.38
Hammond, J., Keeney, R., & Raiffa, H. (1999). Smart choices: a practical guide to making
better life decisions. Retrieved from
http://scholar.google.com.co/scholar?hl=es&q=Smart+choices:+a+practical+guide+to+ma
king+better+life+decisions&btnG=&lr=#0
Hammond, J. S., Keeney, R. L., & Raïffa, H. (1999). Smart Choices: A Practical Guide to
Making Better Life Decisions. Broadway Books. Retrieved from
http://books.google.com.co/books/about/Smart_Choices.html?id=gsr4lPC4sU4C&pgis=1
Harrison, N. B., Avgeriou, P., & Zdun, U. (2007). Using Patterns to Capture Architectural
Decisions. IEEE Software, 24(4), 38–45. Retrieved from
He, X., Yang, Q., & Member, S. (2000). Performance Evaluation of Distributed Web
Server Architectures under E-Commerce Workloads. In In Embedded Internet Conference
2000 (pp. 285–292).
Heesch, U. van, & Avgeriou, P. (2010). Naive Architecting - Understanding the Reasoning
Process of Students A Descriptive Survey. Retrieved September 14, 2014, from
http://www.cs.rug.nl/~paris/papers/ECSA10a.pdf
Heesch, U. van, & Avgeriou, P. (2011). Mature Architecting - A Survey about the
Reasoning Process of Professional Architects. In 2011 Ninth Working IEEE/IFIP
Conference on Software Architecture (pp. 260–269). IEEE. Retrieved from
Hlupic, V., & Paul, R. J. (1996). Methodological approach to manufacturing simulation

software selection. Computer Integrated Manufacturing Systems, 9(1), 49–55. Retrieved
from http://www.sciencedirect.com/science/article/pii/0951524095000372
Ho, W. (2008). Integrated analytic hierarchy process and its applications - A literature
review. European Journal of Operational Research, 186(1), 211–228.
http://doi.org/10.1016/j.ejor.2007.01.004
Huang, L.-C., & Wu, R. Y.-H. (2005). Applying fuzzy analytic hierarchy process in the
managerial talent assessment model--an empirical study in Taiwan’s semiconductor
industry. International Journal of Technology Management, 30(1), 105–130.
Huang, X., Lu, T., Ding, X., Liu, T., & Gu, N. (2013). A provenance-based solution for
software selection in scientific software sharing. Proceedings of the 2013 IEEE 17th
International Conference on Computer Supported Cooperative Work in Design, CSCWD
2013, 172–177. http://doi.org/10.1109/CSCWD.2013.6580958
Hut, J. C., Mungee, S., & Schmidt, D. C. (n.d.). Techniques for Developing and Measuring
High Performance Web Servers over High Speed Networks 1 Introduction 2 Web Server
Performance over ATM. Traffic, (314), 1222–1231.
IEEE. (2000). IEEE Recommended Practice for Architectural Description of Software-

Intensive Systems, i–23. Retrieved from
http://ieeexplore.ieee.org/articleDetails.jsp?arnumber=875998
Illa, X. B., Franch, X., & Pastor, J. A. (2000). Formalising ERP selection criteria. In Tenth
International Workshop on Software Specification and Design. IWSSD-10 2000 (pp. 115–
122). IEEE Comput. Soc. Retrieved from
Iyengar, a., MacNair, E., & Nguyen, T. (1943). An analysis of Web server performance.
GLOBECOM 97. IEEE Global Telecommunications Conference. Conference Record, 3,
1943–1947. http://doi.org/10.1109/GLOCOM.1997.644616
Jadhav, A. S., & Sonar, R. M. (2011). Framework for evaluation and selection of the
software packages: A hybrid knowledge based system approach. Journal of Systems and
Bibliografía 123
Software, 84(8), 1394–1407. Retrieved from

http://www.sciencedirect.com/science/article/pii/S016412121100077X
Jadhav, A., & Sonar, R. (2008). A Hybrid System for Selection of the Software Packages.
In 2008 First International Conference on Emerging Trends in Engineering and
Technology (pp. 337–342). IEEE. http://doi.org/10.1109/ICETET.2008.7
Jadhav, A., & Sonar, R. (2009). Analytic Hierarchy Process (AHP), Weighted Scoring
Method (WSM), and Hybrid Knowledge Based System (HKBS) for Software Selection: A
Comparative Study. In 2009 Second International Conference on Emerging Trends in
Engineering & Technology (pp. 991–997). IEEE. Retrieved from
Jaime, G. (2013). A hybrid method for information technologies selection combining multi-
criteria decision making ( MCDM ) with technology roadmapping.
Jansen, A., & Bosch, J. (2005). Software Architecture as a Set of Architectural Design
Decision. Retrieved September 14, 2014, from
http://www.ics.uci.edu/~andre/ics223w2006/jansenbosch.pdf
Jansen, A., Der Ven, J., Avgeriou, P., & Hammer, D. (2007). Tool Support for
Architectural Decisions. In 2007 Working IEEE/IFIP Conference on Software Architecture
(WICSA’07) (pp. 4–4). IEEE. Retrieved from
Javanbarg, M. B., Scawthorn, C., Kiyono, J., & Shahbodaghkhan, B. (2012). Fuzzy AHP-
based multicriteria decision making systems using particle swarm optimization. Expert
Systems with Applications, 39(1), 960–966. http://doi.org/10.1016/j.eswa.2011.07.095
Jianhua, H. J. H., Shugong, Z. S. Z., Guangfeng, Z. G. Z., & Chunrui, L. C. L. (2010). A

study on ERP system software selecting evaluation based on fuzzy neural network model.
Advanced Computer Theory and Engineering (ICACTE), 2010 3rd International
Conference on, 1, 365–368. http://doi.org/10.1109/ICACTE.2010.5578997
Kahraman, C., & Öztayşi, B. (2013). Personnel selectıon usıng type -2 fuzzy ahp method.
The Business & Management Review, 4(1), 118–126.
Karsak, E. E., & Özogul, C. O. (2009). An integrated decision making approach for ERP
system selection. Expert Systems with Applications, 36, 660–667.
http://doi.org/10.1016/j.eswa.2007.09.016
Kilic, H. S., Zaim, S., & Delen, D. (2014). Development of a hybrid methodology for ERP
system selection: The case of Turkish Airlines. Decision Support Systems, 66, 82–92.
http://doi.org/10.1016/j.dss.2014.06.011
Kilic, H. S., Zaim, S., & Delen, D. (2015). Selecting “The Best” ERP system for SMEs
using a combination of ANP and PROMETHEE methods. Expert Systems with
Applications, 42, 2343–2352. http://doi.org/10.1016/j.eswa.2014.10.034
Kitchenham, B. (2004). Procedures for performing systematic reviews. Keele, UK, Keele
University, 33(2004), 1–26.
Kreng, V. B., & Wu, C. Y. (2007). Evaluation of knowledge portal development tools using
a fuzzy AHP approach: The case of Taiwanese stone industry. European Journal of
Operational Research, 176, 1795–1810. http://doi.org/10.1016/j.ejor.2005.10.052
Kruchten, P. (1995). Architectural Blueprints—The “4+1” View Model of Software

Architecture. Retrieved March 1, 2015, from
http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
Kruchten, P. (2004). An Ontology of Architectural Design Decisions in Software-Intensive

Systems. Retrieved September 14, 2014, from
http://pkruchten.files.wordpress.com/2009/07/kruchten-2004-design-decisions.pdf
Kunda, D. (2003). STACE: social technical approach to COTS software evaluation.

Component-Based Software Quality, 64–84. Retrieved from
http://link.springer.com/chapter/10.1007/978-3-540-45064-1_4
L. Etaati, S. Sadi-Nezhad, A, M. (2011). Using Fuzzy Analytical Network Process and ISO
9126 Quality Model in Software Selection: A case study in E-learnig Systems. Journal of
Applied Sciences.
Bibliografía 125
Lai, V. S., Wong, B. K., & Cheung, W. (2002). Group decision making in a multiple criteria
environment: A case using the AHP in software selection. European Journal of
Operational Research, 137(1), 134–144. Retrieved from
Le Blanc, L. A., & Tawfik Jelassi, M. (1989). DSS software selection: A multiple criteria
decision methodology. Information & Management, 17(1), 49–65. Retrieved from
http://www.sciencedirect.com/science/article/pii/0378720689900542
Lee, H. S., & Wang, M. H. (2007). A fuzzy model for selecting software. Proceedings -
Fourth International Conference on Fuzzy Systems and Knowledge Discovery, FSKD
2007, 3(Fskd), 411–415. http://doi.org/10.1109/FSKD.2007.36
Lee, L., & Kruchten, P. (2007). Capturing Software Architectural Design Decisions. In
2007 Canadian Conference on Electrical and Computer Engineering (pp. 686–689). IEEE.
Retrieved from http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4232835
Li, Y., & Thomas, M. A. (2014). A Multiple Criteria Decision Analysis (MCDA) Software
Selection Framework. In 2014 47th Hawaii International Conference on System Sciences
(pp. 1084–1094). IEEE. http://doi.org/10.1109/HICSS.2014.141
Lin, H.-Y., Hsu, P.-Y., & Sheen, G.-J. (2007). A fuzzy-based decision-making procedure
for data warehouse system selection. Expert Systems with Applications, 32(3), 939–953.
Retrieved from http://www.sciencedirect.com/science/article/pii/S0957417406000509
Mannisto, T., Savolainen, J., & Myllarniemi, V. (2008). Teaching Software Architecture
Design. In Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA
2008) (pp. 117–124). IEEE. Retrieved from
Maxville, V., Armarego, J., & Lam, C. P. (2009). Applying a reusable framework for
software selection. IET Software, 3(October 2008), 369. http://doi.org/10.1049/iet-
sen.2008.0096
Medvidovic, N., & Taylor, R. N. (2010). Software architecture. In Proceedings of the 32nd
ACM/IEEE International Conference on Software Engineering - ICSE ’10 (Vol. 2, p. 471).
New York, New York, USA: ACM Press. Retrieved from
http://portal.acm.org/citation.cfm?doid=1810295.1810435
Minetola, P., Iuliano, L., & Calignano, F. (2015). A customer oriented methodology for
reverse engineering software selection in the computer aided inspection scenario.
Computers in Industry, 67, 54–71. http://doi.org/10.1016/j.compind.2014.11.002
Misra, S. K., & Ray, A. (2013). Integrated AHP-TOPSIS Model for Software Selection
Under Multi-criteria Perspective. Driving the Economy through Innovation and
Entrepreneurship, 163–174. http://doi.org/10.1007/978-81-322-0746-7
Morera, D. (2002). COTS Evaluation Using Desmet Methodology & Analytic Hierarchy
Process (AHP). (M. Oivo & S. Komi-Sirviö, Eds.) (Vol. 2559). Berlin, Heidelberg: Springer
Berlin Heidelberg. Retrieved from http://link.springer.com/10.1007/3-540-36209-6
Nelson, B. L., Kelton, W. D., & Clark, G. M. (1991). SELECTING SIMULATION

SOFTWARE.
Neto, A. A., & Vieira, M. (2011). Selecting software packages for secure database
installations. Proceedings of the 2011 6th International Conference on Availability,
Reliability and Security, ARES 2011, 67–74. http://doi.org/10.1109/ARES.2011.19
Ngai, E. W. T., & Chan, E. W. C. (2005). Evaluation of knowledge management tools

using AHP. Expert Systems with Applications, 29(4), 889–899. Retrieved from
Nikoukaran, J., Hlupic, V., & Paul, R. J. (1999). A hierarchical framework for evaluating
simulation software. Simulation Practice and Theory, 7(3), 219–231. Retrieved from
Nikoukaran, J., & Paul, R. J. (1999). Software selection for simulation in manufacturing: a
review. Simulation Practice and Theory, 7(1), 1–14. Retrieved from
Ossadnik, W., & Lange, O. (1999). AHP-based evaluation of AHP-Software. European

Journal of Operational Research, 118(3), 578–588. Retrieved from
http://www.sciencedirect.com/science/article/pii/S037722179800321X
Bibliografía 127
Oztaysi, B. (2014). A decision model for information technology selection using AHP
integrated TOPSIS-Grey: The case of content management systems. Knowledge-Based
Systems, 70, 44–54. http://doi.org/10.1016/j.knosys.2014.02.010
Peña-Ortiz, R., Gil, J. A., Sahuquillo, J., & Pont, A. (2013). Analyzing web server
performance under dynamic user workloads. Computer Communications, 36(4), 386–395.
http://doi.org/10.1016/j.comcom.2012.11.005
Pomerol, J.-C., & Barba-Romero, S. (2012). Multicriterion Decision in Management:

Principles and Practice. Springer Science & Business Media. Retrieved from
https://books.google.com/books?id=sk_hBwAAQBAJ&pgis=1
Rojas Duarte, A. L., Pinzón, Y., & Cortés Aldana, F. A. (2015). Selección de software, una
revisión sistemática del estado del arte. Inge@UAN.
Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study
research in software engineering. Empirical Software Engineering, 14(2), 131–164.
Saaty, R. W. (1987). The analytic hierarchy process—what it is and how it is used.

Mathematical Modelling, 9(3-5), 161–176. Retrieved from
Saaty, T. L. (1977). A scaling method for priorities in hierarchical structures. Journal of

Mathematical Psychology, 15(3), 234–281. Retrieved from
Saaty, T. L. (1988). What is the analytic hierarchy process? Springer.
Saaty, T. L. (1996). The Analytic Network Process. RWS Publications. Retrieved from
https://books.google.com/books?hl=en&lr=&id=65N6FiNBMjEC&pgis=1
Sadeghi, M., Rashidzadeh, M., & Soukhakian, M. (2012). Using Analytic Network Process
in a Group Decision-Making for Supplier Selection. Informatica, 23(4), 621–643.
Sarrab, M., & Rehman, O. M. H. (2014). Empirical study of open source software
selection for adoption, based on software quality characteristics. Advances in Engineering
Software, 69, 1–11. Retrieved from
Shih, H.-S., Shyur, H.-J., & Lee, E. S. (2007). An extension of TOPSIS for group decision
making. Mathematical and Computer Modelling, 45(7-8), 801–813.
http://doi.org/10.1016/j.mcm.2006.03.023
Shtub, A., Spiegler, I., & Kapeliuk, A. (1988). Using DSS methods in selecting operations
management software. Computer Integrated Manufacturing Systems, 1(4), 211–220.
Retrieved from http://www.sciencedirect.com/science/article/pii/0951524088900535
Shukla, V., Auriol, G., & Hipel, K. W. (2014). Multicriteria Decision-Making Methodology
for Systems Engineering. IEEE Systems Journal, PP(99), 1–11. Retrieved from
Siddiqui, Z., Abdullah, A. H., & Khan, M. K. (2011). Qualified analysis b/w ESB(s) using
Analytical Hierarchy Process (AHP) method. Proceedings - 2011 2nd International
Conference on Intelligent Systems, Modelling and Simulation, ISMS 2011, 100–104.
http://doi.org/10.1109/ISMS.2011.25
Stamelos, I., & Tsoukias, A. (2003). Software evaluation problem situations. European
Journal of Operational Research, 145(2), 273–286.
Stamelos, I., Vlahavas, I., Refanidis, I., & Tsoukiàs, A. (2000). Knowledge based
evaluation of software systems: a case study. Information and Software Technology,
42(5), 333–345. Retrieved from
Sumathi, S., & Esakkirajan, S. (2007a). Fundamentals of Relational Database

Management Systems (Vol. 47). Berlin, Heidelberg: Springer Berlin Heidelberg.
http://doi.org/10.1007/978-3-540-48399-1
Sumathi, S., & Esakkirajan, S. (2007b). Fundamentals of Relational Database

Management Systems. http://doi.org/10.1007/978-3-540-48399-1
Tang, A., & Lau, M. F. (2014). Software architecture review by association. Journal of
Systems and Software, 88, 87–101. Retrieved from
Bibliografía 129
Team, C. P. (2010). CMMI for Development, Version 1.3.
Tyree, J., & Akerman, A. (2005). Architecture decisions: Demystifying architecture. IEEE
Software, 22(April), 19–27. http://doi.org/10.1109/MS.2005.27
V, S. R., & Muccini, H. (2014). A Study on Group Decision-Making in Software

Architecture. http://doi.org/10.1109/WICSA.2014.15
Vaidya, O. S., & Kumar, S. (2006). Analytic hierarchy process: An overview of

applications. European Journal of Operational Research, 169(1), 1–29. Retrieved from
Van Laarhoven, P. J. M., & Pedrycz, W. (1983). A fuzzy extension of Saaty’s priority
theory. Fuzzy Sets and Systems, 11(1-3), 199–227. http://doi.org/10.1016/S0165-
0114(83)80082-7
Verville, J., & Halingten, A. (2003). A six-stage model of the buying process for ERP
software. Industrial Marketing Management, 32(7), 585–594. Retrieved from
Victor, F. P., & Ricardo, C. (2005). E-Business Software Evaluation. In Collaborative

Networks and Their Breeding Environments (pp. 475–482). Springer.
Wei, C. C., Chien, C. F., & Wang, M. J. J. (2005). An AHP-based approach to ERP
system selection. International Journal of Production Economics, 96, 47–62.
http://doi.org/10.1016/j.ijpe.2004.03.004
Wei, C.-C., & Wang, M.-J. J. (2004). A comprehensive framework for selecting an ERP
system. International Journal of Project Management, 22, 161–169.
http://doi.org/10.1016/S0263-7863(02)00064-9
Xavier, F., & Carvallo, J. P. (2003). Using Quality Models in software package selection.
Ieee Software, 20, 34–41. http://doi.org/10.1109/MS.2003.1159027
Yazgan, H. R., Boran, S., & Goztepe, K. (2009). An ERP software selection process with
using artificial neural network based on analytic network process approach. Expert
Systems with Applications, 36(5), 9214–9222. http://doi.org/10.1016/j.eswa.2008.12.022
Yoon, K. P., & Hwang, C.-L. (1981). Multiple Attribute Decision Making. Springer-Verlag.
Zaidan, a. a., Zaidan, B. B., Al-Haiqi, A., Kiah, M. L. M., Hussain, M., & Abdulnabi, M.
(2014). Evaluation and selection of open-source EMR software packages based on
integrated AHP and TOPSIS. Journal of Biomedical Informatics.
http://doi.org/10.1016/j.jbi.2014.11.012
Zayaraz, G., Vijayalakshmi, S., & Vijayalakshmi, V. (2009). Evaluation of software

architectures using multicriteria fuzzy decision making technique. In 2009 International
Conference on Intelligent Agent & Multi-Agent Systems (pp. 1–5). IEEE. Retrieved from

Seleccion de Servidores

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Seleccion de Servidores

Transféré par

Droits d'auteur :

Formats disponibles

Selección de servidores de

aplicaciones como parte del diseño

Andrés Leonardo Rojas Duarte

Universidad Nacional de Colombia

Andrés Leonardo Rojas Duarte

Universidad Nacional de Colombia

En esta sección quiero agradecer a:

 Los profesores de la Universidad Nacional de Colombia: PhD. Félix Cortes Aldana

En este documento se presenta la aplicación de una metodología de análisis multicriterio,

Palabras clave: Análisis multicriterio, AHP, procesos de negocio, servidores de

Key words: Multicriteria analysis, AHP, business processes, application servers,

Lista de figuras ............................................................................................................... IX

Lista de tablas ................................................................................................................. X

Lista de Símbolos y abreviaturas .................................................................................. XI

1. Revisión del estado del arte .................................................................................... 5

2. Estudio de caso ...................................................................................................... 32

3. Criterios de Selección ............................................................................................ 39

4. Valoración de los criterios de selección ............................................................... 47

5. Solución del problema de decisión ....................................................................... 55

7. Trabajos Futuros .................................................................................................... 68

A. Anexo: Propuesta de trabajo final ......................................................................... 69

B. Anexo: Articulo COGESTEC 2014 ......................................................................... 91

C. Anexo: Articulo Inge@UAN ..................................................................................108

Lista de Símbolos y abreviaturas

AHP Analytic Hierarchy Process

MRP Manufacturing Resource Planning

El primer grupo de definiciones considera a la arquitectura de software como una

entre los componentes software y no software, respecto a su ambiente de desarrollo y de

En el caso de las aplicaciones basadas en tecnologías web, se sugiere la

El segundo grupo de definiciones de arquitectura de software la consideran como el

En el caso de la selección de software o herramientas que dan soporte a una solución, se

Los factores que hacen que un proceso de decisión en el contexto de la definición de la

Figura 2. El proceso MCDA. Adaptado de Belton, V., & Stewart, T. (2002)

En este trabajo se presenta la aplicación de una metodología multicriterio, en el proceso

1. Revisión del estado del arte

Planificación Ejecución Presentación de la

Figura 3. El proceso de revisión sistemática de la literatura. Adaptado de Kitchenham, B. (2004)

1.1.1 Preguntas de investigación

 PI1. ¿Es la selección de software un área de investigación continuamente activa?

1.1.2 Definición del proceso de búsqueda

El proceso de búsqueda tuvo como primera etapa la definición de las ecuaciones de

Posteriormente se definieron las fuentes de búsqueda en las cuales se ejecutó de forma

 IEEE Explorer (IEEE)

Las ecuaciones de búsqueda “Selección de software” y “Evaluación de software”, solo

1.1.3 Criterios de Inclusión

En el caso de los criterios, los artículos seleccionados se incluyeron debido a que

1.1.4 Recolección de datos y análisis de datos

Como resultado de la ejecución de las ecuaciones de búsqueda definidas para el estudio,

Para la clasificación de los documentos analizados en la revisión, se definieron etiquetas

En esta sección del documento se da respuesta a las preguntas de investigación

PI1. ¿Es la selección de software un área de investigación continuamente activa?

PI2. ¿Cuáles son las metodologías de selección de software más utilizadas?

De acuerdo con los resultados obtenidos de la clasificación de los documentos

Figura 5. Cantidad de publicaciones en selección de software por metodología. Elaboración propia.

Metodología Documentos en la que se publicó

Metodología Documentos en la que se publicó

AHP ha sido aplicado exitosamente en procesos para seleccionar la alternativa más

QFD Medicina Pronóstico

La metodología AHP define 4 etapas básicas las cuales se resumen en la Figura 7 de

Definición del problema mediante

Ejecución de Test de Consistencia

Cálculo de la Prioridad General

Figura 7. Etapas de la metodología AHP. Adaptado de Ho, W. (2008).