ISSN 0718-3291 Versión Impresa

ISSN 0718-3305 Versión en línea

  • SciELO Analytics
  • Traducción automática
  • Indicadores

    Links relacionados

    • En proceso de indezaciónCitado por Google
    • No hay articulos similaresSimilares en SciELO
    • En proceso de indezaciónSimilares en Google

    Compartir


    Ingeniare. Revista chilena de ingeniería

    versión On-line ISSN 0718-3305

    Ingeniare. Rev. chil. ing. vol.29 no.3 Arica set. 2021

    http://dx.doi.org/10.4067/S0718-33052021000300505 

    Artículos

    Evaluación de un modelo de progresión de captura de información para requisitos de software

    Evaluating an information capture progression model for software requirements

    Dante Carrizo1  * 

    Jacqueline Manriquez2 

    1 Universidad de Atacama, Departamento de Ingeniería Informática y Ciencias de la Computación. Copiapó, Chile. E-mail: dante.carrizo@uda.cl

    2 Universidad Católica del Norte, Departamento de Ingeniería de Sistemas y Computación. Antofagasta, Chile. E-mail: jmanriquez@ucn.cl

    RESUMEN

    En la educción de requisitos de software, uno de los aspectos más inciertos es saber cuándo terminar el proceso. Es decir, cuándo se cuenta con la suficiente información desde los stakeholders y otras fuentes para especificar los requisitos del sistema informático. No hay orientación alguna que prescriba heurísticas para esto. La aproximación más relevante es el modelo de progresión de captura de información que pretende reflejar cómo se ha desarrollado la sesión de educción en términos de la información que se ha capturado. En este artículo se aplica un método analítico, basado en patrones de la experiencia de usuario, para evaluar la notación utilizada en el modelo e identificar aspectos a mejorar en el futuro. Los resultados son positivos arrojando una evaluación global de 75%.

    Palabras clave: Ingeniería de Software; ingeniería de requisitos; modelos de procesos; método de evaluación; notaciones

    ABSTRACT

    In the elicitation of software requirements, one of the most uncertain aspects is knowing when to end the process. That is, when there is sufficient information from stakeholders and other sources to specify the requirements of the software system. There is no guidance that prescribes heuristics for this. The most relevant approach is the information capture progression model that aims to reflect how the elicitation session has developed in terms of the information that has been captured. In this article an analytical method is applied, based on patterns of the user experience, to evaluate the notation used in the model and identify aspects to improve in the future. The results are positive, giving an overall evaluation of 75%.

    Keywords: Software Engineering; requirements engineering; process models; evaluation method; notations

    INTRODUCCIÓN

    La Ingeniería de Requisitos (IR) es un proceso de carácter socio-técnico que tiene como fin descubrir, documentar, analizar y mantener un conjunto de requisitos en un proyecto de desarrollo de software 1. Dentro de este proceso, una de las tareas más relevantes es la educción, que pretende identificar información que ayude a determinar las características deseadas del sistema software a desarrollar. Para esto, es necesario considerar información acerca del dominio de aplicación y de los stakeholders, los que tienen interés en el desarrollo del sistema software 2.

    Sin embargo, la educción de requisitos presenta dificultades provenientes de la naturaleza borrosa y cambiante de los requisitos, y de las particularidades de cada organización y de sus funcionarios, lo cual plantea grandes retos a los practicantes de la IR (3. En resumen, su desempeño es dependiente de las características del contexto en que ocurre. Uno de los aspectos más difíciles de atacar es determinar cuándo es pertinente terminar el proceso. El asunto parece no ser importante para los investigadores, de allí la baja atención que ha recibido desde la comunidad científica. Pitts y Browne 4 presentan uno de los pocos trabajos en esta dirección. Los autores han estudiado diversas heurísticas que los analistas utilizan para determinar si se han alcanzado conclusiones satisfactorias de una sesión de educción y así concluir la recolección de información. Desde este trabajo no se encuentran estudios que propongan reglas, o que modelen el proceso de educción con el fin de decidir cuándo terminar las sesiones con stakeholders pues ya se ha capturado la información relevante para especificar los requisitos del sistema software.

    Uno de los autores de este trabajo ha propuesto un marco de trabajo para gestionar el proceso de educción de requisitos a través de dos enfoques complementarios 5. El segundo enfoque, denominado Modelo de Progresión de Captura de Información (MPCI) pretende reflejar cómo se ha desarrollado la sesión de educción en términos de la información que se ha capturado, si es que esta información ha servido para generar requisitos, e ir realizando un seguimiento del proceso completo, usando la sesión de educción como hito de avance.

    En este trabajo, se presenta la evaluación del modelo MPCI utilizando un marco analítico de Patrones de Experiencia del Usuario (PUX) (6. El método analítico de patrones 7, es un patrón que se basa en el marco de la Notación de Dimensiones Cognitivas, relacionada con el comprender e interactuar con la construcción y representación de estructuras teórica, conceptuales y prácticas, dándole un sentido a la realidad (8.

    Es decir, es un lenguaje de patrones que se enfoca en referenciar las experiencias de los usuarios en correspondencia a los patrones de diseño de software 9, caracterizando sistemáticamente la experiencia que tienen los usuarios respecto a la perspectiva teórica 10, considerando la representación visual de la estructura de la información con la interacción de texto, diagramas, visualizaciones u otros sistemas de notación, donde los elemento de datos y las relaciones entre ellos proporcionan una estructura de la información, incluyendo las relaciones fundamentales. Tanto los marcos de Dimensiones Cognitivas como PUX resaltan que las experiencias de los usuarios surgen no solo de una representación visual formal 11, sino que también de cómo se utilizan las herramientas, o sea, de cómo el usuario interactúa con la herramienta, tareas o actividades. Esto brinda la posibilidad de efectuar una evaluación no solo centrada en las propiedades visuales de las notaciones en sí.

    El resto del artículo se organiza de la siguiente forma. En la sección 2 se presenta un resumen del Modelos MPCI. En la sección 3 se presenta el método de evaluación basado en PUX. En la sección 4 se lleva a cabo la evaluación del modelo MPCI con el método PUX. Finalmente se entregan las conclusiones de todo el trabajo realizado.

    MODELO DE PROGRESIÓN DE CAPTURA DE INFORMACIÓN (MPCI)

    En un proyecto de desarrollo de software, cuando el ingeniero de requisitos acomete un proceso de educción de requisitos, la unidad de trabajo fundamental es la sesión. La sesión de educción es la instancia para entrar en contacto con los stakeholders, aplicar técnicas y capturar información. Toda la dinámica asociada con la educción depende de cómo el ingeniero de requisitos maneje los factores que la condicionan, pero, si se fuera modelando la trazabilidad de la captura de información y cómo se configuran los requisitos del sistema, el ingeniero de requisitos podría disponer de insumos que le permitan tomar la decisión de cuál es la última sesión 12.

    El Modelo de Progresión de Captura de Información pretende reflejar cómo se ha desarrollado la sesión de educción en términos de la información que se ha capturado, si es que ésta ha servido para obtener requisitos, e ir realizando un seguimiento del proceso completo, usando la sesión como hito de avance. Este modelo se basa en la aplicación de otro componente contextual planteado en literatura 13,14, el Dominio del Problema, y su objetivo es hacer un seguimiento de la progresión en el tiempo, de la captura de información que se produce durante las sesiones de educción. De esta forma, el ingeniero de requisitos puede conocer tanto la cantidad de información que se va capturando a medida que se ejecuta la educción, como la proporción de requisitos que se obtienen a partir de dicha captura, que es una medida de la calidad de la información obtenida. Con estos dos antecedentes el ingeniero de requisitos puede evaluar en cualquier momento del proceso cómo va desarrollándose.

    Cantidad de Información Capturada

    La información capturada busca cuantificar los resultados del proceso, a través de un núcleo dinámico de información que representa todo lo que se va capturando y transformando en requisitos en las sesiones de educción. Este núcleo es propuesto como una estimación de la información total que contiene el factor contextual Dominio del Problema de un proyecto en particular. Se puede asumir que no hay seguridad en obtener toda la información de un dominio en concreto, por lo tanto, este núcleo es una aproximación que pretende representar la información sobre el dominio que es posible capturar en la educción, y crecerá hasta el punto en que las sesiones ya no agreguen ninguna nueva información.

    El núcleo está formado por 4 componentes relacionados con el dominio del problema, los cuales se proponen basados en (15, que se deberían considerar como información a capturar para producir requisitos. La Figura 1 ilustra este núcleo como una circunferencia formada por los componentes dentro del dominio del problema y con un límite superior que representa su máximo potencial de crecimiento. Este límite, que se materializa al finalizar el proceso, es meramente ilustrativo, una representación de que siempre puede quedar información sobre el dominio del problema que la educción nunca llega a descubrir. La Tabla 1 ilustra los componentes que forman este núcleo, cada componente a su vez lo forman una serie de dimensiones y se da un valor al grado de completitud de cada componente basado en estas dimensiones.

    Figura 1 Vista del núcleo de información. 

    Tabla 1 Componentes del núcleo de información. 

    El fin del núcleo es reflejar la cantidad de información que se va capturando en relación a cada componente y sus dimensiones, sin embargo, no se pueden establecer medidas exactas ya que las fuentes de información para cada componente pueden ser muy distintas. Este núcleo es dinámico en el tiempo y su progresión a través de las sesiones de educción está relacionada con el otro concepto importante de este segundo modelo, el estado Ri de los requisitos.

    Lista Ri y Estado de los Requisitos

    Hickey and Davis 13, en su modelo unificado de educción buscan reflejar la relación entre la cantidad de información capturada y los requisitos que se obtienen de ella durante las sesiones de educción. El objetivo es hacer seguimiento a la situación de los requisitos luego de terminar una sesión particular i. Concretamente, Ri es una lista de los requisitos educidos hasta el momento durante el proceso. Los requisitos en Ri se clasifican en tres estados: requisitos estáticos donde se incluye los requisitos que no se han modificado desde la sesión anterior, requisitos actualizados, aquellos que se modificaron en la presente sesión i, y requisitos nuevos, que son los que han aparecido durante la sesión i.

    Cuando termina la sesión, se examina la lista Ri para ver si ha cambiado la distribución del total de requisitos estáticos, actualizados y nuevos. Luego se verifica la información que ha sido capturada en el núcleo en la misma sesión i. De este modo, se puede tomar una medida de la calidad de la información que se obtiene, ya que por un lado el núcleo de información indica la cantidad que se ha capturado en una sesión i, y en Ri se reflejará si se ha modificado la distribución de requisitos como consecuencia de la aparición de nueva información. Por lo tanto, se podría estimar la calidad del proceso de educción mediante su impacto en Ri. Por ejemplo, si la información capturada en la sesión i no ayuda a mejorar requisitos estáticos ni a educir nuevos, se puede considerar que en la sesión se ha capturado información de baja calidad o repetitiva.

    Niveles de Estabilidad de la Lista Ri

    Al examinar la distribución de requisitos en cualquier sesión i de la lista Ri, se puede establecer una medida de estabilidad (S) de Ri, que vendrá dada por la proporción de requisitos que no se han modificado a través de las sesiones de educción, definiéndose entonces niveles de estabilidad, que servirán para seguir el desarrollo en cualquier momento del proceso. La estabilidad de Ri vendrá dada por el porcentaje de requisitos estáticos (que han permanecido estables en su definición desde que fueron agregados a Ri) sobre el total de requisitos en la lista, el resto será medido también en porcentaje considerando a los requisitos que han sido modificados y los nuevos que han sido agregados en la actual sesión i. De este modo, esta distribución de Ri se utilizará como un umbral, para determinar 3 niveles de estabilidad de los requisitos en Ri.

    En la Figura 2 (b) se presenta el núcleo de información, pero esta vez, con las dimensiones de cada componente y sus grados de completitud. Este diagrama se va completando a medida que se captura nueva información sobre cada componente según el grado de información (Low, Medium, High) que se haya capturado en la sesión actual, salvo el componente TIC, que se completa por nivel organizacional. Así, se puede saber la cantidad de información que se ha capturado por cada componente. Por otra parte, se integra este núcleo dentro de una vista circular seccionada que representa los niveles de estabilidad de la lista Ri. Esta vista es el diagrama de progresión de niveles de estabilidad, la idea es que a medida que se captura información, el núcleo se expande, alcanzando los niveles del diagrama, según el impacto que la nueva información produzca en la lista de requisitos Ri. Se debe observar el valor del umbral S para determinar si la nueva información afectó de tal forma a la distribución de requisitos que, como resultado, el núcleo de información se expande y sube el nivel de estabilidad en el diagrama.

    Figura 2 Niveles de estabilidad e inicialización de información. 

    El nivel 3 o de alta estabilidad, será alcanzado dentro de varias sesiones representando una gran estabilidad de los requisitos, que va de la mano de una baja cantidad de nueva información capturada. Cuando se alcance la estabilidad completa se puede dar por finalizado todo el ciclo de sesiones de educción, ya que, aunque se siga capturando información, no producirá nuevos requisitos ni permitirá mejorar los ya establecidos. La Figura 2 (a) muestra este esquema de niveles de estabilidad.

    Utilizando este esquema, con notación abreviada de sus componentes, se puede estimar la cantidad de información que se ha capturado por cada componente. Combinando ambos diagramas se puede tener una idea de la calidad de dicha información, observando el valor del umbral S, como se muestra en la Figura 3. Esta figura muestra el núcleo de información integrado con el diagrama de progresión de niveles de estabilidad de Ri, el diagrama representa una sesión de educción inicial, donde los componentes del núcleo aún tienen muy poca información y hay muy pocos requisitos educidos.

    La expansión del núcleo a través del esquema de niveles de estabilidad de Ri depende exclusivamente de los grados de completitud de sus distintos componentes, y cambiará de tamaño, subiendo de nivel, solamente cuando dicha completitud produzca un impacto en el umbral S. Por lo tanto, el núcleo es la pieza central de este modelo de progresión, ya que su transición entre niveles indicará en qué situación se encuentra la captura de información y la producción de requisitos (observando la lista Ri), en cualquier momento del proceso.

    Los grados de completitud de los componentes, también pueden servir para saber hacia dónde orientar la captura de información en las siguientes sesiones, ya que el núcleo no depende de que todos sus componentes hayan alcanzado grandes cantidades de información para avanzar de nivel. Se puede dar que uno o dos componentes de los cuales se ha capturado mucha información en una sesión i en particular, produzcan un impacto significativo en la distribución de requisitos en Ri.

    Figura 3 Niveles de estabilidad e inicialización de información combinados. 

    MÉTODO PATRONES DE EXPERIENCIA DEL USUARIO

    El método de Patrones de Experiencia del Usuario (PUX), en relación a los patrones de diseño de software, se basa en la semántica especificada como estructura y las herramientas como sistema de notación, este método se divide en 2 secciones, las cuales consisten en: Patrones de uso, que describen las actividades donde el usuario interactúa con las notaciones; y Patrones de experiencia, que describen si las experiencias que tienen los usuarios son o no importantes respecto a la necesidad y actividad real.

    El método PUX además incluye dependencias entre los tipos de uso y los tipos de experiencia, lo que permite anticipar las consecuencias de las decisiones de diseño al analista o diseñador. Los patrones de uso describen la interpretación que se da a las actividades respecto a la información necesaria visible, diseño visual, el flujo que sigue la elaboración de información respecto a la descripción visual, construcción respectos a sus propósitos fundamentales, la interacción, facilidad de uso y convencimiento de su utilización. Mientras que los patrones de experiencias están orientados netamente a la utilización del modelo en el ámbito de implementación.

    Los patrones de uso y de experiencia son 46, existiendo en algunos casos dependencia de unos respecto de otros. Hay 3 categorías de actividades de los patrones de uso: Interpretación (IA1-3), Construcción (CA1-4) y Social (SA1-3), mientras que los patrones de experiencias están divididos en 7 categorías: Visibilidad (VE1-5), Estructura (SE1-4), Significado (ME1-6), Interacción (IE1-6), Pensamiento (TE1-5), Proceso (PE1-6) y Creatividad (CE1-4).

    Patrón de Uso "Interpretación"

    En la Tabla 2 se especifica y describe cada actividad del patrón de uso "Interpretación" y su vinculación con el patrón de experiencia.

    Tabla 2 Descripción de actividades del patrón de uso "Interpretación". 

    Patrón de Uso "Construcción"

    En la Tabla 3 se especifica y describe cada actividad del patrón de uso "Construcción" y su vinculación con el patrón de experiencia.

    Tabla 3 Descripción de actividades del patrón de uso "Construcción". 

    Patrón de Uso "Social"

    En la Tabla 4 se especifica y describe cada actividad del patrón de uso "Social" y vinculación con el patrón de experiencia. Además, en este patrón se identifican patrones antes usados por patrón de uso de interpretación y construcción, vistos en las Tabla 2 y Tabla 3.

    Tabla 4 Descripción de actividades del patrón de uso "Social". 

    Utilización del Método PUX modificado

    Los patrones se desglosan en criterios y sus respectiva preguntas de evaluación, las cuales se describen en las rubricas de evaluación, que contienen la valoración "+" (generalmente positiva), "+/-" (aspectos positivos y negativos en balance) o "-" (generalmente negativa).

    Esta nomenclatura dificulta las evaluaciones globales, por lo que los autores de este artículo los han modificado proponiendo el método de evaluación que sigue. Los valores fluctúan entre 0 y 1, indicando si la actividad del patrón de uso y experiencia es aplicable por el usuario.

    En la Tabla 5 se presenta, como ejemplo, la rúbrica de evaluación para algunas de las actividades del patrón de uso "Interpretación". Por razones de espacio no es posible mostrar los otros patrones.

    Tabla 5 Descripción de rúbrica de evaluación de algunas actividades del patrón de uso "Interpretación". 

    La valoración de los puntos estipulados para cada patrón se realiza mediante las ecuaciones (1), (2) y (3). Los valores de la ecuación (1) y (2) son el resultado obtenido de la sumatoria respecto a la valoración de cada rúbrica por separado, siendo n la cantidad de criterios estipulados en la misma, mientras que ecuación (3) es el resultado de la sumatoria evaluada en las 3 rúbricas existentes, las cuales se mencionan en la Tabla 6.

    En la Tabla 6 se visualiza la cantidad de criterios revisados por la rúbrica donde el promedio ponderado del patrón PUX con el acrónimo PP-PUX-U en porcentaje, indica el valor de estimación de la aplicación de este método para la actividad. El valor final obtenido denominado VEE-PUX brinda un valor de estimación de la Efectividad de la utilización de este modelo.

    Tabla 6 Cantidad de criterios aplicados por la rúbrica de patrón de Uso y Experiencia. 

    Además, en la Tabla 6 se menciona la cantidad ítem por patrón de experiencia, donde el promedio ponderado de patrón P-PUX-E, en porcentaje indica el valor de aceptación por actividad de experiencia del método PUX.

    (1)

    (2)

    (3)

    Dada la ecuación (1) se tiene:

    • VC: Valor de criterio por nivel valorado en el intervalo [0,1].

    • j = Cada uno de los criterios específicos asociados a cada rúbrica.

    • n = Cantidad total de criterios asociados a cada rúbrica específica.

    • PP-PUX-Ui = Valor [0,1] obtenido como resultado de la aplicación de la fórmula el cual indica el valor estimado eficiencia de la actividad en la utilización del modelo por rúbrica por patrón de uso.

    Dada la ecuación (2) se tiene:

    • VC: Valor de criterio por nivel valorado en el intervalo [0,1].

    • j = Cada uno de los criterios específicos asociados a cada actividad específica de experiencia de la rúbrica por patrón de uso.

    • n = Cantidad total de criterios asociados a cada a cada actividad específica de experiencia de la rúbrica por patrón de uso.

    • PP-PUX-Ei=Valor [0,1] obtenido como resultado de la aplicación de la fórmula el cual indica el valor estimado eficiencia de la actividad en la utilización del modelo por rúbrica por patrón de experiencia.

    Dada la ecuación (3) se tiene:

    • i = Cada una de las rúbricas.

    • VE-PUX = Valor [0,1] obtenido como resultado de la aplicación de la fórmula el cual indica el valor estimado de eficiencia de la utilización del modelo y la aplicación final.

    Los procedimientos utilizados en la validación referida a una rúbrica varían según el número de patrones utilizados y el número de criterios empleados.

    Al aplicar las ecuaciones (1), (2) y (3) el resultado obtenido por VEE-PUX el cual se encuentra entre un intervalo de [0,1]. Dependiendo del valor, se puede categorizar la aceptación del modelo, como muestra la Tabla 7.

    Tabla 7 Categorización del Valor de Estimación de Eficiencia del modelo. 

    EVALUACIÓN DE MPCI

    En este documento, se aplica el método PUX modificado al Modelo de Progresión de Captura de Información descrito anteriormente. El propósito es evaluar las opciones de representación que presenta este modelo para indicar si existe efectividad de ser utilizado en la construcción de estructuras de información. Es decir, vincular el diseño MPCI a qué tareas y experiencias son las más deseables, para luego seleccionar los patrones que sean más apropiados, informativos y relevantes, enfatizando en obtener resultados no ambiguos y que tengan sentido para los usuarios del modelo. Los patrones de uso están orientados a la interpretación de las actividades, mientras que los patrones de experiencias a la utilización de MPCI en el ámbito de la implementación de PUX como patrón. En la Tabla 8 se visualiza la aplicación de la rúbrica de los patrones PUX al modelo MPCI hecha por los autores. Por razones de espacio no es posible mostrar todas las evaluaciones. La evaluación es el resultante del promedio entre las evaluaciones individuales y por separado hecha por los autores.

    Tabla 8 Categorización del Valor de Estimación de Eficiencia del modelo. 

    Con la aplicación de las ecuaciones (1) y (3) se obtienen los resultados mostrados en la Figura 4, los cuales indican que al aplicar el método PUX de patrones de uso sobre modelo, las diferentes actividades obtuvieron sobre un 60% de aceptación. Mientras que en la Figura 5, se visualiza que al aplicar el método PUX de patrones de experiencia sobre el modelo, sus actividades obtuvieron en algunos casos el 100% de aceptación mientras que en la actividad creatividad solo obtuvo un 45%.

    Figura 4 Promedio de las actividades del patrón de uso. 

    Figura 5 Promedio de las actividades del patrón de experiencia. 

    Al aplicar las ecuaciones (1) y (2) el resultado obtenido por VEE-PUX es de 0.75, lo que indica que se encuentra entre el rango Aceptación Moderada, por lo que se puede categorizar que el modelo es aceptable en su uso por el usuario, como se muestra en la Tabla 9.

    Tabla 9 Valor de Estimación de Eficiencia obtenido al aplica PUX sobre el modelo. 

    CONCLUSIONES

    En este documento se creó una rúbrica para aplicar los patrones PUX de uso y de experiencia en un método gráfico para la educción de requisitos. Según los resultados obtenidos, este método es apto para ser aplicado en la ingeniería de software. Con la aplicación del patrón PUX se puede enfatizar las experiencias del usuario en sus propiedades formales del método en su representación gráfica incluyendo que la herramienta puede manipular las tareas y sus actividades en las que participa el usuario, ya que no solo se centra en la parte visual sino también en la notación en sí.

    Esta evaluación arrojó que este modelo hace interactuar al usuario con la notación y la representación, además de la experiencia que el usuario puede encontrar valiosa dependiendo de la actividad en la que participa desde una perspectiva teórica y práctica.

    Respecto a la rúbrica se ha pretendido que sea de fácil uso y aplicable a las distintas actividades de los patrones de PUX para que pueda ser utilizada para distintos métodos de representaciones gráficas, buscando una evaluación generalizada. Se espera sea una real contribución a la evaluación de nuevos métodos y un elemento agregado al ser aplicado.

    Uno de los aspectos más bajos en la evaluación fue la creatividad, ya que el modelo identifica como poco claras la definición de varias tareas por ideas y el extender el lenguaje. Además, parece confuso el significado de algunos elementos y la baja posibilidad de agregar comentarios.

    Entre las limitaciones del estudio, está la evaluación juiciosa realizada por ambos autores, lo que representa una amenaza a la generalización de los resultados. Además, aunque el método ha sido aplicado a otros casos, aún falta una validación empírica con mayor validez estadística. Finalmente, el modelo evaluado solo fue aplicado a pocos casos lo que puede albergar un sesgo en su dominio por la falta de entrenamiento.

    Cabe notar que los resultados expuestos están aplicados a este método en particular, por lo que se debe replicar la evaluación del patrón PUX en otros estudios para realizar una validación juiciosa y más precisa. Aunque los resultados son favorables en este punto es necesario seguir analizando otras investigaciones para poder ver la posibilidad de generalización y poder calibrar el instrumento.

    REFERENCIAS

    [1] J. Dick, E. Hull and K. Jackson. "Requirements engineering". Springer International Publishing. Fourth Edition. Switzerland, 2017. [ Links ]

    [2] M. Chemuturi. "Requirements engineering and management for software development projects". Springer-Verlag. First Edition. New York, USA. 2013. [ Links ]

    [3] S. Sharma and S.K. Pandey. "Requirements elicitation: Issues and challenges". IEEE International Conference on Computing for Sustainable Global Development (INDIACom), pp. 151-155. 2014. DOI: 10.1109/IndiaCom.2014.6828119. [ Links ]

    [4] M.G. Pitts and G.J. Browne. "Stopping behavior of systems analysts during information requirements elicitation". Journal of Management Information Systems. Vol. 21 N° 1, pp. 203-226. 2004. [ Links ]

    [5] D. Carrizo y C. Ortiz. "Hacia un marco basado en contexto para la gestión del proceso de educción de requisitos software". Actas 13a Conferencia Ibérica de Sistemas y Tecnologías de Información CISTI'2018. Cáceres, España. 13-16 de Junio. 2018. [ Links ]

    [6] A.F. Blackwell and S. Fincher. "PUX: patterns of user experience". Interactions. Vol. 17 N° 2, pp. 27-31. 2010. [ Links ]

    [7] C. Alexander, S. Ishikawa and M. Silverstein. "A pattern language". Oxford University Press, pp. 1171. 1977. ISBN-10: 0195019199. [ Links ]

    [8] T. Green. "Cognitive dimensions of notations". People and Computers V, pp. 443-460. 1989. [ Links ]

    [9] H. Gomaa. "Software modeling and design: UML, use cases, patterns and software architectures". Cambridge University Press. First Edition, pp. 578. 2010. ISBN-10: 0521764149. [ Links ]

    [10] A. Blackwell. "Patterns of user experience in performance programming". In Proceedings of the First International Conference on Live Coding. Leeds, United Kingdom: ICSRiM, University of Leeds, pp. 12-22. 2015. DOI: 10.5281/zenodo.19315 [ Links ]

    [11] N. Crilly, A. Blackwell & P. Clarkson. "Graphic elicitation: using research diagrams as interview stimuli". Qualitative Research. Vol. 6 N° 3, pp. 341-366. 2006. [ Links ]

    [12] Z. Jin. "Environment modeling-based requirements engineering for software intensive systems". Morgan Kaufmann. First Edition. 2018. [ Links ]

    [13] A.M. Hickey and A.M. Davis. "A unified model of requirements elicitation". J. Man ag. Inf. Syst. Vol. 20, pp. 65-84. 2004. [ Links ]

    [14] D. Carrizo. "Contextual dynamic of the software requirements elicitation". Revista Facultad de Ingeniería Universidad de Antioquia. Vol. 69, pp. 34-52. 2013. [ Links ]

    [15] D. Carrizo. "Influential contextual attributes in the requirements elicitation process: a comprehensive literature review". Ingeniare. Rev. Chil. Ing. Vol. 23, pp. 208-218. 2015. [ Links ]

    Recibido: 06 de Enero de 2021; Aprobado: 30 de Abril de 2021

    * Autor de correspondencia: dante.carrizo@uda.cl

    Creative Commons License Este es un artículo publicado en acceso abierto bajo una licencia Creative Commons

     

    Artículos Relacionados

    Volumen 29 N° 3, Julio - Septiembre 2021

    pdf Índice

    Evaluación de un modelo de progresión de captura de información para requisitos de software

    Ver en SciELO
    Evaluación de un modelo de progresión de captura de información para requisitos de software

    SciELO - Scientific Electronic Library Online

     
    vol.29 número3Inspección del desgaste en contactos eléctricos usando segmentación por instanciasDiagnóstico de neuropatías en pacientes diabéticos mediante la aplicación de machine learning índice de autoresíndice de materiabúsqueda de artículos
    Home Pagelista alfabética de revistas  

    Servicios Personalizados

    Revista

    Articulo

    Como citar este artículo
    # Título Ver
    1
    Taxonomía de riesgos de outsourcing de software (2013)
    Gloria Piedad Gasca-Hurtado, Bell Manrique Losada
    HTML | PDF
    2
    Transformación de requisitos representados en esquemas preconceptuales a modelos de interacción de sistemas holónicos (2014)
    Carlos M. Zapata, Gloria L. Giraldo, Germán Zapata, Adrián S. Arboleda
    HTML | PDF
    3
    La especificación formal en contexto: actual y futuro (2014)
    Edgar Serna M., Alexei Serna A.
    HTML | PDF
    4
    Extracción de objetivos y su clasificación en el modelo de KAOS a partir del procesamiento del lenguaje natural (2015)
    Luis Alfonso Lezcano R., Jaime Alberto Guzmán L., Sebastián Alonso Gómez A.
    HTML | PDF
    5
    Método ágil híbrido para desarrollar software en dispositivos móviles (2015)
    Ignacio Leiva Mundaca, Marco Villalobos Abarca
    HTML | PDF
    6
    Elicitación de requisitos no funcionales basada en la gestión de conocimiento de los stakeholders (2018)
    Sandra L. Buitrón, Brenda L. Flores-Rios, Francisco J. Pino
    PDF
    7
    Metodologías, técnicas y herramientas en ingeniería de requisitos: un mapeo sistemático (2018)
    Dante Carrizo, Jorge Rojas
    PDF
    8
    Estructuras metodológicas de revisiones sistemáticas de literatura en Ingeniería de Software: un estudio de mapeo sistemático (2018)
    Dante Carrizo, Carlos Moller
    PDF
    9
    Comparando dos estrategias de aprendizaje activo para enseñar Scrum en un curso introductorio de ingeniería de software (2020)
    Silvia I. Lozano, Elizabeth Suescún, Paola Vallejo, Raúl Mazo, Daniel Correa
    PDF
    10
    Proceso y progreso de la formalización de requisitos en Ingeniería del Software (2020)
    Edgar Serna M., Alexei Serna A.
    PDF


    Otros Artículos

    # Título Ver
    1
    Modelado numérico 3D aplicado al análisis de fundaciones con pilotes (2018)
    Jean Rodrigo Garcia, Paulo José Rocha de Albuquerque
    HTML | PDF
    2
    Temperature and heat flow when tapping of the hardened steel using different cooling systems (2009)
    Lincoln Cardoso Brandão, Reginaldo Teixeira Coelho
    HTML | PDF
    3
    Una nueva definición de la logística interna y forma de evaluar la misma (2017)
    Orlem Pinheiro de Lima, Sandro Breval Santiago, Carlos Manuel Rodríguez Taboada, Neimar Follmann
    PDF

    Desarrollado por: Cristian Díaz Fonseca - cfonseca@matiasluke.cl