Review_1: Comentarios generales: • Se recomienda revisar todo el escrito ya que hay palabras de más o palabras escritas de manera equivocada por ejemplo: imcompletas, ítemes (pag 3);  quedebe (pag 4), del de (pag 5)… etc • Revisar el espaciado de las palabras • Revisar la numeración de la bibliografía ya que tiene que ser listada en el orden en que ésta aparece. • Revisar que el texto sea del mismo tamaño  (ejemplo: final primera columna página 1)  Comentarios por secciones  II SCRUM YSPEM • Referenciar la parte dedicada a SCRUM así como la figura ya que no es propia de los autores si no tomada de alguien más  III LEVANTAMIENTO DE REQUERIMIENTOS UTILIZANDO SPEM • Revisar el concepto de stakeholder o referenciar de que referencia utilizó ese concepto, por ejemplo incluyo los conceptos de stakeholder para CMMI. “Parte interesada (stakeholder) Un grupo o individuo que se ve afectado por o es de alguna manera responsable del resultado de una empresa” “Parte interesada (stakeholder) Un grupo o individuo que se ve afectado por o es de alguna manera responsable del resultado de una empresa”  IV DESARROLLO DE SOFTWARE CON SCRUM • Título de Figura 5, puede mejorarse el título de la figura por ejemplo: modelo del proceso de desarrollo de software basado en SCRUM y utilizando SPEM para su modelado • Se recomienda reforzar la sección agregando referencias para los términos  V METRICAS PARA DEFINIR LA CALIDAD DEL DESARROLLO DEL SOFTWARE • Se recomienda agregar referencias cuando describe los conceptos de métricas  VI UN CASO PRÁCTICO • Se recomienda mejorar la descripción de la Tabla I (contenido de columnas y operación u operaciones llevadas a cabo para establecer las desviaciones estándar de peso y evaluación) • Hay una viñeta sin texto debajo de la Tabla 1 • Se recomienda apoyar la sección con una gráfica o tabla en la que se muestra un resumen de la medición de la calidad, para entender la medición “just in time” de la que habla en las conclusiones Review_2: El artículo promete presentar un método para medir la calidad del desarrollo de software en SCRUM.  Considero la propuesta interesante y relevante, sin embargo el trabajo tiene debilidades en su construcción.  La promesa del título se diluye en eL abstract y la introducción, con la “introducción” de SPEM como herramienta. Luego en el cuerpo de artículo no queda clara la vinculación entre SPEM y el método de medición de calidad propuesto.  Tampoco queda claro el caso de estudio sobre el que están basando su trabajo. El modelado en SPEM es sobre SCRUM en forma teórica en sobre el caso de estudio. La evaluación del método no parece medir la calidad del software, sino los criterios de los involucrados con respecto al apego al proceso modelado. Y en todo caso, siempre mide documentos intermedios del proceso y no defectos o atributos primeros de la calidad del software producido.  Comentarios menores: - Revisar la construcción de las referencias - El modelado de SCRUM no incluye la reunión de retrospectiva. Si se está modelando una implementación particular de SCRUM aclararlo en el cuerpo del paper. De lo contrario es un error importante de modelado. - Por que utilizan un proceso tradicional para modelar un proceso ágil? No podría haberse usado uno de estos últimos? - En la primera hoja, al final de la primera columna, cambia el tipo de letra. 
Output: accept