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].

Review_1: En este trabajo se realiza una revisión sistemática de literatura sobre el tema de gestión de requisitos software en empresas pequeñas.  El trabajo resulta relevante para la comunidad dada la poca información existente en esta temática. Como correcciones menores se recomienda trabajar más la sección de resultados añadiendo la síntesis de la revisión así como discutir los resultados de acuerdo a la pegunta de investigación planteada, por último se recomienda quitar la referencia que aparece en el resumen. Review_2: En cuanto a los aspectos generales, tres cosas: 1) los autores deberían de ser consistentes con la nomenclatura utilizada: principalmente requerimientos vs requisitos: por favor, utilicen solo una de las dos denominaciones, pero no mezclen a su antojo. 2) En segundo lugar, small settings (pequeños entornos) vs pequeñas y medianas empresas. Si van a la definición dada por el SEI, verán que no es lo mismo, siendo más amplio el concepto de small setting. En este caso creo que los autores se están refiriendo a pequeñas empresas. 3) Como tercer comentario, general, revisen los signos de puntuación, frases muy largos. En el resumen, los autores indican que van a ofrecer una propuesta de trabajo para pequeño entornos. No encuentro esa propuesta de trabajos en el artículo. Además, es mejor no poner referencias en el resumen. En la introducción, segundo párrafo, aparece "ya que ésta permite garantizar DESDE ..."  se espera un HASTA TAL COSA... En el apartado de proceso de revisión sistemática, no es necesario hacer una subsección, no tiene mucho sentido dividir una cosa en un solo apartado. En la subvención de fases de la revisión sistemática, primero dicen que hay 3 pasos y luego lo llaman fases. Cual de las dos es??? Los nombres dados a las fases, no coinciden con los de las secciones siguientes, ni tampoco con los de la Figura 1. La Figura 1 no aporta nada. En la sección de planificación, palabras como "por sobre" no son muy válidas en el lenguaje escrito. Igualmente en la planificación incluyen párrafos que justifican el porque de las PYMEs, esto está ya fuera de contexto aquí. Además indican que el objetivo de la revisión es encontrar modelos, metodologías, propuestas o procesos relacionados con la gestión de requerimientos. Bien, pues esto es lo que se espera que obtengan en los resultados de la revisión sistemática, Y esto, NO aparece apenas (solo aparece una lista de metodologías y poco mas). Además mezclan mejora de procesos software, con mejora de gestión de requerimientos. Luego indican que los resultados se miden por número de propuestas... cuando anteriormente han dicho otra cosa. Los apartados de la revisión no siguen fielmente las de Kitchenham, y Biolchini. Igualmente en la parte de "cadena de búsqueda" aparece "es que", que en el lenguaje escrito no queda bien. La lista de fuentes, ¿por qué aparece en la subvención de cadena de búsqueda? En la parte de revisión, la Tabla 3 y la Figura 2 son redundantes, si se añade una columna más a la tabla, indicando el porcentaje correspondiente, tenemos el mismo efecto. En la parte de Revisión, NO SE PUEDE DECIDIR INCLUIR SOLO LOS 20 PRIMEROS, entonces para qué hacemos la revisión sistemática???? Igualmente una solo subvención???. Cuáles son los 20 artículos que seleccionaron? ¿Dónde están referenciados? Igualmente pasa con la Figura 4 y la Tabla 4. Respecto a los Resultados, es de suponer que las referencias 18 a 29 son los artículos primarios??? En estos resultados solamente indican justificaciones relativas a la gestión de requerimientos, pero nada relativo a lo que indican en el objetivo de su revisión sistemática. En base a una referencia del año 2007, la 24, indican que no hada que trate la gestión de requerimientos en pequeñas empresas. Les indico solamente una tesis doctoral de la UPM de noviembre de 2013, titulada Metamodelo para la mejora del proceso de gestión de requisitos, cuyo autor es Ariel E. Serrano Rico y Director Jose A. Calvo-Manzano, para que vean que si existen cosas sobre gestión de requisitos. Aquí además es el único sitio donde indican una serie de metodologías.  Esto que se supone que es uno de los resultados esperados, solamente aparece en dos líneas del apartado de resultados. Luego añade una serie de factores clave, y de condiciones que parecen que aparecen por sí solas, sin ninguna referencia y que además no son el objetivo que dicen los autores respecto a la revisión que han hecho. 
accept

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. 
accept

Review_1: Resulta interesante el desarrollo de un web framework para la gestión de cámaras IP. Un tema que es, para mí, novedoso y que puede ser extendido en su utilidad.  Hay problemas de redacción y presentación (por ejemplo, "cuenta con una cámara IP las cuales pueden ..."). Además, queda poco claro si se han desarrollado aplicaciones sobre el framework y si estas tienen un funcionamiento adecuado. Review_2: Muestra una mezcla de tecnologías web para su desarrollo e implementa una solución nativa.  No muestra cuanto ancho de banda se consume en las troncales por la aplicación cuando están las cámaras funcionando todas juntas. Necesita mostrar más resultados. Review_3: El trabajo presenta el desarrollo un web framework para la transmisión con capacidad de análisis de imágenes de cámaras IP.  La bibliografía presentada son páginas webs relacionadas a las herramientas utilizadas para el desarrollo, pero no a temas relacionados  u otras aplicaciones relacionadas.  Problemas de formato (revisar ortografía,  saltos de línea cuando no debería, identación,  Indica en el resumen que el sistema tiene capacidad de análisis, pero al final indica que está desactivada.  ¿Cuál es la ventaja del ahorro en uso de Ips reales?  Falta un análisis de la situación anterior con la actual. En qué mejoró el sistema. 

accept

