In this task, you are given a set of paper reviews in English and Spanish language. Based on given reviews, your job is to generate decision, i.e., "accept" or "reject" for the given paper. Note that URLs in the text have been replaced with [Link].

[EX Q]: Review_1: El presente paper realiza una categorización de formas de integrar reglas de negocio en un diseño utilizando el paradigma orientado a aspectos y propone una plantilla de documentación para reglas de negocio basado en dicha categorización.  El paper entrega información útil sobre el problema en particular, así como una categorización razonable de diferentes aspectos en este problema. Es un buen punto de partida para una investigación en esa línea.  Aunque la información entregada en el paper es de suma relevancia para una investigación en este tema, es insuficiente para aceptarlo como un trabajo completo y autocontenido. La razón es que el paper se enfoca en identificar problemas y proponer un artefacto (la plantilla) que debería resolver dichos problemas. Sin embargo no presenta evidencias de por qué esta plantilla es una buena alternativa para resolver dichos problemas. Para ello se requieren los elementos mencionados en el trabajo futuro, específicamente la especificación formal y la herramienta automática para crear plantillas y mapearlas a AOP.  Mi sugerencia es esperar a que estos elementos estén listos para completar este paper y enviarlo a una nueva conferencia. Review_2: El trabajo presenta una alternativa viable para resolver el problema del cambio de las reglas de negocio.  Se puede mejorar agregando algo más de background al tema de aspectos, dado que se asume un conocimiento previo de este tema, por lo que el paper no es autocontenido. Review_3: El trabajo presenta una metodología para abordar al complejidad de implementar reglas de negocios sin realizar cambios en la funcionalidad base de un sistema.  Propone una metodología clara basada en documentación mediante plantillas para manejar y analizar el impacto de realizar la implementación de una regla de negocio vía orientación al aspecto.  Las razones presentadas para indicar que el enfoque OA para encapsular la conexión entre las reglas de negocio y la funcionalidad base no es una tarea trivial, son generales y deberían ser abordadas con mayor profundidad.  No presenta evidencias formales de que la utilización de las plantillas propuestas resuelvan de forma concreta un problema.  Se sugiere presentar un problema resuelto por medio de la herramienta que se encuentra en desarrollo que maneje automáticamente las plantillas. En su defecto, demostrar la aplicación a un problema específico. 
[EX A]: accept

[EX Q]: Review_1: Resumen:  El artículo busca analizar las redes de colaboración existentes entre investigadores de Sistemas de Información (SI) en Chile y en Latinoamérica. Se utilizan las co-autorias de investigaciones publicadas en Contecsi e Infonor para realizar un análisis de redes sociales, explicando estas últimas. Se plantean 3 preguntas que se responden luego en el análisis de los resultados a través de tablas y grafos; concluyendo varias similitudes entre comunidades y que existe colaboración entre investigadores de SI, la cual es lamentablemente es en su mayoría intra-institucional.  Evaluación:  El trabajo está bien realizado. Presenta una estructura clara y concisa que ayuda al lector a entender las ideas que se están tratando. Es un trabajo interesante que pertenece a un proceso que aún no termina debido a la escasez y continuidad de datos. La primera provocada por problemas de registros y normalización de papers publicados, y la segunda debido a que habrá nuevas versiones de los congresos que entregaran nuevos datos.  Aun así, se logra identificar algunos problemas, estos son:  1) No se da un argumento basado en datos del por qué estos son los dos congresos elegidos, dados que estos congresos son pequeños.  2) Al ser un trabajo de un alcance pequeño (respecto a los congresos usados), la utilidad del resultado también lo es.  Comentario menor:  Existe un error en la numeración de las páginas. Review_2: El trabajo expone de manera clara y con buenos argumentos un análisis de la colaboración entre distintos investigadores e instituciones. Es interesante el aporte realizado, primero como identificación de las oportunidades de mejora en el trabajo conjunto, y segundo, como análisis de la publicación local.  Sería interesante aplicar la misma metodología sobre otros congresos del área, ya sea Chilenos o latino-americanos y ver los resultados obtenidos. Review_3: Si bien es cierto el trabajo se encuentra bien estructurado y da muestras de una metodología adecuada, no queda clara la utilidad del estudio realizado. Los resultados obtenidos y presentados, se basan en un periodo de estudio muy reducido, lo cual quita confianza a las conclusiones. Se observan algunos pequeños errores de edición y redacción en el texto. Se recomienda ampliar el conjunto de datos de entrada del estudio. 
[EX A]: accept

[EX Q]: Review_1: Se presenta el desarrollo de un prototipo para una herramienta de asignación automática de requisitos de software entre los desarrolladores. Esta herramienta puede ser muy útil para los equipos de desarrollo de software. Se trata de realizar un aporte mediante esta herramienta a  la calidad de los productos desarrollados.  No se explica cuál es la heurística utilizada para la asignación de requisitos a los programadores. No se presentan un estudio de las herramientas de gestión de requisitos existentes, en donde se demuestre que no existen herramientas alternativas a la presentada. Y en caso de existir alternativas, justificar por qué desarrollar una nueva. No se explica claramente las funcionalidades de la herramienta. No hay evidencia de la mejora del proceso al incluir esta herramienta, sólo se dice en las conclusiones que "es perceptible el cambio en la calidad del proceso" Las referencias bibliográficas utilizadas son en su mayoría páginas web, no se nota una revisión bibliográfica en bases de datos especializadas. Las figuras no se distinguen bien. Las referencias bibliográficas no cumplen el formato establecido. Debe redactar en tercera persona. Review_2: - Propuesta novedosa de planificación de requisitos para una fábrica de software, como un aporte hacia el mejoramiento de la calidad de proyectos.  - A pesar que el título del artículo se orienta hacia la 'planificación de requerimientos', este punto solo se vuelve a abordar cuando narran cómo implementaron el prototipo. - No incluyen una base conceptual que permita sustentar el papel que juega la administración de requisitos en el proceso de desarrollo de software y particularmente en el aseguramiento de la calidad del proceso. - No se evidencia cómo con un aporte en la planificación automática de los requisitos para la fábrica de software, ésto le permitirá reducir sus tiempos de desarrollo (estimados vs reales) y por ende asegurar una mayor calidad. - No es muy clara la relación que existe entre la propuesta que hace en el marco de CMMI.  El artículo propone un modelo de planificación de requisitos, apoyado por una herramienta automática.  El prototipo que proponen es interesante y relevante. Pienso que puede organizarse mejor el modelo y método que proponen asociado a él, que en realidad es el aporte real de los autores. Considero que desde el punto de vista técnico sería importante que el análisis de resultados que plantean con el caso de estudio del banco, se hiciera por medio de una interpretación o comparación cuantitativa, que realmente evidencie que con esa planificación automática realmente se está mejorando la calidad del proceso y/o al menos la estimación y ejecución real de tiempos de desarrollo serán menores, escenario que según antecedentes ya ha sido justificado en su relación directa con la calidad.  Es una propuesta interesante que puede ser aplicada en casos reales de procesos de administración de ingeniería de requisitos. Actualmente aportaría en la disminución de tiempos asociados a esta fase de desarrollo de productos software, y consecuentemente con la calidad del proceso. Teniendo en cuenta que la Ingeniería de Requisitos tiene tantas causas y acciones problémicas, que generan crisis de software y por ende una afectación en la gestión de la calidad, queda como un interrogante abierto el que realmente un aporte hacia la 'planificación' del requerimiento logre un efecto considerable, con respecto a otras causas o puntos cruciales como la 'priorización de requisitos', la validación y/o su trazabilidad como tal.  La organización del documento puede mejorar en los siguientes aspectos: - Algunas de las figuras que se incluyen no son necesarias, pues realmente no aportan algo adicional de lo descrito en el texto, además que visualmente no dicen mucho. - En el apartado de 'Diseño de APARD' nombran muchos aspectos de orden técnico característicos de las fábricas de software de referencia, que no le dan mayor peso a la intención del artículo, ni están dando datos realmente influyentes parra la aplicación. - Se puede optimizar la calidad de las figuras (principalmente las que muestran los componentes internos del algoritmo y las acciones de uso del sistema -perfiles, pues son las que evidencian el mayor aporte). - Hay varios errores de redacción que deben ser revisados (p. ejemplo: el uso de 'en base de', debería cambiarse por 'con base en'; 'se hace uso', por 'se usa'.. ) Review_3: - La herramienta APARD - La temática asociada a requerimientos y fábrica de software es interesante  - No está detallado el caso práctico que considere el uso APARD con sus ventajas y limitaciones - La sección que explica la implementación de la solución APARD debe ser mejorada - Mejorar conclusiones - La presentación:  con errores ortográficos y de redacción, escrito en primera persona, figuras con letras muy pequeñas, color blanco de letras en figuras la hacen poco legible, referencias escritas de diferente forma, etc. - Se recomienda no utilizar Wikipedia como referencia para un artículo científico. - Falta autor en referencias 6, falta nombre de tema en referencia 13 - Referencia 7 está escrita con autor de manera diferente a las otras y con título antes de autor. - Cambiar “Palabras claves” por “Palabras clave”. - De acuerdo a formato, poner como mínimo 5 palabras clave. - Pone referencia en otro formato, ejemplo, Greenfield y Short(2003) - Hay mucho detalle de tecnologías y herramientas y productos detallados en la sección Especificación Tecnológica de APARD - ¿Qué significa IQNET[z]? - Sugiero poner en Introducción las secciones que componen el paper. 
[EX A]:
accept

