instruction:
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].
question:
Review_1: Este paper presenta problemas importantes en su formulación.  Los papers de experiencias prácticas deben entregar algo más que una simple descripción del sistema desarrollado: deben indicar claramente qué nuevo conocimiento, técnica o solución se obtuvo de dicha experiencia. Consecuentemente, un paper de esta naturaleza debería incluir, al menos, los siguientes elementos esenciales:  - Una introducción que explique claramente el propósito del trabajo: (a) el problema que fue resuelto directa o indirectamente con la experiencia práctica, (b) por qué el problema es importante y no trivial y (c) por qué que esta experiencia entregó información nueva dentro de dicho contexto (no obtenida con experiencias similares). - Marco teórico - La descripción del sistema: no debe ser una mera enumeración de sus componentes y funcionalidades, sino indicar claramente aquellos elementos que, durante su desarrollo, aportaron información relevante al problema del estudio. - Conclusiones: deben estar alineadas con los elementos de la introducción y deben estar soportados por la evidencia entregada en la descripción del sistema.  Analizando el paper bajo esta perspectiva, encontramos problemas importantes:  Primero, la introducción no es clara respecto al propósito del trabajo y. La única parte donde se mencionan los objetivos es en el 5o párrado, donde se indica que el caso de estudio es "para demostrar empíricamente los costos de desarrollo" asociados a las tecnologías mostradas en el paper. Esto, junto con "destacar las principales características y potenciales virtudes de CakePHP y MVC.." parecen ser los elementos centrales del paper.  Segundo, la descripción del sistema no difiere mucho de un manual de sistema; falta evidencia esencial para soportar los elementos de la introducción: costos de desarrollo asociados (tiempo, personas, recursos) que, se supone, deberían ser menores que con otra metodología. Si bien las secciones que describen CakePHP y MVC tienen información relevante para el problema, no aportan valor al trabajo si no están respaldadas por evidencia obtenida directamente de la experiencia de desarrollo con esta tecnología. Por sobre todo, eché de menos una comparación con alguna otra experiencia similar, indicando, claramente qué mejoras al desarrollo introduce CakePHP/MVC.  Por último, las conclusiones del paper no están alineadas con los elementos indicados en la introducción; algunas de ellas entregan información fuera del contexto (conclusiones #5 y #6) o son irrelevantes (conclusión #2); otras carecen de evidencias que las soporten (conclusión #1) o no son explicitas en asociar la evidencia con lo concluido (conclusiones #3 y #4).  Al margen de las observaciones anteriores, el paper también requiere mejoras en la presentación de la información. Por ejemplo, no es explícito el valor que el código SQL de las figuras 10 y 11 entregan al paper. Las Figuras 12-15 no están adecuadamente descritas. Una persona que no comprenda bien el trabajo con línea de comando puede terminar totalmente desorientada y no entenderá los argumentos esgrimidos.  Por todos esos motivos el paper no está en condiciones de ser aceptado para publicación. Review_2: Presenta un framework para el trabajo de MVC con PHP de forma simple.  Podría ser un poco más técnico en cuanto a elementos de configuración y agregar comparación con otros frameworks existentes para entender por qué CakePHP y no otra alternativa. Review_3: El trabajo expone la aplicación del framewok CakePHP a un problema específico.  Expone en forma clara la utilización del patrón MVC mediante CakePHP.  La introducción es muy general y pone énfasis en elementos (calidad, tiempo y RAD) que no son desarrollados o demostrados en profundidad en el trabajo.  Presenta el caso de estudio en CakePHP, sin realizar una comparación específica a partir de los elementos que sean mediables (tiempo, costo) con otros frameworks.  Posee faltas ortográficas (Universiades).  Se menciona la utilización de la técnica de programación extrema, sin embargo, no se específica de que forma fue desarrollada por los autores.  Se presenta código SQL sin especificar como se encuentra relacionado con el framework CakePHP.  No se identifica de manera clara el aporte de los screenshots presentados.  Sería deseable una introducción más detallada el problema específico resuelto. No queda claro cuáles son los beneficios de utilizar CakePHP para el desarrollo de esta aplicación.  Las conclusiones son muy generales y distan de ser específicas para el trabajo desarrollado. 
answer:
reject


question:
Review_1: Este paper presenta una herramienta (SAVE) para la verificación de arquitectura de software. SAVE realiza un chequeo estático de reglas asociadas a dependencias permitidas y prohibidas entre elementos del diseño y del código, y permite entregar un reporte sobre la consistencia entre ambos niveles respecto a dichas reglas.  En general la herramienta parece bastante poderosa por dos motivos: el uso de reglas sencillas y la inclusión de sets de reglas pre-definidas para patrones de diseño de amplia utilización. Esto, a mi juicio, es la diferencia más importante con otros frameworks similares.  La redacción es, en algunos lugares, poco objetiva. En particular sugeriría evitar el uso excesivo de adjetivos para los cuales no se provee de evidencia que los soporte. Por ejemplo, en varios lugares noté el uso de "poderosa herramienta", "herramienta intuitiva" o similares (no solamente referidos a SAVE, sino a otros trabajos). En todos esos casos, no se provee en forma explícita una evidencia que soporte el uso de dichos adjetivos.  Otro detalle que requiere arreglo es el título que aparece en el archivo PDF: "Predicción de la dinámica del comportamiento...", el cual no coincide con el título del paper. Probablemente los autores utilizaron una plantilla de un paper anterior con dicho título. Review_2: La verificación de la arquitectura de un producto software puede ser una gran contribución a la calidad del mismo, por lo cual, cualquier herramienta que facilite esta labor es un aporte a la ingeniería de software. Presentan evidencias de una revisión previa de métodos y herramientas alternativas o complementarias a la propuesta. Las descripciones presentadas se acompañan de ejemplos aclaratorios.  No queda claro el rol e interacción del experto del dominio. En las secciones iniciales dice que la herramienta realiza análisis estático y dinámico, sin embargo al final del artículo, en la identificación de posibles mejoras de SAVE se propone incluir el análisis dinámico, lo que se contradice con la afirmación inicial. La descripción del funcionamiento de la herramienta no está lo suficientemente claro. La calidad de la figuras no es adecuada, por el tamaño y resolución de las mismas no es posible apreciar bien los detalles. La redacción de artículo puede ser mejorada. Hay varias frases en donde faltan conectores, por ejemplo "En el presente apartado, veremos S.A.V.E. logra recuperar las dependencias existentes en el código fuente...." Muchos errores en la acentuación de las palabras. 
answer:
accept


question:
Review_1: Este trabajo se enmarca en el área de la arquitectura del negocio y propone un interesante modelo de automatización de reglas de negocio para mejorar la flexibilidad de los sistemas de información aplicado a entidades financieras. El modelo propuesto  se orienta a desacoplar la lógica de negocio de  las reglas de negocio.  La problemática que aborda el artículo está sustentada adecuadamente en las dificultades mencionadas en el ámbito de los proyectos de software y en el mundo financiero.  El autor podría profundizar un poco más en las experiencias de desarrollo de proyectos en otros ámbitos y la relevancia de las reglas de negocios en el desarrollo de sistemas de información eficientes en la empresa.  El objetivo declarado por el autor  es proponer una metodología que permita flexibilizar la operatoria de los sistemas de información en las entidades financieras  el que en general se explicita  en forma adecuada.  La revisión bibliográfica es pertinente a los temas que se abordan y las teorías y modelos considerados son  adecuados al objetivo que se ha planteado. Los análisis asociados al concepto de reglas de negocios y arquitectura del sistema son atingentes al tema. El autor debería especificar como se establece la relación entre el modelado de procesos y el diseño y caracterización de las reglas de negocio. Se menciona que utilizan las tablas de puntos de decisión, pero estas no se mencionan en detalle ni visualmente. El autor debería sustentar de mejor manera la elección de “Pipes and Filter”  como modelo de arquitectura del sistema. Sería importante destacar también si existen trabajos similares realizados en otros ámbitos  ( ya que el autor  no lo menciona)  El aspecto metodológico del trabajo se  enfoca a describir el proceso a través del cual se llega a la definición de la arquitectura de software para automatizar las reglas de negocios y las herramientas que se utilizaron en su desarrollo. Este enfoque metodológico es adecuado y se asocia claramente a una aplicación de estudio de caso. El aporte importante en este aspecto es la descripción detallada del proceso desde el levantamiento de las reglas hasta el diseño y desarrollo de la arquitectura de aplicación propuesta.  El autor  debería hacer un cuadro resumen en el que se represente este proceso en forma resumida.   Es claro que los resultados de este trabajo tienen la validez deseada, ya que se sustenta en la utilización de modelos y herramientas ya validados en el ámbito del diseño de plataformas de negocios basadas en reglas.  La contribución del trabajo es importante ya que sistematiza un proceso que es de amplia utilización en el desarrollo de sistemas de información que sean flexibles y adaptables al entorno cambiante. Sin embargo en las conclusiones no está reflejado con toda claridad estas contribuciones por lo cual se sugiere a los autores mejorar las conclusiones incluyendo los aportes significativos en términos metodológicos y de aporte a la disciplina en la que se enmarca el artículo.  Los aspectos formales del trabajo son satisfactorios para el congreso. Hay detalles menores  en la gramática como en el primer párrafo de la introducción que falta la letra U.  Se sugiere aceptar el artículo con modificaciones menores Review_2: El artículo se titula "Arquitectura de Software para la Automatización de Reglas de Negocio en la Recepción de Solicitudes de Crédito en Entidades Financieras". En el resumen se indica que el trabajo tiene como objetivo  proponer un modelo de automatización de reglas de negocio que logre desacoplar la lógica de negocio, sin embargo durante el documento no se hace referencia a ningún modelo. Se presenta una metodología en el apartado con su nombre, pero no queda claro cómo dicha metodología permite generar un modelo de automatización de reglas de negocio. Al artículo le falta una secuencia lógica de apartados que den cuenta de la propuesta explícita citada en el resumen. En el apartado Arquitectura del sistema, se presenta la arquitectura de un sistema y se explican aspectos de la arquitectura. Sin embargo, en dicho apartado tampoco se logra identificar un modelo de automatización de reglas de negocio.  Teniendo en cuenta que al artículo le falta un trabajo fuerte para mejorar la presentación del mismo que permita entender la propuesta que se realiza, sugiero rechazarlo.  A continuación remito algunas observaciones que pueden sevir para mejorar el trabajo:  Si bien, la metodología utilizada está explicada detalladamente por fases, en ninguna de ellas se hace referencia a los resultados logrados en su implementación en el caso del trabajo que se expone, es decir aplicado en un entorno de entidades financieras.  En el apartado de arquitectura del sistema, se presenta la figura 5 y la figura 6 pero no se explican ni se contextualizan dentro del documento. Esto genera confusión. En este apartado no se identifica la aplicación de la metodología expuesta en el apartado anterior, con relación a la arquitectura generada. Debería indicarse claramente cómo se logró la arquitectura a partir de la metodología seleccionada y explicada en el apartado Metodología.  En la introducción que queda clara cuál es la propuesta del trabajo presentado. Debe estructurarse un párrafo donde se incluya una definición del objetivo el trabajo y la propuesta de solución que se hace teniendo en cuenta el título del trabajo.  Se deben corregir algunos errores de redacción en como:  - En el resumen...Para lo cual la se propone....? - En la introducción... no de los retos principales de la ingeniería de software es generar ...? - En la página 3 la fase Un término posee un significado para el negocio que debe ser comprendido y compartido, está repetida dos veces. - En la página 4 la palabra valido, lleva acento y en el último párrafo el acento está por fuera de la palabra esta´. - Al final de la página 5 el título queda divido (viuda). - Se sugiere mejorar la redacción del párrafo... Se ha observado la vulnerabilidad arquitectónica de los sistemas de software en la prestación en los servicios que presta respecto a las libranzas... -Las figuras no están citadas en el texto, solamente se indica siguiente figura, lo que constituye problemas tanto de forma como edición del artículo. Deben citarse las figuras en el texto, con el número correspondiente en el título de la figura. - La figura 3 no se entiende. El texto es muy pequeño y no se logra identificar el modelo de proceso de negocio al que se hace referencia en el párrafo inmediatamente anterior. - El último párrafo de la página 6 no se entiende y se habla en primera persona. Debería corregirse la redacción. - En el apartado Metodología, se hace referencia a un proyecto que no se ha descrito antes. Sería conveniente explicar de qué se trata el proyecto al que se hace referencia. En este apartado no es claro el tipo de metodología a la que se hace referencia. Se puede tratar de una metodología de investigación o una metodología de desarrollo de arquitectura. 
answer:

reject