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 artículo presenta un plan de investigación que propone combinar los constructos teóricos de competencias para la gestión de tecnología (con el modelo BTM) y la precepción de éxito profesional (con un modelo propuesto que combina varios factores de diversas fuentes).  La capacidad de gestión de TI es un elemento clave para los profesionales del área y no solo sus competencias tecnológicas. Parece relevante estudiar como impactan estas competencias en el éxito profesional, o, al menos, en la precepción subjetiva de dicho éxito.  El estudio contiene referencias a fuentes relevantes, aunque se sugiere reducir el número y priorizar para el caso de los artículos en revistas o congresos.  Si bien el tema es relevantes existen algunos riesgos en la definición de los constructos que no son analizados. ¿Cuáles son los límites entre la percepción de éxito profesional y personal? ¿Se puede hacer un estudio de la percepción del éxito profesional solo considerando el modelo BTM y dejando fuera las competencias tecnológicas? ¿El estudio aplica a todos los profesionales de TI o solo a los que gestionan proyectos tecnológicos como CIOs?  La principal debilidad de la investigación es que se identifica como un método experimental, cuando en realidad la encuesta no tiene el grado de control sobre el objeto de estudio para clasificarse de esta manera. También se habla de estudio de causalidad, pero la encuesta solo permitiría un estudio de co-relación.  Sobre la encuesta se explica cuáles son los factores evaluados y la escala Lickert. Sin embargo, faltan ejemplos de preguntas concretas y explicar como van a ser respondidas por los sujetos. Por ejemplo: ¿Es viable que una persona evalúe su compromiso o liderazgo? Aunque se esté evaluando la relación en términos generales y no propios, convendría realizar primero una validación del modelo y luego de la propia encuesta con un grupo de expertos o gestores de profesionales de TI. Review_2: El artículo muestra el diseño de una investigación sobre el impacto de las competencias TI en la percepción del éxito profesional, pero no es lo que señala en su título. Se observa una sección correspondiente a una extensa revisión de trabajos previos y definiciones, en comparación con la sección que muestra el diseño de la investigación, la cual es bastante breve. En mi opinión era conveniente haber presentado el artículo como una revisión sistemática sobre la literatura existente del tema con el objeto de encontrar brechas y/o similitudes en el diseño de la investigación, o haber puesto más énfasis en esto último. Si bien el tema puede ser novedoso, el artículo no lo demuestra, ya que solo es la presentación de un diseño de investigación.  En la sección de conclusiones, no se muestran conclusiones concretas a partir del trabajo realizado, solo se plantean posibles escenarios de un trabajo futuro.  Con respecto a la forma, el artículo se encuentra bien estructurado, pero se observan detalles a corregir:  - abuso de “TI” - en algunos párrafos se señalan trabajos previos sin ser referenciados - la figura del modelo es muy básica (no es un aporte) - párrafos no alineados (justificados) - la figura 1 debió ser una tabla - error en la correlación de figuras Review_3: Este artículo tiene como objetivo identificar la incidencia de las competencias de negocio TI en la percepción del éxito profesional. Se presenta el problema, el modelo de análisis, la hipótesis y la metodología de investigación.  Es un tema interesante, pero la autora indica que la investigación se  encuentra en la fase de recolección de datos y que faltan unos 7 meses para  obtener los resultados finales.  Sin embargo, el análisis teórico realizado es  bastante importante.  La Figura 3 es muy simple. Sugiero que el modelo propuesto aporte mayor información. Para ello, puede unir en una sola figura las Figuras 3,  4 y 2.  Utiliza referencias numéricas y referencias en formato APA (debe usar solamente referencias numéricas y de manera correcta).  Hay 2 páginas con número de página 3.  En página 5 aparece la Figura 4, en página 6 aparece la Figura 2 ¿? ¿Existe la Figura 3?  En Referencia [11] no indica el nombre de la conferencia, Referencia [15] no tiene fecha, la Referencia [30] ¿es un libro?, la Referencia [34] tiene su título escrito totalmente en mayúsculas, Referencia [45] dice solamente “Quinta”, Referencia [46] dice “Segunda”.  En Conclusiones, cambiar “tesis q del” por “tesis del”. Cambiar “se mostrara” por “se mostrará”.  Las Referencias [8] y [46] no son utilizadas en el texto.  El nombre del autor e institución debería ser anónimo (según normas del congreso).  En página 5, debe revisar que el texto esté justificado a la derecha.  En página 8, cambiar “se capaces” por “ser capaces”. 
[EX A]: reject

[EX Q]: Review_1: De forma: •	Se recomienda cambiar la palabra “catastros” del título •	Problemas de ortografía. Ejemplo: agiles (primer párrafo de la introducción), ingles (sección criterios de inclusión y exclusión) •	Se recomienda siempre redactar en tercera persona para textos en español. •	Las páginas 6 y 8 del artículo están en blanco.  De fondo: •	El artículo es claro en su estructura y de fácil lectura. •	Se muestra de forma inicial el proceso seguido para el mapeo sistemático y luego de forma ordenada se muestran los resultados al ejecutar cada paso. •	Se recomienda cambiar la figura 2 al idioma español, para los casos en que sea posible. •	Se aborda un tema interesante y relevante para la comunidad científica y empresarial, y el alcance logrado está acorde con el tipo de productos solicitados para el evento INFONOR. Review_2: El documento presenta un estudio del estado de situación de las técnicas y métodos que el corpus de la investigación ofrece para el tratamiento de requisitos en entornos ágiles. La temática es totalmente actual y coincido con los autores es que hay poco realizado aún y es un campo de explotación. Hay sin embargo, dos comentarios que me gustaría trasladar a los revisores. El primero es que no queda claro porque no han hecho una revisión sistemática de la literatura de manera más formal. La justificación que ofrecen no me parece convincente. Por otro lado, me gustaría que hubiesen desarrollado algo más los trabajos futuros. Tras un buen trabajo no me queda claro qué han aprendido para ponerlo en práctica en su futura investigación. 
[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