TendenciasdelaIngenieradeSoftware ImpactoenlasTIC

See
discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/313988077
Propuesta de un Modelo para la Implementación

de un Sistema de Gestión del Conocimiento en la
Educación Dual
Chapter · January 2016
CITATIONS READS
0 468
4 authors, including:
Omar Romero Sandoval Katiuska Fernández Morales

Instituto Tecnológico Superior de Naranjos Tecnológico de Monterrey
4 PUBLICATIONS 4 CITATIONS 11 PUBLICATIONS 9 CITATIONS
SEE PROFILE SEE PROFILE
Sergio D. Ixmatlahua
Instituto Tecnologico Superior de Zongolica
5 PUBLICATIONS 4 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Metrópoli Digital View project
Análisis de las tendencias tecnológicas y pedagógicas en la Educación Superior View project
All content following this page was uploaded by Katiuska Fernández Morales on 24 February 2017.
The user has requested enhancement of the downloaded file.

Tendencias de la
Ingeniería de Software
Impacto en las Tecnologías de Información y Comunicación
Jezreel Mejia Miranda Mirna A. Muñoz Mata Alma Y. Quiñonez Carrillo Hugo A. Mitre Hernández José A. Mora Soto
Tendencias en la Ingeniería de Software
Editado por:
Jezreel Mejia Miranda Mirna A. Muñoz Mata Alma Y. Quiñonez Carrillo Hugo A. Mitre Hernández José A. Mora Soto
Publicado por:
Tendencias en la Ingenieria del Software.
Impacto en las Tecnologias de Información y Comunicación
D.R. © Primera edición, 2016
D.R. © Centro de Investigación en Matemáticas, A.C.
Jalisco s/n, Valenciana

C.P. 36240, Guanajuato, Gto., México
Apdo. Postal 402
http://www.cimat.mx
El cuidado de la edición estuvo a cargo de Jezreel Mejia Miranda, Mirna A. Muñoz Mata, Alma Y. Quiñonez Carrillo,
Hugo A. Mitre Hernández y José A. Mora Soto.
ISBN: 978-607-96212-6-1
Este libro no puede ser reproducido total ni parcialmente, por ningún medio electrónico o de otro tipo, sin autorización
escrita del editor.
This book may not be reproduced, whole or in part, by any means, whitout written permission from the publisher.
Impreso y hecho en México.
Printed and Made in Mexico.
.
Agradecemos su apoyo para la realización del presente libro.
Prólogo de la serie
Este libro está dedicado a la publicación de los trabajos de investigación con aplicaciones reales y de actualidad,
los cuales están relacionados a las tendencias en la Ingenieria del Software aplicados a las Tecnologias de
Información y Comunicación.
Prólogo:
La Ingeniería de Software (IS) permite el establecimiento y uso de principios de ingeniería robustos, orientados
a obtener productos y servicios de software de alta calidad, económico, fiable, eficiente y que satisfaga las
necesidades del usuario. Por lo tanto, la IS se ha convertido sin duda una área indispensable para el desarrollo
de productos y servicios orientados en las Tecnologias de Informacion y Comunicación (TICs) ya que éstas se
han convertido en un motor que mueve a la sociedad en todos sus sectores.
En este contexto, los trabajos publicados en este libro abordan temas relacionados a: la definición y validación
de requerimientos de sistemas basada en herramientas y bajo el esquema de patrones; Aspectos euristicos para
el mejoramiento de herramientas desarrolladas bajo componentes; Método de validación de software con base
en el modelo CMMI; Desarrollo de software para un entorno universitario y de la utilización de nuevos
componentes como la Graph API de Facebook para la difusión de información. Asimismo, se presenta un
modelo para la integración de las MiPymes, Sociedad y Gobierno a través del uso de las TICs. Además, en el
contexto de la educación se presenta un sistema de detección de emociones para la recomendación de recursos
educativos y un modelo para implementar un sistema de gestión del conocimiento en la educación Dual. En el
área de seguridad de las TICs se presenta una propuesta de contenido y controles de seguridad para un sitio
web de un CSIRT. Para el sector Salud se presenta una solución alternativa para el uso de TICs
específicamente en la endoscopia y finalmente, se presenta una trabajo en progreso acerca del establecimiento
del estado del arte sobre marcos de trabajo, métodos y metodologías para evaluar la implementación de
metodologías agules en Pymes.
Los trabajos publicados en este libro abordan nuevos enfoques o áreas de interés mencionados anteriormente,
presentando investigaciones que abarcan tanto el entorno académico como el industrial, y que permiten
dimensionar los retos a los cuales la IS se enfrenta actualmente.
Editores:
Jezreel Mejia
Mirna Muñoz
Alma Y. Quiñonez Carrillo
Hugo A. Mitre Hernández
José A. Mora Soto
Comité Científico
Adriana Peña Perez-Negron Universidad de Guadalajara México

Alejandro Rodríguez Gonzalez Universidad Politecnica de Madrid España
Alma Maria Gómez Rodriguéz Universidad de Vigo España
Alvaro Rocha Universidade de Coimbra Portugal
Angel Jordan Carnegie Mellon University Estados Unidos
Antoni Lluis Mesquida Calafat Universidad de las Islas Baleares España
Antonia Mas Pichaco Universidad de las Islas Baleares España
Antonio Pereira Instituto Politécnico de Leiria Portugal
Antonio de Amescua Seco Universidad Carlos III de Madrid España
Arturo Méndez Penín Universidad de Vigo España
Carla Pacheco Universidad Tecnológica de la Mixteca, Oaxaca México
Carlos Lara López CIMAT Unidad Zacatecas México
Diego Martín de Andrés Universidad Carlos III de Madrid España
Edrisi Muñoz Mata CIMAT Unidad Zacatecas, México México
Edwin León Cardenal CIMAT Unidad Zacatecas México
Elisabet Cápon Swiss Federal Institute of Technology, Zürich
Suiza
(ETHZ)
Enrique Barreiro Alonso Universidad de Vigo España
Fernando Moreina Universidade Portucalense Portugal
Francisco Ortín Soler Universidad de Oviedo España
Giner Alor Hernandez Instituto Tecnológico de Orizaba México
Gloria P. Gasca Hurtado Universidad de Medellin Colombia
Gonzalo Cuevas Agustín Universidad Politécnica de Madrid España
Gonzalo R. Luzardo Morocho Escuela Superior Politécnica del Litoral Ecuador
Gustavo Illescas Universidad Nacional del Centro de la Provincia de
Argentina
Buenos Aires
Henrique Mamede Universidade Aberta de Lisboa Portugal
Hugo Arnoldo Mitre CIMAT Unidad Zacatecas, México México
Ivan A. Garcia Pacheco Universidad Tecnológica de la Mixteca, Oaxaca México
Jaime A. Guzmán Luna Universidad Nacional de Colombia Colombia
Javier García Guzman Universidad Carlos III de Madrid España
Joao Barroso Universidad Tras-os-Montes e Alto Douro Portugal
Jörg Thomaschewski Universidad de Vigo -Hochschule Emden-Leer España
Jose A. Calvo Manzano Villalon Universidad Politécnica de Madrid España
Jose A. Mora Soto CIMAT Unidad Zacatecas México
Jose Antonio Cerrada Somolinos Universidad Nacional de Educación a Distancia España
Jose Baltasar García Perez-
Universidad de Vigo España
Schofield
Juan Carlos Gonzáles Moreno Universidad de Vigo España
Juan Manuel Cueva Lovelle Universidad de Vigo España
Leandro Rodríguez Linares Universidad de Vigo España
Leandro Rodríguez Linares Universidad de Vigo España
Luis Casillas CUCEI de la Universidad de Guadalajara México
Luis Fernández Sanz Universidad de Alcalá España
Luis Borges Goveia Universidad Fernando Pessoa Portugal
Luis J. Dominguez Pérez CIMAT Unidad Zacatecas México
Magdalena Arcilla Cobián Universidad Nacional de Educación a Distancia España
Manuel Pérez Cota Universidad de Vigo España
María José Lado Touriño Universidad de Vigo España
María Y. Hernández Pérez Instituto de Investigaciones Eléctricas México
Marion Lepmets Regulated Software Research Centre, Dundalk
Estonia
Institute of Technology, Ireland
Omar S. Gómez Escuela Superior Politécnica de Chimborazo Ecuador
Paul Clarke Dundalk Institute of Technology Irlanda
Perla Velasco-Elizondo Universidad Autonoma de Zacatecas (UAZ) México
Rafael Valencia García Universidad de Murcia España
Ramiro Goncalves Universidad Tras-os Montes Portugal
Raúl Aguilar Vera Universidad Autónoma de Yucatán México
Ricardo Colomo Palacios Østfold University College Noruega
Rory O´Connor Dublin City University Irlanda
Santiago Mataloaga Universidad ORT Uruguay Uruguay
Sodel Vázquez Reyes Universidad Autonoma de Zacatecas (UAZ) México
Sulema Torres Ramos CUCEI de la Universidad de Guadalajara México
Tomas San Feliu Gilabert Universidad Politécnica de Madrid España
Ulises Juárez Martínez Instituto Tecnológico de Orizaba México
Ulrik brandes Universidad de Konstanz, Alemania
Valentine Casey Dundalk Institute of Technology Irlanda
Vianca Vega Universidad Católica del Norte Chile
Victor Saquicela Uiversidad de Cuenca Ecuador
Vítor Filipe Universidad Tras-os-Montes e Alto Douro Portugal
Yadira Quiñonez Universidad Autonoma de Sinaloa México
Yilmaz Murat Çankaya University Turquia
Índice general
Herramienta para administración y validación de requerimientos de sistemas 7
Definición de Requerimientos de Software a Través de Escenarios utilizando Patrones 15
Proceso basado en patrones de proceso para desarrollar aplicaciones Web 22
Evaluación Heurística de Herramientas de Composición de Componentes Centrada en el 32

Usuario Final
Metamodelo para validación de software basado en el CMMI 41
Presupuesto-CUC y SIRU, dos Experiencias de Desarrollo De Software A La Medida

Para Fortalecer La Gestión De La Universidad De La Costa: Presentación De
Resultados, Impactos, Dificultades y Recomendaciones. 49
Propuesta de un modelo para la Implementación de un Sistema de Gestión del

Conocimiento en la Educación Dual 55
Propuesta de un modelo para la integración de las MiPyMES, Sociedad y Gobierno a

través del uso de las TIC de la Zona Metropolitana del Valle de Orizaba, Veracruz 62
Sistema de detección de emociones para la recomendación de recursos educativos 68
Propuesta de contenido y controles de seguridad para un sitio web de un CSIRT 75
Forming an alternate solution for endoscopy 83
Establishing the state of art of frameworks, methods and methodologies to assess the
implementation and use of agile methodologies in SMEs: A systematic review 90
Jezreel Mejia Miranda - Mirna A. Muñoz Mata - Alma Y. Quiñonez Carrillo - Hugo A. Mitre Hernández - José A. Mora Soto
Herramienta para administración y validación de requerimientos de

sistemas
Oscar Carlos Medina, Marcelo Martín Marciszack, Mario Alberto Groppo
GIDTSI, Grupo de Investigación, Desarrollo y Transferencia de Sistemas de Información

Universidad Tecnológica Nacional, Facultad Regional Córdoba
Maestro López esq. Av. Cruz Roja Argentina, Ciudad Universitaria – (5016) Córdoba
oscarcmedina@gmail.com, marciszack@gmail.com, sistemas@groppo.com.ar
Abstract. El presente trabajo describe una aplicación web denominada SIAR (Sistema Integral de
Administración de Requerimientos) que gestiona los requerimientos de un sistema de información
mediante Casos de Uso, según los lineamientos de UML (Lenguaje Unificado de Modelado). Los
Casos de Uso son útiles para la generación y análisis de requisitos de sistemas. La finalidad principal
de SIAR es la administración de Casos de Uso con una herramienta informática que agilice su
registración, normalice su contenido y posibilite implementar validaciones funcionales, como por
ejemplo un método automatizado de análisis de consistencia de Casos de Uso, para lo cual el sistema
genera un grafo con la transición de estados de cada Caso de Uso, expresado en el protocolo XPDL
(Lenguaje de Definición de Flujo de Trabajo), que es analizado en un simulador de autómata finito
determinista para verificar la cohesión de los escenarios en él definidos.
Palabras Clave: Caso de Uso, Requerimientos, UML, XPDL, Autómata finito determinista.
1 Introducción
SIAR (Sistema Integral de Administración de Requerimientos) es la denominación que se le dio a una

aplicación web que gestiona los requerimientos funcionales de un sistema de información según los
lineamientos de UML (Lenguaje Unificado de Modelado).
Esta aplicación se originó dentro del proyecto de investigación ―Validación de Requerimientos a través 7
de Modelos Conceptuales‖ del GIDTSI (Grupo de Investigación, Desarrollo y Transferencia de Sistemas
de Información), dependiente del Departamento Ingeniería en Sistemas de Información de la Universidad
Tecnológica Nacional, Facultad Regional Córdoba que ―busca dar solución a uno de los principales
problemas de la Ingeniería de Requisitos relacionado a la elicitación y especificación de requerimientos,
que vincula las distintas etapas del proceso de desarrollo de software manteniendo la trazabilidad de los
mismos hasta su validación e implementación‖.
Como el modelo de requerimientos tiene por objetivo la registración y estandarización de
requerimientos funcionales, la construcción de SIAR tiene por fin administrar en forma integral los
requerimientos funcionales de un proyecto de software según la metodología UML. SIAR es una
aplicación web que permitió registrar en forma normalizada los casos de uso y cuya primera versión
comprende el siguiente alcance:
• Administración de los atributos de un proyecto de software y su versionado.
• Diseño y validación del Modelo Conceptual.
• Gestión de los alcances de cada versión del proyecto y los casos de uso asignados.
• Administración de los atributos de un caso de uso, incluyendo actores, pre-condiciones, post-
condiciones, cursos de acción, normal y alternativos, y su versionado.
• Clasificación, priorización y trazabilidad de los casos de uso.
• Visualización de consultas y generación de reportes en distintos formatos, inclusive XPDL, para
comunicarse con otras aplicaciones.
• Gestión de atributos de procesos de negocio, de actividades de negocio que los componen y los
casos de uso asociados a estas actividades.
• Registración y consulta de un glosario por proyecto, con entradas y sinónimos, siguiendo las
recomendaciones de LEL (Léxico Extendido del Lenguaje), que es una estrategia de modelado de
requisitos basada en lenguaje natural.
2 Construcción de una herramienta para la administración integral de Casos de

Uso
La herramienta ha sido diseñada con un criterio de lógica que permite describir la siguiente relación de
cascada:
Fig. 1. Relaciones de SIAR.
SIAR permite trabajar con diferentes Sistemas, cada uno con sus propias Versiones, cada Versión
cubre un número limitado de Alcances, cada Alcance gestiona un grupo de Casos de Uso, cada Caso de
Uso está compuesto por una secuencia ordenada de Pasos, finalmente un paso puede o no tener
Alternativas.
Los Pasos de un Caso de Uso permiten efectuar tareas que son descriptos con el soporte del sistema 8
que se ha desarrollado.
Desde el punto de vista conceptual un Caso de Uso es la descripción de una secuencia de interacciones
entre el sistema y uno o más Actores. Las personas o entidades que participarán en un caso de uso se
denominan Actores.
Cada caso de uso tiene pre-condiciones que se deben cumplir para que el flujo de eventos se puedan
llevar a cabo. Dichas pre-condiciones son las reglas o condiciones que se deben cumplir antes de que sea
iniciado el caso de uso.
También posee post-condiciones que reflejan el estado en que se queda el Sistema una vez ejecutado
el caso de uso.
Puede clasificarse con diferentes niveles de Complejidad según el criterio de cada Analista funcional
en Muy Alta, Media y Baja.
A su vez, un Caso de Uso puede ser del tipo Concreto o Abstracto. Un caso de uso es Abstracto si no
puede ser realizado por sí mismo, o si no es Concreto ya que puede ser iniciado por un actor y realizado
por sí mismo.
Los pasos son las actividades que deberán realizarse para llevar a cabo algún proceso (Rumbaugh,
Jacobson, Booch, 1999).
Cada paso posee alternativas que a su vez puede tener pasos y estos volver a tener alternativas.
Cada caso de uso está codificado con 5 dígitos que conforman el Identificador del Caso de Uso:
1. Id del Sistema.
2. Id de la Versión del Sistema.
3. Id del Alcance de la Versión.
4. Id del Caso de Uso.
5. Id de la Versión del Caso Uso.
3 Alcance de SIAR versión 1.0
El aplicativo busca cubrir las siguientes necesidades:

3.1 Administración de requerimientos
Se planteó la necesidad de generar un sistema que no solo administre los casos de usos por separado, sino
también gestione en forma integral todo el proyecto que lo contiene. Es decir, sistema con sus versiones,
por cada versión del sistema sus alcances y por cada alcance sus casos de usos con sus versiones.
Fig. 2. Consulta de Casos de Uso de un Sistema.
Para cumplir con esta funcionalidad se incluyó también el concepto de sistema, versiones y alcances de
versiones. A su vez cada caso de uso incluye pasos y alternativas. También se propone hacer una
trazabilidad de los cambios. 9
3.2 Configuración del entorno de desarrollo
Para su implementación se utilizó una plataforma de desarrollo ―case‖, generando en lenguaje de

programación C# y almacenando la información en una base de datos MYSQL.
3.3 Interfaz de usuario
El desarrollo del sistema es web porque solo se precisa Internet para acceder a la aplicación desde una
computadora personal. No se escogió un desarrollo de escritorio porque sería necesario contar con un
entorno de configuración local en el equipo que se desee acceder al sistema.
3.4 Administración de proyectos de sistemas
Como se mencionó anteriormente, el trabajo tiene por objetivo principal administrar las descripciones y
mantenimiento de casos de uso en forma integral.
3.5 Administración de Casos de Uso
Durante la descripción de un Caso de Uso, pueden administrarse las pre-condiciones, post-condiciones,

pasos y alternativas como así también los datos básicos de un Caso de Uso. Del mismo modo, en la
descripción de un nivel o paso, una vez definido el mismo puede modificarse o darse de baja, esto se ve
reflejado en las versiones del CU. Lo mismo con cada alternativa de un nivel o paso.
3.6 Versionado de Casos de Uso
La aplicación permite versionar sistemas y versionar Casos de Uso. Se ofrecen distintas herramientas
para llevar a cargo esta tarea, por ejemplo el listado de comparación de versiones de un caso de uso,
detalla los cambios entre dos versiones seleccionadas. Puede ocurrir que el usuario que consulta el
versionado del Caso de Uso no sea el mismo que lo generó, de esta manera puede ver reflejada en el
listado la evolución del CU desde el principio hasta la última modificación.
Fig. 3. Versionado de un Caso de Uso.
3.7 Exportación a archivos XML
Esta es una funcionalidad que proporciona el sistema para poder intercambiar datos con otras
aplicaciones por ejemplo un autómata finito. El archivo XML representa en este protocolo de intercambio
de datos el grafo de estados del Caso de Uso que surge de la equivalencia con sus pasos y alternativas.
3.8 Consultas
Es posible obtener las siguientes salidas del sistema: 10

a) Sistemas
b) Versionado de Sistemas
c) Alcances por Versión de Sistema
d) Casos de Uso por Alcance
e) Versionado de Casos de Uso
f) Comparación entre dos Versiones de un Caso de Uso
g) Reportes de Casos de Uso
Para la versión vigente de un Caso de Uso se pueden imprimir los siguientes reportes:
• Conversión a archivo XML para ingresar a Autómata Finito Determinista.
• Gráfico de estructura del Caso de Uso en forma de árbol.
• Reporte PDF del Caso de Uso.
• Tabla de Estados del Caso de Uso.
h) Información de Usuarios
4 Validación de consistencia de Casos de Uso con simuladores de autómatas finitos
En la actualidad UML es reconocido como el estándar para el modelado de proyectos de software

orientado a objetos.
Los componentes principales de esta metodología son los Casos de Uso ya que especifican el
comportamiento deseado del sistema. Por definición el caso de uso ―especifica una secuencia de acciones,
incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para
un particular actor‖.
Una vez generado un caso de uso, es necesario comprobar y asegurar su validez. La verificación de
consistencia de la secuencia de acciones descripta en el caso de uso es una de las tareas que permiten su
validación.
Es deseable que esta verificación pueda realizarse de manera automatizada para lo cual se podría
trabajar con autómatas finitos deterministas, ya que un autómata finito es un conjunto de estados y un
control que se mueve de un estado a otro en respuesta a entradas externas (Marciszack, Pérez, Castro,
2013). Se llama determinista al autómata que puede estar únicamente en un estado en un momento
determinado. El desafío es transformar el caso de uso en un autómata finito determinista para validar su
cohesión secuencial.
Partiendo de estas premisas, el aporte del presente análisis a la validación de requerimientos que se
propone lograr el proyecto de investigación, consiste en dar respuesta a la siguiente pregunta:
¿Es factible determinar un método, basado en simuladores de autómatas finitos deterministas, que
verifique la consistencia de la secuencia de acciones, incluyendo variantes, definidas en un caso de uso?.
La funcionalidad de SIAR que se detalla a continuación propone una alternativa viable para esta
necesidad, que se realiza en 3 pasos:
4.1 Registración normalizada del requerimiento.
4.2 Transformación del Caso de Uso en una máquina de estados.
4.3 Validación de la consistencia secuencial de los cursos de acción del Caso de Uso.
4.1 Registración normalizada del requerimiento
Como el modelo de requerimientos tiene por objetivo la captura de requerimientos funcionales (Jacobson
y otros, 1992), la primera tarea que se emprendió, fue la construcción de SIAR, una herramienta cuyo fin
es administrar en forma integral los requerimientos funcionales de un proyecto de software según el
estándar UML y permite registrar en forma normalizada los casos de uso.
4.2 Transformación del Caso de Uso en una máquina de estados
En segunda instancia se definió un conjunto de reglas de conversión del caso de uso en un grafo de
estados para que sea la entrada a un simulador de autómata finito determinista.
Una vez completa la versión de un caso de uso, se genera un grafo de estados a partir de las siguientes
definiciones:
• Todo caso de uso tiene al menos un curso de acción normal.
• Un caso de uso puede no tener ningún, o tener uno o tener varios cursos de acción alternativos.
• Cada paso de un curso de acción de un caso de uso responde a un estado y es un nodo de la
máquina de estados.
• Todo caso de uso tiene un paso inicial, y es el primer paso de todos los cursos de acción. Este 11
paso es el estado/nodo inicial.
• Todo caso de uso tiene un paso final por aceptación, y es el último paso del curso de acción
normal. También puede ser el último paso de algún curso alternativo. Este paso es el estado/nodo
final por aceptación.
• Un caso de uso puede no tener ningún, tener uno o tener varios finales por error, y son el último
paso de un curso alternativo. Estos pasos son estados/nodos finales por error.
• Todo caso de uso pasa de un estado/nodo a otro por medio de una función de transición.
• Partiendo de un estado/nodo origen se puede continuar en un único estado/nodo destino, o en
dos nodos/estados destino alternativos dependiendo de una condición de bifurcación.
• El grafo de estados asociado al caso de uso tiene un alfabeto de tres símbolos para indicar qué
evento lo cambia de un estado/nodo a otro:
o A = Por medio de una Acción determinada.

o S = Cuando Si se cumple una condición que bifurca los cursos de acción.
o N = Cuando No se cumple una condición que bifurca los cursos de acción.
Fig. 4. Bifurcación en la especificación de trazo fino de un Caso de Uso.

Partiendo de un estado/nodo origen, en la función de transición puede estar asociado solamente uno de los
símbolos: A, N o S. Con esto se cumple la condición necesaria de un autómata finito determinista. De esta
manera, si la transición entre dos estados/nodos se da dentro de un mismo camino, se asocia el símbolo A.
Si en cambio interviene una bifurcación, la función de transición hacia el estado/nodo destino por
cumplimiento de la condición de bifurcación, se asocia el símbolo S. Por el otro camino de la bifurcación,
se asocia el símbolo N.
Fig. 5. Tabla de estados de un Caso de Uso. Transformación automática por SIAR.
Una vez generado el grafo de estados se expresa en protocolo XPDL, por ser el más adecuado para
intercambiar modelos de procesos entre distintas herramientas. Este lenguaje ―da soporte a la definición y
a la importación/exportación de procesos, con el objetivo de que, aunque se modele un proceso en una
aplicación, este modelo pueda ser usado por otras aplicaciones de modelado y/o por otras aplicaciones
que trabajen en el entorno de ejecución‖ (Pérez, 2007).
12
Fig. 6. Fragmento de archivo XPDL generado por SIAR.
4.3 Validación de la consistencia secuencial de los cursos de acción del Caso de Uso
Finalmente se ingresa el archivo XPDL, que representa al caso de uso como grafo de estados, al programa
―Autómata Finito‖ que forma parte del conjunto de ―Herramientas Prácticas para el Aprendizaje de
Informática Teórica‖. Esta aplicación java ―permite definir autómatas y gramáticas para la enseñanza y
ejercitación de los alumnos de la asignatura Sintaxis y Semántica del Lenguaje que se dicta en la carrera
de Ingeniería en Sistemas de Información de la Universidad Tecnológica Nacional Facultad Regional
Córdoba‖ (U.T.N. F.R.C., 2009).
Fig. 7. Fragmento del grafo de estados en el simulador de autómatas finitos.
El simulador posibilita probar el grafo de estados y comprobar si es aceptado o rechazado. En el segundo

caso se puede visualizar el detalle para detectar la inconsistencia, la cual puede ser corregida en una
nueva versión del caso de uso, generando un nuevo grafo de estados automáticamente. De esta manera se
logra control y trazabilidad de los cambios en los cursos de acción de los requerimientos funcionales.
Vale recordar a F. P. Brooks cuando dijo: ―la tarea más importante que el ingeniero de software hace para
el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto‖.
4.4 Limitaciones
El software limita su alcance con las siguientes restricciones:

• En cada paso abarca alternativas hasta un nivel, sin embargo cada alternativa puede incluir más
de un paso.
• Los Casos de Usos no registran relaciones de inclusión y extensión..
4.5 Resultados 13
Se pone a consideración este método automatizado, implementado en el aplicativo SIAR que registra,
normaliza y transforma un caso de uso a formato XPDL y un simulador de autómatas finitos, que permite
verificar la consistencia secuencial de los distintos caminos del caso de uso.
El aporte que realiza SIAR al proyecto en el que fue concebido, ―Validación de Requerimientos a través
de Modelos Conceptuales‖, es el de constituirse como plataforma de software integradora de las
aplicaciones que se utilizan en cada una de las líneas de investigación.
El presente desarrollo está fundamentado en una ―Propuesta Metodológica para validación de
Requerimientos Funcionales a través de Modelos Conceptuales‖ registrada en la República Argentina con
Derecho de autor de producciones tecnológicas (rubro ―Modelo de organización y/o gestión, Ciencia y
cultura-Ciencia y tecnología‖) según Expediente No.5229942. Esta metodología expone cómo se llega a
identificar la necesidad de construir SIAR y la especificación de requerimientos funcionales de sus
alcances, módulos y funcionalidades.
También ―S.I.A.R. – Sistema Integral de Administración de Requerimientos‖ está registrado en la
República Argentina con Derecho de autor de producciones tecnológicas (rubro ―Máquina, equipo,
instrumento y/o herramienta o su/s componente/s. Informática-software. Ciencia y cultura-Ciencia y
tecnología‖) según Expediente No.5229955.
En lo que respecta a la funcionalidad de análisis de consistencia, SIAR ofrece un método automatizado
para validar la cohesión de un caso de uso desde el punto de vista de la transición de estados definidos
intrínsecamente en los pasos de su especificación funcional. Permitiendo también enlazar este proyecto
con un trabajo académico de la carrera Ingeniería en Sistemas de Información, el del Grupo de
Herramientas Didácticas de Informática Teórica que contribuyó con el simulador de autómatas finitos.
Finalmente se tiene previsto en el año 2015 hacer una transferencia del software a una empresa
especializada en desarrollos de seguridad informática de la región en el marco de un programa
gubernamental de generación y transferencia de conocimientos.
5 Conclusión
En el presente trabajo se han analizado y comprendido el procedimiento y el modelo de datos asistido por
una aplicación web denominada SIAR que gestiona los requerimientos funcionales de un sistema de
información según los lineamientos de UML. Haciendo posible también enlazar este proyecto con un
trabajo académico de la carrera Ingeniería en Sistemas de Información, el del Grupo de Herramientas
Didácticas de Informática Teórica que contribuyó con el simulador de autómatas finitos, que permitió
implementar un método automatizado para validar la cohesión de un caso de uso desde el punto de vista
de la transición de estados definidos intrínsecamente en los pasos de su especificación funcional.
Como lo señalaron Taurant y Marciszack: ―Actualmente existen en el mercado una gran variedad de
herramientas y metodologías que permiten la gestión de requerimientos de software a lo largo del ciclo de
vida de desarrollo. Independientemente de la herramienta o metodología utilizada, la creación y
mantención de un gran número de modelos y artefactos es realizada por el analista en forma manual,
generando con gran frecuencia inconsistencias entre los modelos generados, impactando en la
trazabilidad de los requerimientos.‖
Es por esto que se propuso con SIAR, el desarrollo de una herramienta que permita al analista
gestionar los requerimientos en forma asistida y parcialmente automatizada, por medio de la generación
de modelos conceptuales como representaciones de máquinas abstractas, considerando que se alcanzaron
estos objetivos parcialmente.
Una alternativa factible para continuar trabajando con SIAR es ampliar la trazabilidad de los modelos
de requerimientos de manera tal que permita medir el impacto de los cambios desde el Modelo
Conceptual hasta el Modelo de Sistema de Información agregando técnicas de validación y
funcionalidades de gestión de proyectos de software. Hasta el momento la metodología propuesta y el
modelo de datos de la herramienta que la soporta, posibilitan la trazabilidad desde el modelo de
requerimientos del sistema con su origen en el modelo de datos, pero aún no se alcanza a medir el
impacto en el cambio de dichos modelos. Se está indagando la incorporación de ―Patrones‖, según el
concepto de la Ingeniería de Software, en la validación de Modelos Conceptuales como el próximo paso a
seguir para ampliar el alcance de esta herramienta.
Además se hace necesario validar dentro del Modelo Conceptual también los Requerimientos no
funcionales desde el punto de vista del usuario, entendiendo que usabilidad es el atributo de calidad que
mide la facilidad de las interfaces de un sistema.
Referencias
14
Rumbaugh, J., Jacobson,I., Booch,G. (1999). The Unified Modelling Language Reference. Addisson Wesley.
Chakraborty, Samarjit (2003). Formal Languages and Automata Theory-Regular Expressions and Finite Automata-.
Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology (ETH) Zurich.
Marciszack, Marcelo, Pérez,Ramiro, Castro, Claudia Castro (2013). Validación de Requerimientos a través de
Modelos Conceptuales – Modelos y Transformaciones. WICC 2013.
Jacobson, Ivar y otros (1992). Object Oriented Software Engineering. A Use Case Driven Approach. Addison
Wesley.
Pérez, J. D. (2007). Notaciones y lenguajes de procesos. Una visión global. Tesis de Doctorado Universidad de
Sevilla.
U.T.N. F.R.C. (2009). Proyecto Construcción de Herramientas Didácticas para la enseñanza y ejercitación práctica
en laboratorio de Informática Teórica en las Carreras con Informática. Manual de Usuario – Grupo de
Herramientas Didácticas.
Bibliografía adicional
Sommerville, I. (2005). Software Enginnering, Computing Departament, Lancaster University, John Willey&Sons
Ltd.
Davis, A. (1993). Software requeriments. Object, functions and states. Pretince Hall international Inc.
Brooks, Frederik P. (1987). No Silver Bullet. Essence and Accidents in Software Engineering. IEEE Computer.
Leonardi, C., Leite, J.C.S., Rossi, Gustavo (2001). Una estrategia de Modelado Conceptual de Objetos, basada en
Modelos de requisitos en lenguaje natural. Tesis de Maestría Universidad Nacional de la Plata.
Definición de Requerimientos de Software a Través de Escenarios

utilizando Patrones
Carlos Alberto Cortés Bravo1, María A. Abud Figueroa1, Celia Romero Torres,
1
Ulises Juárez Martínez1, Gustavo Pelaez Camarena ,
1
Instituto Tecnológico de Orizaba, División de Estudios de Posgrado e Investigación,
Av. Oriente 9 No. 852, Orizaba, Veracruz, México
cortesbravocarlos@gmail.com, {mabud, cromero, ujuarez
gpelaez}@ito-depi.edu.mx
Abstract. La definición de los requerimientos de software consiste en la especificación y validación

de las funcionalidades que el sistema a desarrollar debe proporcionar, al igual que las restricciones
que el sistema debe cumplir. Para el análisis de los requerimientos existen varias técnicas, siendo los
escenarios una técnica que permite describir el comportamiento esperado del software en un lenguaje
reconocido por los involucrados con lo que se logra una buena comunicación con el cliente. Por otra
parte, los patrones permiten reutilizar elementos previamente comprobados funcionando como un
registro de experiencias que ayudan a agilizar y mejorar los procesos. En este artículo se presenta una
propuesta para la definición de patrones de escenario que servirán para tener una descripción más
clara de los que se espera del software a desarrollar y que serán la base para un catálogo de patrones
para un dominio especifico.
Keywords: patrones, escenarios, requerimientos de software
1 Introducción
Un punto prioritario en el desarrollo de software es la definición de lo que se quiere producir, ya que el

desarrollo del software inicia hasta el momento en el que se tienen establecidas a detalle las
características del software que se va a desarrollar, situación que es más crítica cuando se trata de
sistemas complejos.
La ingeniería de requisitos es el área de investigación que atiende este punto fundamental en el proceso
de producción, proponiendo métodos, técnicas y herramientas que facilitan el trabajo de definición de lo
que se quiere de un producto de software. Su objetivo es aumentar el conocimiento del dominio del
problema para así representar las necesidades de un cliente en función de una aplicación de software de
una manera adecuada y entendible tanto para los usuarios finales como para el equipo de desarrollo.
Es de suma importancia asegurar una buena comunicación con los clientes y/o usuarios, ya que de ello
depende un futuro éxito o fracaso, porque es en esta parte en donde se recopila todo lo que el futuro
sistema tendrá implementado.
Existen diversas técnicas para documentar los requisitos, como son casos de uso, prototipos, puntos de
vista, escenarios, entre otras. De éstas se reporta como una de las más exitosas los escenarios, ya que
éstos permiten mantener mucha información en una forma que los involucrados reconocen (Ridao, et al
2001). Son muchas las definiciones de la palabra escenario (Ridao, et al. 2001; Sutcliffe, 2003; Hadad, et
al. 1996), una de las cuales es: ―un escenario es una descripción parcial y concreta del comportamiento de
un sistema en una determinada situación‖ (Ridao, 2000).
Por otra parte, los patrones permiten, en diferentes áreas del conocimiento, utilizar soluciones previas a
un problema en nuevas situaciones, ofreciendo un mecanismo de reutilización de experiencia. En este
trabajo, se propone el uso de patrones en la definición de escenarios con el fin de aprovechar las
situaciones recurrentes en la definición de requerimientos, para lo cual se establece un formato para su
definición. En la sección 2 de este artículo se muestra una revisión de diferentes propuestas para la
representación de requerimientos a través de escenarios, posteriormente en la sección 3 se presenta una
propuesta para la definición patrones de escenarios en la definición de requerimientos, finalmente se
presentan las conclusiones.
2 Trabajos Relacionados sobre Definición de Requerimientos
Los requerimientos especifican qué es lo que el sistema debe hacer (funciones) y sus propiedades
esenciales y deseables. La captura y el análisis de los mismos son actividades de mucha importancia para
proporcionar una visión amplia sobre lo que se pretende resolver con el desarrollo de una aplicación de
software.
En la fase de definición de requerimientos, el ingeniero de requerimientos se enfrenta a distintas
dificultades (Hadad et al 1996). La elección de una buena técnica para recopilar requerimientos como el
uso de un lenguaje común, tanto para los desarrolladores como para los clientes y usuarios, es vital para
garantizar un buen proceso de definición y validación de requerimientos. De igual manera es muy
importante comprender el dominio del problema, con lo cual se necesita que el ingeniero de
requerimientos se vuelva experto en el dominio para así comprender de la manera más amplia las
necesidades del cliente, ya que de no ser así es muy probable que se recopilen requerimientos incompletos
y erróneos.
2.1 Lenguaje para Definición de Requerimientos
Capturar el dominio del problema es una de las formas mediante las cuales se garantiza una mejor
compresión en la descripción de un escenario, tanto por clientes como por el equipo de desarrollo. El
vocabulario del UdeD (Universo de Discurso) es el que refleja las palabras peculiares y más usadas en el
mismo (Ridao, et al. 2001). Para la recopilación del conocimiento del UdeD es necesario revisar la
documentación, realizar entrevistas o aplicar otras técnicas. Son diversos los casos donde la construcción
de escenarios se basa en el UdeD como en (Ridao, et al. 2001; Ridao, 2000; Doorn, 2002), con el
propósito de mantener una buena comunicación con el cliente, ya que se logra que el ingeniero de
requerimientos maneje un vocabulario entendible tanto por los integrantes del equipo de desarrollo así
como por los clientes y/o usuarios. Uno de los métodos que permite mantener un leguaje homogéneo para
ambos es el LEL (Léxico Extendido del Lenguaje), el cual es una representación de los símbolos en el
lenguaje del dominio del problema (do Prado Leite. et al. 1997). Combinar el uso de escenarios y el LEL
facilita la compresión por parte de las personas no especializadas en el desarrollo del software (Hadad,
2010).
Los objetivos del LEL son conocer el vocabulario del usuario y contar con un instrumento simple de
trazabilidad (Hadad, et al. 1996). Los elementos para la descripción de un símbolo LEL son: nombre,
noción e impacto; el nombre identifica el símbolo del LEL, la noción indica qué es el símbolo y el
impacto cómo repercute en el sistema. En la Tabla 1 se presenta un ejemplo de un símbolo del LEL que
se construye para un caso de estudio de una biblioteca, en la cual se observa que el nombre que se le da 16
está formado por dos palabras siendo estas sinónimos mediante las cuales se identifica el símbolo
(Kaplan, et al. 2000).
Tabla 1. Ejemplo simbología del LEL.
Las heurísticas que son utilizadas para la construcción del LEL son: identificar fuentes de información,
identificar símbolos, clasificar símbolos, describir los símbolos, verificar el LEL y validarlo. Una vez que
se obtiene el LEL es necesario actualizarlo para obtener la mejor compresión del UdeD. Así como esta
técnica mejora la comprensión del dominio del problema, también es posible que tenga defectos los
cuales surgen cuando no se construye un LEL de manera correcta. Los principales defectos que pueden
contener el LEL son: de descripción, de clasificación, de identificación y de referencia los cuales están
descritos en (Kaplan, et al. 2000).
2.2 Representación de un Escenario
En Ryser (1999) define un procedimiento para la recopilación de los requerimientos y su documentación

a través de escenarios, en el cual destacan 15 pasos para la creación de un escenario:
• Encontrar todos los actores que tengan interacción con el sistema.
• Encontrar todos los eventos relevantes al sistema.

• Determinar entradas, resultados y salidas del sistema.
• Determinar límites del sistema.
• Crear descripciones de escenarios amplias.
• Priorizar los escenarios de acuerdo a la importancia, asegurar que los escenarios cubran
la funcionalidad del sistema.
• Crear una descripción paso a paso de eventos y acciones para cada escenario
• Crear un gráfico general y un diagrama de dependencia.
• Tener opinión y comentarios de los usuarios sobre los diagramas y escenarios.
• Extender escenario al refinar su descripción, dividir las tareas en pasos de trabajo
individuales.
• Flujo de acciones del modelo alternativo, especificar excepciones y cómo reaccionar a
las excepciones.
• Factorizar escenarios abstractos (secuencias de interacciones que aparecen en más de un
escenario).
• Incluir requerimientos no funcionales y cualidades en escenarios.
• Revisar el diagrama de información general y diagrama de dependencia.
• Pedir a los usuarios comprobar y validar los escenarios (revisiones formales).
Para la construcción de un escenario es preciso considerar los elementos por los que este escenario
estará formado. En (Hadad, G et al 1996) se muestran algunos ejemplos de escenarios, en los cuales se
observan los siguientes elementos como parte de un escenario: nombre, objetivo, contexto, recursos,
actores, conjunto de episodios y casos alternativos. En (Hadad, G et al 1997) se propone otra
representación de un escenario que se ilustra como un diagrama E-R y se observa en la Figura 1.
17
Fig. 1. Diagrama Entidad-Relación para la construcción de un escenario
Las propuestas revisadas son muy similares, básicamente tienen los mismos elementos para representar
un escenario. En la Tabla 2 se presenta un ejemplo de un escenario de un caso de estudio ―Sistema
Nacional para la Emisión de Pasaportes (Hadad, et al. 1998).
Tabla 2. Ejemplo Escenario para ―Sistema Nacional de Emisión de Pasaportes‖
Tomando en cuenta los modelos revisados, se propone incluir en la representación de un escenario los
elementos: título, objetivo, acción, recursos, actores, episodios y excepciones, mismos que se representan
en un diagrama de clases UML como se muestra en la Figura 2.
18
Fig. 2. Elementos Escenario
3 Patrones de Escenario
El uso de patrones en la construcción de escenarios permite ahorrar tiempo para la construcción de los
mismos, ofreciendo una visión más estructural de las situaciones, y con esto determinar el tipo de
escenario que corresponda a cada situación. En este sentido existen algunas propuestas como la de
(Ridao 2001), sin embargo ofrecen situaciones muy abstractas y difíciles de utilizar.
En este trabajo se propone el uso de patrones para la representación de escenarios basados en la
notación LEL, compuesto por la siguiente notación:
+ significa composición,
{x} significa cero o más ocurrencias de x,
( ) es usado para agrupamiento,
| significa or, y
[x] denota que x es opcional
El patrón se forma con los siguientes elementos:
 Título
o El título identificará de forma única un escenario para una acción específica del sistema.
o Sintaxis: Frase
 Objetivo
o El objetivo describirá de forma breve que se logra con implementación de este
escenario.
o Sintaxis: [Actor | Recurso] + Verbo + Predicado
 Actores
o Se mencionarán los involucrados que participan en este escenario en particular.
o Sintaxis: Nombre
 Acción
o Describirá la actividad que se ejemplifica este escenario.
o Sintaxis: [Sujeto | Actor | Recuso] + Verbo + Predicado + {Restricción}
 Restricción
o Describirá la situación solo en la que este escenario tendrá lugar (opcional)
o Sintaxis: [Actor | Recurso] + Verbo + Predicado
 Secuencia
o Contendrá los pasos que describen de forma clara los pasos que sigue este escenario,
para llegar a un fin.
o Sintaxis:
<sentencia básica> ::= <sentencia simple> | <sentencia condicional> |
<sentencia opcional>
<sentencia simple> ::= <sentencia episodio>
<sentencia condicional> ::= IF <condición> THEN <sentencia episodio>
<sentencia opcional> ::= [ <sentencia episodio > ]
donde
<sentencia episodio > es descrita como:
(([Actor | Recurso] + Verbo + Predicado) | ([Actor | Recurso] + [Verbo] +
19
Título)) + {Restricción}
 Secuencia Alterna
o En caso de que durante el proceso de esta actividad no se logre completar
satisfactoriamente en este apartado se describirá lo que sucederé en esos casos.
o Sintaxis:
Causa [(Solución)]
donde Causa es:
Frase | ([Sujeto | Actor | Recurso] + Verbo + Predicado)
donde Solución es:
Título
Con base en esta propuesta, en la Tabla 3 se muestra un ejemplo del patrón de escenario Ingreso,
mismo que detalla los pasos a seguir cuando un usuario realiza una acción de acceso al sistema.
Tabla 3. Patrón de Escenario Ingreso
Título Ingreso
Objetivo Un actor ingresa datos de identificación para acceder al sistema
Actores Sólo un actor
Acción El Usuario inicia sesión en el Sistema
Restricción Por lo menos una
Secuencia Por lo menos uno como el siguiente:
 El Actor ingresa datos de identificación para acceder al sistema
 Se verifica que los datos son correctos
DEBEN ESTAR EN SECUENCIA INTERACCIÓN ACTOR Y
SISTEMA
Secuencia Alterna  Circunstancia que obstaculiza el acceso al sistema
La Tabla 4 muestra el caso específico de uso de este patrón para un ingreso donde se solicita a un
usuario su id y contraseña para acceder al sistema.
Tabla 4. Uso del Patrón de Escenario Ingreso

Título Ingreso
Objetivo Un actor ingresa datos de identificación para acceder al sistema
Actores Usuario
Acción El Usuario inicia sesión en el Sistema
Restricción El Usuario debe ser un Usuario Registrado
Secuencia  El Usuario ingresa id y contraseña y selecciona la opción Ingresar
 SI id existe ENTONCES verifica contraseña
 SI contraseña es correcta ENTONCES el sistema verifica
privilegios e inicia sesión
Secuencia Alterna  Id no existe [mensaje de error]
 Contraseña errónea [mensaje de error]
4 Conclusiones
Los escenarios son una técnica que permite mantener una descripción clara y concisa de los
requerimientos, por lo que combinándola con el uso de LEL como la técnica para la construcción de
escenarios, permite tener un proceso más ágil de definición/validación de requerimientos con los
clientes/usuarios y de esta manera evitar la propagación de requerimientos y descripciones incompletas
que pueden llegar a ser interpretadas de múltiples maneras y llevar a errores en la implementación de las
funcionalidades de un software.
Una de las ventajas que tienen los escenarios es que la posibilidad de construirlos a partir de patrones,
de tal manera que es posible reutilizar las soluciones a situaciones similares que se presentan en diversos
proyectos de software. El contar con una representación formal para un escenario facilitará la creación de
un catálogo de patrones que ayude a agilizar y hacer más segura la definición de requerimientos.
En comparación con los trabajos revisados, esta propuesta está enfocada en describir escenarios que
puedan ser útiles para tener una descripción más precisa en cuanto a lo que se espera del software a
desarrollar, cuyas situaciones son recurrentes en casi cualquier sistema de software, en el trabajo de Ridao
(2001) su propuesta describe situaciones muy abstractas y difíciles de reconocer en primera instancia. 20
Como trabajo futuro se propone el desarrollo de un catálogo de patrones de escenarios para un dominio
específico y realizar las pruebas de campo que permitan exponer las ventajas que trae consigo el uso de
un catálogo de patrones para la construcción de escenarios.
Agradecimientos.
El autor corresponsal agradece al Consejo Nacional de Ciencia y Tecnología CONACYT por el apoyo
brindado para la realización de los estudios de postgrado.
Referencias
1. Do Prado Leite, J. C. S., Rossi, G., Balaguer, F., Maiorana, V., Kaplan, G., Hadad, G., & Oliveros, A.
Enhancing a requirements baseline with scenarios. Requirements Engineering, 2(4), 184--198 (1997)
2. Doorn, J. H., Hadad, G. D., & Kaplan, G. N. Comprendiendo el Universo de Discurso Futuro con
Escenarios. In WER, 117--131 (2002).
3. Hadad, Graciela DS., Doorn, Jorge., Kaplan, Gladys. Enfoque middle-out en la Construcción e Integración
de Escenarios, (1998)
4. Hadad, G., Kaplan, G., Oliveros, A., & Sampaio do Prado Leite, J. C. Integración de Escenarios con el
Léxico Extendido del Lenguaje en la elicitación de requerimientos*: Aplicación a un caso real, (1996)
5. Hadad, G.; Kaplan, G.; Oliveros, A.; Leite, J.C.S.P. Construcción del Léxico Extendido del Lenguaje y
derivación de Escenarios para la elicitación de requerimientos, (1997)
6. Hadad, G. D. S. Uso de Escenarios en la Derivación de Software. In XII Workshop de Investigadores en
Ciencias de la Computación, (2010)
7. Kaplan, G. N., Hadad, G. D., Doorn, J. H., & do Prado Leite, J. C. S. Inspección Del Lexico Extendido Del
Lenguaje. In WER, 70—91 (2000)
8. Potts, C., Takahashi, K., & Antón, A. Inquiry-based requirements analysis. IEEE software, 11(2). 21--32
(1994)
9. Ridao, Marcela. Uso de Patrones en el Proceso de Construccion de Escenarios. Workshop de Engenharia de
Requisitos. 140--157 (2000)
10. Ryser, J., & Glinz, M. A scenario-based approach to validating and testing software systems using
statecharts. In Proc. 12th International Conference on Software and Systems Engineering and their
Applications, (1999)
11. Ridao, Marcela. Uso de Patrones en el Proceso de Construcción de Escenarios. Tesis Doctoral. Facultad de
Informática, (2001)
12. Ridao, Marcela and Jorge Doorn., and Julio Cesar Sampaio (2001). Incorporación de Patrones al Proceso de
Construccion de Escenarios. Workshop em Engenharia de Requisitos, Buenos Aires, Argentina, s.f. 107--
123 (2001)
13. Sutcliffe, A. Scenario-based requirements engineering. In Requirements engineering conference,.
Proceedings. 11th IEEE international 320--329 (2003)
14. Toro, A. D., & Jiménez, B. B. Metodología para la Elicitación de Requisitos de Sistemas Software. Informe
Técnico LSI-2000-10. Facultad de Informática y Estadística Universidad de Sevilla. (2000)
21
Proceso basado en patrones de proceso para desarrollar aplicaciones

Web
I.S.C. Ana Cristina Sánchez Hernández1, M.C. María Antonieta Abud Figueroa2, M.C. Gustavo Peláez
Camarena3, Dr. Ulises Juárez Martínez4, M.C. Celia Romero Torres5
División de Estudios de Posgrado e Investigación, Instituto Tecnológico de Orizaba, Orizaba, Veracruz, México.
anacsh24@gmail.com, mabud@ito-depi.edu.mx, sgpelaez@yahoo.com.mx, ujuarez71@gmail.com,
cromerotorres@hotmail.com
Resumen. En la actualidad las aplicaciones Web tienen una importancia creciente y ello ha
evolucionado la manera en que se construyen, ya que por su naturaleza se requiere un desarrollo
rápido. Además su complejidad creciente requiere procesos mejor definidos que aseguran su calidad,
y aunque existen diversas metodologías para el desarrollo Web, la mayoría de éstas se enfoca a las
etapas de análisis y diseño y no consideran todo el ciclo de vida de la aplicación, ni la parte de gestión
y control de calidad. Por otra parte los patrones de proceso permiten reutilizar bloques validados
previamente en el desarrollo de software que aseguran desarrollos de calidad, por lo que en este
trabajo se presenta la propuesta de un proceso basado en patrones de proceso para el desarrollo de
aplicaciones Web, utilizando el meta-modelo SPEM 2.0.
Palabras Clave. Patrones de proceso, meta-modelo, aplicaciones Web.
1 Introducción
Un patrón describe una solución probada que se aplica a un problema que ocurre de manera recurrente y
permite su reutilización adaptándose a diferentes contextos según sea el problema (Alexander, 1979).
Existen diversos tipos de patrones que en la actualidad se aplican en diferentes áreas, entre los cuales se
encuentran los patrones de proceso, que se definen como una colección de técnicas generales, acciones
y/o tareas para desarrollar software orientado a objetos. Scott Ambler clasifica los patrones de proceso en
tres tipos dependiendo de su nivel de abstracción: Fase, Etapa y Tarea. Un patrón de proceso Tarea
representa los pasos detallados para realizar una tarea específica. Un patrón de proceso Etapa representa
los pasos en una sola etapa del proyecto, y a menudo se realiza de manera iterativa. Un patrón de proceso
Fase representa la interacción que existe entre un conjunto de patrones de proceso de etapa que lo
conforman. Ambler presentó un Proceso de Software Orientado a Objetos (OOSP) genérico el cual
incluye los tres tipos de patrones de proceso antes descritos (Ambler, 1998, 1999).
En este artículo se presenta la definición de un proceso que se basa en patrones de proceso para el
desarrollo de aplicaciones Web, el cual se conforma de 4 fases: Inicio, Construcción, Entrega, y
Mantenimiento-Soporte. El proceso se desarrolló con base a una selección previa de los patrones de
proceso que conforman el proceso de software orientado a objetos (OOSP) propuesto por Scott Ambler
(Figura 1), y metodologías para desarrollo Web como UWE y OOHDM, de donde se tomaron las
actividades más comunes e importantes para llevar a cabo todo un proceso de desarrollo de software.
Para la definición del proceso se utilizó el meta-modelo SPEM 2.0 (Software Process Engineering
Metamodel) que se usa para definir procesos de desarrollo de software y sistemas junto con sus
componentes y proporciona un esquema estandarizado para describir procesos de desarrollo administrado
por el OMG (Francisco Ruiz, 2008).
Este documento está estructurado de la siguiente manera, en la sección 2 se presentan trabajos
relacionados con la utilización de patrones de proceso. En la sección 3 se describe el proceso planteado
para la generación de aplicaciones Web. En la sección 4 se presentan las conclusiones y finalmente en la
sección 5 el trabajo a futuro.
Fig. 1 Proceso de software orientado a objetos
2 Trabajos relacionados
En (Xiang-xi Meng, 2007) se menciona que a pesar de que existe gran variedad de casos exitosos en el
uso de métodos ágiles, dado que cada proyecto de software es único es difícil definir una serie de
procesos universales y repetibles para todos los proyectos ágiles. Por ello, se propuso un lenguaje que se
basa en patrones de proceso para métodos de desarrollo ágil. PPL (Process Pattern Language, Lenguaje
de Patrones de Proceso) se basa en dos metodologías ágiles, XP (eXtreme Programming, Programación
Extrema) y SCRUM, combinando el proceso de desarrollo de ambas metodologías para generar un
modelo de proceso ágil apropiado para diferentes proyectos en diferentes organizaciones.
En (Mohsen Asadi, 2009.) se menciona la poca flexibilidad que proporcionan las metodologías de
desarrollo tradicionales ya que no proveen el soporte necesario para el desarrollo de proyectos de sistemas
modernos, lo cual conlleva a cambiar de metodología entre un proyecto y otro. Por ello propusieron el
proceso de ingeniería de métodos situacional (SMEP) como marco de trabajo que se basa en patrones de
proceso para generar procesos SME (Situational Method Engineering, Ingeniería de Métodos Situacional) 23
a la medida.
En (Tran, 2007) se mencionó que aplicar patrones de proceso tiene como principales objetivos dar a
conocer las mejores prácticas de los procesos y reducir el tiempo de modelado de éstos. La problemática
que se abordó es que aunque existen diversos intentos para formalizar a los patrones de proceso, ninguno
cumple totalmente con todos los requerimientos que se mencionan anteriormente, es por esta razón que
presenta un meta-modelo de procesos que se basa en UML y permite una representación explícita de
patrones de proceso en los modelos de procesos. Lo novedoso de la propuesta es que permite la
aplicación de diferentes tipos de procesos no solo para construir sino también para mejorar los modelos
de procesos.
La principal aportación de los patrones de procesos es reducir tiempo y esfuerzo en el desarrollo de
software mediante la reutilización de procesos de desarrollo ya existentes. Como se observa este tipo de
patrones tienen diferentes usos. Sin embargo no existen trabajos que reporten un proceso basado en estos
patrones que sirva para el desarrollo de aplicaciones Web.
3 Proceso
En esta sección se presenta el proceso propuesto basado en patrones de proceso para desarrollar
aplicaciones Web. Se tomó como base los patrones propuestos por Scott Ambler (Tabla 1), eligiendo las
actividades más adecuadas para el caso de las aplicaciones Web, complementado la definición con los
patrones de diseño de Gamma para la parte de diseño.
3.1 Elementos del proceso
La idea central del proceso se basa en tres elementos básicos: rol, producto de trabajo y tarea (Figura 2).
Las tareas representan el esfuerzo a hacer, los roles representan quién lo hace y los productos de trabajo
representan las entradas que se utilizan en las tareas y las salidas que se producen. La idea central
subyacente consiste básicamente, en decir quién (rol) realiza qué (tarea) para, a partir de unas
entradas (productos de trabajo), obtener unas salidas (productos de trabajo) (Francisco Ruiz, 2008).
Fig.2 Idea básica de proceso SPEM 2.0
Tabla 1. Patrones de proceso propuestos por Scott Ambler.

Patrón de proceso
Descripción
propuesto por Scott Ambler
Initiate El objetivo principal de este patrón es poner las
bases para un proyecto exitoso. Se compone de la
definición y validación de los requerimientos, la
administración de documentos, la justificación y
definición de la infraestructura del proyecto.
Construct Este patrón se concentra en la construcción de la
aplicación de manera que sea fácil de mantener y de
mejorar. Incluye tareas de modelado, programación,
pruebas unitarias y reutilización.
Deliver Se enfoca en proporcionar al cliente una
aplicación que se haya desarrollado con un trabajo
de alta calidad y que se encuentre bien documentada.
Se basa en realizar pruebas, mejorar los defectos, y
en la liberación del sistema poniéndola a disposición
de los usuarios y capacitándolos.
Maintenance and Support Su objetivo es mantener la aplicación en 24
funcionamiento y lo más actualizada posible. Es
decir, que se atienden las necesidades de los usuarios
proporcionando capacitación, dando respuesta a sus
dudas y reparando cualquier problema que se
presente.
3.2 Roles
A continuación se definen los roles técnicos y el perteneciente a la parte del cliente. Es importa
mencionar que roles como ingeniero de requisitos, administrador del proyecto, programador, diseñador,
ingeniero de pruebas y técnico de soporte, tendrán la tarea de realizar los documentos que sean necesarios
de acuerdo a los productos de trabajo que se definieron.
Jefe del proyecto. Se encarga de dirigir el proyecto, asegurándose que cada actividad, tarea y producto de
trabajo se realice de manera correcta. Las tareas que desempeña este rol se muestran en la Figura3.
Fig.3 Jefe de proyecto

Ingeniero de requisitos. Recolecta toda la información necesaria que el cliente proporciona para el
desarrollo de la aplicación. Las tareas que desempeña este rol se muestran en la Figura 4.
Fig.4 Ingeniero de requisites
Administrador del proyecto. Es el encargado de elaborar todos los documentos administrativos del
proyecto. Las tareas que desempeña este rol se muestran en la Figura 5.
Fig.5 Administrador del proyecto
Programador. Es el encargado de construir la aplicación de acuerdo con las especificaciones dadas en

los requisitos que el cliente proporcionó. También realiza las mejoras de los defectos que la aplicación
necesite. Las tareas que desempeña este rol se muestran en la Figura 6.
25
Fig.6 Programador
Diseñador. Analiza los requisitos y en base a ellos elabora los modelos que permitirán observar con más
detalla cómo estará constituida y estructurada la aplicación. Las tareas que desempeña este rol se
muestran en la Figura 7.
Fig.7 Diseñador
Ingeniero de pruebas. Realiza las pruebas que son necesarias para verificar la correcta funcionalidad de
la aplicación y documenta todo a través de reportes. Las tareas que desempeña este rol se muestran en la
Figura 8.
Fig.8 Ingeniero de pruebas
Técnico de soporte. Es el encargado de recibir, analizar y proporcionar una solución a las solicitudes de
soporte que el cliente requiere. Las tareas que desempeña este rol se muestran en la Figura 9.
Fig.9 Técnico de soporte
Usuario final. Es el cliente que se encarga de aportar la información necesaria sobre qué es lo que espera
y cómo quiere interactuar con la aplicación Web. Las tareas que desempeña este rol se muestran en la
Figura 10.
Fig.10 Usuario Final
3.3 Fases del proceso
En esta sección se explicarán a detalle las fases que conforman el proceso de desarrollo de aplicaciones
Web, cada una de las cuales se conforman de actividades que a su vez contienen tareas y productos de
trabajo. El proceso consta de cuatro fases principales: inicio, construcción, y mantenimiento-soporte, de
las cuales las fases de construcción y entrega son iterativas (Figura 11).
Fig.11 Fases del proceso

26
3.3.1 Fase de Inicio
La fase de inicio tiene como objetivo obtener información proveniente del cliente para detectar los
requerimientos para la construcción de la aplicación, así como preparar los documentos que permitan una
mayor organización para lograr el éxito del proyecto. Las actividades propuestas en esta fase se
seleccionaron del patrón de proceso Initiate (Inicio) propuesto por Scott Ambler (Figura 12) y se detallan
a continuación:
Fig.12 Fase de inicio
Definir y validar requerimientos. Determina exactamente las características del software que se
entregará al usuario final, para ello se realizan una serie de actividades con el fin de recolectar, definir y
validar los requisitos que indiquen qué características tendrá la aplicación a desarrollar. Las tareas a
realizar son:
 Definición de requerimientos. El jefe del proyecto y el ingeniero de requisitos se citan con el
cliente para realizar una serie de entrevistas que permitan obtener la mayor cantidad de
información para determinar los requerimientos de la aplicación que se quiere desarrollar.
 Documentación de requerimientos. El ingeniero de requisitos realiza un documento de
requerimientos donde especifica cada uno de los requerimientos del sistema.
 Validación de requerimientos. El ingeniero de requisitos, el jefe del proyecto y el cliente se
reúnen en varias ocasiones según se requiera con el fin de realizar un análisis para verificar los
requerimientos que se tienen, para evitar se olvide algún requisito o que no se haya comprendido
con claridad.
El producto de trabajo generado es:
 Documento de requerimientos. Especificación a detalle de los requerimientos acordados con el
cliente.
Definir documentos de administración. En esta etapa se crean documentos importantes que permiten la
administración adecuada del proyecto. Las tareas a realizar son:
 Elaboración del plan del proyecto. El jefe del proyecto y el documentador realizan un
documento formal y aprobado el cual se usará para guiar, controlar y ejecutar el proyecto.
 Elaboración del plan de evaluación de riesgos. El jefe del proyecto y el documentador evalúan
e identifican los posibles riesgos que surgirán durante el desarrollo del proyecto y plantean
medidas de solución. El objetivo es identificar los riesgos para que tengan un impacto mínimo en
el proyecto y así evitar pérdidas de tiempo y dinero.
 Elaboración del plan de aseguramiento de la calidad. El jefe del proyecto y el documentador
identifican las técnicas y procedimientos que se emplearán en las actividades de prueba y
aseguramiento de la calidad
Los productos de trabajo generados son:
 Plan del proyecto. Documento que permite organizar todos los componentes que conforman un
proyecto.
 Plan de evaluación de riesgos. Documento en donde se definen los posibles riesgos del
proyecto, su prioridad y la tasa de impacto que tendrá, así como posibles alternativas de
solución.
 Plan de aseguramiento de la calidad. Documento que describe las políticas y procedimientos
de prueba que serán empleadas.
Justificación. Se conforma de un estudio de factibilidad y por la identificación de posibles riesgos que

puedan surgir durante el desarrollo del proyecto. Las tareas a realizar son:
 Realización del estudio de factibilidad. El administrador del proyecto es el encargado de
realizarlo, con el fin de comparar diversas alternativas de implementación basándose en la
factibilidad técnica, económica y operacional que se tenga. De acuerdo con los resultados que se
obtengan se selecciona la alternativa que mejor convenga.
 Identificación de riesgos. El administrador del proyecto identifica y define los riesgos posibles
que fueron encontrados durante el estudio de factibilidad técnica y operacional del proyecto, los
cuales se agregan al documento de riesgos.
 Documento de estudio de factibilidad. Describe los resultados del estudio de factibilidad. 27
 Documento de riesgos. Describe los posibles riesgos y sus soluciones.
Definir infraestructura. Se define la infraestructura necesaria para el desarrollo de la aplicación: las

herramientas de desarrollo, el equipo de trabajo, entre otras. Las tareas a realizar son:
 Definición del equipo del proyecto. El administrador del proyecto/ingeniero de infraestructura
selecciona a las personas que formarán parte del equipo de desarrollo de acuerdo a sus
habilidades, asignando a cada una su rol y las responsabilidades que tendrá dentro del desarrollo
del proyecto.
 Adaptación del proceso de software. Se seleccionan y definen los procedimientos y
metodologías que se deberán seguir para que los miembros del equipo de desarrollo sepan qué es
lo que harán y cómo se realizará, con el fin de aumentar la eficacia del equipo del proyecto.
También se seleccionan y definen los estándares y directrices que se aplicarán en el proyecto
para asegurar consistencia y mantenibilidad.
 Definición de herramientas. Antes de comenzar la fase de construcción se necesita seleccionar
la herramienta que se utilizará para el modelado, la documentación, la administración del
proyecto, entornos de programación, de soporte y de prueba.
 Documento de infraestructura. Tiene una descripción de las personas involucradas en el
proyecto, cuáles serán los roles y qué responsabilidades tendrán, así como las herramientas de
apoyo para el desarrollo
3.3.2 Fase de Construcción
La fase de construcción se compone de tres etapas, así como una serie de iteraciones para el desarrollo de
cada parte de la aplicación Web y al final se define un hito que permite verificar si los objetivos se
cumplieron. Se basa en el patrón de proceso Construct (Construcción) propuesto por Scott Ambler
(Figura 13) y consta de las siguientes actividades:
Fig.13 Fase de construcción
Modelado. Se crean diversos modelos con base en los requerimientos que permiten al desarrollador una
mejor compresión de lo que realmente se desea construir. Las tareas a realizar son:
 Diseño del modelo de requerimientos. El diseñador con base en los requisitos identifica los
actores que participarán en el uso de la aplicación Web así como las funciones a las que tendrá
acceso cada uno.
 Diseño del modelo conceptual. Consiste en el diagrama de clases que representa los datos del
dominio que se usan en la aplicación.
 Diseño del modelo de presentación. El diseñador define cómo se verá estructurada la
aplicación Web, es decir, crea las interfaces de usuario que se mostrarán. Se sugiere utilizar los
patrones de diseño de interfaz de usuario, los cuales permiten un buen diseño de interfaz.
 Diseño del modelo de navegación. El diseñador define la forma en cómo el usuario navegará a
través de la aplicación Web.
 Definición de la tecnología a utilizar. Determinar qué tecnología se utilizará para el desarrollo
de la aplicación Web.
 Modelo de requerimientos. Permite representar los elementos que formarán parte de la
aplicación Web, así como la relación que existirá entre ellos.
 Modelo conceptual. Permite representar las clases con los elementos que formarán parte de la
aplicación.
 Modelo de presentación. Permite representar la forma en que se presentará la información al
usuario, así se tiene una mejor comprensión y se especifica cómo los actores interactuarán con la
aplicación.
 Modelo de navegación. Permite representar la navegación a páginas relacionadas a través de 28
asociaciones o enlaces hipertextuales.
 Tecnología. Engloba el lenguaje de programación, servidor de base de datos, y cualquier
tecnología a utilizar para el desarrollo de la aplicación Web.
Programación. Se genera el código fuente para el desarrollo de la aplicación Web y su respectiva

documentación. Aquí se desarrolla la tarea:
 Codificación y documentación. El programador con base en los requisitos, y los modelos que
se diseñaron anteriormente, construye la aplicación Web haciendo uso de la tecnología de
programación que se seleccionó, así como también se genera la documentación necesaria para el
usuario. En esta etapa se sugiere utilizar patrones de diseño propuestos por Gamma.
 El producto de trabajo es:
 Código Fuente Documentado. Es un conjunto de instrucciones que engloban la funcionalidad
de la aplicación incluyendo información detallada.
 Pruebas unitarias. Se enfoca en la verificación, validación y prueba de documentos, modelos y
código fuente que se generó durante cada iteración. Las tareas a realizar son:
 Realización de pruebas. El ingeniero de pruebas realiza una serie de pruebas necesarias para
verificar que los artefactos desarrollados funcionen bien de acuerdo a lo que el usuario necesita,
y documenta lo que salió mal, sugiriendo su solución.
 Realización de correcciones. El programador, con base al reporte de pruebas, corrige los
errores que se presentaron y se verifica nuevamente que todo funcione de manera correcta.
 Reporte de pruebas unitarias. Documenta todos los detalles de las pruebas que se realizan a la
aplicación Web.
3.3.3 Fase de Entrega
La fase de entrega permite ajustar los últimos detalles del producto para asegurar que al ser implementado
funcionará de manera adecuada para satisfacer las necesidades del cliente. Consta de un conjunto de
iteraciones que permiten unir una parte nueva con lo que ya se desarrolló anteriormente para verificar su
funcionamiento hasta concluir con una entrega final, también de milestones (hitos) que permiten
visualizar que los objetivos de la iteración se cumplieron, así como de las siguientes actividades, las
cuales fueron seleccionadas del patrón de proceso Deliver (Entrega) propuesto por Scott Ambler (Figura
14).
Fig.14 Fase de entrega
Pruebas de integración. Se junta lo que se desarrolló durante la iteración con lo que ya funciona de la
liberación anterior, para después realizar una serie de pruebas para verificar que funciona correctamente.
Las tareas a realizar son:
 Integración de módulos. El programador integra el módulo que se desarrolló durante la
iteración con lo que ya se tiene de liberaciones anteriores.
 Realización de pruebas del sistema. El ingeniero de pruebas realiza una serie de pruebas a la
aplicación Web para determinar las capacidades de la aplicación y resolver los problemas antes
de pasar a las pruebas de usuario.
 Realización de pruebas de usuario. El usuario realiza un proceso de pruebas con el fin de
verificar que la aplicación satisface sus necesidades.
 El producto de trabajo generado es:
 Reporte de pruebas de integración. Documenta todos los detalles de las pruebas que se
realizan a la aplicación Web.
 Mejora. Se reparan defectos críticos que se detectaron en la etapa de pruebas de integración.
Consta de las siguientes tareas:
 Priorización de defectos. El ingeniero de pruebas analiza los defectos que se encontraron
durante la etapa de pruebas de integración y los enlista de acuerdo a la prioridad que requieren
para ser resueltos, de manera que se reparen a tiempo antes de que generen un gasto mayor
después. 29
 Reparación de defectos. El programador se encargará de dar solución a los defectos según su
prioridad. Antes de realizar estos cambios, se realizará un análisis de impacto, para determinar
las posibles afectaciones al hacer el cambio. Con base a los resultados de este análisis, se
realizarán las modificaciones que necesite la aplicación, en dónde se actualizarán los modelos,
código fuente, documentación y se realizará otra vez pruebas unitarias.
 Reporte de mejora defectos. Enlista los defectos que se encontraron con base a su prioridad y la
descripción detallada de cada uno.
Liberación. Se entrega la liberación de una iteración hasta llegar a la entrega final de la aplicación Web,
la documentación correspondiente y dar la capacitación necesaria al usuario. Las tareas a realizar son:
 Preparación de la liberación. El administrador y jefe del proyecto se aseguran y preparan todo lo
necesario (documentos, aplicación, etc.) para realizar la entrega al cliente.
 Liberación a la comunidad de usuarios. El jefe del proyecto se encarga de realizar la entrega
formal de la aplicación al cliente para su implantación.
 Aplicación Web. Producto funcionalmente terminado que cuenta con las características que el
cliente solicitó.
 Manual del usuario. Documento dirigido al usuario final que explica el funcionamiento de la
aplicación, desde su instalación hasta cómo se utiliza en general.
3.3.4 Fase de Mantenimiento-soporte
La fase de mantenimiento-soporte es la fase final del proceso e involucra la identificación de defectos y la

corrección de los mismos una vez que el producto está implementado, de manera que se mejore y
optimice la aplicación. Consta de las siguientes actividades, las cuales fueron seleccionadas del patrón de
proceso Maintenance and Support (Mantenimiento-soporte) propuesto por Scott Ambler (Figura 15).
Fig.15 Fase de mantenimiento-soporte
Soporte. Se da respuesta a las solicitudes entrantes provenientes de los usuarios, para identificar una
solución a la solicitud y después supervisar la implementación a esa solución. Las tareas a realizar son:
 Respuesta a una solicitud. El técnico de soporte recibe una solicitud de un usuario el cual
necesita que le brinden soporte para resolver un problema a la brevedad posible.
 Determinación de la resolución. El técnico de soporte trabajará en conjunto con el usuario
solicitante con el fin de determinar una solución para el problema.
 Resolución del problema. Una vez que se tiene una estrategia de solución, el técnico en soporte
guiará al usuario para implementar la solución con el objetivo de resolver el problema actual.
 Solución. Es la respuesta que se le da a un problema para que funcione adecuadamente el
elemento que lo presenta.
 Solicitud de cambio de software (SCR). Descripción de una mejora al software. Las solicitudes
se envían a la etapa de identificar defectos y mejores para que se traten esos cambios.
Identificar defectos y mejoras. Se analizan las solicitudes de cambio de software que se definieron en la
etapa de soporte de modo que esos cambios se identifican y se asignan a los elementos de configuración
apropiados. Las tareas a realizar son:
 Análisis de peticiones de cambio de software. Se analizan las solicitudes que se tienen y se
identifica si se trata de un defecto o de una mejora. Para ello se tienen cuatro categorías para
mantenimiento de cambios: preventivo y correctivo que se usan para defectos, y adaptativo -
perfectivo para mejoras.
 Priorización de mantenimiento. Después de que se ya se identificó si se dará mantenimiento a
la aplicación por defecto o por mejora, se les asigna prioridad. Existen tres maneras de priorizar:
emergencia, urgente y regular.
 Asignación de cambios de mantenimiento a los elementos de configuración. Se realizan los 30
cambios de acuerdo a su prioridad.
El producto de trabajo que se genera es:
 Reporte de mantenimiento-soporte. Documento que engloba una descripción de los problemas
de software que se identificaron y de los cambios que se realizarán.
4. Conclusiones
El uso de patrones de proceso en el desarrollo de software proporciona un beneficio ya que permiten

reutilizar actividades que fueron probadas y tuvieron resultados de éxito en situaciones similares, lo que
tiene como ventaja un desarrollo rápido, disminuyendo el riesgo de fracaso en los proyectos.
En la actualidad no se reporta un proceso basado en patrones de proceso para desarrollar aplicaciones
Web, por ello el presente documento presentó la definición de un proceso el cuál se basa en el conjunto
de patrones de proceso propuesto por Scott Ambler. Consta de cuatro fases principales, así como sus
etapas, tareas y productos de productos de trabajo respectivos que se definieron como parte del proceso de
desarrollo para aplicaciones Web, el cual fue creado con base al meta-modelo SPEM 2.0 y de acuerdo a la
selección de un conjunto de patrones de proceso que se consideraron importantes para el ciclo de vida de
desarrollo de aplicaciones Web. También se especifica cada uno de los roles que participan en este
proceso y sus responsabilidades.
5. Trabajo a futuro
Se trabaja en un caso de estudio para validar el proceso de desarrollo propuesto. Se desarrolla una
aplicación Web que automatice el proceso de residencias profesionales que se llevan a cabo en el
departamento académico de sistemas y computación del Instituto Tecnológico de Orizaba. Actualmente
se está trabajando en la etapa de modelado de la fase de construcción, refinando detalles del modelo
conceptual, de navegación y presentación.
Como trabajo futuro se seguirá trabajando en las siguientes fases y etapas de desarrollo del caso de
estudio, con el fin de evaluar que las actividades que se definieron sean las necesarias para el desarrollo
de aplicaciones Web.
6. Referencias
Alexander, C. (1979). The Timeless Way of Building. Oxford University Press, New York.
Ambler, S. W. (1999). More process patterns: building large-scale systems using object technology. Cambridge
UniversityPress.
Ambler, S. W. (1998). Process patterns: building large-scale systems using object technology. Cambridge University
Press.
Gamma Erich et al (2009). Patrones de diseño. Pearson Addison Wesley,
Mohsen Asadi, R. R. (2009.). "Method engineering process patterns.". Proceedings of the 2nd India software
engineering conference.New York, USA: ACM. , 143-144.
Ruiz Francisco, J. V. (2008). ―Guía de Uso de SPEM 2 con EPF Composer‖.
Tran, H. C. (2007). "Modeling Process Patterns and Their Application.". Software Engineering Advances, ICSEA. ,
25-31.
Xiang-xi Meng, Y.-s. W.-J. (2007). "A Process Pattern Language for Agile Methods.". Software Engineering
Conference, APSEC. , 374 - 381.
31
Evaluación Heurística de Herramientas de Composición de

Componentes Centrada en el Usuario Final
Yadira Jarvio Hernández1, Perla Velasco-Elizondo2 y Edgard Benítez-Guerrero1

1
Universidad Veracruzana, Facultad de Estadística e Informática, Xalapa, VER, 91020, México.
2
Universidad Autónoma de Zacatecas, Unidad Académica de Ingeniería, Ciudad Universitaria Siglo XXI,
Zacatecas, ZAC, 98000, México.
zs13015663@estudiantes.uv.mx, pvelasco@uaz.edu.mx, edgardibenitez@gmail.com
Resumen. Cada vez más personas realizan diversas tareas apoyándose de sistemas de software que
son construidos a partir de la composición de componentes. A pesar de la popularidad del desarrollo
centrado en composición y las herramientas existentes para soportarlo hay evidencia sobre que el uso
de éstas sigue siendo complicado. Sin embargo, existe poca evidencia que permita comprender esta
problemática en un contexto de usuarios finales. En este trabajo se realiza una evaluación heurística
de herramientas de composición de componentes centrada en el usuario final. Una contribución
importante de esta evaluación es que considerando un conjunto de aspectos intrínsecos al desarrollo
centrado en composición y a los usuarios finales, se identifican un conjunto de heurísticas relevantes
para detectar problemas generales de usabilidad. Las heurísticas y los problemas identificados
proveen una base de conocimiento que puede ser extendida en dominios específicos de aplicación
para mejorar el diseño de herramientas de composición.
Keywords: evaluación heurística, composición de componentes, usuarios finales.
1 Introducción
Muchas personas realizan diversas tareas apoyándose de sistemas de software que son construidos a partir
de la composición de componentes. En términos generales, un componente es un elemento de software
pre-existente que implementa alguna funcionalidad, la cual puede ser accedida a través de interfaces bien
definidas (Sommerville, 2006). Los COTS (Commercial Off-The-Shelf) (Morisio, Seaman, Basili, Parra,
Kraft, & Condon, 2002), los Servicios Web (Cauldwell, Chawla, & Chopra, 2002), los Mashlets
(Abiteboul, Greenshpan, & Milo, 2008) o las (Web) APIs son ejemplos de componentes en estos
sistemas.
Enfoques de desarrollo como el Desarrollo Basado en Componentes (Sommerville, 2006), las Líneas
de Productos de Software (Clements & Northrop, 2001), la Arquitectura Orientada a Servicios (Erl, 2005)
o más recientemente las arquitecturas de micro servicios (Fowler, 2014) han adquirido popularidad puesto
que soportan el desarrollo de sistemas de software usando un enfoque centrado en la composición.
Actualmente existen diversas herramientas y (repositorios de) componentes en dominios específicos que
facilitan el desarrollo de sistemas bajo este enfoque.
La disponibilidad de herramientas y (repositorios de) componentes ha contribuido a que nuevas
comunidades de usuarios incursionen en el desarrollo de este tipo de sistemas. Un ejemplo es la
comunidad de usuarios finales (Mehandjiev, Namoune, Wajid, Macaulay, & Sutcliffe, 2010), (Garlan,
Dwivedi, Ruchkin, & Schmerl, 2012), (Roy Chowdhury, 2012). En términos generales este tipo de
usuarios y los sistemas que construyen presentan las siguientes características:
a. Son inexpertos en materia de desarrollo de sistemas y, generalmente, expertos en algún dominio
profesional.
b. Soportan sus tareas diarias mediante sistemas de software que ellos mismos construyen a partir de la
composición de componentes de software que son provistos por terceras partes.
c. Los sistemas que construyen tienen una arquitectura ―data-flow‖ (Taylor, Medvidovic, & Dashofy,
2009).
Ejemplos de estos usuarios incluyen a sociólogos realizando análisis de influencia en redes sociales
(Knoke & Yang, 2008) con scripts que usan las APIs de Twitter (Twitter, 2015) e igraph para R (Team,
2015) o biólogos realizando análisis de cadenas de proteínas con workflows creados con la herramienta
de composición Taverna (School of Computer Science, 2010) y servicios Web en BioCatlogue (Bhagat,
et al., 2010).
A pesar de la popularidad del desarrollo centrado en composición y las herramientas existentes para
soportarlo hay evidencia sobre que el uso de éstas sigue siendo complicado. Sin embargo, existe muy
poco material que permita comprender esta problemática en un contexto de usuarios finales. En este
trabajo se describe una evaluación heurística de herramientas de composición de componentes para
detectar problemas generales de usabilidad relevantes al contexto de un usuario final. En contraste con
trabajos relacionados, una contribución importante de esta evaluación es que se usaron heurísticas que
fueron identificadas considerando un conjunto de aspectos intrínsecos al desarrollo centrado en
composición y a los usuarios finales. Las heurísticas y los problemas identificados proveen una base de
conocimiento inicial que puede ser extendido en dominios específicos para mejorar el diseño de
herramientas de composición.
El artículo está organizado como sigue. La sección 2 discute trabajos relacionados al tema de este
artículo. En la sección 3 se describen los detalles de la evaluación realizada. En la sección 4 se muestran
los resultados obtenidos de la evaluación. Finalmente, en la sección 5 se presentan las conclusiones y
posibles líneas de trabajo futuro.
2 Trabajos Relacionados
En el contexto de la Ingeniería de Software la usabilidad es un atributo de calidad que tiene que ver con
la facilidad de uso de un sistema de software. Existen diversas definiciones de usabilidad. Sin embargo,
dos ampliamente adoptadas son las provistas por los estándares 9241 y 9216 de la ISO/IEC. El estándar
ISO/IEC 9241 define usabilidad como ―el grado en el que un producto puede ser utilizado por usuarios
específicos para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un
determinado contexto de uso‖ (ISO/IEC 9241-11, 1998). Similarmente, en el estándar ISO/IEC 9126 la
usabilidad se define como ―la capacidad de un software de ser comprendido, aprendido, usado y ser
atractivo para el usuario, en condiciones específicas de uso‖ (ISO/IEC 9126, 1992).
La usabilidad se evalúa considerando un conjunto de características. No hay un consenso sobre el
conjunto de características que deben ser consideradas. Sin embargo, características como eficiencia,
facilidad de aprendizaje, reconocimiento antes que recuerdo, manejo de errores y satisfacción subjetiva
son comunes en varios estándares y modelos de calidad (Seffah, Donyaee, B. Kline, & K. Padda, 2006).
En el pasado se han realizado evaluaciones relacionadas al desarrollo centrado en composición. Por
ejemplo, evaluaciones de métodos y lenguajes para realizar la composición de componentes como BPEL,
OWL-S, autómatas, redes de Petri, Álgebras de Procesos, (Beek, Bucchiarone, & Gnesi, 2006), (ter Beek,
Bucchiarone, & Gnesi, 2007), (Feenstra, Janssen, & Wagenaar, 2007), (Baryannis & Plexousakis, 2010),
(Portchelvi, Prasanna Venkatesan, & Shanmugasundaram, 2012). Igualmente se han reportado resultados
de evaluaciones de herramientas de composición en trabajos como (Minhas, Sampaio, & Mehandjiev, 33
2012), (Insfran, Cedillo, Fernández, Abrahão, & Matera, 2012), (Yeltayeva, 2012). Todas estas
evaluaciones reportan problemas relevantes. Sin embargo, la principal limitación de estas evaluaciones es
que no consideran a los usuarios finales como usuarios potenciales de estas herramientas.
Por otra parte trabajos como (Zhao, Bhattarai, Liu, & Crespi, 2011), (Malinga, Gruner, & Koschmider,
2013) reportan resultados de evaluaciones a herramientas de composición para usuarios finales. Aunque
se reportan problemas relevantes, estas evaluaciones presentan dos limitaciones importantes: son
evaluaciones de una sola herramienta lo cual hace difícil el determinar si los problemas detectados se
presentan en otras y, las evaluaciones no consideran ambos aspectos intrínsecos al desarrollo centrado en
composición y a los usuarios finales. La Tabla 1 describe estos aspectos.
Tabla 1. Aspectos intrínsecos al desarrollo centrado en composición y a los usuarios finales, que impactan en la
usabilidad de herramientas de composición de componentes cuando son utilizadas por usuarios finales.
Aspecto Descripción
Selección de componentes Existen muchos componentes con las mismas características. Al momento
disponibles de realizar una composición se debe realizar la selección de un subconjunto
particular que satisfaga las características funcionales requeridas, e.g.,
traducir a español. Idealmente esta selección debería ser asistida.
Detección de incompatibilidades Los componentes son desarrollados por diferentes fabricantes y podrían
entre componentes presentar incompatibilidades al momento de su composición, e.g., formato o
semántica de los datos que intercambian. Idealmente, estas incompatibilidades
deberían ser detectadas y resueltas automáticamente durante el proceso de
composición.
Estimación de calidad de servicio Cada componente define individualmente valores de atributos de calidad
de la composición de servicio, e.g., desempeño, disponibilidad. La calidad servicio del sistema
resultante es relevante e, idealmente, debería ser estimada automáticamente
durante el proceso de composición.
Uso de un lenguaje de bajo nivel El usuario final no tiene conocimiento técnico profundo sobre desarrollo de
de abstracción sistemas. Por ello, se preferiría en las herramientas de composición el uso de
un lenguaje poco técnico y con un alto nivel de abstracción.
3 Descripción de la Evaluación
En las siguientes secciones se describen los detalles de la evaluación.
3.1 Selección de Herramientas
La selección de herramientas de composición se inició con una búsqueda en fuentes bibliográficas y sitios
web. Producto de esta búsqueda se obtuvo información sobre 23 herramientas. Posteriormente, se realizó
un análisis de esta información para conservar solamente las herramientas que soportaran lo siguiente:1
1. Acceso a servicios pre-existentes (SP). Que permitan acceder a componentes pre-existentes provistos
por terceras partes; esto es porque generalmente los usuarios finales no desarrollan sus propios
componentes y tienden a utilizar componentes pre-existentes.
2. Facilidades “drag and drop” (DD). Que provean un ambiente gráfico de composición de
componentes con facilidades ―drag and drop‖; esto es porque se considera que este tipo de
facilidades permite de forma práctica y poco técnica seleccionar y ensamblar componentes.
3. Composiciones con una arquitectura “data-flow” en la forma de “worfklows” o “mashups” (WM).

Que permitan construir composiciones de este tipo; esto debido a que generalmente los usuarios
finales construyen sistemas de este tipo.
4. Disponibilidad de la herramienta (DI). Que se encuentren disponibles actualmente y no sean

propietarias.
La Tabla 2 muestra las 23 herramientas indicándose el soporte o no soporte de los criterios listados
anteriormente con los símbolos  y  respectivamente. Como se puede apreciar las únicas herramientas
que cumplen con los criterios son las siguientes: 1. Apache ODE, 3. BonitaSoft, 12. LONI Pipeline, 20.
Taverna, 21. Wave Maker, 22. Yahoo Pipes!
34
Tabla 2. Herramientas consideradas en la evaluación.
# Nombre Características
S D W D
D D D I
1 Apache ODE, (Apache, 205).    
2 Apatar, (Apatar, 2014).    
3 BonitaSoft, (Bonitasoft, 2015).    
4 Dapper, (Al Sarraj, 2014).    
5 Enhyndra Shark, (Together Teamsolutions Co., 2011).    
6 Google Mashup, (Al Sarraj, 2014).    
7 Intel Mash Maker, (Al Sarraj, 2014).    
8 Jaw Flow, (Garcês, De Jesus, Cardoso, & Valente, 2009).    
9 JBoss, (RedHat, 2014).    
10 JackBe, (Al Sarraj, 2014).    
11 JOpera, (JOpera.org, 2013).    
12 LONI Pipeline, (Laboratory, 2015).    
13 Marmite, (Patel , Na , Latih, Wills, Shukur , & Mull, 2010).    
14 Microsoft Popfly, (Al Sarraj, 2014).    
15 OpenKapow, (Kapow, 2015).    
16 Potluck, (Al Sarraj, 2014).    
17 QedWiki, (Patel , Na , Latih, Wills, Shukur , & Mull, 2010).    
18 RSSBus, (RSSBus, 2014).    
19 RUNA WFE, (RunaWFE, 2013).    
20 Taverna, (School of Computer Science, 2010).    
21 Wave Maker, (Muñoz Jiménez, 2010), (WaveMaker, 2014).    
22 Yahoo Pipes, (Yahoo!, 2014).    
23 YAWL, (Garcês, De Jesus, Cardoso, & Valente, 2009).    
1 Estos criterios fueron establecidos por los autores considerando principalmente las características de los usuarios finales
descritas en la Sección 1.
3.2 Composición Realizada
Para evaluar estas herramientas se consideró un sistema, creado a partir de la composición de

componentes de software, que debe automatizar lo siguiente: Se desea obtener una lista de comentarios de
Twitter. Dichos comentarios deben estar ordenados por fecha de forma ascendente y traducidos al
español. Además se necesita que la composición se ejecute en un tiempo aproximado de 900-1000
milisegundos y que tenga una disponibilidad de al menos 95 %. Para poder crear ese sistema, se utilizaron
seis web APIs provistas por diferentes fabricantes y las seis herramientas seleccionadas.
3.3 Método de Evaluación
Considerando nuestro objetivo de identificar un conjunto de problemas generales de usabilidad en

herramientas de composición de componentes que sean relevantes al contexto de usuarios finales, se
escogió de entre otros métodos la evaluación heurística (Nielsen & Molich, 1990). En este tipo de
evaluación un grupo de expertos inspecciona un producto de software con el fin de determinar si se
adhiere o no a un conjunto de principios o heurísticas de diseño. Existen evidencias sobre que bastan
entre tres y cinco expertos para encontrar, aproximadamente, el 75% de los problemas de usabilidad
(González, Lorés, & Pascual, 2006).
La evaluación fue realizada por cinco evaluadores, cuatro de ellos Licenciados en Informática y
actualmente alumnos del cuarto semestre un programa de Maestría en Sistemas Interactivos Centrados en
el Usuario. El quinto evaluador es Licenciado en Informática y Maestro en Redes y Sistemas Integrados y
cuenta con 3 años de experiencia laboral en el desarrollo de sistemas basados en componentes.
Existen varias propuestas de heurísticas a utilizar. En la Tabla 3 se listan algunas de las más relevantes
en la literatura: las propuestas por Nielsen (Nielsen J. , 1994), Tognazzini (Tognazzini, 2014) y,
Shneiderman y Plaisant (Shneiderman & Plaisant, 2010). Para facilitar su comprensión se han organizado
en categorías. Teniendo en cuenta los aspectos que afectan la usabilidad en el contexto de los usuarios
objeto de estudio y la tarea realizada, se indican con letras negritas cursivas cuáles de estas heurísticas
han sido consideradas en esta evaluación. A continuación se describe esta selección.
Tabla 3. Conjunto de heurísticas y principios seleccionados para la evaluación.

Categoría Descripción 35
Nielsen Tognazzini Shneiderman y
Plaisant
Retroalimentación Visibilidad del estado del Navegación visible Retroalimentación
sistema Anticipación informativa
Control sobre el Control y libertad del usuario Eficiencia del usuario Revertir acciones
ambiente Autonomía Control por parte del
Interfaces explorables usuario
Manejo de errores Prevención de errores Manejo de errores
Ayudar a los usuarios a Manejo de errores
reconocer, diagnosticar y
recuperarse de los errores
Valores por defecto
Aprendizaje Relación entre el sistema y el Aprendizaje
mundo real Uso de metáforas
Objetos humanos
Reconocimiento antes que Aprendizaje Reducir la carga de
recuerdo Uso de metáforas memoria de corto plazo
Objetos humanos
Flexibilidad y eficiencia de uso Uso de atajos
Consistencia y estándares Consistencia Consistencia
Ayuda y documentación
Valores por defecto
Otros Estética y diseño minimalista
Daltonismo
Ley de Fitts
Reducción de la latencia
Legibilidad
Guardar el estado
Protege el trabajo del
usuario
Secuencias de
acciones organizadas
El principio de anticipación, definido por Tognazzini, hace referencia a que los sistemas deberían
anticiparse a las necesidades y deseos del usuario. Se debe evitar que los usuarios tengan que buscar o
recordar mucha información durante el uso del sistema y, en cambio, mostrarle la información y
herramientas necesarias para realizar su trabajo. De esta forma, la consideración de este principio en el
diseño de las herramientas de composición facilitaría a un usuario final realizar la selección de los
componentes que satisfagan no solo las características funcionales requeridas (aspecto: selección de
componentes disponibles en la Tabla 1), sino también los que satisfagan la calidad servicio de la
composición requeridas para la composición (aspecto: estimación de calidad de servicio de la
composición en la Tabla 1).
Como se observa en la Tabla 3, en la categoría manejo de errores hemos agrupado heurísticas y
principios, propuestos por los tres autores, relacionados con este tema. En todos estos se comparte la
visión de que el sistema debe ser capaz de reconocer, diagnosticar y recuperarse de errores. Así, el
considerar las heurísticas y principios en esta categoría en el diseño de las herramientas de composición
evitaría que el usuario final tuviera que detectar, diagnosticar y resolver manualmente incompatibilidades
entre los componentes que va a utilizar (aspecto: detección de incompatibilidades entre componentes en
la Tabla 1).
Heurísticas como relación entre el sistema y el mundo real y reconocimiento antes que recuerdo,
propuestas por Nielsen, establecen que el sistema debe hablar el lenguaje de los usuarios prefiriendo los
conceptos y frases familiares a éstos. Por otra parte el principio de aprendizaje de Tognazzini indica que
se debe reducir la curva de aprendizaje del uso sistema. De esta forma, estas heurísticas y principios en el
diseño de las herramientas de composición contribuye a mejorar el nivel abstracción del lenguaje
utilizado (aspecto: uso de un lenguaje de bajo nivel de abstracción en la Tabla 1).
La Tabla 4 define las sub-heurísticas que se consideraron para la evaluación del conjunto de
heurísticas y principios presentados en la Tabla 3. Estas sub-heurísticas se seleccionaron de listas
predefinidas --e.g., (Nielsen J. , 1994), (Shneiderman & Plaisant, 2010), (Tognazzini, 2014). Algunas
sub-heurísticas fueron adaptadas para corresponder mejor al contexto de los usuarios objeto de estudio, la
composición realizada y las herramientas evaluadas.
Tabla 4. Conjunto de sub-heurísticas seleccionadas para la evaluación.

Aspecto Heurísticas y Sub-heurísticas 36
Principios
Selección de componentes disponibles Anticipación A1. Al inicio del proceso de composición
el usuario puede especificar los aspectos
Estimación de calidad de servicio de la funcionales y de calidad del servicio que
composición espera de la composición.
A2. Durante el proceso de composición

se sugiere al usuario los componentes que
satisfacen la funcionalidad y calidad del
servicio.
Detección de incompatibilidades entre Prevención de E1. Durante el proceso de composición
componentes. errores se previene que los usuarios cometan
errores.
Ayudar a los
usuarios a E2. Durante el proceso de composición,
reconocer, si se detectan errores se informan las
diagnosticar y posibles causas.
recuperarse de los
errores E3. Durante el proceso de composición,
si se detectan errores se sugieren posibles
Manejo de soluciones para resolverlos.
Errores
E4. Los mensajes de error, e información
relacionada, se comunican usando un
lenguaje poco técnico.
Uso de un lenguaje de bajo nivel de Relación entre el L1. Los íconos son claros y usan un
abstracción sistema y el mundo lenguaje visual intuitivo y poco técnico.
real
L2. El lenguaje de composición es claro y
Reconocimiento poco técnico.
antes que recuerdo
Aprendizaje
4 Resultados Obtenidos
En la Tabla 5 y la Tabla 6Tabla 5. Resultados de la evaluación heurística - I. se muestran los resultados

obtenidos de la evaluación heurística de usabilidad de las herramientas de composición seleccionadas, los
cuales deben ser interpretados considerando lo siguiente.
Valor que representa la frecuencia con la que se incurre en el error:
0 = nunca.
1 = a veces.
2 = muchas veces.
Valor que representa el impacto asociado a cada sub-heurística:
0 = No es problema de usabilidad.
1 = Problema sin importancia, no es necesario arreglarlo a menos que haya tiempo.
2 = Problema de poca importancia, arreglarlo no tiene mucha importancia.
3 = Problema grave, es importante arreglarlo.
4 = Problema catastrófico, es vital arreglarlo.
El valor mostrado en las columnas E1, E2, E3, E4, E5 indica el nivel de severidad del error detectado
por cada experto. El nivel de severidad se calcula multiplicando los valores de frecuencia e impacto
descritos antes. Este nivel indica qué tan grave es el error detectado en la evaluación y se interpreta como
sigue:
0 = No es un error.
1 - 2 = Error sin importancia.
3 - 4 = Error de grado medio.
5 - 6 = Error grave.
7 - 8 = Error catastrófico
Tabla 5. Resultados de la evaluación heurística - I. 37

Sub- Apache ODE BonitaSoft LONI Pipeline
heurísticas E1 E2 E3 E4 E5 R E1 E2 E3 E4 E5 R E1 E2 E3 E4 E5 R
A1 8 6 8 6 6 6.8 8 6 8 2 6 6 8 6 8 1 8 6.2
A2 8 6 8 3 6 6.2 6 6 6 1 6 5 8 1 8 2 6 5
E1 6 3 6 3 8 5.2 3 4 4 3 6 4 6 1 3 2 6 3.6
E2 6 3 6 8 6 5.8 6 6 6 3 6 5.4 6 1 6 3 6 4.4
E3 8 6 8 8 8 7.6 6 8 8 8 6 7.2 6 2 8 6 6 5.6
E4 8 8 8 8 8 8 8 3 8 8 6 6.6 6 3 8 3 6 5.2
L1 8 8 8 6 6 7.2 8 3 6 1 6 4.8 6 2 3 2 6 3.8
L2 8 6 8 3 8 6.6 8 2 8 2 6 5.2 6 2 3 3 6 4
Tabla 6. Resultados de la evaluación heurística - II.

Sub- Taverna Wave M aker Yahoo Pipes!
heurísticas E1 E2 E3 E4 E5 R E1 E2 E3 E4 E5 R E1 E2 E3 E4 E5 R
A1 8 6 8 3 6 6.2 8 6 8 2 6 6 8 6 8 2 6 6
A2 8 6 8 3 6 6.2 8 6 8 2 6 6 6 6 8 3 6 5.8
E1 6 6 2 3 6 4.6 8 3 8 4 6 5.8 6 2 8 4 6 5.2
E2 6 3 6 6 6 5.4 6 2 8 3 6 5 6 2 8 6 6 5.6
E3 8 8 8 4 6 6.8 8 4 8 6 6 6.4 8 4 8 6 6 6.4
E4 8 6 6 6 6 6.4 8 8 8 6 6 7.2 8 3 6 8 6 6.2
L1 8 8 8 3 6 6.6 8 3 8 2 6 5.4 8 2 8 6 6 6
L2 8 3 8 2 6 5.4 8 8 8 2 6 6.4 8 2 8 6 6 6
Fig. 1. Resultados obtenidos de la evaluación heurística.
En la Tabla 5 y la Tabla 6 la columna ―R‖ es el promedio obtenido de los valores de los cinco
expertos. Este promedio está graficado en la Fig. 1 y se observa lo siguiente.
La anticipación es un problema que va de grave a catastrófico (valores de 5 a 7), debido a que ninguna
de las herramientas ofrece soporte para especificar, al inicio del proceso de composición, los aspectos
funcionales y de calidad del servicio que se espera del sistema a construir (sub-heurística A1). Como
consecuencia de lo anterior, ninguna de las herramientas evaluadas ofrece soporte para realizar la
selección de componentes considerando los aspectos funcionales y de calidad de servicio requeridos (sub-
heurística A2). El usuario final tiene siempre que resolver todo esto de forma manual.
En lo que se refiere al manejo de errores se detectó que es un problema que va de grado medio a
catastrófico (valores de 4 a 8), ya que algunas herramientas brindan cierto soporte para prevenir errores
(sub-heurística E1), sin embargo cuando se presentan errores, los mensajes de error no brindan
información de la causa y tampoco de cómo resolver el error presentado (sub-heurísticas E2 y E3),
además el mensaje se comunican al usuario usando un lenguaje técnico (sub-heurística E4). 38
Finalmente, el uso de un lenguaje de bajo nivel en la composición es un problema que va desde grado
medio hasta catastrófico (valores de 4 a 7), esto porque todas las herramientas utilizan íconos poco
intuitivos y un lenguaje muy técnico para los usuarios finales (sub-heurísticas L1 y L2), sin embargo
algunas tienen un lenguaje que puede ser más técnico que el utilizado en otras y dado que los evaluadores
tienen conocimientos en desarrollo de sistemas, no calificaron el lenguaje utilizado como un lenguaje
muy técnico.
5 Conclusiones y Trabajo Futuro
En este trabajo se presentó una evaluación heurística de herramientas de composición de componentes

para detectar problemas generales de usabilidad relevantes al contexto de un usuario final. En contraste
con algunos trabajos relacionados, una contribución importante de la evaluación presentada es que se
usaron heurísticas que fueron identificadas considerando un conjunto de aspectos intrínsecos al
desarrollo centrado en composición y a los usuarios finales.
Los problemas identificados con nivel de severidad alto y que ocurren frecuentemente incluyen: el
uso de un lenguaje técnico, el poco soporte ofrecido para la especificación de aspectos funcionales y de
calidad del servicio y, el poco soporte ofrecido para la selección de componentes basada en dichas
especificaciones.
Aunque estos problemas son generales, consideramos que es importante conocerlos pues proveen un
conjunto inicial que puede ser considerado para, como trabajo futuro, mejorar las muchas herramientas de
composición actuales. Igualmente estos problemas proveen la base para realizar futuras evaluaciones
considerando contextos más específicos a determinados tipos de usuarios finales --e.g., sociólogos,
biólogos.
Con base en los resultados obtenidos, consideramos que la evaluación heurística fue un método
apropiado para detectar problemas de usabilidad generales. Sin embargo, en dominios de aplicación
específicos sería necesario utilizar otras técnicas de evaluación; preferentemente aquellas que involucren
a usuarios finales.
Agradecimientos
Los autores desean reconocer a los revisores anónimos de este artículo por sus útiles sugerencias. La
primera autora agradece a CONACYT-Mexico el apoyo para la realización de sus estudios de Maestría en
Sistemas Interactivos Centrados en el Usuario (No. de becario: 297377).
Referencias
Abiteboul, S., Greenshpan, O., & Milo, T. (2008). Modeling the mashup space. Proceedings of the 10th ACM
workshop on Web information and data management (pp. 87--94). California, USA: ACM.
Al Sarraj, W. (25 de October de 2014). Toward Usability Evaluation Criteria for Web Mashup Makers for End-Users.
International Journal of Advanced Computer Technology (IJACT), 3, 23--32.
Apache, S. F. (205). Apache ODE. Obtenido de http://ode.apache.org/
Apatar, I. (2014). Apatar. Connecting data. Obtenido de http://www.apatar.com/
Baryannis , G., & Plexousakis, D. (2010). Automated Web Service Composition: State of the Art and Research
Challenges. Technical Report ICS-FORTH/TR-409. Foundation for Research & Technology - Hellas - Institute
of Computer Science.
Beek, M., Bucchiarone, A., & Gnesi, S. (2006). A Survey on Service Composition Approaches: From Industrial
Standards to Formal Methods. In Technical Report 2006TR-15, Istituto. IEEE CS Press.
Bhagat, J., Tanoh , F., Nzuobontane, E., Laurent , T., Orlowski, J., Roos, M., . . . Globe, C. A. (10-15 de Septiembre
de 2010). BioCatalogue: a universal catalogue of web services for the life sciences. Obtenido de
https://www.biocatalogue.org/
Bonitasoft, I. (2015). Bonitasoft. Obtenido de http://www.bonitasoft.com/
Cauldwell, P., Chawla, R., & Chopra, V. (2002). Servicios Web XML. España: Anaya Multimedia-Anaya Interactiva.
Clements , P., & Northrop, L. (2001). Software Product Lines: Practices and Patterns. Boston, MA, USA: Addison-
Wesley Longman Publishing Co., Inc.
Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall.
Feenstra, R. W., Janssen, M., & Wagenaar, R. W. (2007). Evaluating Web Service Composition Methods: the Need
for Including Multi-Actor Elements. Electronic Journal of e-Government, 5(2), 153--163.
Fowler, M. (2014). Microservices. Obtenido de http://martinfowler.com/articles/microservices.html
Garcês, R., De Jesus, T., Cardoso, J., & Valente, P. (2009). Open Source Workflow Management Systems: A Concise
Survey. En GWDL: A graphical workflow definition language for business workflows. Springer Berlin 39
Heidelberg.
Garlan, D., Dwivedi, V., Ruchkin, I., & Schmerl, B. (2012). Foundations and Tools for End-user Architecting.
Proceedings of the 17th Monterey Conference on Large-Scale Complex IT Systems: Development, Operation
and Management (pp. 157--182). Oxford, UK: Springer-Verlag.
González, M. P., Lorés, J., & Pascual, A. (2006). Evaluación Heurística. En La Interacción Persona Ordenador (pp. 1-
-40). AIPO Press.
Insfran, E., Cedillo, P., Fernández, A., Abrahão, S., & Matera, M. (2012). Evaluating the Usability of Mashups
Applications. Quality of Information and Communications Technology (QUATIC), 2012 Eighth International
Conference on the (pp. 323--326). Lisbon: IEEE.
ISO/IEC 9126. (1992). Information technology-Software product evaluation-Quality characteristics and guidelines
for their use.
ISO/IEC 9241-11. (1998). ISO/IEC, 9241-11. Ergonomic requirements for office work with visual display terminals
(VDT)s - Part 11 Guidance on usability.
JOpera.org. (2013). JOpera. Process Support for Web Services. Obtenido de http://www.jopera.org/
Kapow. (2015). Kapow Software. A Kofax Company. Obtenido de http://www.kapowtech.com/
Knoke, D., & Yang, S. (2008). Social Network Analysis. SAGE Publications, Inc.
Laboratory, o. N. (2015). Loni Pipeline. Obtenido de http://pipeline.bmap.ucla.edu/
Malinga, M., Gruner, S., & Koschmider, A. (2013). Quality and Usability of Mashup Tools: Criteria and Evaluation.
Proceedings of the South African Institute for Computer Scientists and Information Technologists Conference
(pp. 154--159). East London, South Africa: ACM.
Mehandjiev, N., Namoune, A., Wajid, U., Macaulay, L., & Sutcliffe, A. (2010). End user service composition:
Perceptions and requirements. Web Services (ECOWS), 2010 IEEE 8th European Conference on (pp. 139--
146). Ayia Napa: IEEE.
Minhas, S. S., Sampaio, P., & Mehandjiev, N. (2012). A Framework for the Evaluation of Mashup Tools. Services
Computing (SCC), 2012 IEEE Ninth International Conference on (pp. 431--438). Honolulu, HI: IEEE.
Morisio, M., Seaman, C., Basili, V., Parra, A., Kraft, S., & Condon, S. E. (2002). COTS-based software
development: processes and open issues. Systems and Software, 189--190.
Muñoz Jiménez, J. A. (May de 2010). Programación con AJAX. Obtenido de
http://jamj.webcindario.com/programacion/ajax/AJAX.pdf
Nielsen, J. (1994). Enhancing the Explanatory Power of Usability Heuristics. Proceedings of the SIGCHI Conference
on Human Factors in Computing Systems (pp. 152--158). Boston, Massachusetts, USA: ACM.
Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces. SIGCHI Conference on Human Factors in
Computing Systems (pp. 249--256). ACM.
Patel , A., Na , L., Latih, R., Wills, C., Shukur , Z., & Mull, R. (2 de November de 2010). A Study of Mashup as a
Software Application Development Technique with . Journal of Computer Science, 6(12), 1406.
Portchelvi, V., Prasanna Venkatesan, V., & Shanmugasundaram, G. (2012). Achieving Web Services Composition - a
Survey. 2, pp. 195--202. Software Engineering.
RedHat. (2014). JBoss Developer. Obtenido de http://www.jboss.org/
Roy Chowdhury, S. (2012). Assisting End-user Development in Browser-based Mashup Tools. Proceedings of the
34th International Conference on Software Engineering (pp. 1625--1627). Zurich, Switzerland: IEEE Press.
RSSBus, I. (2014). RSSBus. Obtenido de http://www.rssbus.com/
RunaWFE. (2013). RunaWFE. Obtenido de http://wf.runa.ru/
School of Computer Science, U. o. (01-03 de Noviembre de 2010). Taverna. Obtenido de http://www.taverna.org.uk/
Seffah, A., Donyaee, M., B. Kline, R., & K. Padda, H. (2006). Usability measurement and metrics: A consolidated
model. Software Quality Control, 4(2), 159--178.
Shneiderman, B., & Plaisant, C. (2010). Designing the User Interface: Strategies for Effective Human-Computer
Interaction: Fifth Edition. Addison-Wesley Publ. Co.
Sommerville, I. (2006). Ingeniería de Software. España: Pearson Addison Wesley.
Taylor, R. N., Medvidovic, N., & Dashofy, E. M. (2009). Software Architecture: Foundations, Theory, and Practice.
Wiley Publishing.
Team, T. i. (2015). igraph R package. Obtenido de igraph R package: http://igraph.org/r/
ter Beek, M., Bucchiarone, A., & Gnesi, S. (2007). Web Service Composition Approaches: From Industrial Standards
to Formal Methods. Internet and Web Applications and Services, 2007. ICIW '07. Second International
Conference on (pág. 15). Morne: IEEE.
Together Teamsolutions Co., L. (2011). Together - Professional Open Source. Obtenido de
http://www.together.at/prod/workflow/tws
Tognazzini, B. (10--15 de Noviembre de 2014). First Principles of Interaction Design. Obtenido de Ask.Tog:
http://asktog.com/atc/principles-of-interaction-design/
Twitter, I. (2015). REST APIs - Twitter Developers. Obtenido de REST APIs - Twitter Developers:
https://dev.twitter.com/rest/public
WaveMaker, I. (2014). WaveMaker. Obtenido de http://www.wavemaker.com/
Yahoo!, I. (2014). Yahoo Pipes! Obtenido de https://pipes.yahoo.com/pipes/
Yeltayeva, K. (2012). Usability Study of the Taverna Scientific Worflow Workbench. University of Manchester,
Faculty of Engineering and Physical Sciences . University of Manchester.
Zhao, Z., Bhattarai, S., Liu, J., & Crespi, N. (2011). Mashup services to daily activities: end-user perspective in
designing a consumer mashups. Proceedings of the 13th International Conference on Information Integration and
Web-based Applications and Services (pp. 222--229). Ho Chi Minh City, Vietnam: ACM.
40
Metamodelo para validación de software basado en el CMMI
Jose Calvo-Manzano1, Gonzalo Cuevas1, José de J. Jiménez Puello2, Tomás San Feliu Gilabert1
1
Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software
Universidad Politécnica de Madrid
Boadilla del Monte, 28660 Madrid, España,
2
Departamento de Informática
Universidad de Panamá
{jacalvo@fi.upm.es, gcuevas@fi.upm.es, jjimpue@hotmail.com, tsanfe@fi.upm.es}
Resumen. En el presente artículo se establece un metamodelo de validación de software basado en

el modelo CMMI. Se consideró el área de proceso de validación, específicamente la meta SG1
preparar la validación, que incluye las prácticas SP 1.1 Seleccionar los productos a validar, SP 1.2
Establecer el entorno de validación y SP 1.3 Establecer los procedimientos y criterios de validación.
El metamodelo está diseñado a través de una taxonomía de proyectos, un método para caracterizar
pruebas según proyecto, plantillas de prueba y un plan de pruebas. La evaluación y validación del
metamodelo se realizó por medio de un caso de estudio. Los resultados de la evaluación indican que
el metamodelo es efectivo para la validación de software.
Palabras claves: CMMI, mejora de procesos, metamodelo, prueba de software, validación de
software.
1 Introducción
Es primordial que toda organización que se dedique al desarrollo de TI establezca una serie de
mecanismos de control que permitan determinar que su producto cumpla con normas, procesos y
estándares de calidad, que garanticen que su producto este libre de errores, ante el mercado competitivo.
Uno de los procesos que aseguran esta competitividad es la validación de software. La validación no es 41
más que la prueba de software en sí (Monteiro, Machado & Kazman, 2009; Oh, Choi, Han & Wong,
2008; Kurokawa & Shinagaw, 2008).
Según (Ballou, 2008) todavía las organizaciones tienen que tratar con los defectos de software, un año
después de ser liberados. El 55% del software sigue dando problemas dos años después de su
implementación, donde un 55 por ciento señala que el software presenta problemas en el transcurso de los
meses iniciales después de realizada la prueba. Lo anterior trae como consecuencia que los proyectos de
desarrollo de software fallen debido a pruebas inadecuadas, a pruebas no planificadas o pobres, que
indican que el proyecto no está metodológicamente comprobado, lo que ocasiona fallos, probablemente
debido a la inadecuada capacitación de los usuarios que desconocen el propósito de las pruebas (Quillen,
2011; Jäntti, 2008).
El problema en la preparación de la validación, debido a la ausencia de planificación y estrategias para
abordar las pruebas y la escasa o nula formación por parte de los probadores, incide en un proceso de
prueba desorganizado donde los métodos, técnicas, pruebas, entorno de validación, procedimientos y
criterios de pruebas de validación no correspondan de forma probable al proyecto a validar. Tal como
señalan (Iyengar & Karamouzis, 2007), la falta de pruebas y estándares de calidad, como la ausencia de
consistencia, son precursores de que sucedan interrupciones en las organizaciones debido a fallos en el
software que pueden ser costosos. No hay una definición clara de los tipos de pruebas que deben aplicarse
a un tipo de proyecto específico que cada organización aplica (Causevic, Sundmark & Punnekkat, 2010).
A pesar de que existen modelos y estándares que abordan el proceso de validación de software, como
el modelo CMMI DEV v1.2 (SEI, 2010), éstos solo indican ―el Qué‖ sin indicar ―el Cómo‖ (Humphrey
Konrad, Over & Peterson, 2007; Faroog & Dumke, 2007). Uno de los problemas de la validación es que
los modelos establecidos para este proceso son difíciles de utilizar, porque solo indican ―el qué hacer‖
(García Guzmán, de Amescua Seco & Velasco de Diego, 2006). Uno de los mayores problemas en la
prueba de software, radica en determinar si de acuerdo al tipo de prueba, se han realizado las pruebas
adecuadas (Desai & Shah, 2011; Nayyar & Rizwan, 2009; Rajamani, 2006). Estos problemas deben
abordarse desde la perspectiva de la mejora de procesos a través de un metamodelo, que integre mejores
prácticas de prueba para la validación de software. Por consiguiente, se ha desarrollado un metamodelo de
validación de software que facilite a las organizaciones establecer la preparación e identificación de las
pruebas para realizar la validación de un proyecto.
El artículo se organiza en seis secciones: la sección 1 es la presente introducción, en la sección 2.se

presentan los Trabajos relacionados, en la sección 3 se expone el Metamodelo para validación de
software. Y en la sección 4 se presenta el Caso de estudio donde se ha aplicado. Finalmente en la sección
5 se exponen las Conclusiones y la última sección se muestran las referencias utilizadas.
2 Trabajos Relacionados
Un metamodelo es presentado por (Fleurey, Steel & Baudry, 2004), para técnicas de validación de
software en el entorno de la arquitectura dirigida por modelos. Los autores sugieren que a través de un
modelo de pruebas se puede establecer técnicas de pruebas funcionales y estructurales, incluso otros tipos
prueba como la de mutación para mejorar la calidad de la prueba. Por su parte (Brottier, Fleurey, Steel,
Baudry & Le Traon) establecen un metamodelo basado en generación de datos de pruebas denominados
(modelos de pruebas) para modelos de transformación en el contexto de la arquitectura dirigida por
modelos, como mecanismo de comprobar las transformaciones que tiene que realizar los modelos
generados. Para ello, implementa un algoritmo que crea modelos de pruebas de un metamodelo. (Hsue,
Shenm, Yang & Yang, 2008) presentan un metamodelo que aplica un modelo de simulación para
comprobar la definición de procesos implementados en SPEM, mediante las prácticas de validación del
CMMI. En (Sadilek & Weißleder, 2008) proponen un metamodelo para pruebas de metamodelos, que
determine la existencia de errores en los metamodelos. Para ello, se enfoca en un metamodelo de prueba
automatizado basado en una especificación de prueba. (Hernández, King & Clarke, 2008), establecen un
metamodelo para soportar pruebas de regresión para aplicaciones Web, debido al rápido cambio en la
tecnología, lo que genera que las aplicaciones que migran de forma continua no puedan validarse debido
al cambio de las plataforma y de las pruebas. (Lévesque, 2009) proponen un metamodelo para pruebas de
unidad para lenguaje de programación orientado a objeto, que facilita escribir pruebas de unidad dentro
de las clases para que sean probadas. (Marin, Vos, Giachetti, Baars & Tonella, 2011), proponen una
metodología de prueba para aplicaciones Web, mediante la integración de búsqueda de pruebas, a través
de un metamodelo de prueba que implementa la metodología.
Los metamodelos descritos no resuelven la problemática de preparar la validación y menos identifican
las pruebas a la que debe someterse un proyecto específico. Además aplican el concepto de metamodelo
definido para la arquitectura dirigida por modelos, que como señala (Muñoz, 2003) un metamodelo es un 42
soporte para crear y desarrollar modelos a partir de un modelo.
Por el contrario, el metamodelo a plantear, resuelve la problemática de preparar la validación. El
metamodelo consiste en una solución innovadora referente a los modelos y estándares existentes, ya que,
proporciona ―el cómo hacer‖ identificando y aplicando las prácticas de validación para la mejora del
proceso de validación. El metamodelo no aplica el concepto de metamodelo de la arquitectura dirigida
por modelos que trata sobre la transformación de modelos.
3 Metamodelo para validación de software
El metamodelo que se presenta toma como referente el concepto de que a partir de un modelo se podrán
definir otros modelos. Es decir, el metamodelo permite que se puedan establecer modelos para preparar la
validación acordes a diferentes proyectos, tomando como referente la estructura base del metamodelo que
a su vez es el modelo. El metamodelo desarrollado está basado en el modelo CMMI para desarrollo v.1.3,
que al ser un metamodelo puede derivar otros modelos. El CMMI está integrado por áreas de procesos, el
área de proceso seleccionada para la definición del metamodelo es el área de procesos de validación, y su
meta específica preparar la validación que incluye las prácticas específicas (SP 1.1. Seleccionar los
productos a validar, SP 1.2. Establecer el entorno de validación y SP 1.3 Establecer los procedimientos y
criterios de validación). Estas prácticas específicas permiten organizar y establecer el proceso de
preparación de la validación de software para luego ejecutar la validación. El entorno de aplicación del
metamodelo abarca cualquier organización que desarrolle software. Principalmente las pequeñas, que
presentan menos recursos económicos, tecnológicos y de formación de personal en validación y pruebas
de software.
3.1. Diseño del Metamodelo
El metamodelo está organizado a partir de una taxonomía de proyectos de software, un método para
caracterización de pruebas, plantillas de prueba y el plan de pruebas como resultado de la aplicación de
las prácticas específicas definidas para preparar la validación. El diseño del metamodelo se representa por
el diagrama de clases (Fig. 1). Las clases categoría de proyecto, subcategoría de proyecto y proyecto,
representan la taxonomía (Fig. 2), que define una serie de categorías y subcategorías de proyectos que
establecen los proyectos específicos en base a su tecnología para desarrollo de software (Calvo-Manzano,
Cuevas, San Feliu & Jiménez, 2015a).
Fig. 1. Metamodelo de validación.
Otro elemento del metamodelo es la clase caracterización de pruebas, La caracterización de pruebas

permite identificar cuáles son las pruebas de software que deben ser aplicadas a un proyecto específico
para validarlo (Calvo-Manzano, Cuevas, San Feliu & Jiménez, 2015b). La caracterización establece un
método para identificar las pruebas de acuerdo a un proyecto determinado. Las fases del método son:
Seleccionar, el proyecto de software a caracterizar, establecer la estrategia de búsqueda, establecer una
plantilla para caracterizar las pruebas, analizar los resultados y mostrar los resultados. El metamodelo
establece una serie de plantillas de prueba basadas en las prácticas específicas SP 1.1, SP 1.2 y SP 1.3 del
área de proceso de Validación de CMMI. Las clases del metamodelo que representa la plantilla que
corresponde a la práctica SP 1.1 establecer el producto, está conformada por la clase requisitos, la clase
restricciones y la clase método de validación. La plantilla de la práctica SP 1.2 establecer el entorno de
validación, está representada por las clases entorno de validación, hardware, software espacio físico y
calendario y programación de las pruebas. La plantilla de la práctica SP 1.3, se representa por las clases
procedimiento de prueba, procedimiento de validación y criterios de prueba.
43
Fig. 2. Taxonomía de proyectos de software.
El plan de prueba establece las pruebas a que debe someterse un proyecto. El plan especifica: tipo de prueba, nivel de
prueba, características a probar, pruebas específicas, técnicas y herramienta de prueba.
4 Evaluación del metamodelo
En la evaluación del metamodelo se aplicó un caso de estudio acorde con (Wohlin, Höst & Henningsson,
2003), que plantea que una estrategia para caso de estudio, es comparar los resultados de una nueva
propuesta y una línea base. Para establecer la línea base se aplicó la técnica de la encuesta a través de un
cuestionario. Además, se definieron dos variables como indicadores para determinar el estado actual del
proceso de validación, según las prácticas SP1, SP2 y SP3 en la organización de estudio. El cuestionario
consta de once ítems (Tabla 1) que se definió para dar soporte a las variables. Se estableció una escala de
tipo Likert con cinco niveles de respuesta (donde 1 es nunca, 2 es pocas veces, 3 es muchas veces, 4 es
casi siempre, 5 es siempre) para determinar la frecuencia en la que se considera se ubica cada respuesta
afirmativa. Las variables definidas son dos: Estado del proceso de validación y el estado de las pruebas en
la organización.
Tabla 1. Cuestionario para determinar la línea base.
Nº Preguntas Si No 1 2 3 4 5
1 ¿Aplican pruebas específicas al proyecto?
2 ¿Disponen de una metodología, modelo, guía, marco o referencia para el desarrollo de

las pruebas?
3 ¿Definen un plan de pruebas?
4 ¿El plan de prueba está basado en los requisitos del usuario y del proyecto?
5 ¿Antes de validar definen que pruebas se deben aplicar al proyecto?
6 ¿Las pruebas se basan en algún estándar de calidad de software?
7 ¿Aplican técnicas de pruebas?
8 ¿Utilizan herramientas de pruebas?
9 ¿Las pruebas tiene definidos los procedimientos y criterios que deben ser probados?
10 ¿Establece un entorno de validación?
11 ¿Disponen de un equipo de prueba con conocimiento en el desarrollo de pruebas?
Las respuestas obtenidas en el cuestionario proporcionan información sobre el estado actual del proceso
de validación en la institución que será sometida al caso de estudio.
44
4.1. Caso de estudio
El caso de estudio se llevó a cabo en la Dirección de Informática, de una institución de educación superior
pública con presencia en todo el país. La dirección de informática tiene a su cargo el desarrollo de
software académico, administrativo y financiero de la institución a nivel de todo el país. La institución la
componen 19 facultades, 9 centros regionales, 3 extensiones docentes, 13 institutos, 1 universidad del
trabajo y 1 universidad de la tercera edad. Se pudo observar la ausencia de una estructura definida para el
desarrollo de pruebas de validación, documentación y resultados, por lo que acogió con entusiasmo e
interés aplicar el metamodelo en los proyectos de software que desarrolla, para la mejora de sus procesos
de validación. Solo dispone de tres analistas programadores encargados del desarrollo de aplicaciones a
nivel Web y cliente servidor. Los analistas programadores son los que realizan las pruebas de validación a
cada proyecto que desarrollan. Los analistas programadores no tienen formación en validación y pruebas
de software. El proyecto seleccionado, en este caso, es un proyecto Web tradicional que forma parte de
una subcategoría dentro de la taxonomía de proyectos establecida como elemento del metamodelo.
4.1.1 Línea base
La población encuestada fue de 3 analistas programadores, por consiguiente se trabajó con toda la
población (N=3). Los resultados del estado del proceso de validación (variable 1), indican carencia de
documentación del proceso de validación. El 100% señala que no se aplica metodología alguna, modelo,
guía o marco de referencia para el desarrollo de las pruebas de validación de software. Un plan de prueba
no se define ni se aplica, probablemente debido a que el personal no tiene conocimiento en pruebas de
software (Fig. 3). Sin embargo, el 66% considera que establecen pruebas antes de validar. Esta confusión
obedece a que aplican alguna prueba de entrada de datos para comprobar el resultado de salida, que
obviamente, no implica que estén desarrollado un proceso organizado de validación del software.
Fig. 3. Estado de la organización del proceso de validación.
En cuanto a la variable 2 (pruebas en la organización) (Fig. 4), el 100% señala que no aplican pruebas
según un estándar de calidad, no utilizan técnicas de prueba y menos herramientas de prueba y no
establecen un entorno de validación. Sin embargo, en la (Fig. 5), el 100% indica que aplican pruebas
específicas al proyecto, muchas veces, pero no siempre. Un 66% aplica un plan de prueba según los
requisitos del usuario y proyecto. Esto contradice el estado de la organización en cuanto al proceso de
validación, ya que, indican que no aplican un plan de prueba. Lo que significa que hacen pruebas de
validación y consideran que esto es un plan de pruebas, porque cubren las entradas de datos del proyecto
y de esta forma comprueban la funcionalidad, pero esto no significa que aplican un plan de prueba
específico al proyecto, que sería lo indicado.
Fig. 4. Pruebas en la organización.
45
Fig. 5. Pruebas en la organización.
4.1.2. Resultados de la aplicación del metamodelo
La validación del proyecto se realizó según lo especificado por el metamodelo, a través del plan de
prueba y las plantillas de prueba aplicadas al proyecto Web. La prueba aplicada fue la funcional y se
realizó de forma manual. La técnica utilizada fue la de partición de equivalencia. Previo a la aplicación de
la misma se explicó a los tres analistas programadores en que consistía la prueba y la técnica.
Los resultados de la validación indican que del total de requisitos probados con el metamodelo, un
porcentaje significativo (36%) presentó algún tipo de error o fallos. Posterior a la validación del proyecto
y obtenido los resultados, se procedió a aplicar a los probadores (A los tres analistas programadores que
contestaron la encuesta de la línea base), una encuesta a través de un cuestionario para determinar la
valoración sobre el metamodelo. Los resultados obtenidos a partir del cuestionario se muestran en la
Tabla 2.
Tabla 2. Cuestionario para evaluar el metamodelo.
Nº Preguntas Si No 1 2 3 4 5
1 ¿El metamodelo facilitó el desarrollo de las pruebas?
2 ¿Las pruebas organizadas en el plan son las apropiadas al proyecto?
3 ¿El metamodelo le proporcionó técnicas, pruebas, herramientas y criterios de

pruebas antes no considerados?
4 ¿Se detectó ausencia de requisitos, errores, fallos o defectos con el plan de pruebas
aplicado?
5 ¿Con las pruebas aplicadas se dispone de un producto que satisface al usuario?
6 ¿Utilizaría el metamodelo para validar otros proyectos?
7 ¿El plan de prueba del metamodelo permite contar con un proyecto fiable,
confiable y seguro?
8 ¿El aplicar el plan de prueba garantizó la calidad del producto?
9 ¿La aplicación del metamodelo fue satisfactoria en cuanto a los resultados

obtenidos a partir de las plantillas?
10 ¿El metamodelo permitió el aprendizaje durante el desarrollo de las pruebas?
Los resultados obtenidos permiten establecer y aplicar las pruebas específicas de un proyecto para
comprobar que los requisitos del usuario, han sido satisfechos en cuanto a su funcionalidad, tal como se
había planteado acerca del metamodelo y su relación con las prácticas de validación. Estos resultados se
han dividido y agrupado en dos partes. La primera parte abarca las preguntas sobre la aplicación del plan
de prueba y la segunda es sobre la aplicación del metamodelo.
En la (Fig. 6) se observa que el plan de prueba para proyecto Web, proporcionado por el metamodelo 46
es apoyado en un 100% por los probadores. Un alto porcentaje (66%) considera que muchas veces el plan
le proporciona las pruebas acordes al proyecto, y un 34% considera que siempre. Iguales resultados se
obtuvieron, al considerar si el plan les permitió detectar ausencia de requisitos, fallos, errores o defectos.
Por otro lado, el 66 % considera que el plan de pruebas permite satisfacer los requisitos del usuario casi
siempre y el 34% que siempre. Con respecto a la calidad del producto, el 66% considera que casi siempre
con el plan se garantiza la calidad del producto y un 34% que muchas veces.
Fig. 6. Aplicación del plan de prueba.
4.1.2.2. Aplicación del metamodelo
La aplicación del metamodelo resultó muy positiva y de mucha ayuda. Como se observa en la Fig. 7 y
Fig. 8, los probadores en un 100% aprueban el metamodelo por los aspectos siguientes: facilita las
prueba, proporciona técnicas de pruebas, herramientas y criterios de pruebas antes no considerados, lo
utilizarían para validar otros proyectos, permite contar con un proyecto fiable, confiable y seguro,
satisfacción en cuanto a los resultados obtenidos y permitió el aprendizaje durante el desarrollo de las
pruebas. Al igual que en el caso anterior un alto porcentaje (66%) considera que el metamodelo facilita
las pruebas para un proyecto. Con relación a si proporcionó técnicas, pruebas, herramientas y criterios de
pruebas, muchas veces obtuvo el 66%. El 66% de los participantes utilizaría el metamodelo para validar
otros proyectos. Este mismo porcentaje señala que ―casi siempre‖ el metamodelo permite contar con un
proyecto fiable, confiable y seguro, de satisfacción en cuanto a los resultados obtenidos y que permitió el
aprendizaje durante el desarrollo de las pruebas.
Fig. 7. Aplicación del metamodelo.
Fig. 8. Aplicación del metamodelo.
5 Conclusión
Se implementó un metamodelo de validación basado en el modelo de mejora de procesos CMMI DEV

1.3, a partir de las prácticas específicas SP 1.1, SP1. 2 y SP 1. 3 del área de proceso de validación. El
metamodelo se diseñó basado en los siguientes elementos: una taxonomía de proyecto de software, un
método para la caracterización de pruebas de software, plantillas de prueba y el plan de prueba que
especifica las pruebas para un proyecto específico. 47
El metamodelo fue evaluado mediante un caso práctico, en donde se determinó de forma inicial, que la
organización donde se realizó la experimentación del metamodelo, carece de la estructura para preparar la
validación y por lo tanto, de un plan de prueba que establezca las pruebas para un proyecto software.
Además, existe una ausencia en la cultura de validación formal de sus proyectos y de la documentación
del proceso de validación. El personal en su mayoría no está capacitado en prueba o desconoce las
mismas. Inclusive no presentan una política y estrategia para validación de sus proyectos.
El metamodelo fue efectivo en su aplicación, guió a los probadores y le permitió de forma sistemática
y organizada, establecer y preparar la validación, a pesar de la falta de formación o de conocimiento en
pruebas y en modelos y estándares de pruebas de validación que tenían los probadores. Cabe resaltar que
la organización donde se aplicó el estudio es pequeña y por lo tanto, los hallazgos y resultados obtenidos
se basan en el contexto de la misma. El metamodelo, demostró su validez, ya que, los probadores
consideran que el metamodelo les aporta las pruebas específicas y requeridas para el desarrollo del
proceso de validación y les permite preparar la validación para un proyecto determinado, y así ofrecer un
software que cumpla con la calidad y con los requisitos del cliente.
6 Conclusión
Ballou, M. (2008). Improving Software Quality to Drive Business Agility, Coverity. Recuperado de:
http://www.coverity.com/library/pdf/IDC_Improving_Software_Quality_June_2008.pdf
Brottier, E.; Fleurey, F.; Steel, J.; Baudry, B. & Le Traon, Y. (2006). Metamodel-based Test Generation for Model
Transformations: an Algorithm and a Tool. Software Reliability Engineering. pp.85-94.
Calvo-Manzano, J., Gonzalo Cuevas, A., San Feliu Gilabert, T. & Jiménez Puello, J. (2015a). A Taxonomy for
Software Testing Projects. Álvaro Rocha, Arnaldo Martins, Gonçalo Paiva Dias, Luís Paulo Reis, Manuel Pérez
Cota (Eds.). Sistemas e Tecnologias de Informação, Atas da 10ª Conferência Ibérica de Sistemas e Tecnologias
de Informação. Águeda, Portugal. AISTI | Universidade de Aveiro Vol. I Artigos 1, pp 289-294.
Calvo-Manzano, J., Gonzalo Cuevas, A., San Feliu Gilabert, T. & Jiménez Puello, J. (2015b). Characterization of
tests focused on validation of software Project. 22nd EuroAsiaSPI Conference. Turkish Standards Institute,
Ankara, Turkey.
Causevic, A., Sundmark, D. & Punnekkat, S. (2010). An Industrial Survey on Contemporary Aspects of Software
Testing. Software Testing, Verification and Validation (ICST), pp.393-401.
Desai, A., Shah, S. (2011). Knowledge management and software testing. Proceedings of the International
Conference & Workshop on Emerging Trends in Technology (ICWET'11), pp 767-770.
Faroog, A., Dumke, R. (2007). Research Directions in Verification & Validation Process Improvement. ACM
SIGSOFT Software Engineering Notes. 32 (4), pp.1-3.
Fleurey, F., Steel, J. & Baudry, B. (2004). Validation in model-driven engineering: testing model transformations,
Model, Design and Validation, Proceedings. First International Workshop, pp. 29-40.
García Guzmán, J., de Amescua Seco, A. & Velasco de Diego, M. (2006). Top 10 De Problemas Relativos a la
Mejora del Proceso de Verificación y Validación en Organizaciones Intensivas en Software. Taller sobre
Pruebas en Ingeniería del Software (PRIS).
Hernandez, Y., King, M., Pava, J. & Clarke, P. (2008). A Meta-Model to Support Regression Testing of Web
Applications. Recuperado de:
http://users.cis.fiu.edu/~clarkep/research/areas/REUPubs/HernandezKingPavaClarke.pdf
Hsueh, N-L., Shen, W-H., Yang, Z-W, & Yang, D-L. (2008). Applying UML and software simulation for process
definition, verification, and validation. Information and Software Technology, 50, (9–10), pp. 897–911.
Humphrey,W.S., Konrad, M. D., Over, J. W. & Peterson,W. C. (2007). Future directions in process improvement.
Crosstalk-The Journal of Defense Software Engineering, 20, (2).
Iyengar, P. & Karamouzis, F. (2007). Offshore Application Testing Drives Greater Business Value. Gartner
Research. pp. 1-3.
Jäntti, M. (2008). Difficulties in Managing Software Problems and Defects. (Doctoral dissertation), Kuopio
University, Kuopio, Finlandia. Recuperado en: http://wanda.uef.fi/uku-vaitokset/vaitokset/2008/isbn978-951-
781-990-9.pdf
Kurokawa, T. & Shinagaw M. (2008).Technical Trends and Challenges of Software Testing. Science & Technology
Trends Quarterl y Review, 29, pp. 34-45. Recuperado de:
http://data.nistep.go.jp/dspace/bitstream/11035/2787/1/NISTEP-STT029E-34.pdf
Lévesque, M. (2009). A Metamodel of Unit Testing for Object-Oriented Programming Languages, Recuperado de:
http://arxiv.org/pdf/0912.3583.pdf
48
Marin, B., Vos, T. Giachetti, G., Baars, A. & Tonella, P. (2011). Towards testing future Web applications, Research
Challenges in Information Science. pp.1-12.
Monteiro, P., Machado, R. & Kazman, R. (2009). Inception of Software Validation and Verification Practices within
CMMI Level 2. ICSEA, pp. 536-541.
Muñoz, M. (2003). SCMM: Metamodelo para la Creación de Aplicaciones en Redes de Siguiente Generación. (Tesis
Doctoral). Universidad Carlos III De Madrid. Leganes, España.
Nayyar, M. & Rizwan, J. (2009). Improvement of Key Problems of Software Testing in Quality Assurance. Sci.Int.
21(1), pp. 25-28. Recuperado de: http://arxiv.org/ftp/arxiv/papers/1202/1202.2506.pdf
Oh, H., Choi, B., Han, H. & Wong, W. (2008). Optimizing Test Process Action Plans by Blending Testing Maturity
Model and Design of Experiments, The Eighth International Conference on Quality Software, pp.57-66.
Quillen, R. (2011).Why Some Software Development Projects Fail and What You Can Do About It. Quillen
Infrastructure Technologies. Recuperado de:
http://www.quillenit.com.au/docs/Why_Software_Development_Projects_Fail.pdf
Rajamani, S. (2006). Automatic Property Checking for Software: Past, Present and Future, Software Engineering and
Formal Methods, pp.18-20
Sadilek, D. & Weißleder, S. (2008). Testing Metamodels. Model Driven Architecture Foundations and Applications
.Lecture Notes in Computer Science, 5095,( pp 294-309)
SEI (Software Engineering Institute) (2010). CMMI for Development, Version 1.3.Recuperado de:
http://www.sei.cmu.edu/reports/10tr033.pdf
Wohlin, C., Höst, M. & Henningsson, K. (2003).Empirical Research Methods in Software Engineering.
ESERNET, pp. 7-23.
Presupuesto-CUC y SIRU, dos Experiencias de Desarrollo De

Software A La Medida Para Fortalecer La Gestión De La Universidad
De La Costa: Presentación De Resultados, Impactos, Dificultades y
Recomendaciones
Harold Arturo Combita Niñoa

a
Universidad de la Costa CUC, Facultad de Ingeniería
Barranquilla, Colombia
hcombita1@cuc.edu.co
Resumen. El presente articulo tiene como objetivo dar a conocer dos experiencias de desarrollo de
software a la medida realizados para fortalecer la gestión de la Universidad de la Costa (CUC):
Presupuesto-CUC y SIRU (Sistema de Información de Recursos Universitarios). El primero para
gestionar el presupuesto de la institución y el segundo para gestionar los recursos físicos y
tecnológicos. En este se denotan las diferentes necesidades administrativas, estratégicas y académicas
presentadas en la Universidad y la manera como el Desarrollo de software a logrado satisfacerlas con
impactos significativos, reflejados en la calidad de la información, optimización de procesos, ahorro
de tiempo y resultados exitosos que han contribuido al desarrollo y mejoramiento de la institución.
Se delimitan también las diversas dificultades presentadas en todo el proceso de diseño, desarrollo e
implementación y la manera como fueron subsanadas para cumplir a cabalidad con los resultados
propuestos. Experiencias claves que permiten establecer recomendaciones a Universidades que
tengan pensado iniciar o ya hayan iniciado un proyecto de desarrollo de software.
Palabras Clave: desarrollo de software, experiencias, casos de estudio, gestión universitaria,
software para universidades, presentación de resultados, lecciones aprendidas, impactos, dificultades,
recomendaciones, investigación.
49
1 Introducción
Las universidades de Latinoamérica, como entidades generadoras de conocimientos, deben ser los
principales agentes de innovación de la región. Alcanzando un desarrollo competitivo y productivo en la
institución y en el país. Además, promoviendo los procesos I+D+i (Investigación, Desarrollo e
Innovación) en el sector empresarial. A continuación presentaremos dos experiencias que ha tenido la
Universidad de la Costa en los últimos 3 años, en materia de innovación en software. Principalmente
atendiendo a la gestión universitaria y destacando su impacto en la estrategia y consecución de metas
institucionales. Queremos resaltar necesidades identificadas, soluciones propuestas, impactos generados,
dificultades encontradas y como estas fueron solucionadas.
1.1 Universidad de la Costa
Con el propósito de contribuir al desarrollo educativo regional a nivel superior, se creó el 16 de

Noviembre de 1970, la UNIVERSIDAD DE LA COSTA –CUC, entidad sin ánimo de lucro, dedicada a
la formación de profesionales en el área de la ciencia, la tecnología, las humanidades, el arte y la filosofía
[1]. Esta ubicada en la ciudad de Barranquilla (Colombia). En los últimos años ha trabajado fuertemente
en la acreditación de alta calidad, en fortalecer sus procesos de I+D+i e incrementar sus relaciones con el
sector empresarial. Para su crecimiento como institución ha sido consiente de la importancia que tiene
alinear la tecnología informática con la estrategia.
1.2 Desarrollo de Software en la Universidad de la Costa
Para fortalecer su proceso de desarrollo de software, la Universidad ha realizado un convenio

interinstitucional con la Fundación I+D+i. La entidad aliada, es un centro de desarrollo tecnológico que
integra en cada uno de sus proyectos, la dinámica I+D+i y las tecnologías de la información, para
afrontar los retos actuales que se presentan en las organizaciones. Cuenta con una unidad de desarrollo de
software certificada en Moprosoft.
La Fundación I+D+i ha desarrollado un framework llamado EXTIDI, que integra codeigniter y Extjs.
Contiene un ORM (Object-Relational mapping) que ha permitido el desarrollo a partir de modelos de
datos y generación automatizada de interfaces. Reduciendo considerablemente los tiempos que deben
invertirse en la etapa de codificación[2]. Lo que beneficia en los tiempos dedicados a otras etapas igual o
mas importantes. El framework permite el desarrollo por componentes, y en su base ya dispone de un
ACL (gestor de usuarios, roles y permisos) , gestor de módulos, escritorio web , uso de widgets, gestión
de parámetros del sistema, reporteador, integración con PDF y Excel, módulos de importación,
integración con directorio activo Windows e integración con el sistema académico de la Universidad de la
Costa.
2 Desarrollo de Software Web Para La Gestión del Presupuesto
Cada año, durante el mes de agosto, la universidad inicia un proceso de construcción del presupuesto
anual del siguiente año. El departamento de planeación a través de la unidad de presupuesto, es el
encargado de recolectar las necesidades presupuestales de cada dependencia, organizarlas, presentarlas al
concejo directivo, informar las aprobadas (o negadas), e integrarlas al sistema financiero[4]. Por cada
departamento hay un responsable de unificar, priorizar y presentar las solicitudes de presupuesto. El
proceso puede extenderse hasta finales del mes de diciembre.
Antes del año 2012, cuando aun no existía solución tecnológica como apoyo, todo era desarrollado a
través del llenado de formatos impresos. Para realizar una solicitud era necesario validar mas de 30
formatos y seleccionar el que mas se acomodaba a la necesidad a subsanar. Los formatos eran llenado a
mano y enviado a la unidad de presupuesto. El trabajo más complejo era para ésta dependencia, ya que
recibía en promedio 650 solicitudes, que poseían muchos errores y mas del 50% debían ser devueltos para
correcciones. Posteriormente, debían ser transcritas por computador a una tabla en Excel y organizadas de
forma manual. Luego de conocer que solicitudes fueron aprobadas, los informes eran desarrollados a
mano; la preparación de los archivos planos para SAP tomaban tiempo, ya que debían manipularse
códigos, fechas, valores y otros datos sensibles. Un error en una cifra podía impactar negativamente las
finanzas de la institución.
50
2.1 Resultados
Actualmente, proceso de construcción del Presupuesto CUC, esta sobre una plataforma web con
interfaces graficas amigables para el usuario. Que disminuyen los errores por parte de éste y reduce los
tiempos en cada fase del proceso. Iniciamos con la descripción del acceso que disponen los lideres de
dependecia. El usuario cuenta con dos pestañas en los cuales puede gestionar sus solicitudes y administrar
los avales de las solicitudes que le corresponde validar. En el primero puede ver, crear, modificar,
eliminar, imprimir, ver avales recibidos y enviar solicitudes. En el segundo puede ver las solicitudes de
otras dependencias, que le corresponde avalar, con la opción de ver los avales que ha recibido (si aplica)
de otras dependencias y realizar un comentario respectivo a la hora de avalar o no.
Al momento de crearse una solicitud, el usuario debe seleccionar el tipo de presupuesto (gasto e
inversión). Posteriormente debe seleccionar un formulario a utilizar. Solamente puede ver los formularios
a los cuales posee permisos. Existen tres tipos de formularios: sencillos, compuesto y proyectos. Los
primeros por lo general solicitan el llenado de texto que describe la necesidad y casillas para informar un
valor de presupuesto a solicitar. El formulario compuesto dispone de grillas para llenar varios elementos a
presupuestar en una misma solicitud. Un ejemplo de estos dos los podemos apreciar en la figura 1.
Fig. 1. Ejemplos de formulario sencillo, compuesto y proyectos respectivamente. El usuario debera indicar para que
objetivo del plan estrategico institucional esta relacionada la solicitud.
Las solicitudes de proyectos permite llenar información descriptiva y cuantitativa del proyecto y
anexar otras solicitudes al mismo. En la figura 2 tambien podemos apreciar la disposición de varias
pestañas, donde tambien se pueden anexar documentos como: fotografias, planos, entre otros.
Posteriormente se puede enviar la solicitud para que sea avalada (si aplica) por otras dependencias y
recepcionada por la unidad de presupuesto. En esta misma interfaz podra ver el resultado que obtuvo su
solicitud despues de la realización del concejo directivo. Y monitorear su presupuesto en el proximo años.
La Unidad de Presupuesto cuenta con un panel administrativo en el cual puede gestionar las
convocatorias de presupuesto, gestionar las solicitudes de cada convocatoria, gestionar el presupuesto de
personal (nómina), integrar cada solicitud a ordenes SAP, enviar mensajes, gestionar usuarios , ver
reportes y gestionar las dependencias (y los permisos de acceso a formularios).
En el modulo de gestión de solicitudes, el administrador puede modificar, aprobar, negar, colocar en
estudio, imprimir y ver los avales de las solicitudes enviadas por las dependencias. Para la revisión
realizada en el concejo directivo es clave la disposición de filtros por cada campo y la exportación a
excel, como podemos ver en la figura 2.
Fig. 2. Gestión de solicitudes. Los proyectos agrupan las solicites que tiene como anexos.
Finalmente en la sección de informes se le permite al administrador la generación de informes que son

enviados al ministerio de educación, reportes que son importados en SAP, y otros informes para las
directivas.
51
2.2 Impactos
El software de presupuesto ha estado en producción durante los últimos 3 años, impactando positivamente
en la construcción de unos de los documentos financieros más importantes y complejos de consolidar, al
momento de contar con mas de 80 dependencias que participan de este ejercicio. La creación del
presupuesto duraba mínimo 6 meses, antes del software, actualmente tiene una duración de 2 meses
máximo. Los errores humanos se han reducido a un 0%, gracias a un software comprometido con la
usabilidad, las validaciones desde los formularios y el desarrollo de sesiones de capacitación. Desde la
estrategia universitaria, el concejo directivo dispone de herramientas para la toma de decisiones de
inversión y priorización de gastos. Las directivas pueden conocer, el presupuesto de cada objetivo del
Plan Estratégico Institucional. Por otro lado, la unidad de presupuesto dispone de mayor tiempo para
orientar a los lideres de dependencia en la construcción de sus solicitudes, realizar un seguimiento en
tiempo real del procesos, sobre todo de los avales que eran los antiguos cuellos de botella. El envió de
alertas por correo ha permitido que cada año se logren mejores tiempos para el cierre del presupuesto.
El administrador ha dejado a un lado las actividades operativas para fortalecer la estrategia financiera
de la universidad, con la construcción de políticas, manuales y buenas practicas. La validación periódica
del proceso permite el desarrollo de mejoras del software, durante los meses en el que la convocatoria
esta cerrada. Finalmente, no podemos olvidarnos del impacto ambiental, importante para una institución
que esta comprometida con disminuir a gran escala el uso del papel.
2.3 Dificultades y Recomendaciones
El mayor reto presente en el desarrollo de este proyecto fue la fase de pruebas. Los datos que son
manipulados en el software corresponden a cifras de dinero e información importante de proyectos. Se
dispuso de un equipo especialmente destinado para el desarrollo de pruebas de sistema e integración, con
la generación de datos de prueba. Durante la primera convocatoria se identificó que los usuarios dejaban
para el ultimo día, la construcción del presupuesto, pensando en que la facilidad otorgada por el software
lo permitiría. Quedaba poco tiempo para que las dependencias pudieran avalar. Sin embargo, para la
segunda convocatoria se proponen mejores practicas en la construcción del presupuesto y el envío de
correos para recordar formularios que no han sido llenados y solicitudes que quedaron en construcción y
no han sido enviadas. Además, se dispone de una fase especial para el desarrollo de los avales, posterior
a la fase de desarrollo de solicitudes.
3 Desarrollo de Software Web Para Gestionar Los Recursos Universitarios
Lograr una alta eficiencia en el uso de los activos es un reto importante para las universidades, ya que
tiene un impacto significativo sobre los beneficios. Una buena gestión de los recursos físicos(salones,
laboratorios, salas de informática, entre otros) y tecnológicos (computadores, software, video-beans, entre
otros) le permite lograr alta productividad, competitividad y calidad. Hasta el año 2014 la Universidad
usó un software de escritorio para gestionar las reservas de su planta física. Éste solamente permitía
almacenar la información a través de un usuario. Este usuario era administrado por el coordinador de
planta física vinculado al departamento de planeación. Era el encargado de recibir solicitudes de reservas
a través de correo electrónico, en un formato hecho en Microsoft Office. Además, tenia que ingresar a
mano, la oferta académica y sus espacios reservado, que se asignaban y almacenaban en SICUC (sistema
de información académico de la universidad CUC). Se presentaban muchas inconsistencias como por
ejemplo: doble asignación de un mismo lugar a una misma hora a diferentes personas y demoras en
localizar espacios libres y en responder la solicitud al usuario. Sumado a esto, encontrábamos elaboración
manual de estadísticas de uso de espacios e informes de planta física. Por otro lado, las salas de
informática no contaban con un software para registrar la entrada y salida de sus usuarios. Tampoco
existía una base de datos unificada donde encontrar un inventario de recursos físicos y su uso en la
institución.
3.1 Resultados
La plataforma web SIRU (Sistema de Información de Recursos Universitarios) dispone de herramientas

en línea para gestionar el uso de la planta física y los elementos tecnológicos que se encuentran dentro de
las instalaciones. Se puede administrar la asignación de espacios para la oferta académica, permite la
realización de reservas en línea por parte de la comunidad académica, administrar los mantenimientos y
validar el uso real de los espacios reservados. En ésta se puede medir la gestión realizada sobre los 52
recursos físicos y tecnológicos, conociendo en tiempo real las asignaciones por recurso, asistencia y uso a
espacio físico, uso por programa y facultades, entre otros informes mas claves para la toma de decisiones.
Además tiene la posibilidad de integrarse con su sistema académico y con el sistema de carnet (para el
registro de uso del espacio físico).
Las categorías de recurso físico (ej.: salones, laboratorios, etc.) contienen recursos físicos (ej. Salón
301, laboratorio de física). Un recurso físico se caracteriza por sus propiedades (ej. Tiene aire
acondicionado, capacidad, etc.) e imágenes. Además, un recurso físico puede contener recursos
tecnológicos (ej. Computadores, video beam, etc.). Finalmente, un recurso tecnológico se le pueden
definir propiedades (ej. Software instalados, memoria RAM, etc.) Todas las categorías, propiedades y
demás definiciones anteriormente mencionadas son parametrizables en la plataforma.
El software permite definir departamentos, programas académicos, asignaturas, estudiantes (integrado
al sistema académico), bloques, categorías de recursos, recursos físicos y recursos tecnológicos. Además,
se puede configurar el calendario de disponibilidad, en el cual se podrán realizar asignaciones. Pero
principalmente permite: la gestión de la oferta académica y los recursos a utilizar y la gestión del proceso
de reservas de espacios, que puede ser realizada por usuarios internos o externos a la universidad.
En la figura 3 se puede apreciar el entorno de trabajo propuesto por SIRU, que cuenta con un
ambiente de escritorio y que posee una barra de herramientas en la parte inferior, un menú con las
funcionalidades organizadas en módulos y widgets de utilidades a la derecha del escritorio.
Fig. 3. Entorno de trabajo SIRU.
El sistema de información propone la centralización en un unico calendario en el cual se almacenan las

asignaciones. Una asignacion corresponde a un espacio de media hora de un recurso fisico en una fecha
especifica. Como podemos arpeciar en la figura 4 las reservas, los mantenimientos y la oferta academica
se integran en este.
Fig. 4. Calendario unificado de asignaciones SIRU.
Una reserva tiene secciones (ej: reservar un salon en dos secciones una el lunes 3 de abril a de 8am a
12m y otro el martes 4 de abril de 2pm a 4pm.) y puede tener recursos adicionales (ej: refrigerios).
Destacamos una herramienta que dispone SIRU para la busqueda de recursos, la cual podemos realizar a
partir de cualquiera de sus propiedades y/o atraves de las propiedades de los recursos tecnologicos que
contiene. Por ejemplo. Un docente puede localizar rapidamente una sala informatica con capacidad de 30
estudiantes, que tenga instalado AutoCad y que tenga video beam.
En cuanto a la oferta academica, como se aprecia en la figura 8, el software dispone de un panel con
un calendario semanal para asignar por cada recurso fisico, los bloques reservados para las asignaturas
ofertadas por la institución. Esta reserva es replicada automaticamente todas las semanas durante la
duración del semestre academico.
3.2 Impactos
El sistema de información SIRU ha permitido una completa automatización del proceso de reservas de
espacios físicos, donde los espacios son auto reservados por docentes y administrativos, sin la
preocupación de que existan cruces. El sistema de reportes ha permitido la toma de decisiones y la
estrategia orientada a la construcción de nuevos espacios. La validación del uso de los espacios ha 53
permitido planificar la construcción de nuevos recursos físicos de manera eficiente. La satisfacción de los
interesados ha aumentado, los usuarios pueden encontrar en pocos segundos el espacio que necesitan. Se
ha fortalecido las relaciones con el sector externo, permitiendo la reservación de los espacios de la
institución a las entidades con convenios, a través de la plataforma web. Por otro lado, se ha fortalecido la
construcción de la oferta académica y la asignación eficiente de los espacios necesarios.
3.3 Dificultades y Recomendaciones
El principal reto que propuso el proyecto fue la alta parametrización que este exige. Contar con un
framework de desarrollo como EXTIDI permitió el desarrollo de gran cantidad de módulos para la
definición de datos parámetros. Además tener en cuenta que esto exigía una fase de parametrización y
migración. Esta ultima es importante debido a que el software remplazaba un sistema legado.
Una dificultad presente fue la integración con el sistema académico institucional, que finalmente fue
resuelta satisfactoriamente a través de la generación de archivos planos. Cabe destacar que también se
realizo integración con el directorio activo de la universidad.
La solución SIRU es altamente recomendada para universidades en proceso de crecimiento, que se
encuentren en una etapa en la cual estén tomando decisiones importantes en tema de expansión y
construcción. Cabe destacar que se ha identificado un siguiente paso para fortalecer la solución, y es el
desarrollo de un proyecto de inteligencia de negocio, enfocado en la predicción y caracterización de las
reservas de recursos físicos.
7 Conclusiones
En este trabajo se ha presentado dos software significativos para la Universidad de la Costa. No siendo
los únicos productos que se han desarrollado dentro de la institución, el objetivo fue tomar alguna de estas
experiencias para resaltar las lecciones aprendidas en los procesos de desarrollo de software a la medida.
No cabe duda del alto grado de incertidumbre que tiene este tipo de proyectos en las instituciones. A esto
se le suma, la variedad de intereses y procesos en las distintas áreas y facultades académicas. Por tal razón
quisimos abordar diferentes casos, unos impactan mas en la estrategia y otros mas en la operación. Pero
todos son importantes para el crecimiento en competitividad y productividad de la Universidad[7].
Finalmente queremos hacer mención de otros experiencias fructíferas que ha tenido la Universidad de la
Costa junto con la Fundación I+D+i en desarrollo de software: Software Evaluación Docente, Software
de Autoevaluación y acreditación, Plataforma para la gestión del Plan estratégico institucional, Software
para la gestión de la investigación, Aplicación Móvil CUC, Software para Gestión Documental, Portales
Web Institucionales, Tienda Virtual Editorial Educosta, Plataforma Web para Egresados, Software para
procesos de practicas empresariales, Software para gestión de la deserción estudiantil, Software para
clima laboral, Software para la gestión del desempeño laboral y Plataforma LMS para la virtualidad.
Además actualmente nos encontramos en el re-diseño del software académico de la institución y el
desarrollo de un software Balance Score Card. No cabe duda que la Universidad de la Costa es una
Institución comprometida con el desarrollo tecnológico y la innovación en la gestión universitaria
apoyadas con TIC.
Referencias
1. Universidad de la Costa. Recuperado el 20 abril del 2015, de

http://www.cuc.edu.co/index.php?option=com_flexicontent&view=items&cid=38&id=63&Itemid=89
2. Xia, C., Yu, G., & Tang, M. (2009, December). Efficient implement of ORM (Object/Relational Mapping)
use in J2EE framework: Hibernate. In Computational Intelligence and Software Engineering, 2009. CiSE
2009. International Conference on (pp. 1-3). IEEE.
3. Vaillant, Denise. Construcción de la profesión docente en América Latina: tendencias, temas y debates.
Vol. 31. PREAL, 2004.
4. Burbano Ruiz, Jorge E., and Alberto Ortiz Gómez. "Presupuestos: enfoque moderno de planeación y
control de recursos." (1995).
5. Vera, Francisca Rosa Alamo. La planificación estratégica de las universidades: propuesta metodológica y
evidencia empírica. Diss. Universidad de Las Palmas de Gran Canaria, 1995.
6. Trujillo Barreto, C. N. A., Spíritus, U. C. S. B. S., Remedios, C. D. C. J. M., Titular, G. P., & Mayea, C. D.
C. T. H. TÍTULO: La autoevaluación institucional en la gestión de la calidad de los procesos universitarios.
7. Ibañez, J. S. (2008). Innovación educativa y uso de las TIC. Universidad Internacional de Andalucía.
54
Propuesta de un modelo para la Implementación

de un Sistema de Gestión del Conocimiento
en la Educación Dual
Omar Romero1, Katiuska Fernández1, Ricardo Raygoza1 y Sergio Ixmatlahua1
1 Instituto Tecnológico Superior de Zongolica, Av. poniente 7, 856, col. Centro, 94300, Orizaba, Veracruz,
México
{isc.romeroo, katiuska.fernandez, raygozc}@gmail.com, sergio.ixmatlahua@outlook.com
Abstract: Se propone un modelo para la implementación de un Sistema de Gestión del Conocimiento

en la Educación Dual, por medio del cual los usuarios pueden generar cuestionamientos sobre dudas
surgidas en la empresa donde realizan su proyecto integrador, con el fin de generar una base de datos
en la que participan múltiples actores, que aportan soluciones al cuestionamiento del usuario inicial,
quien tomando en cuenta la utilidad de la respuesta emitida, evalúa y retroalimenta a los
colaboradores, para generar competencias específicas. El presente estudio pretende responder: ¿Qué
aspectos de la educación dual pueden mejorar a través de la implementación de un modelo de gestión
del conocimiento? Tomando como base la Berufsakademie alemana, donde se tienen resultados de la
formación profesional que resulta de la fusión entre la empresa y las instituciones de educación
superior. La siguiente fase del proyecto contempla la elaboración del prototipo del sistema de gestión
del conocimiento.
Keywords: Gestión del conocimiento, Modelo Educativo Dual, educación superior, plataforma Web,
minería de datos, Tecnologías de la Información y la Comunicación
1 Introducción
En los años 60, las necesidades de las empresas que se ajustaban al proceso de integración europea y a la
globalización estaban enfocadas a la formación de capital humano idóneo (López-Hermoso, Montero,
Martín-Romo, De Pablos, Izquierdo y Nájera, 2000). Por esta razón se inició la implementación de un
modelo de formación para el trabajo con la idea de facilitar la capacitación a partir de la práctica en la
empresa, en conjunto con la formación teórica de la escuela. La base de este modelo se remonta al
método de aprendizaje de oficios de la época medieval que posteriormente fue adaptado a las necesidades
de la industria moderna y ha ido evolucionado como consecuencia de la cooperación entre la educación,
la industria y el comercio (Berufsakademie, 2009).
El Modelo Educativo Dual no es la solución a todos los problemas de formación, ni cubre todos las
deficiencias de los profesionales en el sector productivo, sin embargo, se reconoce como una estrategia de
formación universitaria que coadyuva en la preparación de profesionales que requieren amplia
experiencia en el campo laboral para complementar la formación científica y de investigación de la
instituciones educativas (Ferreyra, 1999).
El objetivo de la presente investigación es proponer un modelo de gestión del conocimiento para
satisfacer las necesidades o resolver los problemas que surgen en el binomio escuela/empresa dentro del
paradigma del Modelo Educativo Dual.
A continuación se presenta el estado del arte de la gestión del conocimiento, se vincula con el proceso
de educación dual y se plantea un modelo que permitirá generar una base de datos que será alimentada
por los mismos usuarios y que podrá ser consultada en una plataforma amigable utilizando la
categorización de los temas por perfil y por área.
2 La gestión del conocimiento y el Modelo Educativo Dual

2.1. Antecedentes de la gestión del conocimiento
Por conocimiento se entiende la presencia en la mente de ideas acerca de una cosa o cosas que se saben
de cierta. En concreto se puede entender por conocimiento como una combinación de idea, aprendizaje y
modelo mental. Por gestión se comprende la acción de administrar o aquélla que se realiza para la
consecución de algo. En suma, Gestión del Conocimiento es la función que planifica, coordina y controla
los flujos de conocimientos que se producen en la empresa en relación con sus actividades y con su
entorno con el fin de crear unas competencias esenciales (Bueno, 1999).
Dentro de los procesos de enseñanza aprendizaje, la GC es uno de los temas más relevantes en los
que intervienen las Tecnologías de la Información y Comunicación, ya que estas herramientas permiten a
múltiples usuarios interactuar en ambientes virtuales educativos, a través de plataformas de software que
facilitan la interacción que genera el conocimiento por medio de datos e información suministrada por
todos los participantes (estudiantes, docentes, profesionistas, etc.) de tal forma que estas aportaciones
alimentan la base de datos del sistema de gestión (Olga, Sanchez, Miguel, & Leguizamon, 2014).
La gestión del conocimiento involucra varios conceptos que intervienen en el proceso de enseñanza
aprendizaje bajo el contexto de los datos y la información, entendiendo como datos al conjunto de
elementos que se pueden representar y transmitir dentro de un proceso de comunicación, los cuales de
manera aislada no representan gran importancia, pues no pueden ser interpretados, pero que al converger
en un sistema puede generar información de valor.
La Información forma parte de un conjunto de datos contextualizados donde existe un componente
cognitivo, el cual puede impactar sobre juicios de valor y comportamiento, la información da forma al
conocimiento y permite ser utilizada y organizada para un propósito. De acuerdo con Olga, Sanchez,
Miguel & Leguizamon (2014) esta debe ser contextualizada, categorizada, calculada, corregida y
condensada para que pueda servir para la toma de decisiones.
En este contexto, el conocimiento es una aplicación consciente e inconsciente de la información que
se posee, dicha aplicación se realiza con base en la experiencia personal, según Daveport & Prusak (1999)
es una mezcla de experiencia, valores información y ―know how‖ que sirve como base para la aplicación
de nuevas experiencias e información útil para determinada situación, pues la mezcla de varios elementos
da origen a una estructura más compleja, la cual puede ser formalizada.
Cada persona tiene cierto conocimiento existente como parte de su ser y el conocimiento viene a partir
de la información, de la comparación, de la correlación y la experiencia.
El conocimiento también tiene una clasificación de dos tipos (Nonaka & Takeuchi, 1995):
Conocimiento Tácito: el cual poseen las personas como producto de las experiencias personales de un
contexto, sin embargo, es difícil de transmitir, reproducir, materializar, estructurar y almacenar; su forma
más común de transmisión es frente a frente.
Conocimiento Explícito: este tipo de conocimiento puede ser codificado de alguna manera y permite
ser articulado en un lenguaje formal y transmitirse con relativa facilidad entre individuos utilizando
herramientas tecnológicas.
56
2.2 Modelo Educativo Dual
En la dualidad escuela-empresa, se admite a la segunda como una nueva escuela, donde el estudiante
aprende mediante la práctica en situaciones o problemas reales de un puesto de trabajo, ya que ofrece la
posibilidad de aplicar los principios teóricos que un individuo aprende en la institución educativa, y a su
vez, permite confrontar con la realidad del medio todos los conceptos abordados dentro del aula.
Este modelo se inició en el año 1971, con la implementación en Daimler-Benz que solicitó el apoyo al
Ministerio de Cultura de aden-W rttemberg para que se fomentara entre los estudiantes una cultura para
desarrollar competencias profesionales que les permitieran más oportunidades de éxito dentro de la
industria que las que ofrecía, en su momento, el sistema educativo tradicional. Así se formaron las
llamadas Berufsakademie en Alemania, con la finalidad de ampliar la oferta y la cobertura de educación
superior, con la idea de atender a estudiantes con la necesidad de satisfacer la formación con enfoque
práctico y la necesidad de contar con colaboradores altamente profesionalizados y motivados para
compartir el conocimiento con los aprendices (Berufsakademie, 2009).
El Modelo Educativo Dual en la base curricular, humanística y tecnológica, a partir de una
perspectiva filosófica, epistemológica, psicopedagógica y socioeconómica, conlleva a la necesidad de
actualización del docente y la orientación hacia la innovación, por lo que es importante tomar en cuenta
las aptitudes y actitudes de los seres humanos y su necesidad constante de formación.
Queda establecido así, que la educación dual se fundamenta en la actividad educativa a partir del
proceso de enseñanza-aprendizaje en el campo laboral, y que en esa capacitación de los recursos
humanos se establece una relación teórica-práctica a partir de la integración del conocimiento y la
experiencia. De tal forma que se lleva la escuela hacia las organizaciones, dada la necesidad de
enriquecer el potencial del recurso humano mediante la formación académica y práctica, lo cual es
fundamental para el logro de profesionales altamente calificados.
En este proceso de formación intervienen tres figuras imprescindibles: el estudiante, la empresa y la
institución educativa:
1. El estudiante, es el actor principal hacia quien se orientan todas las acciones de los
proyectos que se plantean en este modelo pedagógico.
2. La empresa, es quien adquiere el papel de entidad formadora a partir de la actividad

didáctico-productiva, la cual por medio de un asesor interno lleva a cabo la enseñanza en un
puesto de trabajo. En este caso, dicho asesor asume la responsabilidad de transferir
conocimiento en la práctica.
3. La institución educativa es representada por los docentes que trabajan como asesores de
cada proyecto, quienes tienen la responsabilidad de orientar o guiar la enseñanza académica de
los estudiantes en coordinación con el resto de los docentes del Instituto.
Desde esta perspectiva, el papel del docente en la educación dual debe destacarse como mediador del
proceso de educación técnica y profesional, creando situaciones de aprendizaje que pongan al estudiante
en una situación crítica, donde tenga un papel protagónico para reflexionar y analizar cómo aprende,
cómo resuelve los problemas, cómo satisface sus necesidades y qué le falta en su comportamiento como
ser humano a partir de la práctica por medio de sus vivencias y experiencias.
Aunado a este modelo pedagógico de formación dual, el estudiante desarrollará por medio del
aprendizaje situado, un proyecto integrador por semestre. Esta idea tiene su base en la Teoría del
Aprendizaje Situado donde se postula que existe una relación entre el aprendiz y el contexto, por ello,
para que el aprendizaje sea efectivo, el aprendiz debe estar activamente envuelto en una situación real.
Este modelo educativo tiene una connotación vivencial, ya que el aprendizaje se reconstruye cuando
se utiliza en situaciones reales, por lo que se considera a la Teoría del Aprendizaje Situado para
fundamentarlo teóricamente (Sagástegui, 2004).
2.3 Beneficios del sistema de gestión del conocimiento al Modelo Educativo Dual
Hoy en día, es fundamental otorgar valor al conocimiento que se genera en las organizaciones, porque
éste ayuda a satisfacer las necesidades del entorno y a responder a las exigencias de la constante
evolución de la tecnología. Por esta razón, se estima que un sistema gestor del conocimiento puede
coadyuvar al desarrollo de los estudiantes del modelo dual porque la concepción de este tipo de
herramientas va encaminado a alimentar las bases de datos que se originan en las organizaciones y que se
utilizan para integrar el pensamiento colectivo reflejado en la práctica. Es así como el Modelo Educativo
Dual se verá beneficiado por la información obtenida a través de la experiencia de los participantes,
quienes coadyuvarán en la concentración de datos interrelacionados que servirán para que los estudiantes 57
que participan en el modelo educación-trabajo puedan exponer dudas, consultar opciones de respuesta
y retroalimentar las aportaciones de los colaboradores para auxiliar en la existencia del conocimiento
colectivo que se evidencia en la actitud y el comportamiento de los integrantes de cualquier institución.
2.4 Requisitos para la implementación de un modelo gestión de conocimiento para la educación

dual.
 Un consenso entre los diversos actores implicados en el Modelo Educativo Dual y en la

forma de implementación de esta.
 Un compromiso por parte de la empresa en el modelo de gestión del conocimiento,
correspondiente a la disponibilidad de adaptarse a esta propuesta, además de apoyar a
los alumnos a incorporarse a los procesos productivos.
 Capacitación a los actores involucrados para el uso de la plataforma (alumnos,
profesores, investigadores, empresa, empleados, etc.), lo anterior permitirá acortar la
brecha digital en ambas instituciones para poder generar el conocimiento colaborativo
esperado.
3 Modelo de Gestión del Conocimiento para la Educación Dual (MGCED).

Se propone un modelo para la implementación de un sistema de gestión del conocimiento en la educación
dual (ver Figura 1), por medio del cual los usuarios pueden generar cuestionamientos sobre los problemas
o situaciones que ocurren en la empresa donde realizan su proyecto integrador.
Lo anterior con el fin de generar una base de conocimiento transversal donde participan activamente
múltiples actores (alumnos, profesores, investigadores, empresarios, empleados, etc.), lo que conlleva a la
generación de conocimiento colaborativo, donde dichos usuarios aportan soluciones al cuestionamiento
realizado por el primer actor.
Tomando en cuenta la utilidad de la respuesta el usuario inicial evalúa y retroalimenta a los
colaboradores, llegando así a la generación de nuevas competencias específicas.
Fig. 1. Modelo para el sistema de gestión del conocimiento.
3.1 Componentes del MGCED
Usuario con competencias previas: Se trata de cualquier actor que se encuentre involucrado en el
Modelo Educativo Dual (alumnos, profesores, investigadores, empresarios, empleados, etc.) a quien en 58
algún momento le puede surgir una duda dentro del proceso productivo.
Necesidad de competencias específicas: El Modelo Educativo Dual se fundamenta en el aprendizaje
situado, donde de forma vivencial el usuario con competencias previas (genéricas o específicas) se
relaciona con procesos y procedimientos de los que surgen necesidades o problemas que requieren de
ciertas competencias específicas de un área de conocimiento determinado.
El usuario inicial por medio de un sistema de gestión del aprendizaje (LMS por sus siglas en inglés)
ingresa su duda a la plataforma de gestión del conocimiento, clasificando previamente según el perfil y el
área correspondiente.
Conocimiento Colaborativo: Cuando el usuario inicial genera una pregunta detonadora, el sistema
emite una alerta vía correo electrónico o ventana emergente donde se da aviso a los participantes sobre la
existencia de un cuestionamiento por resolver.
Los usuarios que tienen las competencias necesarias para resolver la interrogante del usuario inicial,
realizan aportaciones que ayudan a solucionar la duda, generando así un conocimiento colaborativo,
donde múltiples usuarios participan activamente tomando como base las experiencias previas.
Evaluación y retroalimentación: El usuario inicial recibe notificaciones cuando otros usuarios
responden a su cuestionamiento y posteriormente, según la utilidad de las sugerencias para la resolución
del problema, el usuario aplica las soluciones propuestas por los colaboradores hasta encontrar una
idónea para satisfacer su necesidad, teniendo así la opción de retroalimentar y a su vez enriquecer el
sistema de gestión del conocimiento que se construye con el trabajo colaborativo de los participantes.
Posteriormente, tiene la posibilidad de evaluar las respuestas con base en una escala del 1–10, donde uno
es la calificación más baja (y señala menor utilidad) y 10 es la más alta.
Generación de nuevas competencias: Cuando el usuario inicial pone en práctica la solución elegida,
involucra otro aspecto importante del Modelo Educativo Dual, se trata del aprendizaje significativo, que
se da cuando el individuo involucra los conocimientos y las experiencias previas que posee con los
nuevos conocimientos adquiridos en el campo laboral para resolver problemas o satisfacer necesidades.
Lo anterior coadyuva a la generación de nuevas competencias en el individuo inicial, logrando así
resolver la interrogante emitida al inicio del proceso, misma que alimenta la base de datos del sistema
gestor del conocimiento, para que en ocasiones posteriores pueda ser consultada por otros usuarios que se
enfrenten con situaciones iguales o similares.
3.2 Relación entre los componentes
El usuario inicial genera la pregunta detonadora en el sistema gestor del aprendizaje (plataforma) esta será
expuesta en un foro, en el cual estarán participando activamente (tanto asincrónica como
sincrónicamente) los usuarios colaboradores.
La plataforma que se propone para sustentar el sistema de gestión del conocimiento es Moodle, ya que
es un software de código abierto que utiliza el paradigma constructivista, permite además la
personalización e incorporación de un módulo para crear perfiles e implementar métodos de evaluación,
además tiene el soporte para la implementación de foros y realizar la clasificación por diferentes áreas, a
través de etiquetas.
Por medio de las herramientas mencionadas anteriormente la plataforma permite la generación de
conocimiento colaborativo, para que los usuarios que cuentan competencias necesarias puedan apoyar a la
resolución de problemas planteados por el usuario inicial, este último, evaluará cada una de las propuestas
de solución con base en la utilidad para la resolución de su incógnita, así, una vez resuelto su problema,
tiene la opción de retroalimentar a los demás colaboradores sobre cuál fue la respuesta con la que pudo
resolver su interrogante o en su caso informar acerca de alguna contribución que haya realizado.
Una vez implementada la solución, el usuario inicial generó un nuevo conocimiento que a su vez
queda almacenado en la base de datos del sistema, para que en caso de que posteriormente otro usuario se
le presente el mismo problema, solo tenga que realizar la búsqueda por palabras clave para verificar la
solución que ya ha sido probada e implementada satisfactoriamente.
3.3 Arquitectura por capas para el MGCED
De acuerdo al análisis del MGCED se propone una arquitectura en capas (ver Figura 2) con la intención
de facilitar la integración y flexibilidad de cada uno de los elementos que lo conforman, los diferentes
niveles en que se divide la arquitectura se presentan a continuación.
En el primer nivel, denominado capa de presentación, se encuentra la interfaz para la comunicación y
colaboración de los diferentes actores que interactúan en el sistema a través de la plataforma.
El segundo nivel denominado capa de Tecnología de la Información y Comunicación (TIC), tiene dos
subcapas:
59
 En la primera de ellas se encuentra la plataforma Moodle con los diferentes
componentes que servirán para realizar los cuestionamientos, dar seguimiento y
valoración a cada una de las respuestas a través de foros, wikis y etiquetas, además por
medio de mencionada plataforma se crearán los distintos perfiles usuario que ocuparan
también otras herramientas como chat y mensajería para su comunicación.
 En la segunda subcapa se encuentra el sistema gestor de conocimiento, que por
medio de minería de datos, se realiza un análisis y clasificación de la información, la
cual se alimenta de las aportaciones de cada usuario así como de las valoraciones
realizadas por el actor que realiza el cuestionamiento.
En el tercer y último nivel se detalla la capa de datos, en la cual se encuentra almacenada la

información de los perfiles de cada usuario, así como repositorios digitales que servirán de apoyo a los
actores del sistema en los cuestionamientos realizados, también se almacena un bando de proyectos
realizado alimentado por dichos usuarios y que servirán de base para futuros proyectos.
Fig. 2. Arquitectura por capas para el MGCED.
60
4 Trabajos a futuro
Levantamiento de requerimientos: Se analizarán requisitos funcionales y no funcionales para la
plataforma, además de los requisitos en general del sistema de gestión de conocimiento, que incluye
desde que un actor inicial detona una pregunta hasta la evaluación y retroalimentación del usuario inicial
para alimentar la base de conocimiento.
Prototipo: Haciendo uso de la plataforma Moodle y sus componentes se crea un prototipo del sistema
gestor del conocimiento, donde los usuarios por medio de foros participarán activamente para la
resolución de problemas o situaciones surgidas en el ámbito laboral o escolar, logrando de esta manera
enriquecer la base de datos de conocimientos.
Implementación del sistema gestor: La implementación se llevará a cabo en una institución
educativa de nivel superior donde ocupen el Modelo Educativo Dual ya que se involucran múltiples
usuarios tanto de la parte educativa como de la empresa. La plataforma estará en la nube para que todos
los usuarios involucrados en este proceso tengan acceso y puedan aportar y enriquecer el sistema de
gestión de conocimiento.
Evaluación del sistema: Una vez implementada la plataforma por un semestre en una institución
académica que ocupa el Modelo Educativo Dual se procederá a verificar los resultados obtenidos en
cuanto a la generación de una base de datos de conocimiento y la utilidad que esta pueda tener para todos
los actores que figuran en los procesos, a partir del cual se genera una serie de recomendaciones en base a
la experiencia obtenida.
Los usuarios actualizarán constantemente la base de datos de conocimiento conforme se vaya
haciendo uso del sistema, ya que entre más activamente participen todos los usuarios, se enriquecerá la
mencionada base de datos.
5 Conclusiones
Con base en la pregunta de investigación ¿qué aspectos de la educación dual pueden mejorar a través de
la implementación de un modelo de gestión del conocimiento? Se propone la implementación de la
herramienta MGCED, con el propósito de innovar los procesos educativos y mejorar la calidad de la
formación, generando una base de conocimiento relacionada con dicho modelo educativo, donde se
utilice la plataforma Moodle y sus componentes, tales como: foros, wikis, etiquetas, etc., para que a través
de esta herramienta los usuarios expongan sus dudas con la intención de que otros colaboradores aporten
posibles soluciones a los problemas que se les presentan en la práctica, generando así nuevas
competencias entre los usuarios y, además, se genera y se enriquece la base de datos que puede ser
utilizada por cualquier miembro de la comunidad académica.
El desarrollo de esta propuesta busca generar conocimiento a partir de las experiencias que los
alumnos viven en la empresa ya que éstas se constituyen como oportunidades de aprendizaje práctico, que
es precisamente donde se fundamenta el Modelo Educativo Dual, mismo que se caracteriza por efectuar
la mayor parte del aprendizaje dentro de la empresa, mediante la realización de tareas cotidianas y
específicas según el área. Además, este trabajo práctico enriquece el sistema gestor de conocimiento y
contribuye así para mejorar la producción de la propia empresa y al aprendizaje de otros usuarios.
6 Referencias
Alario, C., Pérez, M., & Delgado, C. (2013). El MOOC Canvas, 1–8.
Añez, C. (2005). El capital intelectual: nuevo enfoque dela flexibilización laboral. Revista Venezolana de Gerencia,
10(30).
Bueno, E. (1999). La gestión del conocimiento: Nuevos perfiles profesionales.
Berufsakademie. (2009). Documento síntesis. Fundamentos, principios y funcionamientos. Consultado en
http://www.uniempresarial.edu.co/assets/documentos/1.pdf
López-Hermoso, J., Montero, A., Martín-Romo, S., De Pablos, C., Izquierdo, V. y Nájera, J. (2000). Informática
aplicada a la gestión de empresas. Madrid: Universidad Rey Juan Carlos.
Nonaka, I y Takeuchi (1995). The knowledge creating Company. Oxford: Oxford University Press
Olga, I. N. G., Sanchez, N., Miguel, I. N. G., & Leguizamon, A. (2014). Propuesta para la gestión del conocimiento
en entornos virtuales. Universidad pedagógica y tecnológica de Colombia, 1–17.
Pérez, B. (n.d.). El trabajo metodológico en la educación superior. Un enfoque desde la gestión del conocimiento y el
aprendizaje organizacional.
Sagástegui, D. (2004). Una apuesta por la cultura: el aprendizaje situado. Revista Electrónica Sinéctica, (24), 30–39.
Consultado en http://www.redalyc.org/articulo.oa?id=99815918005
Sandoval, C. (2013). Propuesta para implementar un sistema de gestión del conocimiento que apoye el diseño de un
curso online. Proposal to Implement a Knowledge Management System to Support the Design of an Online
Course. 21(3), 457–471. http://doi.org/10.4067/S0718-33052013000300015. 61
Uribe-Tirado, A., Melgar-Estrada, L.-M., & Bornacelly-Castro, J.-A. (2007). Utilización de Moodle en la gestión de
información, documental y del conocimiento en grupos de investigación. El Profesional de La
Informacion, 16(5), 468–474. http://doi.org/10.3145/epi.2007.sep.09
Propuesta de un modelo para la integración de las MiPyMES,

Sociedad y Gobierno a través del uso de las TIC de la Zona
Metropolitana del Valle de Orizaba, Veracruz
Ricardo O. Raygoza1, Sergio D. Ixmatlahua1 y Omar Romero1.
1 Departamento de Sistemas y Computación, Instituto Tecnológico Superior de Zongolica,

94300, Orizaba, Veracruz, México
raygozc@gmail.com, sergio.ixmatlahua@outlook.com, , isc.romeroo@gmail.com
Resumen. Se propone un modelo de integración de MiPyMES - Sociedad – Gobierno (MIMSG), con

el objetivo de disminuir la brecha digital y aumentar la competitividad de estos sectores a través del
uso de las TIC en la zona metropolitana de Orizaba, Veracruz. El modelo incluye el desarrollo de
herramientas tecnológicas para contribuir con el fortalecimiento socioeconómico de la región a través
de plataformas Web abiertas para el acceso a la información, así como la oferta de productos y
servicios, comerciales y gubernamentales implementando modelos de negocio en Internet como el e-
Commerce. El artículo inicia describiendo la plataforma Web Metrópoli Digital y los diferentes
modelos de e-Commerce, luego se describe el modelo propuesto, las interacciones entre sus
elementos y la integración de las TICs para su implementación.
Palabras clave: Tecnologías de la Información, Plataformas Web abierta, comercio electrónico,
MiPyMES, sociedad, Gobierno TI.
Abstract. A model for the integration of MSMEs , Society and Government (MIMSG), with the aim
of reducing the digital gap and increase the competitiveness of these sectors through the use of ICT in
the metropolitan area of Orizaba , Veracruz is proposed. The model includes the development of
technology to contribute to the socio-economic strengthening of the region through open access to
information tools Web platforms as well as the tender of products and services, not just commercial
but governmental, implementing Internet business models such as e- Commerce . The article begins
by describing the Digital Metropolis Web platform and the different models of e- Commerce, then the
proposed model describes the interactions between the elements and the integration of ICT for
implementation
Keywords: Information Technology and Communication, open Web platforms, e-commerce, small
business, society, government IT.
1 Introducción
Es indudable que las herramientas tecnológicas se han convertido en un factor indispensable para alcanzar
mejores condiciones de bienestar social. Las TIC en la actualidad son un pilar en el desarrollo
competitivo de México, la competitividad de un país está ligada íntimamente al uso y
aprovechamiento de las TIC.
Ninguna otra tecnología como la Internet se ha desarrollado tan rápido en la región, esto en parte,
gracias a la generalización del uso de dispositivos móviles con acceso a Internet. Sin embargo, en lo que
respecta a América Latina en comparación con países desarrollados el uso sigue siendo poco rentable y
prevalece principalmente el rol de consumidores pasivos. La importancia la Internet en la economía es
muy grande, representa entre el 0.5% al 5.4% de países en desarrollo y contribuye entre 1.7% y 6.3% en
economías más avanzadas (CEPAL, 2015).
Los estudios estadísticos sobre los usuarios de Internet y el impacto económico (Palacios, 2012), dejan
claro que el rol de usuarios de la Internet, desde un enfoque pasivo, no refleja grandes beneficios
socioeconómicos; por lo que resulta necesario generar modelos que permitan generar un marco de trabajo
en el que faciliten un mayor aprovechamiento real del uso de la Internet y tenga un impacto en sectores
como las MiPyMES, Sociedad y Gobierno.
En este contexto, el artículo presenta la propuesta de un modelo denominado MIMSG (Modelo para
la Integración de las MiPyMES, Sociedad y Gobierno en el uso de las TIC); un modelo que incluye el
desarrollo de herramientas tecnológicas para contribuir con el fortalecimiento socioeconómico de la
región a través de plataformas Web abiertas para el acceso a la información, MIMSG incluye modelos de
e-Commerce para generar interacciones que permitan la integración de los usuarios de Internet
pertenecientes a los distintos sectores a través del uso de las TIC para lo que se cuenta con el desarrollo
de la plataforma Web Metrópoli Digital (Ixmatlahua et al., 2015) para la implementación del modelo..
3 Marco teórico
En este apartado se describe cada uno de los conceptos principales que dan fundamento a la propuesta que
se presenta en este artículo, cabe mencionar que la descripción de Metrópoli Digital forma parte de un
trabajo previo al desarrollo del modelo propuesto.
3.1 Metrópoli Digital
Metropóli Digital es una plataforma Web libre que implementa un modelo de negocio cuyo objetivo
principal es la integración digital de las MiPyMES, Sociedad y Gobierno bajo un esquema integral
permitiendo así la reactivación del flujo económico de estos sectores, a través del uso de las TI como
medio principal de intercambio de información y servicios digitalizados (Ixmatlahua, et al., 2015). En ese
sentido, Metrópoli Digital implementa un modelo de negocio que permite ofrecer servicios digitales tales
como: publicidad en línea, subscripción, e-Commerce, geolocalización, trámites de Gobierno.
Metrópoli Digital al ser una plataforma Web, ha sido desarrollada con el uso de herramientas Open
Source, dentro del estándar Open Web Platform establecido por la W3C (W3C, 2014). Dicho estándar
define el uso de herramientas de desarrollo tales como HTML5, CSS, Ajax, Patrones de Diseño Web,
Arquitecturas Software, que habilitan a la plataforma para estar disponible utilizando cualquier
dispositivo con acceso a Internet tales como computadoras de escritorio, televisiones interactivas,
smathphones, tablets u otros dispositivos.
3.2 e-Commerce
Por medio del comercio electrónico personas y negocios ofrecen bienes o servicios y realizan 63
intercambios diariamente, e-Commerce genera tendencias y modifica las costumbres del comercio físico.
De tal forma, el comercio electrónico así como el comercio físico según (Kotler, 2007) son una
combinación de 4 factores: Promoción, Pedido, Pago y Distribución o entrega.
De este modo la diferencia de los comercios electrónicos y los comercios físicos es que los cuatro
factores mencionados anteriormente se hacen a través de medios virtuales, dependiendo del tipo de
producto que sea. Este tipo de comercio es algo relativamente nuevo comparado con el comercio
tradicional, y ofrece una serie de ventajas muy importantes tales como la disponibilidad, los productos y/o
servicios están disponible a cualquier hora, en cualquier lugar y la posibilidad de expansión a lugares
remotos.
El e-Commerce abarca diferentes clasificaciones, para identificarlos fácilmente se describen los
diferentes modelos que comprende el e-Commerce, de acuerdo a Kotler, a continuación:
 B2B (Business to Business): de empresa a empresa. Involucra las transacciones electrónicas

entre dos negocios.
 B2C (Business to Consumer): De empresa a consumidor o cliente. Son las transacciones entre
negocios y consumidores en internet.
Las transacciones mencionadas son las clasificaciones para la compra o adquisición de bienes y servicio
más comunes, sin embargo existen también diferentes formas de comercio en Internet tales como:
 C2C (Consumer to Consumer): De consumidor a consumidor. Involucra transacciones realizadas

entre consumidores.
 C2B (Consumer to Business): Este modelo representa las transacciones de clientes a empresas,
es muy similar al modelo B2C pero en este caso el consumidor es el vendedor y la organización
la compradora.
Del mismo modo también existen clasificaciones que involucran entidades Gubernamentales y con
empresa y consumidores (Garza, G. P., 2001):
 G2C (Government to Consumer): Este modelo permite ofrecer a las instituciones

gubernamentales servicios en línea útiles a los ciudadanos, tales como servicios administrativos.
 B2G (Business to Government): Este modelo permite la venta en línea de productos y servicios
al gobierno. Entre las principales características de este modelo de negocios, destacan la
transparencia en el desarrollo de convocatorias y licitaciones, mayor rapidez en el desarrollo de
los trámites; el gobierno puede encontrar los mejores precios y condiciones de pago.
4 Propuesta del modelo MIMSG
El MIMSG (Modelo de Integración de las MiPyMES, Sociedad y Gobierno en el uso de las TIC), es una
propuesta que tiene como objetivo principal proveer un esquema que coadyuve al desarrollo económico,
tecnológico y social de estos tres sectores, generando un valor agregado. Conforme a lo mencionado se
establece una estructura para el intercambio de información, mediante el impacto de las TIC, incluyendo
mejora de la productividad, reducción de costos y ventajas competitivas (Nigel, et al., 2004).
La estructura interna del MIMSG se fundamenta en tres partes principales: modelos de e-Commerce
(B2B, B2C, C2C y G2C), sectores socioeconómicos (MiPyMES, Sociedad y Gobierno) y las TIC (a
través de la plataforma Metrópoli Digital, Internet, dispositivos electrónicos con acceso a Internet). Con
base a lo anteior, MIMSG propone la utilización de las herramientas TIC por parte de los sectores
socioeconómicos, así como la implementación de modelos de negocio de e-Commerce que permitan la
compra – venta de productos y/o servicios en línea que los negocios, usuarios oferten y trámites de
gobierno en línea que ofrezcan los Ayuntamientos de los municipios que integran la Zona Metropolitana
del Valle de Orizaba.
En la Fig. 1, se observa graficamente la estructura general de MIMSG, en el cual se representa las
relaciones entre los diversos elementos del modelo. Es decir, los sectores socieoeconómicos, las entidades
digitales (modelos de e-Commerce) y el uso de las TIC.
64
Fig. 1. Modelo de Integración de MiPyMES, Sociedad y Gobierno en el uso de las TIC
4.1 Componentes del modelo
Como se observa en la Fig. 1, el modelo está compuesto por sectores socioeconómicos, modelos de
negocio de e-Commerce, una plataforma tecnológica y el uso de las tics. En esta sección se describe cada
uno de los componentes que integra el modelo propuesto.
Sectores
En esta primera versión del modelo se contemplan tres sectores involucrados en la plataforma:
 MiPyMES: Se contemplan las micros, pequeñas y medianas empresas de la zona Metropolitana

de Orizaba que requieran ofertar productos o servicios, a otras empresas o a la población en
general, a través del uso de las TIC.
 Sociedad: Conjunto de usuarios que usan las TIC y que tienen interés en diversos rubros como
compra/venta de productos y/o servicios, entretenimiento, cultura, negocios, clima, deportes etc.
 Gobierno: Se refiere a los municipios pertenecientes a la zona Metropolitana de Orizaba Ver., de

los cuales se pretende digitalizar sus principales servicios, a través de aplicaciones Web y
móviles, con el objetivo de ofrecer a la Sociedad acceso e información util de sus municipio.
E-Commerce
Es el componente central del modelo, internamente contiene los modelos de negocio de comercio
electrónico con los que se pretende detonar la participación e interacción de los sectores del MIMGS,
mediante herramientas de TIC que implementen una forma ágil de poner en línea y sin dificultades sus
productos y/o servicios. La implementación de los modelos de e-Commerce tienen como meta el dar,
tanto a las MiPyMES, Sociedad como al Gobierno, medios digitales de interacción entre sí, para que ellos
mismos oferten, sus productos y/o servicios a través de estas herramientas de TIC. Dichas herramientas
de TIC estarán diseñadas bajo los modelos que comprenden al e-Commerce, tales como Business to
Consumer, Business to Government, Consumer to Consumer y Business to Business.
Metrópoli Digital
El componente tecnológico que está conformado por un conjunto de herramientas de TIC, es Metrópoli
Digital que formará la base que dará el acceso al intercambio comercial, gubernamental y social que el
MIMGS ofrece a los usuarios de Internet. Metrópoli Digital está basada en estándares reconocidos por la
W3C como el Open Web Platforms, así como también, comprende una serie de aplicaciones móviles para
permitir el acceso a la información desde cualquier dispositivo móvil, e interfaces para conectividad con 65
diversas tecnologías por medio de servicios Web. Es Metrópoli Digital es la base tecnológica que da el
sustento tecnológico para la implementación, por lo tanto juega un papel importante dentro del modelo.
Tecnologías de la Información y Comunicación
Dentro del MIMSG representa la comunicación a través de una infraestructura de telecomunicaciones que
va desde una computadora, hasta la gran infraestructura que tiene Internet. El uso de las TIC es el
componente transversal que incluye las herramientas tecnológicas de acceso al Internet para MiPyMES,
Sociedad y Gobierno mantendrán una interacción para consumir y compartir información que va desde un
dispositivo móvil como smartphones, tablets y laptops de los usuarios, hasta los recursos de Metrópoli
Digital que sustentan el modelo.
4.2 Interacción entre los componentes
Cada uno de los componentes que integra al MIMSG asumen un rol determinante para su
funcionamiento. Estos componentes mantienen una interación entre sí, y aportan capacidades o
características al funcionamiento de los demás. A continuación se describen las responsabilidades e
interacciones entre cada uno de los componentes.
Los sectores socioeconómicos son la parte que detonarán el flujo de la información hacia todos los
componentes del modelo, debido a que son los que proveerán de los datos que entre ellos compartiran.
Estos sectores provee y utilizan la información que ellos mismo generan, esto a través del uso de las TIC,
desde el uso de un dispositivo móvil, una computadora personal o de escritorio, tablet.
En este sentido, la mayor parte de la contribución directa será generada por los usuarios finales,
mediante un esquema que incluirá todas las herramientas tecnológicas a disposición de los actores
principales de los 3 sectores (MiPyMES, gobierno y sociedad) quienes estarán habilitados para
interactuar activamente, a través de las herramientas proporcionadas y la conectividad de Internet.
Para alcanzar este nivel de participación e interacción de los sectores mencionados se desarrollan
varias herramientas de TIC (ver tabla 1). En esta se muestran los diferentes sectores y hacia qué sector
está orientada cada una de las aplicaciones así como la funcionalidad para la cual serán desarrolladas,
conforme al MIMSG.
Tabla 1. Fases de herramientas a desarrollar como parte del modelo integrador.
Sociedad MiPyMES Gobierno

App, plataforma Web App, plataforma Web App, plataforma Web
 Noticias y notificaciones en  Catálogo de productos y  Servicios municipals a
tiempo real, servicios ciudadanos
 Catálogo avisos oportunos  Geolocalización de MiPyMEs  Servicios municipales a
MiPyMES
 Recomendación y  Envío de ofertas y  Pago de servicios en línea
valoración de productos y promociones
servicios
 Acceso a contenidos e  Portal de comercialización e-  Servicios de mensajes y alertas al
intercambio de información Business ciudadano
 Queja ciudadana  Pago de productos y/o servicios  Servicios de mensajes y alertas a
en línea MiPyMES
 Contenido educativo  Bolsa de trabajo
 Difusión turística
Cabe mencionar que actualmente se cuenta con aproximadamente un 40% de las herramientas que
apoyan al modelo integral. Se estima que para mediados de 2016, se tenga el 100% de las aplicaciones,
esperando cumplir con el objetivo del modelo propuesto y por ende su validación.
5 Conclusiones y Trabajos a futuro
En México, la experiencia en el uso de modelos que ayuden a integrar a través de las TICs a los sectores
socioeconómicos es escasa, aún más en la zona metropolitana del valle de Orizaba Ver., donde no existe
prácticamente ninguno, y los que se encuentran documentados no ofrecen un modelo orientado a la
regionalización de la información, por otro lado, los usuarios hacen uso de la tecnología de forma 66
superficial, sin embargo hace falta la explotación de los avances tecnológicos como medios para integrar
los sectores económico y social de la región.
Es por ello que en este trabajo se propone el MIMSG como factor que contribuya al fortalecimiento
socioeconómico, el cual se fundamenta en el uso de las TICS en los sectores Comercio, Sociedad y
Gobierno con el fin de ayudar a una ágil interacción entre dichas entidades por medio de la plataforma
Metrópoli Digital y los usuarios de la Internet, de esta manera también se pretende disminuir la brecha
digital que existe actualmente, además de ayudar a generar competitividad y presencia en los medios
electrónicos, de los cuales se benefician los usuarios.
Por último, el MIMPS se encuentra en fase de desarrollo, por lo que se pretende establecer un marco
de mejora continua para determinar si los componentes que lo conforman son los adecuados. Como
trabajo a futuro, MIMSG se realizará un análisis de acuerdo al grado de interacción por parte de los
propietarios del proyecto, para determinar el grado de impacto del modelo, se definirán indicadores que
permitan evaluar su objetivo, beneficios, fortalezas y debilidades, entre otros aspectos que surjan durante
su implementación, finalmente se realizará un diagnóstico conforme a los resultados obtenidos de acuerdo
a los indicadores.
Referencias
Agudelo, R, Bello, P & Rojas, E. .F. (2015). El Ecosistema Y La Economía Digital En América Latina. España:
Editorial Ariel.
Douglas K Barry. (2015). Web Services Explained. 16-03-2015, de Barry & Associates, Inc. Sitio web:
http://www.service-architecture.com/articles/web-services/web_services_explained.html.
Garza Gorostieta, Mario. (2001). De la. Promoción de ventas : estrategias mercadológicas de corto plazo. México,
D.F. : CECSA, 2001. xxiii, 202 p.
Hess, C. (1995). The virtual CPR: the Internet as a local and global common pool resource, 1995(June). Recuperado a
partir de http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.4429&rep=rep1&type=pdf
Hutchison, D., & Mitchell, J. C. (2009). The Future Internet. http://doi.org/10.1007/978-3-642-20898-0
Ixmatlahua, S. D., Raygoza, R. O., Romero, O., & Vargas, E. J. (2015). Metrópoli Digital : Una plataforma Web para
la inclusión integral de las PyMES , Sociedad y Gobierno en el uso de las Tecnologías de la Información en la
región de las Altas Montañas del estado de Veracruz, México. Revista Ibérica de Sistemas Y Tecnologías de La
Información, E3. http://doi.org/10.17013/risti.n.pi-pf
Kotler, P. (2007). Marketing. (P. Prentice Hall, Ed.). Decimoprimera Edición. México. Retrieved from
http://www.terras.edu.ar/aula/tecnicatura/11/biblio/KOTLER-Philip-ARMSTRONG-Gary-Cap17.pdf.
Palacios, Jena; Flores-Roux, E. (2012). Diagnóstico del sector tic en México: conectividad e inclusión social para la
mejora de la productividad y el crecimiento económico, 1–76. Retrieved from: http://imco.org.mx/wp-
content/uploads/2013/1/diagnosticosectorticenmexico_sept2012_2.pdf
Philippe le Hegaret. (2011). "100 Specifications for the Open Web Platform and Counting". 01-29-2015, W3C.
http://www.w3.org/QA/2011/01/100_specifications_for_the_ope.html
Thomas, D. Martin, J. (2003). Process Modeling for E-Business. 20/03/2015, de George Mason University.
Unión internacional de telecomunicaciones. (2003). Construir la sociedad de la información un desafío global para el
nuevo milenio. Accedido el 1 Agosto, 2015, from http://www.itu.int/wsis/docs/geneva/official/dop-es.html
W3C Working Group. (2000). Simple Object Access Protocol. 2014/07/25, de World Wide Web Consortium Sitio
web: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
W3C Working Group. (2014). Open Web Platforms. Wold Wide Web Consortium. Sitio Web:
http://www.w3.org/standards/
67
Sistema de detección de emociones para la recomendación de

recursos educativos
Agustín Job Hernández Montes1, Raquel Vasquez Ramirez2, Giner Alor Hernández 3, Beatriz
Alejandra Olivares Zepahua4, Guillermo Cortés Robles5, Ignacio López Martínez6
División de Estudios de Postgrado e Investigación, Instituto Tecnológico de Orizaba,

Avenida Oriente 9 No. 852 Col. Emiliano Zapata
Orizaba, Veracruz, México, Orizaba
1agus_job@hotmail.com, 2omeg_22@hotmail.com, 3galor@itorizaba.edu.mx
4bolivares@ito-depi.com, 5gc_robles@hotmail.com,6nachouno@hotmail.com
Abstract. Actualmente existen diversos repositorios de recursos educativos los cuales brindan apoyo
a los estudiantes en el proceso de enseñanza-aprendizaje. No obstante uno de los problemas que se les
presentan a los estudiantes al hacer búsquedas específicas de recursos en diferentes repositorios es
que se encuentran con un gran número de resultados y en ocasiones pierden demasiado tiempo para
seleccionar un recurso o no encuentran lo que necesitan. En este trabajo se presenta EmEdRe un
sistema de recomendación de recursos educativos basado en técnicas de computación afectiva que
permite localizar recursos educativos con base en un análisis de los sentimientos del estudiante
haciéndolo adaptable a las necesidades del usuario.
Keywords: Análisis de sentimientos, computación afectiva, sistemas de recomendación.
1 Introducción
El crecimiento exponencial de información en la Web dificulta la exploración e identificación de recursos

que satisfagan las necesidades de un usuario, en los últimos años han surgido repositorios de recursos
educativos como apoyo a los estudiantes con deficiencias en conocimiento (Aguila, 2010).
Desafortunadamente en ocasiones es necesario buscar en diversos repositorios ya que uno solo no es
suficiente para encontrar los recursos que el estudiante necesite, este puede tomar demasiado tiempo y no
alcanzar el objetivo deseado el cual es encontrar diversos recursos que deben cubrir las demandas de una
materia o tema en específico que el estudiante necesite. Los sistemas de recomendación son herramientas
que generan sugerencias sobre un determinado objeto de estudio, a partir de las preferencias y opiniones
dadas por otros usuarios (Beltrán Páez Germán, 2015). El filtrado colaborativo basa sus recomendaciones
sobre las calificaciones o el comportamiento de otros usuarios en el sistema, esta técnica asume que si a
un grupo de usuarios les gustan las mismas cosas que el usuario activo ―X‖ por lo tanto al usuario ―X‖ es
probable que le gusten las cosas que todavía no ha visto de aquellos usuarios (Michael D. Ekstrand,
2015). Los sistemas de recomendación han tenido un fuerte impacto en diferentes áreas como son
medicina, entretenimiento, comercio electrónico, educativa entre otras (Betancur, 2009) (Castillejo,
2007).
Los sentimientos son el resultado de las emociones y significan un estado de ánimo afectivo que se
presenta en una persona, las emociones son expresiones psicofisiológicas, bilógicas y de estados
mentales, también se pueden definir como adaptaciones del individuo a estímulos provocados por el
entorno, se ha demostrado que las emociones afectan en la mayoría de las actividades humanas entre las
cuales están la creatividad, la toma de decisiones y la comunicación (Barrón-Estrada, 2014). En lo que
respecta al análisis de sentimientos, se hace uso de la computación afectiva la cual es de suma
importancia en el desarrollo de EmEdRe permitiendo que el estudiante se sienta más cómodo adaptando
las recomendaciones a su estado de ánimo. La Computación Afectiva (Affective Computing) es una
disciplina de la Inteligencia Artificial que intenta desarrollar métodos computacionales orientados a
reconocer emociones humanas y generar emociones sintéticas (Causa, 2007).
Para la solución a estos problemas se presenta EmEdRe, la importancia que tiene el desarrollo de este
sistema es brindar al estudiante un apoyo para la búsqueda de recursos educativos de diversos repositorios
permitiendo ahorrase tiempo y además haciendo dichas recomendaciones a partir de su estado de ánimo
mediante un análisis de sentimientos.
Este documento está estructurado de la siguiente manera, en la Sección 2 se presenta el estado del arte
referente a los diversos trabajos relacionados con los sistemas de recomendación y computación afectiva.
En la sección 3 se describe la arquitectura del sistema EmEdRe. En la sección 4 se presentan el proceso
de generación de recomendaciones. En la Sección 5 se presenta un caso de estudio generación de
recomendaciones de recursos educativos. En la Sección 6 se presentan las evaluaciones, finalmente en la

Sección 7 se presentan las conclusiones y trabajo a futuro.
2 Estado del Arte
A continuación se presenta una revisión del estado del arte sobre los trabajos relacionados con los
sistemas de recomendación y computación afectiva.
2.1 Sistemas de recomendación aplicaciones y enfoques
En (Hsu, 2013) se propuso un enfoque de aprendizaje móvil de idiomas basado en recomendaciones

personalizadas. El sistema de aprendizaje móvil proporcionaba un mecanismo de recomendación de
material EFL (Inglés como Lengua Extranjera) de lectura para guiar a los estudiantes a leer los artículos
que se ajusten a sus preferencias y niveles de conocimiento teniendo de referencia los gustos de los
demás estudiantes. En (Pera, 2011) se desarrolló PBRecS, un sistema de recomendación de libros
basado en las interacciones sociales e intereses personales para sugerir libros a los usuarios. PBRecS está
basado en las amistades establecidas en LibraryThing, para generar sugerencias más personalizadas
dependiendo de las amistades del usuario. En (Yang, 2013) (Nieto, 2007) se presentaron estudios y una
descripción acerca de las técnicas y tipos de filtrado colaborativo. Adicionalmente se presenta también un
análisis de los algoritmos y métricas ocupadas en el filtrado colaborativo que permiten el desarrollo de
sistemas de recomendación.
2.2 Implementación de técnicas de computación afectiva
En (Liu, 2013) se presentó un estudio realizado a la importancia que tiene la computación afectiva en la
educación a distancia y se presentaron algunos estudios realizados al aprendizaje de los estudiantes por
medio de la obtención de emociones mediante el reconocimiento facial, fisiológico y auditivo lo cual
permitía ajustar las clases y maestros observando los resultados de sus emociones adaptando clases a los 69
gustos del estudiante. En (Tzu-Wei Tsai, 2012) se desarrolló un juego con varios niveles de dificultad que
utiliza material de aprendizaje adaptativo, los niveles del juego están desarrollados para adaptarse a la
habilidad de cada estudiante haciendo uso de emociones faciales. El juego identifica a través de los gestos
del usuario el nivel de dificultad para adaptarlo a cada estudiante. En (Barrón-Estrada, 2014) (Yasmín
Hernández, 2013) se presentaron sistemas tutores inteligentes STI para el aprendizaje de números
naturales de 3er grado y capacitación para operadores de sistemas eléctricos, los STI eran configurados
por expertos en la materia para lograr una enseñanza optima a los estudiantes y operadores, permitiendo
así mediante técnicas de computación afectiva adaptarse al entorno a través de la deteccion de gestos y asi
determinar si el usuario estaba comprendiendo, los STI se adaptan a lo que los usuarios necesitan para
que la comprensión de los diferentes temas que sepresentaban fuera mas sencilla.
Mediante estas investigaciones se obtuvo una idea mas clara de cómo trabajan los sistemas de
recomendación con el filtrado colaborativo y la computación afectiva en el ámbito educativo y se
determinó que hasta el momento no hay una herramienta que integre estas dos tecnologías, con estas
tecnologias se logran recomendaciones mas precisas y adaptables a las necesidades del usuario mediante
la deteccion de sentimientos.
3 EmEdRe: Arquitectura
EmEdRe (Emotional Education Recommendation) es un sistema de recomendación basado en filtrado
colaborativo y computación afectiva. El objetivo de este sistema es realizar recomendaciones de recursos
educativos permitiendo al usuario ahorrarse tiempo en la búsqueda de material que sea de ayuda para
cubrir sus necesidades.
3.1 Descripción de la Arquitectura
La arquitectura de EmEdRe está diseñada en 3 capas para organizar los componentes y distribuir las
tareas y funcionalidades, los componentes están desarrollados a partir de las necesidades que se
identificaron a lo largo del desarrollo del proyecto. La arquitectura se muestra en la figura 1. Cada capa
contiene componentes que tienen funciones específicas las cuales se explican a continuación:
Fig. 1. Arquitectura de 3 capas sistema EmEdRe.
Capa de presentación: Esta capa presenta un conjunto de interfaces con las que cuenta EmEdRe la
cuales se desarrollaron en HTML5, CSS3, JavaScript. Esta capa es la que permite al usuario interactuar
con el sistema permitiendo hacer búsqueda de los recursos educativos y presentando la información
organizada.
Capa de servicios: Esta capa está formada por 2 módulos, el primer módulo llamado análisis
sentimental contiene la API de Rekognition que permite obtener datos sobre la imagen de un rostro,
dejando saber al analizador de imágenes el estado de ánimo del estudiante, los datos de cada foto tomada
se envían al procesador de resultados donde se obtiene un promedio de los sentimientos analizados. El
segundo módulo llamado recomendaciones es donde se encuentra la API de Apache Mahout que se ocupa
de procesar los datos obtenidos por el módulo de análisis sentimental y aplicar los algoritmos necesarios
para hacer la recomendaciones. Este módulo esta encapsulado en un servicio Web en Java el cual se
invoca mediante el protocolo SOAP desde un sistema Web desarrollado en PHP para realizar dichas
operaciones y obtener un resultado, el analizador de peticiones es el encargado de dirigir al módulo
correspondiente dependiendo si el usuario tiene Webcam y se tomaron las fotos, se envían al módulo de 70
sentimientos o en caso contrario al módulo de recomendaciones.
Capa de datos: Esta capa contiene los diversos repositorios en donde están contenidos los recursos
educativos con los cuales trabaja EmEdRe.
4 Proceso de generación de recomendaciones
En la Figura 2 se presenta el proceso de generación de recomendaciones y se explican cada uno de los

pasos involucrados.
Fig. 2. Proceso de recomendación.
1) El usuario accede a la interfaz de EmEdRe para hacer una búsqueda de un recurso introduciendo
un criterio. De los resultados obtenidos selecciona el recurso educativo que se adapte más a lo
que necesite.
2) En el transcurso de tiempo en el que observa el recurso hasta el cierre de la ventana donde se

encuentra, se toman diversas fotos de la cara del usuario con la Webcam y se almacenan para
enviarse al módulo de análisis de sentimientos (solicitando permisos para dichas fotos). En el
caso de que el usuario no disponga de una Webcam se omite este paso.
3) El usuario realiza la calificación del recurso que acaba de utilizar de acuerdo a su criterio.
4) Las imágenes se envían al módulo de análisis de sentimientos.
5) Se analizan las fotografías del usuario mediante la API de Rekognition la cual permite conocer
do el estado de ánimo del usuario y se envían los resultados al módulo de recomendaciones
(Orbeus ReKognition).
6) En el módulo de recomendaciones se procesa la información obtenida por el módulo de análisis
de sentimientos y por la calificación que el usuario otorgó al recurso educativo. Mediante el uso
de la API de Apache Mahout el filtrado colaborativo ocupara una técnica basada en memoria ya
que se emplean métricas de similitud para saber la semejanza entre un conjunto de usuarios y
realizar las recomendaciones (Apache).
5 Caso de estudio: Generación de recomendaciones de recursos educativos
En esta sección se presenta un caso de estudio como prueba de concepto de EmEdRe. El caso de estudio
presenta el funcionamiento del sistema de recomendación EmEdRe mostrando las recomendaciones que
se brindaron a un estudiante que ingreso un criterio de búsqueda de la asignatura de matemáticas, en la
figura 3 inciso a), se presentan los resultados, un tagcloud con los criterios de búsqueda más regulares de
recursos educativos y un sidebar con los recursos más vistos y mejor calificados.
71
Fig.3. Interfaces de EmEdRe.
En la figura 3 inciso c), se presenta una descripción general del recurso educativo seleccionado por el
usuario incluyendo una url para acceder al contenido del recurso. Después de que el estudiante ingresa al
contenido del recurso, se llevan a cabo las operaciones anteriormente descritas en el proceso de
generación de recomendaciones, el estado de ánimo ocupa un factor importante en las recomendaciones
de EmEdRe ya que con éste se conoce de manera clara si el recurso satisface o no al usuario, así como
también las emociones en concreto del estudiante las cuales son: feliz, triste, sorpresa, enojo, serio,
confusión y disgusto; éstas son todas las emociones que se identifican con la API de Rekognition.
En la figura 4 se presenta un ejemplo grafico de la forma de trabajar de la API de Rekognition y la
información que presenta, dicha información es recolectada después de procesar las fotos mediante la
API haciendo llamadas desde el módulo de análisis sentimental. La información se presenta en formato
JSON (JavaScript Object Notation) y esta se recolecta para determinar el sentimiento del usuario y se
envía al módulo de recomendaciones.
Fig. 4. Ejemplo uso de la API de Rekognition
En este caso en concreto se determinó mediante el análisis sentimental que el estudiante presentaba un
estado de ánimo de enojo y confusión por lo cual en la figura 3 inciso b), se presentan tres
recomendaciones realizadas al estudiante las cuales son materiales interactivos, ya que al presentar un
estado de ánimo de molestia y confusión se pretende mejorar su estado de ánimo mostrando recursos
interesantes e interactivos.
6 Evaluación
Para evaluar los algoritmos de filtrado colaborativo que contiene la API de Apache Mahout se realizó el
cálculo de ―Precisión‖ y ―Recall‖ (Exhaustividad) del dataset Book-Crossing el cual contiene las
calificaciones que varios usuarios han dado a diversos libros, este cuenta con 278858 usuarios, 1149780
calificaciones que han dado los usuarios a los libros y 271379 libros. La Precisión se entiende como la
probabilidad de que un elemento seleccionado sea relevante o no y el Recall se entiende como la
probabilidad de que sea seleccionado un elemento relevante. Las fórmulas para calcular cada una de estas 72
evaluaciones se muestran a continuación:
|{ } { }|
|{ }|
|{ } { }|
|{ }|
La evaluación se realizó obteniendo los datos que arrojaban las diferentes métricas que son correlación de
Pearson, coseno, distancia Euclidiana, haciendo pruebas de búsqueda de un libro de un usuario en
específico, se hicieron las mismas búsquedas con las distintas métricas de similitud y a partir de esto se le
realizaron las recomendaciones pertinentes. Con esto se permitió conocer la ―precisión‖ de las
recomendaciones y el ―recall‖ de cada métrica utilizada.
Cabe hacer mención que sin las métricas de similitud entre usuarios las recomendaciones no tendrían
sustento. Por esta razón, es de suma importancia tener estas métricas que permitan al sistema conocer las
similitudes de los gustos entre los usuarios y así permitir realizar las recomendaciones (Sean Owen,
2011). Los datos ocupados son todos de tipo numéricos y para realizar las evaluaciones correspondientes
se ocuparon: el id del usuario, el id del libro y la calificación que el usuario dio al libro. Con esto se
observa en la figura 5 los resultados obtenidos de cada métrica de similitud, donde se encontró que la
métrica que dio mejores resultados fue la correlación de Pearson.
La correlación de Pearson es un número entre -1 y 1 que mide la tendencia entre dos series de
números, emparejados uno a uno, para moverse juntos. Esto quiere decir si la distancia entre un numero
con otro es larga el valor será -1 y entre más cercanos estén, el valor se acercará cada vez más a 1 (Sean
Owen, 2011). Los resultados obtenidos muestran que la Correlación de Pearson obtuvo resultados más
satisfactorios.
Así también la correlación de Pearson solo considera las asociaciones entre los estudiantes con
mismos recursos vistos, en caso contrario no hace los cálculos ya que si los hiciera a pesar de no tener los
mismos recursos vistos se daría una información menos precisa por la falta de datos entre los usuarios lo
cual disminuiría la precisión de las recomendaciones.
Fig. 5. Evaluaciones de las métricas de similitud.
Uno de los inconvenientes de la distancia Euclidiana es que es sensible a las unidades de medida de las
variables esto se refiere a que las diferencias entre los valores altos de los datos contribuirán en mucha
mayor medida que las diferencias entre los valores de las variables con valores bajos y esto da como
consecuencia de ello los cambios en la escala que determinarán también cambios en la distancia entre los
estudiantes presentando datos no tan precisos (Introducción al análisis de clusters). En el caso del Coseno
no presenta alguna desventaja o algún inconveniente cabe mencionar que la implementación de esta
métrica en la API de Apache Mahout presentan resultados bastantes semejantes a la de correlación de
Pearson por lo cual en (Sean Owen, 2011) se hace la recomendación de ocupar la métrica de correlación
de Pearson.
7 Conclusiones y trabajo a futuro
En este trabajo se presentó EmEdRe el cual aporta una integración de tecnologías para realizar
recomendaciones, en la actualidad no hay un sistema con estas características, se comprendió en el
desarrollo de este sistema que en la actualidad la búsqueda de la precisión y ahorro de tiempo son muy
importantes conociendo la cantidad de información tan extensa que se encuentre en la Web, así como
también el uso de la computación afectiva sirve de ayuda para la toma de decisiones. Los resultados 73
finales en el uso de las evaluaciones de ―precisión‖ y ―recall‖ mostraron que las recomendaciones del
algoritmo de correlación de Pearson son más precisas que los demás algoritmos ya que se ajusta más a
datos numéricos. Como trabajo a futuro se pretende desarrollar un módulo que permita diferenciar el
estado de ánimo del estudiante después de la recomendación se plantea como mejora una mejora al
sistema.
8 Agradecimientos
Este trabajo es apoyado por el Consejo Nacional de Ciencia y Tecnología (CONACYT), Tecnológico
Nacional de México (TecNM) y la Secretaria de Educación Pública (SEP) a través de PRODEP.
9 Referencias
Aguila, J. V. (2010). Distribución de conocimiento y acceso libre a la información con Recursos Educativos Abiertos
(REA). La educación.
Apache. (s.f.). Apache Mahout. Recuperado el 18 de Mayo de 2015, de https://mahout.apache.org
Barrón-Estrada, M. L.-C.-O.-P.-A. (2014). Un tutor inteligente, afectivo y configurable para el aprendizaje de
números naturales de 3er grado.
Beltrán Páez Germán, G. G. (10 de Julio de 2015). Sistema Recomendador Basado En Filtrado. Obtenido de
http://www.enid.unal.edu.co/2012/memorias/fscommand/tecnologias/59.pdf
Betancur, D. M. (2009). Modelo para la recomendación y recuperación de objetos de aprendizaje en entornos
virtuales de enseñanza/aprendizaje Recommendation and retrieval model of learning object in virtual
environments for teaching/learning. Revista Avances en Sistemas e Informática, 6(1).
Buder, J. &. (2012). Learning with personalized recommender systems: A psychological view. Computers in Human
Behavior.
Castillejo, M. M. (2007). El sistema GRADE para la toma de decisiones clínicas y la elaboración de recomendaciones
y guías de práctica clínica. Atención primaria, 39(9), 457-460.
Causa, E. &. (2007). La computación afectiva y el arte interactivo. área Transdepartamental de Artes Multimediales,
52.
Cearreta, I. &. (s.f.). Aplicación de la Ontología Affinto para el Desarrollo de un Sistema de Conversación Emocional
por Texto.
Chia-Cheng, H. H.-C.-K.-M. (2012). A personalized auxiliary material recommendation system based on learning
style on Facebook applying an artificial bee colony algorithm. Computers and Mathematics with Applications.
Herrera-Viedma, E. P. (s.f.). Sistemas de recomendaciones: herramientas para el filtrado de información en Internet.
Hsu, C.-K. H.-J.-K. (2013). A personalized recommendation- based mobile learning approach to improving the
reading performance of EFL students. Computers & Education.
Introducción al análisis de clusters. (s.f.). Recuperado el 27 de 05 de 2015, de
http://www.uv.es/ceaces/multivari/cluster/CLUSTER2.htm
Jorgue Hernández, A. G. (2013). Emociones artificiales usando mecánica cuántica. Computacion afectiva, 2(5), 22-
26.
Kaklauskas, A. Z. (2013). Recommender System to Analyze Student's Academic Performance. Expert Systems with
Applications.
Liu, J. T. (2013). Affective Computing Applications in Distance Education. In 2013 the International Conference on
Education Technology and Information System.
Lungu, V. (2011). A framework for developing embodied intelligent agents with affective behavior.
Michael D. Ekstrand, J. T. (15 de Julio de 2015). Collaborative Filtering Recommender Systems. Obtenido de
http://files.grouplens.org/papers/FnT%20CF%20Recsys%20Survey.pdf
Nieto, S. M. (2007). Filtrado colaborativo y sistemas de recomendación. Inteligencia en Redes de Comunicaciones.
Madrid.
Orbeus ReKognition. (s.f.). Orbeus ReKognition API. Recuperado el 18 de Mayo de 2015, de Orbeus ReKognition
API
Paula N. Medina, O. S.-C. (2013). Desarrollo de un avatar animado con expresión de emociones basicas.
Computación Afectiva, 2(5), 6-10.
Pera, M. S.-K. (2011). Personalized Book Recommendations. WISE 2010 Workshops.
Sean Owen, R. A. (2011). Mahout in Action. Manning.
Tzu-Wei Tsai, H. Y.-S. (2012). An affective computing approach to develop the game-based adaptive learning
material for the elementary students. In Proceedings of the 2012 Joint International . New York.
Xu, Y. G. (2012). Combining social network and semantic concept analysis for personalized academic researcher
recommendation. Decision Support Systems.
Yang, X. G. (2013). A survey of collaborative filtering based social recommender systems. Computer
Communication.
Yasmín Hernández, G. A.-F. (2013). Comportamiento afectivo en sistemas de capacitación inteligente para
operadores de sistemas electricos. Computación Afectiva , 2(5), 16-18.
74
Propuesta de contenido y controles de seguridad para un sitio

web de un CSIRT
Heltton Ramírez, Jezreel Mejía
Centro de Investigación en Matemáticas CIMAT A.C. Unidad Zacatecas

Av. Universidad No. 222, Fracc. La Loma
C.P. 98068, Zacatecas, Zacatecas, México
{heltton.ramirez, jmejia}@cimat.mx
Reseumen: En este artículo se describe la propuesta de contenido y controles de seguridad para un

sitio web de un CSIRT. Un CSIRT está conformado por un grupo de expertos en seguridad de la
información el cual provee de servicios como alertas y advertencias, tratamiento de incidentes,
observatorio de tecnología, auditorías de seguridad, cómputo forense, entre otros. Por lo tanto, tiene
comunicación constante con el público objetivo mediante correo electrónico, teléfono y su sitio web.
Un sitio web sirve como principal contacto con el público objetivo, es por ello que al crear un sitio
web para el CSIRT se debe tomar especial cuidado con las tecnologías a utilizar y aplicar controles de
seguridad con el fin de evitar posibles ataques informáticos los cuales pueden poner en riesgo la
reputación del CSIRT. En este artículo se describen conceptos fundamentales, la definición del
contenido del sitio web del CSIRT, la selección de tecnología para el desarrollo del sitio web, la
revisión sistemática para obtener los controles de seguridad y una propuesta de contenido y controles
de seguridad para el sitio web del CSIRT.
Palabras Clave: CSIRT, CERT, sitio web, seguridad, controles de seguridad, Wordpress.
1 Introducción
De acuerdo con el director general de Smart [1], empresa mexicana de seguridad informática, ―los
ataques a sitios web fue uno de los riesgos más comunes a los que se enfrentan las empresas de
seguridad en internet en México‖ ya que a nivel mundial existen más de 35 grupos de criminales
informáticos activos, los cuales cuentan con anonimato y ubicuidad para robar información y controlar los
portales. Esto hace suponer que México no se escapa como blanco de ataques informáticos. Según portal
de la organización FIRST del inglés Forum of Incident Response and Security Teams, en México
únicamente existen 4 CSIRTs por lo que se considera un número pequeño a comparación de países como
USA que cuentan con 70 CSIRTs (FIRST, 2015). Es por ello que las labores de los CSIRTs son
fundamentales debido a la creciente operatividad en delincuencia informática. Para el establecimiento de
un CSIRT, trabajos como (ENISA, 2006) (Centro Criptológico Nacional, 2013) (Proyecto AMPARO,
2012) (Penedo, 2006) especifican recursos tecnológicos que son necesarios para su funcionamiento, entre
los cuales se encuentra el sitio web. Para muchas personas, el primer contacto que se tiene para un CSIRT
se realiza mediante el sitio web (Penedo, 2006). En ella se encuentra información como la misión, visión,
servicios, datos de contacto y publicaciones sobre avisos de seguridad así como manuales para la
concientización de la seguridad informática (Software Engineering Institute, 2014).
Sin embargo, hasta el momento no se ha estandarizado el contenido ni los controles de seguridad que
debe tenerse en consideración durante el desarrollo del sitio web de un CSIRT. Es por ello que en este
artículo se propone el tipo de contenido, la tecnología y los controles de seguridad para el sitio web de un
CSIRT (concretamente Wordpress), con la finalidad de establecer un portal web más seguro para evitar
posibles ataques informáticos los cuales pueden poner el riesgo la reputación del CSIRT. Para establecer
la propuesta, se ha recolectado información a través de una revisión sistemática, una inspección de sitios
web oficiales del portal FIRST con un Web Scraping y extrayendo información de sitios web del mismo
portal con un web scanner.
Este artículo está estructurado de la siguiente manera: la sección 2 muestra conceptos fundamentales,
la sección 3 muestra el contenido de un sitio web de un CSIRT, la sección 4 muestra cómo fue la
selección de tecnologías para el sitio web, la sección 5 muestra cómo fue la revisión sistemática para
obtener los controles de seguridad del sitio web del CSIRT, la sección 6 muestra la propuesta de
contenido y controles de seguridad para un sitio web de un CSIRT y al final conclusiones y trabajos
futuros.
2 Conceptos fundamentales
Antes de presentar el desarrollo de la propuesta de este artículo, es importante establecer los conceptos
principales que se usan dentro de esta propuesta, como lo son CSIRT, sitio web, controles de seguridad y
Web Scraping.
2.1 CSIRT
Un CSIRT (Computer Security Incident Response Team) es un equipo especialista en seguridad de la

información dedicados a responder incidentes de seguridad informática (Centro Criptológico Nacional,
2013). El termino CSIRT es el que se suele usar en lugar del término protegido CERT, registrado en
EE.UU, por el CERT Coordination Center( CERT/CC) (ENISA, 2006).
Se usan diferentes abreviaturas para el mismo tipo de equipos:
 CERT o CERT/CC: (Computer Emergency Response Team / Coordination Center, equipo de
respuesta a emergencias informáticas / Centro de coordinación).
 CSIRT: (Computer Security Incident Response Team, equipo de respuesta a incidentes de
seguridad informática).
 IRT: (Incident Response Team, equipo de respuesta a incidentes) .
 CIRT: (Computer Incident Response Team, equipo de respuesta a incidentes informáticos)
 SERT: (Security Emergency Response Team, equipo de respuesta a emergencias de seguridad).
2.2 Sitio web
Una página web o sitio web se compone de objetos. Un objeto es simplemente un archivo, puede ser
HTML, una imagen, un applet de Java o un clip de video. Todo objeto web es alcanzable mediante un
único URL (Uniform Resourse Locator, localizador uniforme de recursos), el cual es la forma más común
de identificar un recurso Web. Un URL identifica de manera precisa y sin ambigüedades los nombres de
hosts, el número del puerto y la ruta completa del objeto en ese servidor web .
La información que viaja del servidor HTTP hacia el usuario que solicita la información de la pagina lo
hace mediante XML, HTML entre otros, y la información es visualizada mediante el navegador del 76
cliente. La seguridad en el sitio web se compone de varios aspectos trabajando en conjunto como lo son el
programador, el administrador, la configuración del sitio web y las herramientas utilizadas (Allen, 2001).
2.3 Controles de seguridad
También llamadas Salvaguardas por la metodología Magerit (Esquema Nacional de Seguridad, 2012) los
controles de seguridad son mecanismos de protección frente amenazas, reduciendo la frecuencia de las
amenazas y limitan el daño causadas por éstas. Pueden ser buenas prácticas, software o hardware.
2.3 Web Scraping
Web Scraping es el proceso de automatizar la recolección de información útil de portales web (Vargiu &
Urru, 2013). Esto se hace mediante programas de software los cuales extraen información simulando la
navegación de un ser humano en la World Wide Web ya sea utilizando el protocolo HTTP.
Una vez establecidos los conceptos básicos, en la secciones siguientes se describen cómo se identificó el
contenido que se recomienda tener un sitio web de un CSIRT, como se obtuvo las tecnologías a utilizar
para el desarrollo del sitio web y los controles de seguridad pertinentes para proteger el sitio web.
3 Contenido de un sitio web para CSIRT

El propósito de esta sección es de obtener elementos del contenido de un sitio web de para CSIRT. Es por
ello que se realizó un análisis a la propuesta de contenido hecha en (Uribe, 2014) mediante un Web
Scraping, la cual contempla elementos que se recomienda tener en la página web de un CSIRT mostrados
en la Tabla 1 y un análisis de 10 sitios CSIRT/CERT oficiales mostrados en la Tabla 2.
3.1 Análisis de páginas oficiales de CSIRT con herramienta
Dentro del análisis realizado en (Uribe, 2014) se utilizó una herramienta para la extracción de la
información de páginas oficiales de CSIRTs dentro del portal de la organización FIRST del inglés Forum
of Incident Response and Security Teams que cuenta con una gran cantidad de CSIRTs registrados. La
herramienta es del tipo web scraping la cual funciona recopilando información de portales web. A
continuación en la Figura 1 describe gráficamente el funcionamiento de la herramienta.
Fig. 1. Descripción del funcionamiento del robot web.
3.2 Resultados de la revisión de contenido de la página web de un CSIRT con herramienta
A continuación se presentan los resultados obtenidos mediante la inspección de páginas web oficial de
CSIRTs que se encuentran enumerados dentro del portal de FIRST. En la Tabla 1 muestra los resultados
encontrados mediante la herramienta dividido entre contenido y funcionalidad que se recomienda que una
página de un CSIRT incluya.
Tabla 1. Elementos propuestos por Uribe (2014) sobre contenido y funcionalidad de un CSIRT.
Contenido Funcionalidad
Información del CERT Novedades
FAQ Mapa del sitio
Misión y objetivos Multilíngüe 77
Información de contacto Motor de búsqueda
Eventos Base de conocimineto de vulnerabilidades
Documentos Reporte online de incidentes
Herramientas Zona de accesos restringidos
Avisos / vulnerabilidades Lista de distribución por correo
Noticias / notas de seguridad Publicación por RSS
Indicadores / estadísticas
Enlaces (sitios relacionados)
3.3 Inspección de contenido de sitio web de CSIRT de manera manual
Para reforzar los resultados mostrados en la Tabla 1, también se realizó una inspección de manera
manual, revisando contenido de sitios web sobre 10 CSIRTs/CERTs. Los sitios se eligieron al azar
tomando en consideración que fueran CSIRTs/CERTs formalmente establecidos. Durante el análisis, se
buscaron elementos que se muestran en la Tabla 1 y se añadieron otros que lo complementen. A
continuación se enlistan los resultados dentro de la Tabla 2.
Tabla 2. Cuadro de análisis comparativo entre 10 sitios CSIRT/CERT

Como se puede observar en la Tabla 2, los elementos que complementan a la Tabla 1 son: seguridad en
tu idioma/tips, blogs, cursos, suscripción a alertas y redes sociales.
4 Selección de tecnologías
Para la definición de tecnologías, lenguajes y herramientas a utilizar para la creación del sitio web de un
CSIRT, se realizó un censo de las tecnologías utilizadas en sitios oficiales de CSIRT, obtenidas
directamente de la página del foro de equipos de seguridad y respuesta a incidentes (FIRST, del inglés
Forum of Incident Response and Security Teams) (FIRST.org, Inc., 1995).
Se obtuvo una muestra de 40 sitios web oficiales de CSIRT para conocer qué tecnologías empleaban
mediante la herramienta WhatWeb en su versión 0.4.8 (Horton & Coles, 2015). El objetivo de la
herramienta WathWeb es responder a la pregunta ―¿Qué es este sitio web?‖, el cual identifica tecnologías
incluyendo CMS (Content Management System), plataformas de blog, analiza paquetes, librerías
javascripts, servidores web y dispositivos embebidos. Mediante sus 900 plugins, es posible también
identificar versiones especificas de tecnologías, direcciones de correo electrónico, errores SQL y más
(Morningstar Security, 2011). En la Figura 2 muestra un ejemplo de la información que muestra la
herramienta al inspeccionar un sitio web.
78
Fig. 2. Información extraída del sitio web cert.gov.ua con la herramienta WhatWeb.
Las tecnologías base más sobresalientes fueron 18 sitios que utilizan Apache como plataforma web, 8 de
ellos utilizan ASP.NET, 25 de ellos están desarrollados en Wordpress y sólo 6 en Drupal, entre otras
tecnologías. Por lo tanto, se decidió que la plataforma a utilizar sea Wordpress, la cual es más usada en el
mundo (Onishi, 2013) y Apache para la creación del sitio web del CSIRT, y así dotarlas de seguridad de
forma más especifica.
5 Implementación de controles de seguridad

Definidias las tecnologías a utilizar para el sitio web del CSIRT, como resultado de la inspección de sitios
web mostrados en la sección anterior, se proponen los controles de seguridad en especifico al CMS
Wordpress, esto atrae a una gran cantidad de atacantes el cual su objetivo es penetrar la seguridad del
sistema (Onishi, 2013).
Para llevar a cabo esta labor, se realizó una revisión sistemática, la cual es un método de investigación
desarrollado para obtener, analizar, y evaluar toda la investigación relevante para una pregunta de
investigación o un área de interés particular. Este método cuenta con 3 pasos los cuales son planificación,
revisión y publicación los cuales se describen a continuación:
Planificación: la primer fase, en esta etapa se identifica la investigación, se establecen los objetivos y se
realizan las siguientes actividades:
 Elección de nombre de la investigación.
 Formulación de las cadenas de búsqueda.
 Selección de fuentes de búsqueda de estudios y establecer los criterios de selección de estudios
primarios y secundarios.
Revisión: en esta segunda fase se ejecutan las siguientes actividades:

 Ejecución de la búsqueda.
 Evaluación de la calidad de los estudios.

 Revisión de los estudios seleccionados.
 Extracción de la información.
 Documentos de extracción de datos.
 Ejecución de la extracción.
Publicación: tercera y última fase en la que se resume y analizan los resultados utilizando métodos
estadísticos, las actividades que se contemplan son:
 Cálculo estadístico.
 Presentación de resultados.
A continuación se describen elementos principales de la revisión sistemática como lo es la pregunta de

investigación, cadena de búsqueda y número de resultados obtenidos.
Pregunta de investigación.
¿Cuáles son las mejores prácticas y tecnologías de seguridad existentes orientados a proteger un sitio web
hecho con Wordpress?
Cadena de búsqueda
(Security && Wordpress)
Resultados de la consulta
La cadena de búsqueda fue introducida en 4 fuentes formales para su búsqueda, las cuales fueron IEEE,
Springer Link, ACM y Google Scholar. En la Tabla 3 se muestra la cantidad de resultados por fuente.
Tabla 3. Resultados de la búsqueda de seguridad en Wordpress.

Cadena de IEEE Springer Link ACM Google Scholar
búsqueda
(Security && 9 66 410 10900
Wordpress)
79
6 Propuesta
A continuación se muestra la propuesta obtenida mediante herramientas y una revisión sistemática sobre
contenido de un sitio web y controles de seguridad para el mismo sitio bajo la plataforma Wordpress.
6.1 Contenido de un sitio web de un CSIRT
Como se menciona en la sección 3, se realizó un análisis de páginas oficiales de CSIRT mediante una
herramienta e inspección de 10 sitios web. Este análisis permite proponer el siguiente contenido
recomendado para un sitio web de un CSIRT. El criterio de selección de contenido consiste en que al
menos 8 o más sitios de CSIRT dentro de la Tabla 2 hagan uso de la sección, incluyendo también Tips de
seguridad el cuál es recompensable para dirigirse al publico sin tanta experiencia en los temas de
seguridad.
 Inicio: La página principal del sitio CIMAT CERT. En esta página se pretende mostrar
primeramente una imagen que sea llamativa con el enlace a las secciones de los reportes de
incidentes y a los tips de seguridad.
 Incidentes (reportes): En esta página se muestra el formulario correspondiente al reporte de
incidencias de seguridad por parte de los usuarios.
 Tips de seguridad: En esta página se mostrarán los tips y alertas de seguridad que le permitirán a
los usuarios mejorar sus prácticas de seguridad.
 Publicaciones (documentos): En este apartado será posible leer y descargar una serie de
documetos referentes a investigaciones y actividades de seguridad que el CERT del CIMAT ha
llevado a cabo.
 Contacto: Se mostrará información de contacto y ubicación del CIMAT CERT.
 Acerca de (misión, visión y objetivo): En esta página se pretende mostrar información acerca de
las actividades que el CIMAT CERT lleva a bajo.
 Noticias: En esta página se presentarán las noticias y notas de seguridad más recientes.
 Vulnerabilidades: En esta sección del sitio se mostrarán las vulnerabilidades e incidentes más
recientes.
 Eventos: En esta página se mostrarán los eventos programados junto con información de
contacto relacionados con seguridad informática y de cómputo.
 Entradas (publicación, vulnerabilidad, noticia, incidente, evento, tip): Esta página en realidad es
una generalización de los diferentes tipos de publicaciones que se realizarán en el sitio, como
pueden ser tips de seguridad, noticias, incidentes, eventos, publicaciones y vulnerabilidades.
6.2 Seguridad para el sitio web del CSIRT
Como resultado de la revisión sistemática nombrada en la sección 5, a continuación se presentan los

controles de seguridad que se recomiendan implementar en un sitio web creado con Wordpress. Los
controles de seguridad se seleccionaron para proteger los tipos de ataques en sitios web mostrados en el
trabajo (Patel, Rathod, & Prajapati, 2013) enfocados a Wordpress los cuales son memoria Cache, acceso
seguro, seguridad en archivos .httpaccess/wp-config.php, directorios transversales, bases de datos y
copias de seguridad.
6.2.1 Memoria cache
La memoria caché es una forma de optimización muy utilizada para ahorrar memoria, procesamiento y
poder acelerar el tiempo de carga de una página web de forma considerable. La memoria caché es una
forma de optimización muy utilizada para ahorrar memoria, procesamiento y poder acelerar el tiempo de
carga de una página web de forma considerable. Wordpress por naturaleza es lento, conforme se van
añadiendo más utilidades, temas o complejidad al sitio la página web crece y las velocidades de carga se
van reduciendo, además el lenguaje de programación con el que funciona Wordpress (PHP) es poco
eficiente. Cualquier página web puede sufrir de tráfico masivo (slashdotted) por lo que causa que deje de
responder el sitio, esto es consecuencia de almacenamiento de caché insuficiente. La solución es
almacenar en caché las páginas, esto es guardar copias estáticas de archivos en directorios ocultos y re
direccionar las visitas entrantes a estas páginas, además de acelerar las cosas para los visitantes, también
reduce considerablemente el uso CPU (Leary, 2013).
Lamentablemente Wordpress no cuenta con caché integrada, pero cuenta con diferentes opciones de
caché. El que se implementó en la página web fue WP Super Cache, éste trabaja reescribiendo en el
archivo .htaccess para re direccionar las peticiones de las páginas dinámicas de wordpress a los archivos
estáticos guardados en un directorio oculto en su instalación.
6.2.2 Seguimiento de problemas de rendimiento 80
Si el sitio Wordpress sufre de problemas de rendimiento y no está siendo atacado, es muy probable que
cuente con alguna mala configuración con respecto a red, plugins, temas Wordpress o base de datos.
Si el problema persiste, mediante herramientas propias de Firefox como YSlow (Yslow, 2015) junto con
Firebug pueden ser de utiliza para verificar que existen muchas imágenes o elementos en el sitio al
arrancar. Si no es el caso, puedes probar con un plugin llamado WP Tunner y visitar la página principal,
debajo de ella se verán todas las consultas a la base de datos y así darse cuenta si se trata de problemas
con el motor de la base de datos. Si los problemas persisten, prueba desactivando plugins o cambiar el
tema por el de default para verificar si cuenta con mejor rendimiento (Onishi, 2013).
6.2.3 Acceso seguro
En las versiones más antiguas de Wordpress, la cuenta del primer usuario siempre era Admin. Esto era
relativamente fácil para los piratas informáticos crackear el acceso al sitio. Desde la versión 3.0, el
usuario puede elegir el nombre de usuario durante la instalación, esto acorta el problema en escala, pero
no mitiga por completo el riesgo. Un Método para proteger Wordpress ante ataques de fuerza bruta es
bloquear la pantalla de login. Para mayor seguridad usar siempre SSL en el proceso de login para que las
credenciales viajen de manera encriptada, inclusive, es posible que se considere usar SSL en todas las
tareas administrativas.
Para el bloqueo del login de Wordpress existe un plugin llamado Login Lockdown, el cual funciona
bloqueando un rango de IP después de haber fallado muchos intentos de acceder en un periodo de tiempo
corto.
6.2.4 Remover la etiqueta cabecera generada
Una de las cosas que wp_head() agrega al tema de Wordpress es una etiqueta la cual muestra la versión
exacta de Wordpress que se está usando, esto ayuda a los desarrolladores a ver cuántas versiones de
wordpress hay en el mundo, sin embargo, esto también puede advertir a un pirata informático de qué
versión de Wordpress se está usando en el sitio y así buscar vulnerabilidades de Wordpress en caso que
no se esté al día. Para remover la etiqueta es con la siguiente línea de código.
Remove_action(„wp_head‟, „wp_generator‟)
6.2.5 Seguridad en el archivo .htaccess y wp-config.php
Existen muchas maneras en las cuales piratas informáticos pueden usar el archivo .htaccess de manera
maliciosa. Podrían reescribir reglas para re direccionar a los visitantes a otras páginas que no sea la
genuina. Otra manera de hacer mal uso del archivo es escribir un archivo dentro de un subdirectorio de
Wordpress lleno de enlaces SPAM y usar los directorios de PHP como auto_prepend_file o
auto_append_file para incluir el archivo al archivo index.php del tema en funcionamiento.
Para proteger en ese sentido, es recomendable colocar permisos para que sólo el
administrador pueda modificar el archivo .htaccess. También es posible modificar el archivo
.htaccess para asegurar que sólo tu puedas ver y modificar el archivo wp-config.php. Para
realizar esta protección, es posible hacerlo mediante el siguiente código.
<Files wp-config.php>
order allow, deny
deny from all
</Files>
<Files .htaccess>
order allow, deny
deny from all
</Files>
6.2.6 Cambiar de localización archivos
Es posible mover el archivo wp-config.php y la carpeta wp-content a un lugar diferente del index.php.
Todo esto ayuda a minimizar el ataque mediante un exploit de directorios con permisos de escritura en
lugares predecibles. Un archivo importante de mover es el wp-config.php debido a que ahí se almacenan
contraseñas de la base de datos al igual que otros datos importantes. Es posible mover el archivo a una
localización externa a la carpeta publica del servidor web y Wordpress detectará automáticamente el
nuevo archivo. Para mover el contenido de Wordpress, se debe definir constantes de todo dentro del
archivo de configuración para que plugins que requieran de una ruta especifica no dejen de funcionar.
6.2.7 Seguridad en Base de Datos 81
Es necesario elegir unas buenas credenciales (elegir una buena contraseña) para la base de datos al igual
que cambiar el prefijo de las tablas y respaldar la base de datos con regularidad. Para cambiar el prefijo
que cuenta por default Wordpress es sencillo mediante el proceso de instalación, a la hora de configurar la
base de datos de Wordpress, se muestra la opción de cambiar el prefijo. Esto funciona como medida de
protección ante ataques básicos de SQLInjection, pero no los detiene del todo. Esto es útil cuando un
atacantes hace usos de herramientas de hackeo automatizadas para sitios Wordpress.
6.2.8 Copias de seguridad de base de datos y archivos
Realizar copias de seguridad de tu base de datos con frecuencia es esencial si pretendes restablecer tu sitio
cuando un desastre ocurra. Esto puede ser provisto por tu compañía de hosting aunque siempre es
recomendable tener respaldos propios. Existen muchos plugins que ayudan a hacer respaldos, uno de ellos
es el WP-DB-Backup, una vez instalado es posible realizar un respaldo con su menú de herramientas.
Para realizar respaldos de archivos es mucho más sencillos, sólo es necesario copiarlos. Es posible
automatizar el proceso mediante herramientas como rsync o usar clientes FTP para sincronizar, descargar
y actualizar copias cada vez que sea necesario.
6.2.9 Monitorizar problemas de seguridad
Existen muchos plugins que permiten mantener una segura instalación de Wordpress. Enseguida se
muestra una lista de ellos.
 WP Security Scan verifica los permisos de los archivos, contraseñas, seguridad en base de datos
y más. Provee de herramientas para arreglar muchos de los problemas identificados.
 Wordpress Firewall monitoriza las peticiones HTTP con una lista negra de firmas conocidas
como maliciosas y puede mandar un email cuando algo sospechoso aparezca.
 Exploit Scanner busca en los archivos y base de datos cualquier entrada maliciosa, como
archivos llenos de links SPAM.
 Audit Trail es útil para hacerle saber cuando alguien ha intentado acceder.
6 Conclusiones y trabajos futuros

Actualmente no existe una normativa especifica sobre el contenido que se recomienda que tenga un sitio
web de un CSIRT, sin embargo, este elemento de CSIRT es de vital importancia debido a que en ella se
da a conocer al CSIRT hacia el público objetivo, publicar alertas, amenazas y concientizar a las personas
sobre los peligros del internet, entre otras cosas. Gracias a herramientas como los web scraping fue
posible analizar de manera automática todos los sitios web de los CSIRT del portal FIRST y junto con la
inspección manual se concluye que no todos los sitios oficiales de CSIRT cuentan con la misma
estructura. Además, fue confirmado por la herramienta WhathWeb donde se obtuvo como resultado que
no existe el uso de una misma tecnología para la creación de los sitios web. Debido a la investigación se
obtuvo controles de seguridad para una de las tecnologías más usadas en la creación de sitios web para
CSIRT la cual es Wordpress según la muestra de 40 sitios web. Como trabajo futuro, se esta
desarrollando una aplicación que permita dar seguimiento a los controles de seguridad que se han
propuestos.
Referencias
[1] Gustavo Chapela. (2014) http://www.dineroenimagen.com/2015-03-27/53161. [Online].
http://www.dineroenimagen.com/2015-03-27/53161
[2] FIRST. (2015) FIRST. [Online]. www.first.org/members/map#MX
[3] ENISA, "Cómo crear un CSIRT paso a paso," 2006.
[4] Centro Criptológico Nacional. (2013, Junio) www.ccn-cert.cni.es/. [Online]. https://ccn-
cert.cni.es/publico/seriesCCN-STIC/series/800-Esquema_Nacional_de_Seguridad/820/820-
Proteccion_contra_DoS-jun13.pdf
[5] Proyecto AMPARO, Manual básico de: Gestion de incidentes de seguridad informática., 2012.
[6] David Penedo, "Technical Infrastructure of a CSIRT," IEEE 0-7695-2649-7/06, 2006.
[8] Julia H. Allen, The CERT Guide to System and Network Security Practices., 2001.
[7] Software Engineering Institute. (2014) cert. [Online]. http://www.cert.org/incident-management/services.cfm?
[9] Esquema Nacional de Seguridad. (2012) MAGERIT - Versión 3.0 Metogolodía de Análisis y Gestión de Riesgos
de los Sistemas de Información.
[10] Eloisa Vargiu and Mirko Urru, "Exploiting web scraping in a collaborative filtering- based approach to web
advertising," Artificial Intelligence Research , vol. 2, no. 1, 2013.
[11] Edgar Uribe,., 2014.
[12] FIRST.org, Inc. (1995) https://www.first.org. [Online]. https://www.first.org/members/teams 82
[13] Andrew Horton and Brendan Coles. (2015) https://github.com/urbanadventurer/whatweb. [Online].
https://github.com/urbanadventurer/whatweb
[14] Morningstar Security. (2011) http://www.morningstarsecurity.com/research/whatweb. [Online].
http://www.morningstarsecurity.com/research/whatweb
[15] Adam Onishi, "Security and Performance," in Pro WordPress Theme Development.: Apress, 2013, pp. pp
297-332.
[16] Savan K. Patel, V. R. Rathod, and Jigna B. Prajapati, "Comparative Analysis Of Web Security In Open
Source Content Management System," International Conference on Intelligent Systems and Signal Processing
(ISSP) , 2013.
[18] Yslow. (2015) http://yslow.org/. [Online]. http://yslow.org/
[17] Stephanie Leary, "Performance and Security," in WordPress for Web Developers.: Apress, 2013, pp. pp
125-140.
Forming an alternate solution for endoscopy
Miguel A. Razo Salas, Sodel Vázquez Reyes1, Roberto Solís Robles2
Universidad Autónoma de Zacatecas

Ingeniería de Software
vazquezs@uaz.edu.mx1, rsolis@uaz.edu.mx2
Abstract. Endoscopy is a process for diagnosing and performing surgeries with the help of a video
camera (endoscope), which once introduced in the human body, transmits images and video to a
screen. Currently, in the General Hospital of Zacatecas, having no modern medical equipment,
doctors use a generic endoscope and a laptop as a screen. However, it is necessary to replace the
laptop with a mobile device capable of displaying the captured images and recording the video
generated by the generic endoscope so the doctors can make decisions during surgery. This article
describes the procedure followed to provide an alternative solution to the problem in hand. It
describes 30 real tests with 14 different surgical procedures where the results show that the provided
solution is viable, because it allows speeding up the process and the decision-making.
Keywords: endoscopy, software, process, Dashcam, endoscope.
1 Introducción
There are many benefits when working with mobile devices such as portability, quick access to
information sources and multimedia, flexible communications and a existence of variety of applications
to meet different purposes; on top of that, it also improves and supports the decision making process. The
use of mobile devices by doctors has transformed many aspects of clinical practice and is becoming more
common in the field of health, with a rapid growth in the number of medical software applications for
these platforms. Many applications are now available to assist doctors with many important tools such as:
information and time management, storing and accessing health records, communications and 83
appointments, referrals and information gathering, management and monitoring of the patient, taking
clinical decisions, education and medical training, etc. [1]
Nowadays, many of the achievements and advances in medicine are in part a consequence of
technological developments, which make the medical work increasingly faster and easier to perform, as in
the case of endoscopy. Incorporating endoscopes to the market, has been a big jump in the field of
medicine, since it allows for more precise operations inside the human body without the need for large
incisions in the patient to get to view the internal organs. Endoscopy is a technique used to diagnose and
perform surgical operations with the help of a special video camera called an endoscope. The endoscope
is comprised of a long, flexible optical fiber tube, which sometimes is able to move. The doctor inserts the
endoscope in the human body through a natural orifice, a surgical incision or injury, and it transmits
images to a screen from inside the human body. Depending on the patient's diagnosis, and based on the
transmitted images, the doctor is able to perform a surgical procedure more accurately. Normally, this
process takes place with a professional endoscope where every one of the components necessary to
perform endoscopy, is already connected and ready to use. However, we have the option of using a
generic endoscope (web camera with a design and shape to facilitate its insertion inside the human body)
with an USB type output for transmitting the images, thus giving more flexibility and convenience in the
endoscopic process.
2 Process and Requirements
In the last few years, due to their extremely high costs, the General Hospital of Zacatecas has not used
professional endoscopes. The doctors have therefore resorted to the aforementioned generic endoscope to
perform the endoscopic process, which meets and complies with the medical requirements necessary to
perform surgical procedures and provides most of the functions that professional endoscopes have, as you
can see in Table 1.
Table 1. Specifications and comparison between different endoscopes [2], [3].
ENDOSCOPE GENERIC EG-2990I GIF-XP150N

Brand N/D Pentax Olympus
Waterproof
HD Camera Excellent quality Excellent quality
Illumination
Video Capture
Photo Capture
Cable Length 200 cm 105 cm 110 cm
Camera diameter 7 mm 9.8 mm 5.5 mm
Temperature resistant Greater than 80°C N/A N/A
Tip deflection (º) 210/210 up/down, 210/90 up/down,
120/120 left/right 100/100 left/right
Instrument Channel
With a value of less than $500.00 MX, this generic endoscope contains a CD with a driver and software
to display the images transmitted on an USB connected computer, and due to its convenience and low
cost, is used to solve the same problems a professional endoscope solves. The process followed to
perform the surgery, consists of connecting the endoscope to the laptop via USB, running the driver on
the CD so the computer is able to communicate with the endoscope and may capture images and video.
When the doctor connects the endoscope to the computer with the software running, the doctor intubates a
patient in order to diagnose the disease or to perform any surgical procedure. To do this, the endoscope is
fixed to a tube in which the doctor shall put instruments together that will later introduce into the human
body. Given that the generic endoscope does not have its own mobility, you need someone else to guide
it, in order for it to transmit images of where the patient has a problem. Once the patient is intubated, the
doctor inserts his tools through the tube and based on the images, which are captured by the generic
endoscope, he can make decisions.
This tool gives a high degree of mobility and brings closer the possibility for low-income areas to have
access to important technology, necessary for the health of people, as well as allowing medics to provide
84
a higher quality service without much risks. For this, it is imperative that the doctor carries a laptop in
case of an emergency because otherwise, he could not perform this process, which removes the mobility
to the process itself, and there is the possibility that the doctor forgets the computer by accident.
Therefore, we seek to further enhance the mobility already achieved with the PC and reduce the expenses,
thereby giving a solution with greater utility.
3 Solution and Change
With the need to further optimize the endoscopic process, a new way of performing it was considered,
which results in a very similar process that maintains the concept. For the procedure, an OTG cable is
required to connect the endoscope to the USB port of the cell phone, in order to display images that the
endoscope transmits. The change comes from replacing the computer as a basic tool with a mobile device
that works on an Android operating system. This change provides a greater degree of mobility or
portability because the cell phone has become an everyday tool in the lives of people. According to IAB
Mexico, and the research firm Millward Brown, there are 95.5 million mobile phone subscriptions, which
is equivalent to 85% of Mexicans having a mobile phone, and of these, 17% is a smartphone [4], resulting
in around 16´235,000 people having a smartphone.
We began with the search for information to see if it was feasible to develop an entirely new
application from scratch, we accessed the Android API to determine how to achieve the connection
between the endoscope and the mobile device, and we found seven classes that allow the required
communication: UsbManager, UsbDevice, USBInterface, UsbEndPoint, UsbDeviceConnection,
UsbRequest and UsbConstants. Naturally, these classes only provide methods for making the connection
but not for handling the endoscope, i.e., there is no external API to control the functions of the endoscope
and there is very little information about the endoscope itself. Therefore, we took the decision to search
for existing code or applications that give solution to the problem at hand. We found related software,
among them an open-source library called android-webcam-library and three applications: 1) USB
Camera, 2) SnapExWebcam, and 3) Dashcam. We proceeded to try the android-webcam library, which is
comprised of two parts, the first is a back-end service and the second parts uses the first part to display
the images, but the results were not favorable since it crashed when run. This because of a problem that
the creator of the library mentioned, which is that Samsung devices do not contain in their kernel the
module uvcvideo that provides communication between the Linux kernel and the webcams UVC code [5].
Later we performed tests with the aforementioned three applications, resulting in USB Camera and
SnapExWebcam crashing when run, but Dashcam giving us the desired functionality, as it showed the
images transmitted by the endoscope, and captured photographs and videos.
Now the endoscopic process is performed using the endoscope and the mobile device, this with the
help of three applications:
 Dashcam
o Application to view images the transmitted from the endoscope to the smartphone as
well as capturing images in .jpg format and video in .mp4
 Video player for Android
o Application to view the videos saved by Dashcam as the native Android player does not
support the video recorded by the application
 My Files (Native Android Application)
o The images captured by Dashcam are not shown directly in the gallery of the
smartphone until it is restarted and the gallery is updated. However, you can access the
images through this application by going to the DCIM/dashcam path where the
captured images and videos are stored
We must stress that Dashcam has its limitations: 1) many devices do not support UsbHost which
allows connecting external USB devices to the mobile device and 2) versions 4.4.2 and greater (or even
4.3) of Android need to have superuser permissions, see Table 2.
We perform the process by connecting the endoscope to and OTG cable, and connecting this in turn to
the mobile device. Once the endoscope is connected, the Dashcam application is run and if your device
meets the characteristics, the display will show what the endoscope is capturing with its camera. By doing
this, it is possible for the doctor to perform any surgery the patient needs. However, it is a temporary
solution, because we must modify the source code of the Dashcam application.
Table 2. Testing devices for Dashcam2.
MODEL ANDROID SUPERUSER SUPPORTS WORKS 85

VERSION (ROOTED DEVICE) USBHOST
Samsung 4.2.2
Galaxy S4
Samsung 4.4.2
Galaxy S4
Samsung 4.4.2
Galaxy S4
Samsung 4.4.2
Galaxy Tab 4
LG l9 4.1.2
LG Hub 2.3.4
Sony Xperia 4.3
N1
Alcatel 6030 4.0.4
The next step to make is to test the application in its original state in real situations, i.e., intubate and
perform surgical procedures on real patients in an operating room in order to know whether it is feasible
to carry out the modification of the application so we can get a new application that meets the needs of
the doctor.
2 Table 2 refers to devices in which we tested the Dashcam application. The SuperUser column indicates whether the
device is rooted, that is, if you have superuser permissions, and the column Supports UsbHost column indicates
whether the device supports this feature.
4 Results and Benefits
Having a functional application, we tested it in a real environment with Dr. Guillermo Velazquez, who
conducted 30 tests of 14 different surgical procedures on patients in the General Hospital of Zacatecas, in
which there was only one complication. The complication was caused by an incoming call in the middle
of a procedure, and it was resolved by putting the Smartphone in airplane mode in the subsequent
procedures, see Table 3. It is worth mentioning that a zero in the Recorded Minutes and Number of
Pictures columns means that the surgical procedure was performed without any need to record or save
files. All tests were performed in a Samsung S4 device.
Table 3. Log of tests in operating room.
SURGICAL RECORDED NUMBER OF COMPLICATION

PROCEDURE MINUTES PICTURES
1 THYROIDECTOMY 0 0 NO
2 TONSILLECTOMY 0 1 NO
4 LAPAROTOMY 0 0 NO
5 HEAD TRAUMA 0 0 YES

6 SEPTOPLASTY 1 1 NO
9 CHOANAL ATRESIA 1 0 NO
11 LAPAROTOMY 0 0 NO
12 TIRIODECTOMIA 0 0 NO 86
13 BROKEN JAW 0 0 NO
14 TONGUE TUMOR 0 0 NO
15 HEAD TRAUMA 0 0 NO
18 STRABISMUS 0 0 NO
19 STRABISMUS 0 0 NO
20 BURN IN FACE 0 0 NO
22 LAPAROTOMY 0 0 NO
24 APPENDECTOMY 0 0 NO
25 LAPAROSCOPIC 0 0 NO
CHOLECYSTECTOMY
26 LAPAROSCOPIC 0 0 NO
CHOLECYSTECTOMY
27 KIDNEY TUMOR 0 0 NO
RESECTION
28 MASTECTOMIA 0 0 NO
29 MASTECTOMIA 0 0 NO
30 THYROIDECTOMY 0 0 NO
Current endoscopic systems have many useful features such as calendar and patient monitoring,
reporting, pathology interface, instrument tracking, usage, and maintenance, inventory of drugs and
supplies, clinical investigation and research, among others [6]. Although Dashcam does not provide many
of these features, it gives us the basic functionality which is to display what the endoscope captures of the
human interior, adding that it can take pictures and videos. It is worth mentioning that the image quality is
very good, as shown in Figure 1.
Fig. 1. Epiglottis photograph taken during one of the tests performed by Dr. Guillermo Velázquez
Now, the functions provided by the endoscope for the PC are not very different from the ones given by
the Dashcam application since the PC allows you to capture photos and video and configure the place
where you save them as well as in the Dashcam application. The only difference is that in the PC
software we have a kind of timer, which restricts the duration of the videos. Therefore we can be sure that
in terms of processes, image quality, connectivity and functions are practically the same; the difference is
in the devices agility, mobility and robustness since a mobile device is more compact, which makes it
easier and faster to use.
It was possible to improve the endoscopic procedure, since by replacing the PC with a mobile device;
the necessary tools to perform the procedure are more practical. Now, it will only be mandatory to carry
the endoscope and OTG cable, since the mobile device is currently very difficult to forget accidentally.
Moreover, even if this happens, as mentioned in the preceding paragraph, over 16´235,000 people in
Mexico have a Smartphone, which allows us to find this work tool almost anywhere making it possible
for an endoscopy "to be performed in the doctor's office, an outpatient surgery center or a hospital" [7]. 87
After conducting tests and knowing that the Dashcam application was useful and that it improved the
endoscopic process, we proceeded to obtain the source code of the application with reverse engineering in
order to make modifications and obtain an application according to the specific needs of the doctor. We
could remove unnecessary features for endoscopy, such as the ads, the resolutions menu since the
endoscope has the default 640x480 resolution, the console debug messages, and leave the full screen
mode by default.
Currently we are in the process of adapting the application, since with a tool called apktojava, we
reverse engineered the application only to find a great amount of junk code. This because of the
ProGuard tool, which shrinks, optimizes, and hides code by renaming classes, fields, and methods with
no semantically recognizable names; leaving as a result a smaller apk and more difficult to understand
[8].
However, we can see fragments of code that show how it works in conjunction with the endoscope,
and from that code, we would start to build an application that meets the needs of the doctor. Figures 2
and 3 show how Dashcam starts and stops the camera. Figures 4 and 5 show code that perform the actions
of capturing photos and video.
Fig. 2. CameraView method to turn the camera on.

Fig. 3. CameraView method to turn the camera off.
Fig. 4. CameraViewMenu internal class to capture photos where we can see in the onClick method the code that
selects where the picture is saved and the take_picture call to take it.
88
Fig. 5. CameraViewMenu internal class to capture video, where the code in the onClick method checks if it recording
and if not, is starts it by calling start_recording (), and it stops the recording by calling stop_recording ().
5 Future Work
As mentioned before, this is a temporary solution, which needs corrections and adjustments, but still is a
functional solution contributing to the diagnosis, decision-making and vital surgical procedures for people
with health problems because it has functionality of viewing the images transmitted by the endoscope,
capturing the images and recording video.
Now that we know that the application was very useful for the doctor, we should continue to research
and try to realize the idea of obtaining a compatible product with more mobile devices without the need to
have the Smartphone rooted, helping medicine and other areas where it can be of use.
Once we achieve this, other changes would be for obtaining an application tailored to the needs of
endoscopic process, i.e., removing features that are unnecessary for endoscopy, and allowing viewing the
captured images and videos immediately without needing to restart the device.
References
1. Ventola, C. L.. Mobile devices and apps for health care professionals: uses and benefits. P & T: A Peer-Reviewed
Journal for Formulary Management, 39(5), 356–64. (2014)
2. Endoscopes: Upper Gastrointestinal (GI), Gastroscopy , EG-2990i, http://us.pentaxmedical.
com/en/products/endoscopes/upper-gastrointestinale/gastroscopes/EG-2990i.aspx (2014)
3. Olympus, http://www.olympusmexico.com.mx/spanish/ msg/msg_product_detail_esp.asp?
d=1&s=4&c=16&g=2092 (2014)
4. IAB Mexico, M. B.. IAB México presenta el primer Estudio de Usos y Hábitos de Dispositivos Móviles en
nuestro país | IAB MEXICO. http://www.iabmexico.com/ usos_habitos_mobile (2012)
5. Christopher Peplin. openxc/android-webcam. https://github.com/openxc/android-webcam (2011)
6. Atreja, A., Rizk, M., & Gurland, B. A primer on endoscopic electronic medical records. Clinics in Colon and
Rectal Surgery, 23(1), 5–9. doi:10.1055/s-0030-1247850 (2010)
7. Mayo Clinic Staff. (2015). Upper endoscopy - Mayo Clinic, http://www.mayoclinic.org/ tests-
procedures/endoscopy/basics/definition/prc-20020363?p=1 (2002)
8. Android Developers: Proguard, http://developer.android.com/tools/help/proguard.html (2015)
89
Establishing the state of art of frameworks, methods and

methodologies to assess the implementation and use of agile
methodologies in SMEs: A systematic review
Corona Brisia1, Miramontes Juan1, Muñoz Mirna1

1
Centro de Investigación en Matemáticas
Av. Universidad no 222, 98068 Zacatecas, México
{brisia.corona, juan.miramontes, mirna.munoz}@cimat.mx
Abstract. Many micro, small and medium enterprises (SMEs) are using agile methodologies.
However, the lack of knowledge on the use of processes and methodologies, results in the empirical
adoption of agile methodologies without following the principles of the agile manifesto. In this
context, the goal of this paper is to establish the state of the art regarding the frameworks, approaches
and methodologies developed to evaluate the implementation and use of agile methodologies focused
on Latin America SMEs. To achieve the goal, a systematic review protocol was released. As a result,
35 primary studies were selected. Besides, the information obtained from the primary studies allows
identifying: the agile methodology most used by SMEs and; the methods, frameworks and tools
developed to assess the implementation or use of agile methodologies in a right way.
Keywords: Agile methodologies, Assessment methods, SMEs, assessment, evaluation.
1 Introduction
In recent years the growth of software development provides the opportunity to produce low cost products
and services, this situation makes software development attractive for SMEs, therefore, around 99% of
businesses in Latin America are composed of SMEs (Howard et al, 2011; E. Gomez et al., 2014). In this
context, SMEs have a continuous need of improving their development process, as well as, their product
quality, in order to keep on the market and to achieve a steady growth. However, because of the great
amount of resources and the short and long-term commitments that is perceived by SMEs toward the use
of models and standards, they prefer the implementation of agile methodologies. Unfortunately, most of
time the implementation of agile methodologies is based on benefits that occur in other software
development organizations (VersionOne, 2014 & 2015). Besides, according to (Version One, 2015) exists
a critical period to decline the use agile methodologies between the first and second year. As result, there
is a lack of knowledge regarding the correct implementation of agile methodologies, even when the agile
manifesto (Kent Beck et al., 2001) provides software development principles that serve as guide in the
implementation of agile methodologies. Moreover, this lack of knowledge is reflected in low quality
software products. This research aims to establish the state of the art focusing on the agile methodology
most used by Latin America SMEs and the methods, frameworks and tools developed to assess if an
organization has adopted and used in a right way agile methodologies.
After the introduction, the rest of the paper is organized as follows: Section 2 presents the systematic
review protocol developed for this research. Section 3 shows the analysis performed to data obtained
from the primary studies. Finally, section 4 presents a summary of the conclusions and future work.
2 Systematic Literature Review Protocol
For this research, the guide for developing the protocol of Systematic Literature Review (RSL) proposed
by Kitcheham in (Kitchenham & Charters 2007) is used. This protocol is composed of three phases
planning, execution, and analysis of results, which are described below.
2.1 Planning
The planning phase defines the activities to be performed for RSL. These activities are detailed in the
following sections.
2.1.1 Identify the need for conducting the RSL. Collect and identify accurate and current data
regarding the frameworks, methods and methodologies, which aim to assess the correct use and
implementation of agile methodologies in SMEs as well as those focused on analyzing the maturity of the
organization regarding the use of the agile methodology.
2.1.2 Research Questions: RQ1. What models, methodologies or standards are used in SMEs? RQ2.
What is the percentage of SMEs in Latin America that use agile methodologies? and; RQ3. Are there
frameworks, methods, or methodologies for assessing or evaluating agile methodologies in SMEs?
2.1.3 Data Sources: Important repositories in software engineering were selected: IEEE Xplore, Elsevier
and Science (Science Direct). Besides other repositories such as ScholarGoogle and SEIR were included.
2.1.4 Search Strings: CA-01 (Current State AND (Latam OR Software Organization OR SME)) AND
Agile Methodologies, CA-02 (Software Process AND Agile Methodologies) AND SME
2.2 Execution the review. The second phase of the SLR is executed the review, in which the primary
studies are obtained. The activities are detailed in the following sections.
2.2.1 Selection Criteria. Rules establish to ensure that the obtained studies contain relevant information
regarding the research being conducted.
Table 1. Selection Criteria

Inclusion criteria
IC-1. Studies since 2010 to 2015 IC-5. Industry studies using techniques and tools with agile
methodologies
IC-2. Studies English or Spanish languages IC-6. Studies assessing the use or application of agile
methodologies in SMEs
IC-3. Studies with at least three key words in the title or IC-7. Studies containing analysis, evaluation and application
abstract of agile methodologies
IC-4. Studies showing the status of implementing agile
methodologies in small and medium enterprises
91
Exclusion criteria
EC-1. Studies that do not have clear results in the application of the agile methodology
EC-2. Studies not carried out using agile methodology and in SMEs
EC-3. Studies that do not meet any inclusion criteria
2.2.2 Selection of primary studies. The strategy implemented in this research is composed of 8 steps as
follows: 1) introduce the string according to the search engine requirements; 2) review the study data; 3)
review the study title; 4) review the abstract or summary; 5) apply the rest of the selection criteria, 6)
select the study. As Figure 3 shows, after performing the search strategy, the number of studies found was
358.667. After applying the selection criteria 35 studies were selected as primary studies because they
met the criteria. These primary studies were analyzed and used for establish the results of this research
work. Appendix A presents the list of the primary studies.
IEEE Scholar Google ScienceDirect SEIR
343 230,200 127,733 391

IC-1, IC-2, IC-3
358,667
156 879 2,589 100

IC-4, IC-5, IC-6, IC-7
3,724
47 207 52 28
EC-1, EC-2, EC-3

324
23 25 18 12
35 primary studies
Fig. 1. Primary studies obtained performing the selection strategy.

2.2.3 Data Extraction. The extracted data was recorded in an Excel spreadsheet. The use of a
spreadsheet allows a better management of the studies classification. It contains the following
information: title, author, year, keywords, source, main idea, abstract, and comments. The main idea
allows collecting information of the study goal, the abstract classification allows collecting information of
a complete study overview and classification allows adding specific opinions of the study manager
regarding the study. This classification was added to improve the time for generating the data analysis.
3 Results
In the following sections, the main results obtained of executing the systematic review are detailed.
3.1 Models, methodologies or standards used by SMEs
Only 23 primary studies where identified regarding models, methodologies or standards used in SMEs.
Table 2 shows their classification.
Table 2. Studies classification
Models, methodologies or standards used No. of papers
Hybrid Traditional / agile (CMMI-XP) 2
Traditional Methodologies/models (CMM, CMMI, 6
SPICE)
Agile methodologies (XP, Rapid, Scrum, Kanban) 10
Standards such as ISO family 5
3.2 Percentage of SMEs using agile in Latin America
About the information regarding the use and application of agile methodologies in Latin America SMEs, 92
the obtained results do not provide enough evidence of relevant publications. .
3.3 Frameworks, methods and methodologies for assessing agile methodologies
Regarding the identification of frameworks, methods or methodologies for assessing the use or
implementation of agile methodologies, there were identified around 18 papers present proposals focused
on using, performing, or implementing several assessment types. Table 3 shows a classification of them.
Table 3. Type of proposal developed to assess agile methodologies.

Evaluation type proposal Number of papers
Survey 6
Checklist 1
Evaluation Methodology 2
Framework 5
Evaluation model 3
Tool 41*
* 40 tools were found from the research a paper [31].
4 Conclusions and future work

As result of analyzing the data obtained from primary study, it's important to highlight that most SMEs
around the world uses the agile methodology Scrum and its variants. However, there is limited or almost
null information about the use of agile methodologies in Latin America SMEs. Besides, it was identified
that most proposals are based on the assessment tools and surveys focused on analyzing the years that the
agile methodology has continuously incorporated the organization, as well as, the level of individuals
using it and the size of the project in which it is applied.
Finally, as future work based on the finding of this research two activities will be conducting: 1)
perform a survey to get evidence regarding the use of agile methods in Mexico SMEs and 2) Analyze the
41 tools found.
5 References
1. Kitchenham, B., & Charters, S. (2007). Guidelines for performing Systematic Literature Reviews in
Software Engineering. Engineering (Vol. 2).
2. VersionOne. (2002). Pioneers in Agile Project Planning & Management. 15/07/2015, de © 2015,
VersionOne, Inc. All Rights Reserved. TeamRoom™ is a trademark of VersionOne Inc. Sitio web:
http://www.versionone.com/about-us/
3. Ben Linders. (julio 2014). Autoevaluación de ágiles. Blog: Ben Linders share my xperience, 1, 3. last
updated on July 9, 2015, De http://www.benlinders.com/tools/agile-self-assessments/.
4. Jim Johnson, Jim Crear, Hans Mulder, Lou Vianna, Lee Gesmer. (2013). Chaos Report. 15/07/2015, de
Standish Group Sitio web: http://blog.standishgroup.com/
5. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James
Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor
Ken Schwaber Jeff Sutherland Dave Thomas. (2001). Manifiesto por el Desarrollo Ágil de Software.
06/06/2015, de Alianza ágil Sitio web:
Appendix A. Studies included in systematic revision

[1] Instituto Nacional de Tecnologias de la Comunicaión (INTECO). (Marzo 2009). INGENIERÍA DEL
SOFTWARE: METODOLOGÍAS Y CICLOS DE VIDA. ScholarGoogle, 1, 83. 15/06/2015.
[2] Christer Thörn. (2010). Current state and potential of variability management practices in software-intensive
SMEs: Results from a regional industrial survey. journal homepage: www.elsevier.com/locate/infsof, 1, 11.
23/06/2015.
[3] José H. Canós; Patricio Letelier; Mª Carmen Penadés. (2010). Métodologías Ágiles en el Desarrollo de Software.
ScholarGoogle, 1, 8. 15/06/2015.
[4] Gloria Piedad Gasca-Hurtado; Lina María Giraldo; José Calvo Manzano; Jaime Alberto Echeverri Arias. (2011).
Análisis estadístico de la implementación de buenas prácticas en organizaciones desarrolladoras de software. IEEE, 1, 93
8. 10/06/2015.
[5] Tomohiro Hayata; Jianchao Han. (2011). A Hybrid Model for IT Project with Scrum. IEEE, 1, 6. 10/06/2015.
[6] Javier Heredia Ruiz; Lilián Álvarez Almanza; Naryana Linares Pons. (2011). Comparación y tendencias entre
metodologías ágiles y formales. Metodología utilizada en el Centro de Informatización para la Gestión de Entidades.
ScholarGoogle, Vol.4, 17. 15/06/2015.
[7] Muñoz Mirna; Mejia Jezreel; Calvo-Manzano Jose A; Cuevas Gonzalo, San Feliu Tomás; De Amescua Antonio.
(2012). Expected requirements in support tools for software process improvement in SMEs. IEEE, 1, 6. 01/07/2015.
(H.Ruiz, A. Almanza & L. Pons, 2011)
[8] Marianela Llaneza; Gladys Dapozo; Cristina Greiner; Marcelo Estayno. (2013). Análisis comparativo de modelos
de calidad orientado al desarrollo de software en pymes. ScholarGoogle, 1, 5. 01/07/2015.
[9] Valenzuela, Jorge., Pavlich-Mariscal, Jaime A. (2014). Hacia un Modelo de Madurez para apoyar el Desarrollo
de Software Dirigido por Modelos. IEEE, 1, 6. 10/06/2015.
[10] Gerzon E. Gómez; Antonio A. Aguileta; Grisel B. Ancona; Omar S. Gómez. (2014). Avances en las Mejoras de
Procesos Software en las MiPyMEs Desarrolladoras de Software: Una Revisión Sistemática. Revista
Latinoamericana de Ingeniería de Software; ScholarGoogle, 1, 7. 01/07/2015.
[11] © 2015, VersionOne. (2014). 8vo.Estudio Anual del Estado de las Ágiles. VersionOne, 8, 17. 15/06/2015, De ©
2015, VersionOne, Inc. All Rights Reserved. TeamRoom™ is a trademark of VersionOne Inc.
[12] © 2015, VersionOne. (2015). state-of-agile-development-survey-ninth. VersionOne, 9, 16. 12/07/2015, De ©
2015, VersionOne, Inc. All Rights Reserved. TeamRoom™ is a trademark of VersionOne Inc.
[13] Alcides Quispe, Maira Marques, Luis Silvestre, Sergio F. Ochoa, Romain Robbes. (2010). Requirements
Engineering Practices in Very Small Software Enterprises: A Diagnostic Study. XXIX International Conference of
the Chilean Computer Science Society, 1, 7. 10/06/2015.
[14] Victor manuel Escobar Sarmiento. (2013). Diagnóstico de agilidad en PYMEs Colombianas desarrolladoras de
software. Universidad de colombia, facultad de ingenieria, 1, 184. 15/jul/2015, De ScholarGoogle
[15] Capgemini Worldwide. (2015). world-quality-report-2014-15: Brazil. world-quality-report, 5, 2. 15/jul/2015, De
https://www.capgemini.com/thought-leadership/world-quality-report-2014-15
[16] André Menolli; Maria Alexandra Cunha; Sheila Reinehr; Andreia Malucelli. (2015). ‗‗Old‘‘ theories, ‗‗New‘‘
technologies: Understanding knowledge sharing and learning in Brazilian software development companies.
ScienceDirect, 1, 15. 23/06/2015.
[17] Francisco J. Pino; César Pardo; Félix García; Mario Piattini. (2010). Assessment methodology for software
process improvement in small organizations. ScienceDirect, 1, 18. 30/06/2015.
[18] Francisco J. Pino; Oscar Pedreirab; Félix García; Miguel Rodríguez Luaces; Mario Piattin. (2010). Using Scrum
to guide the execution of software process improvement in small organizations. ScienceDirect, 1, 16. 02/07/2015.
[19] Mehdi Fahmideh Gholami; Jafar Habibi; Fereidoon Shams; Sedigheh Khoshnevis. (2010). Criteria-Based
Evaluation Framework for Service-Oriented Methodologies. ScholarGoogle, 1, 9. 30/06/2015.
[20] Dr. James D. Arthur; Dr. Osman Balci; Dr. Steven D. Sheetz; Dr. Todd Stevens; Dr. Eli Tilevich. (2011). A
METHODOLOGY FOR ASSESSING AGILE SOFTWARE DEVELOPMENT APPROACHES. ScholarGoogle, 1,
68. 30/06/2015.
[21] Sven Overhage, Sebastian Schlauderer; Dominik Birkmeier; Jonas Miller. (2011). What Makes IT Personnel
Adopt Scrum? A Framework of Drivers and Inhibitors to Developer Acceptance. IEEE, 1, 10. 30/06/2015.
[22] Rehan Akbar; Mohd Fadzil Hassan; Azrai Abdullah. (2012). A Framework of Software Process Tailoring for
Small and Medium Size IT Companies. IEEE, 1, 5. 30/06/2015.
[23] Disorn Homchuenchom; Chayakorn Piyabunditkul; Horst Lichter; Toni Anwar. (2011). SPIALS: A light-weight
Software Process Improvement Self-Assessment Tool. ScholarGoogle, 1, 5. 30/06/2015.
[24] Mejhem Yousef; al-Tarawneh; Mohd Syazwan Abdullah; Abdul Bashah Mat Ali. (2011). A Proposed
Methodology for Establishing Software Process Development Improvement for Small Software Development Firms.
ScienceDirect, 1, 5. 02/07/2015.
[25] Hajer Ayed; enoˆıt Vanderose; Naji Habra. (2012). A metamodel-based approach for customizing and
assessing agile methods. IEEE, 1, 9. 30/06/2015.
[26] Victor Escobar-Sarmiento; Mario Linares-Vásquez. (2012). A Model for Measuring Agility in Small and
Medium Software Development Enterprises. IEEE, 1, 10. 30/06/2015.
[27] Shvetha Soundararajan; James D. Arthur; Osman Balci. (2012). A Methodology for Assessing Agile Software
Development Methods. ScholarGoogle, 1, 4. 30/06/2015.
[28] Xiaofeng Wanga; Kieran Conboy; Oisin Cawley. (2012). ―Leagile‖ software development: An experience report
analysis of the application of lean approaches in agile software development. ScienceDirect, 1, 13. 02/07/2015.
[29] A. Qumer; B. Henderson-Sellers. (2013). A framework to support the evaluation, adoption and improvement of
agile methods in practice. ScencieDirect, 1, 21. 02/07/2015.
[30] Karla MendesCalo; Elsa Estevez; Pablo Fillottrani. (2013). Un Framework para Evaluación de Metodologías
Ágiles. ScienceScholar, 1, 10. 08/04/2014.
[31] M. Steven Palmquist; Mary Ann Lapham; Suzanne Miller; Timothy Chick; Ipek Ozkaya. (Octubre 2013).
Parallel Worlds: Agile and Waterfall Differences and Similarities. SEIR, 1, 101. 30/06/2015.
[32] Fernando Selleri Silva; Felipe Santana Furtado Soares; Angela Lima Peres; Ivanildo Monteiro de Azevedo;
Pietro Pereira Pinto; Silvio Romero de Lemos Meira. (2014). A Reference Model for Agile Quality Assurance:
Combining Agile Methodologies and Maturity Models. IEEE, 1, 6. 30/06/2015.
[33] Angela Peres; Tiago Da Silva; Fernando Selleri Silva; Felipe Furtado Soares; Carlos Rosemberg; Silvio Meira.
(2014). AGILEUXModel – Towards a Reference Model on Integrating UX in Developing Software using Agile
Methodologies. IEEE, 1, 3. 30/06/2015.
[34] A. Qumer; B. Henderson-Sellers. (2014). An evaluation of the degree of agility in six agile methods and its 94
applicability for method engineering. ScienceDirect, 1, 16. 02/07/2015.
[35] Lakshman Mahadevan; William J. Kettinger; Thomas O. Meservy. (2015). Running on Hybrid: Control Changes
when Introducing an Agile Methodology in a Traditional ―Waterfall‖ System Development Environment.
ScholarGoogle, Vol.36, 29. 02/07/2015.
Tendencias en la Ingeniería de Software
View publication stats

TendenciasdelaIngenieradeSoftware ImpactoenlasTIC

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TendenciasdelaIngenieradeSoftware ImpactoenlasTIC

Cargado por

Copyright:

Formatos disponibles

See

Propuesta de un Modelo para la Implementación

Chapter · January 2016

Omar Romero Sandoval Katiuska Fernández Morales

SEE PROFILE SEE PROFILE

Metrópoli Digital View project

Análisis de las tendencias tecnológicas y pedagógicas en la Educación Superior View project

The user has requested enhancement of the downloaded file.

D.R. © Primera edición, 2016

D.R. © Centro de Investigación en Matemáticas, A.C.

Jalisco s/n, Valenciana

Impreso y hecho en México.

Printed and Made in Mexico.

Adriana Peña Perez-Negron Universidad de Guadalajara México

Herramienta para administración y validación de requerimientos de sistemas 7

Definición de Requerimientos de Software a Través de Escenarios utilizando Patrones 15

Proceso basado en patrones de proceso para desarrollar aplicaciones Web 22

Evaluación Heurística de Herramientas de Composición de Componentes Centrada en el 32

Metamodelo para validación de software basado en el CMMI 41

Presupuesto-CUC y SIRU, dos Experiencias de Desarrollo De Software A La Medida

Propuesta de un modelo para la Implementación de un Sistema de Gestión del

Propuesta de un modelo para la integración de las MiPyMES, Sociedad y Gobierno a

Sistema de detección de emociones para la recomendación de recursos educativos 68

Propuesta de contenido y controles de seguridad para un sitio web de un CSIRT 75

Forming an alternate solution for endoscopy 83

Herramienta para administración y validación de requerimientos de

Oscar Carlos Medina, Marcelo Martín Marciszack, Mario Alberto Groppo

GIDTSI, Grupo de Investigación, Desarrollo y Transferencia de Sistemas de Información

SIAR (Sistema Integral de Administración de Requerimientos) es la denominación que se le dio a una

2 Construcción de una herramienta para la administración integral de Casos de

Fig. 1. Relaciones de SIAR.

3 Alcance de SIAR versión 1.0

El aplicativo busca cubrir las siguientes necesidades:

3.1 Administración de requerimientos

Fig. 2. Consulta de Casos de Uso de un Sistema.

3.2 Configuración del entorno de desarrollo

Para su implementación se utilizó una plataforma de desarrollo ―case‖, generando en lenguaje de

3.3 Interfaz de usuario

3.4 Administración de proyectos de sistemas

3.5 Administración de Casos de Uso

Durante la descripción de un Caso de Uso, pueden administrarse las pre-condiciones, post-condiciones,

3.6 Versionado de Casos de Uso

Fig. 3. Versionado de un Caso de Uso.

3.7 Exportación a archivos XML

Es posible obtener las siguientes salidas del sistema: 10

4 Validación de consistencia de Casos de Uso con simuladores de autómatas finitos

En la actualidad UML es reconocido como el estándar para el modelado de proyectos de software

4.1 Registración normalizada del requerimiento

4.2 Transformación del Caso de Uso en una máquina de estados

o A = Por medio de una Acción determinada.

Fig. 4. Bifurcación en la especificación de trazo fino de un Caso de Uso.

Fig. 5. Tabla de estados de un Caso de Uso. Transformación automática por SIAR.

Fig. 6. Fragmento de archivo XPDL generado por SIAR.

Fig. 7. Fragmento del grafo de estados en el simulador de autómatas finitos.

El simulador posibilita probar el grafo de estados y comprobar si es aceptado o rechazado. En el segundo

El software limita su alcance con las siguientes restricciones:

Definición de Requerimientos de Software a Través de Escenarios

Abstract. La definición de los requerimientos de software consiste en la especificación y validación

Un punto prioritario en el desarrollo de software es la definición de lo que se quiere producir, ya que el

2 Trabajos Relacionados sobre Definición de Requerimientos

2.1 Lenguaje para Definición de Requerimientos

Tabla 1. Ejemplo simbología del LEL.

2.2 Representación de un Escenario