Definition: You are given a paper review either in Spanish or English language. Based on the given review, evaluate the paper by classifying it to one of the five classes: (1) very negative, (2) negative, (3) neutral, (4) positive, and (5) very positive. Note that URLs in the text have been replaced with [Link].

Positive Example 1 -
Input: El artículo presenta un interesante desarrollo de un caso, como una propuesta más de metodología de inicio para la didáctica de la lógica de programación. Las conclusiones presentadas no tienen mucho fundamento en términos del logro del objetivo de inducir de esta manera el razonamiento lógico.
Output: very positive

Positive Example 2 -
Input: Paper fácil de leer y bien escrito.  Está en la línea de los trabajos de INFONOR.  Sin embargo, no queda claro cómo aplica la 'Teoría de la relevancia', es demasiado escueto en este ámbito del artículo que a mi parecer es lo más importante. Por lo que no es posible dar una opinión certera sobre el trabajo.  Se sugiere expandir la sección 2.2, en lo referente a cómo los aspectos para determinar la relevancia son utilizados o mezclados para determinar si una 'news' es relevante o no.  La herramienta elaborada es interesante como también los elementos utilizados en su desarrollo.
Output: neutral

Negative Example 1 -
Input: Unless there is a strong info sci and business IT community for the conference, and unless the paper addresses its shortcomings (which are significant) - it just doesn't measure up.
Output: positive

Negative Example 2 -
Input: El artículo presenta un interesante desarrollo de un caso, como una propuesta más de metodología de inicio para la didáctica de la lógica de programación. Las conclusiones presentadas no tienen mucho fundamento en términos del logro del objetivo de inducir de esta manera el razonamiento lógico.
Output: very negative

Now complete the following example -
Input: - 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'.. )
Output: 


Answer: positive