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: A lo largo del artículo se exagera el rol de la automatización de las pruebas dentro de las pruebas de software y en forma más general en el marco de aseguramiento. Un modelo de madurez para la prueba de software necesariamente incluye más aspectos que la automatización. Los casos automatizados siempre van coexistir con casos manuales y evaluaciones realizadas por personas. Como está tratado en el artículo, automatización es un concepto demasiado general, puede abarcar la generación, ejecución, evaluación (por ejemplo: mutación, criterios de cobertura) y validación (problema del oráculo).  Aunque la motivación está claramente expresada en la introducción, hacen falta referencias para fundamentar las afirmaciones realizadas sobre el rol de la prueba y el impacto de la automatización en la misma. Decir que la automatización permite realizar las pruebas más rápido o a menor costo es simplista: esto depende del contexto. Los costos de generar casos de prueba automáticos, la estimación sobre la evaluación futura del software y la caducidad de los casos de prueba, junto con otros factores, deben ser tenidos en cuenta en el modelo de costos para determinar la conveniencia de automatizar cierta parte de la prueba.  La sección dedicada a la prueba de software realiza definiciones generales y recorre la historia de la prueba desde los mainframes. Para un artículo de investigación, sugiero realizar definiciones más específicas relacionadas con el foco del estudio (estudios experimentales sobre técnicas de prueba, automatización, costos de las pruebas, modelos de madurez).  Sería adecuado poner el desarrollo del modelo de madurez luego de presentar el trabajo relacionado. No se describe el proceso para obtener la propuesta de un modelo de madurez para testing.  Se debe vincular el desarrollo del modelo a otros modelos de madurez existentes (por ejemplo el Testing Maturity Model) establecer conexiones con la literatura aceptada de testing o normas (por ejemplo ISO 29119) y en general  con modelos de procesos de software.  No se explicita el string de búsqueda utilizado. No todos los modelos encontrados deben catalogarse como ‘modelos de madurez’. Algunos de los modelos incluidos son claramente modelos más generales, que no se enfocan en el problema de la automatización de las pruebas. Se debería al menos discutir estas diferencias.  No se explican los atributos utilizados en la tabla III, ni la forma de obtener los resultados de nivel de madurez. ¿Qué significa ‘nivel de las opiniones publicadas’? Este concepto resulta ambiguo. Se debe reforzar la descripción de este proceso de investigación ya que resulta clave para obtener el resultado de nivel ‘adolescente’. Review_2: El trabajo se titula "Madurez actual del desarrollo de la automatización de las pruebas del software". El documento muestra una serie de apartados que dan cuenta de un trabajo realizado en términos de revisión de literatura y algunos acercamientos a una propuesta para restructurar una escala de niveles de madurez particular para el proceso de automatización de pruebas.  Sin embargo, el trabajo carece de una estructura lógica que permita determinar si su aporte u objetivo principal está en la revisión de literatura o en la propuesta de nuevos niveles de madurez para el proceso de pruebas.  Se recomienda hacer una revisión completa de la información que se presenta y posiblemente re-estructurar el documento presentado. El reporte de esta revisión fue divido por secciones, con el fin de aportar sugerencia que permitan mejorar el trabajo.   Sección -Revisión sistemática  Es importante que los autores revisen el hecho de utilizar un método de revisión sistemática que aún no está publicado existiendo varios métodos publicados, probados y reconocidos para ingeniería de Software. Deberían justificar la selección del método propuesto por Serna M. identificado con el número [16] en el trabajo.  Es indispensable explicar la validación que se hace respecto a la revisión por pares de los artículos, pues no es claro cómo puede tenerse acceso a una revisión por pares de los artículos publicados para poder validarlos y de qué forma se realiza un proceso de validación a partir de dicha información, teniendo en cuenta la cantidad de revisiones que tendría que hacerse por cada artículo encontrado (978).  Automatización de pruebas  Si bien, en el trabajo se reporta un modelo propuesto para evaluar la madurez del proceso de automatización de pruebas de software. El modelo como tal no está descrito. El artículo se limita a presentar una escala de referencia asociada a la madurez de un ser humano. Por tanto, es indispensable que el artículo indique varios aspectos para considerar la estructuración y definición de un modelo. Dentro de los aspectos más importantes a considerar están:  1. Una justificación científica y formal sobre la cual los autores del trabajo se basen para proponer el modelo de madurez y la selección de los niveles de madurez de un ser humano como punto de comparación con un posible nivel de madurez del proceso de automatización de pruebas.  2. Justificación formal de por qué no usar el modelo CMMI y la estructura de niveles de madurez que en él se proponen para evaluar el proceso de automatización de pruebas. Lo anterior, teniendo en cuenta que el modelo de madurez define una escala de madurez apropiada para evaluar procesos en ingeniería de software. Es decir, ¿por qué es necesario replantear esos niveles de madurez para el proceso de automatización de pruebas y proponer una nueva escala basada en la madurez de un ser humano?  3. A nivel de investigación cómo se caracterizan los niveles de madurez en términos de la automatización de pruebas?. Si bien, en el artículo se caracteriza cada nivel indicando las posibles características en las que está el proceso de automatización de pruebas, no se indica cómo se determinó dicha caracterízación, ni se muestra una justificación formal y científica relacionada.  Trabajo relacionado  El trabajo presenta una revisión sistemática, bajo la cual es posible identificar trabajo relacionado con el área de estudio, en este caso automatización de pruebas o niveles de madurez para la automatización de pruebas. Sin embargo, los autores presentan la revisión sistemática aparte de la sección trabajo relacionado, cuando pareciera que los estudios seleccionados como trabajo relacionado deberían ser parte del análisis de resultados de la revisión sistemática.  Además, la revisión sistemática permite determinar vacíos o nichos de investigación (oportunidades de investigación) para determinar una área de trabajo con alguna problemática concreta y, a partir de ahí, proponer una posible solución a dicho problema. En este caso, el artículo presenta la revisión sistemática como un trabajo adicional y posterior a la propuesta de niveles de madurez para el proceso de automatización de pruebas.  Así mismo, los autores muestran la selección de algunos trabajos relacionados, se entiende que son relacionados con la automatización de pruebas, no obstante del primero Michael Grottke, indican precisamente que no se enfoca en el tema a tratar en el trabajo que presentan sino en una propuesta estadística de la automatización de pruebas. Por lo tanto no entraría como trabajo relacionado.   Madurez del desarrollo de la automatización de las pruebas del software   Para realizar una comparación del proceso de automatización de pruebas y los niveles de madurez, los autores presentan la Tabla 3. En ella se indica que en la primera columna se ubican las etapas tradicionales de un proceso de pruebas. Es necesario indicar bajo qué metodología se seleccionan estas etapas como tradicionales o tener una referencia como justificación para la selección de estas y no otras etapas.  En este apartado no existe una explicación clara de la determinación sobre los niveles de madurez en cada etapa. Es indispensable tener descrito el análisis de investigación realizado que da como resultado la definición del nivel de madurez en que se encuentra cada una de las etapas del proceso de pruebas. La tabla no es suficiente explicación para el análisis, pues solo reporta los resultados.  En este punto, si lo que se busca es proponer una nueva escala de madurez para el proceso de pruebas o automatización de pruebas, lo más conveniente es validar dicha escala propuesta con un caso de estudio. En este trabajo, si bien, los autores muestran una tabla donde parecen determinar que el nivel de madurez es "adolecente", no se logra comprender en qué contexto se está evaluando el proceso de automatización de pruebas. Debería, al menos, contextualizarse un caso donde se indique: región, tiempo, tipo de proyectos o empresas y metodología utilizada para evaluar el proceso de automatización de pruebas. Lo anterior es la base para justificar que en determinado contexto el proceso de automatización de pruebas se encuentra en X nivel de madurez (de la escala propuesta). Argumentando, además, los criterios que se tuvieron en cuenta para asignar dicho nivel de madurez. 
[EX A]: reject

[EX Q]: Review_1: El articulo narra la experiencia del desarrollo de una solución robotizada para el problema industrial de reparación de motores eléctricos. En particular, el problema de realizar soldaduras de precisión de motores eléctricos mediante un brazo robótico. El artículo presenta aspectos prácticos del desarrollo de la solución, complementado con ilustraciones que ayudan a entender el problema y el proceso de desarrollo de la solución.  Entendiendo que se trata de una experiencia de transferencia tecnológica a la industria de servicios especializados de apoyo a la principal actividad económica regional (minería), se encontraron las siguientes falencias:  Aspectos de forma:  1. Se incurre recurrentemente en términos no técnicos, que confunden y no aportan antecedentes objetivos, además de fallas de redacción y ortografía. por ejemplo:  fallas infantiles --> simplemente debe ser "fallas" resultados óptimos --> si se emplea "óptimo" debe proveerse evidencia que sustente que es la mejor solución y no hay otra mejor. tasa de falla bastante alta --> es preferible indicar que la tasa de falla estimada es del 55% (5/9). "bastante alta" es ambigua. suelda --> solda? como le requerido --> como lo requerido como la General Electric, con muy buenos resultados --> como General Electric, con buenos resultados.  2. emplear siempre tercera persona.  esto nos entregó --> esto entregó lo que obtuvimos es lo siguiente --> lo que se obtuvo fue lo siguiente  3. no es relevante mencionar ciertas empresas a las cuales se le compró o se les encargó ciertos estudios: MOTORFIL, INDURA  4. Se asume que el lector conoce los términos y es capaz de identificar piezas como bobinas y conmutador desde las figuras. Esto no se debe asumir, y se debe explicar de manera clara y sencilla, e ilustrar su posición en las figuras donde se muestran motores eléctricos. Debe explicarse a pié de página nombres como Innova Chile y su rol en el proyecto.  5. Figura 6 es relevante en la explicación. Lamentablemente, es poco legible y esto debe ser corregido.  6. usar términos de alcanzable global más que local. por ejemplo, costo cercano al millón de pesos (chilenos?) --> costo equivalente a U$2.000 aprox.  7. Gráfico 1 (debe ser Figura 4): uniformar tamaños de fonts e indicar la variable en el eje X.  Aspectos de fondo:  1. falta una sección de background que permita entender luego términos que se utilizan posteriormente sin haberlos definidos/explicados previamente. En este sentido, hay un párrafo que explica que es un robot, pero aparece dentro de la sección de Robotización del Proceso de Soldadura, por lo que está mal ubicado. Debe estar antes junto con los demás elementos del background.  2. cuando se explica cómo se realizó la programación del robot, falta un dibujo o figura que apoye la explicación (plano de referencia, plano de usuario, plano de herramienta, etc.). Lo mismo es válido para la explicación de porqué se agregó un sensor óptico (agregar un dibujo o figura ilustrativa).  3. Se hacen afirmaciones que no se sustentan con referencias a estudios o documentos. Por el contrario, las referencias no son citadas dentro del cuerpo del artículo.  4. revisar la versión en inglés del resumen. Hay varios errores de redacción y gramática.  5. no hay información técnica en detalle de cómo se realizaron los pasos de programación del robot, por ejemplo. Solo hay descripciones generales. Review_2: Es un excelente trabajo de investigación de aplicación tecnológica, vinculada con una empresa de la zona, artículo muy apropiado para Infonor  Tiene fallas con respecto a un artículo tradicional, no hay trabajos relacionados, citaciones, referencias, etc. Tiene problemas de redacción, pero es claro en lo que presenta. Tiene frases largas y hay problemas de puntuación. Habría que adaptarlo para que pase la revisión de la revista. Review_3: Este es un trabajo que muestra la experiencia de incorporación de un robot para realizar soldaduras en una empresa de Antofagasta.  La incorporación de tecnología es importante en la Empresa y me parece importante que las empresas confíen en las Universidades para hacerlo. Es un tema importante de revisar en las jornadas.  Revisar aspectos de formato (redacción en tercera persona, ortografía, algunas imágenes no son claras, contiene 7 páginas y sólo eran consideradas 6 o 10) No queda clara si la Empresa utiliza robot y soldadores o sólo robots. No hay una evaluación de los beneficios en cuanto a dinero percibidos por la utilización del robot. 
[EX A]: accept

[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