Carlos alejandro mera amezquita



Descargar 34,96 Kb.
Fecha de conversión14.05.2017
Tamaño34,96 Kb.

GUÍA PARA INTERACTUAR CON STAKEHOLDERS EN EL PROCESO DE INGENIERÍA DE REQUERIMIENTOS

Anexo A

Listado de Técnicas de levantamiento de información




CARLOS ALEJANDRO MERA AMEZQUITA




En este documento de enmarca un listado de técnicas utilizadas para el levantamiento de Información en el proceso de Ingeniería de Requerimientos, que sirven como referencia para la elaboración del trabajo de grado “GUÍA PARA INTERACTUAR CON STAKEHOLDERS EN EL PROCESO DE INGENIERÍA DE REQUERIMIENTOS”


Tabla de Contenido



1.Entrevistas 3

2.Cuestionarios 3

3.Task Analysis 3

4.Domain Analysis 3

5.Introspección 3

6.Repertory Grids 4

7.Card Sorting 4

8.Laddering 4

9.Group Work 5

10.Lluvia de ideas 5

11.Joint Application Development (JAD) 5

12. Requirements Workshops 5

13. Etnografía 6

14.Observación 6

15.Protocol Analysis 6

16.Apprenticing 6

17.Prototyping 6

18.Goal Based Approaches 7

19.Escenarios 7

20.Viewpoints 7




  1. Entrevistas


Es una de las técnicas mas utilizadas; estas son utilizadas en todo tipo de escenarios y hacen parte del conjunto de actividades que desarrollan todas las sociedades [1]. Una entrevista se puede definir básicamente como una conversación con un propósito entre dos o mas personas, son ideales para obtener información de suposiciones y percepciones, además sirven para indagar información a profundidad sobre un tema en específico. Estas se catalogan en no estructuradas, estructuradas y semi-estructuradas. Usualmente se considera que las entrevistas son el mejor procedimiento para levantar información, pero algunas veces estas limitan la percepción de nueva información; por estar centralizadas en algún tema.
  1. Cuestionarios


Un cuestionario básicamente es un conjunto de preguntas focalizadas que buscan describir conocimiento, comparar conocimientos, actitudes y conductas de un tema en específico; las cuales debe tener cierto grado de preparación para que estos sean efectivos. Estos permiten recopilar mucha información, pero se ven limitadas en la profundización de los temas tratados, explorar nuevas ideas y no permiten la aclaración de interrogantes[1].
  1. Task Analysis


Un análisis de tareas básicamente permite básicamente determinar las acciones que realizan las personas, este tipo de técnica permite representar estas tareas y predecir dificultades en las tareas que las mismas desempeñan. Su principal objetivo es el de crear una jerarquía de tareas que permitan entender el contexto de las tareas desarrolladas por las personas. Este tipo de técnica requiere de esfuerzos considerables para su desarrollo, ya que esta permite análisis profundos por ende es importante limitar su alcance.[2][1]
  1. Domain Analysis


Un análisis del dominio básicamente permite “identificar, recopilar, organizar, y representar la información relevante en un dominio, basado en el estudio de los sistemas existentes y el desarrollo de sus historias, los conocimientos de dominio capturados a través de los expertos, la teoría subyacente, y las tecnologías emergentes dentro de un dominio1. Esta técnica es buena cuando se pretende encontrar conceptos y componentes reutilizables en el dominio, que permita validar nuevas exigencias. A su vez este implica el uso de otras técnicas de levantamiento de información.[1][3]
  1. Introspección


La introspección es una técnica muy usada en la psicología, la cual contribuye a entender el comportamiento de las personas. A nivel de de tecnologías de información es la técnica mas obvia para indagar las necesidades que tiene satisfacer un sistema para tener éxito. Consiste básicamente en observar y documentar cada una de las entradas, acciones, sistemas, estados y salidas que están involucrados en los procesos de una organización o grupo que requiera que se suplan necesidades de información a través de sistemas que usen tecnologías de información. Esta técnica es realmente efectiva cuando la persona o grupo que la realiza tiene cierto grado de familiarización con los procesos de negocio realizados por los usuarios que usaran un eventual sistema.[1][4]
  1. Repertory Grids


Es una especie de entrevista, que insta a los Stakeholders a participar, para desarrollar atributos y asignar valores a un conjunto de entidades de dominio o del sistema. Como resultado, la técnica realiza una modelación en forma de una matriz por clasificación de elementos del sistema, detallando los casos de aquellas clasificaciones, y asignando variables con el valor correspondiente de cada uno. El objetivo es identificar y representar las semejanzas y diferencias entre las diferentes entidades de dominio. Estos representan un nivel de abstracción desconocido para la mayor parte de usuarios. Por consiguiente, esta técnica típicamente es usada obteniendo exigencias de expertos de dominio. Aunque más detallado que la técnica de Card Sorting, y a un grado menor que la técnica de Laddering, las Repertory Grids son limitadas en su capacidad para expresar las características específicas de exigencias complejas.[1][5][6]
  1. Card Sorting


Es una técnica de investigación usada en psicología, la cual permite saber cómo las personas organizan la información. La técnica se usa básicamente haciendo uso de tarjetas en cartón o a través de uso de software, donde cada tarjeta aloja la información de las entidades del dominio y de los procesos del negocio; con estas los Stakeholders que poseen la información, las organizan de acuerdo a sus conocimientos y su forma de pensar, esto con el objetivo de obtener flujos de información y formas de interacción entre los proceso de negocio. Esta técnica necesita de alto entendimiento del dominio y de los procesos del negocio; por parte de los analistas y los participantes de la misma. Desafortunadamente esta maneja un alto nivel de abstracción y la información que arroja es limitada en su detalle.[7]
  1. Laddering


Consiste en que las partes interesadas se les pide realizar una serie de preguntas, conocidas como sondeo, y que son necesarias para organizar las consiguientes respuestas a las mismas en una estructura organizada. Una de las principales hipótesis cuando se emplea el laddering; es que los conocimientos que se suscitan, pueden ser dispuestos de manera jerárquica. Para que esta técnica sea eficaz, los Stakeholders deben ser capaces de expresar su conocimiento del dominio y luego arreglarlo de un modo lógico. Este conocimiento, que a menudo es mostrado usando diagramas de árbol, es repasado y modificado dinámicamente a medida que más se añade. Al igual que lo hace el Card sorting, Laddering se utiliza principalmente como una manera de aclarar los requerimientos del dominio y clasificar entidades.[1]
  1. Group Work


Los grupos de trabajo son muy comunes, es por defecto la técnica mas usada para el levantamiento de requerimientos. Esta técnica es especialmente eficaz; porque involucra y compromete a los Stakeholders y promueve la cooperación directa. Este tipo de sesiones pueden ser difíciles de organizar debido a los diferentes tipos de Stakeholders que puedan estar implicados en el proyecto. Para que la dirección de estas sesiones sea eficaz, se requiere de conocimiento y experiencia, para asegurar que los diferentes tipos de personalidades no dominen las discusiones. Los factores claves para el éxito de los Group Work son el carácter de los participantes y la cohesión que tengan con el grupo. Los Stakeholders deben sentirse cómodos y confiados para hablar abierta y francamente, Lo que implica que el Group Work es menos eficaz en situaciones sumamente políticas.[1]
  1. Lluvia de ideas


Esta una técnica muy usada, que consiste básicamente en la exposición de ideas de manera informal y libre. Su objetivo es generar tantas ideas como sea posible. Es importante resaltar que en este tipo de actividad no es importante el explorar y criticar a gran detalle. Este tipo de sesiones no sirve para tomar decisiones y son muy usadas cuando se empieza con la elaboración de un anteproyecto. Esta técnica permite el descubrimiento de ideas nuevas e innovadoras.[1][8]
  1. Joint Application Development (JAD)


Es una técnica grupal la cual busca la participación de la mayor cantidad de Stakeholders, en la cual se hace uso de herramientas visuales y dinámicas de grupo que contribuya mejorar la comunicación con los participantes. El principal objetivo de esta técnica es su carácter constructivo, ya que busca analizar los problemas y diseñar soluciones a la vez, es por esto que se necesita que, de parte de los moderadores se tenga cierto grado de expertis y a su vez deben tener un alto nivel de preparación y enfoque. A menudo estas son preparadas para evaluar las necesidades y deseos de la empresa y los usuarios, por lo general no hondan en detalles técnicos.[1][9]
  1. Requirements Workshops


Básicamente son diferentes tipos de reuniones grupales en el que se desarrollan, descubren y validan diferentes tipos de requerimientos. Existen muchas formas de hacer talleres de requerimientos que involucren a los Stakeholders de los diferentes departamentos de la organización. Al usar diferentes talleres podemos dar pie a que se haga uso de la creatividad y desarrollar requerimientos de manera colectiva, estos talleres son enriquecedores ya que se retroalimentan del conocimiento del grupo de Stakeholders. Para que esta técnica llegue a ser realmente efectiva, se debe hacer un buen proceso de identificación de Stakeholders, y se deben contar con talleres debidamente preparados y enfocados.[1][10]
  1. Etnografía


Esta técnica consiste básicamente en estudiar el entorno natural en el que se desenvuelven los Stakeholders. Participando de manera activa pasiva en cada una de las actividades en la que cada uno de los Stakeholders participa, con el fin de obtener la mayor cantidad de información pero en el contexto de cada uno de ellos. Dichas actividades ayudan a comprender el porqué de los requerimientos, ya que ayuda a identificar cada uno de los problemas de los procesos y procedimientos que conllevan a la concepción de nuevos sistemas. Su primordial objetivo es la identificación patrones sociales, organizacionales y complejas relaciones entre los Stakeholders. Esta técnica lleva a reconocer los requerimientos implícitos que tienen los procesos con los que las personas en una organización. Esta técnica ha llevado a identificar el trabajo real del supuesto. La etnografía no es una técnica que permita captar la totalidad de los requerimientos debido a que solo se centran en el usuario final, y debe usada como una técnica complementaria para levantar requerimientos. [11][1]
  1. Observación


Es una de las técnicas etnográficas mas usadas, básicamente consiste como su nombre lo dice en observar cada uno de los procesos existentes, claro está que no se interviene de manera directa. Al ser una técnica que involucra personas que tengan un alto grado de análisis que conlleve a interpretar y a comprender de manera eficaz cada uno de los procesos en los que estén involucradas las personas, esta implica demasiado tiempo y sus costos son muy elevados.[1]
  1. Protocol Analysis


Es una técnica utilizada en Psicología cognitiva, consiste básicamente en documentar y analizar cada una de las acciones y procedimientos; que en voz alta el usuario que lo ejecuta, este narra, describiendo el proceso y pensamientos, con el fin de documentar cada una de las actividades cognitivas de las personas. Esta técnica es efectiva cuando los procesos se realizan al pie de la letra, pero debido a que los mismos los desempeñan personas, estos son realizados a la conveniencia o manera de cada una de las personas que los ejecutan. Por ende en algunas veces no se pueden registrar pasos en los procesos que los usuarios dan por obvios.[12][1]
  1. Apprenticing


Esta técnica consiste básicamente en que el analista de requerimientos efectué el rol de usuario aprendiz y ejecute las mismas tareas que hace n usuario de un sistema o proceso de negocio con la supervisión de un usuario experimentando. Es aquí donde el analista procede a realizar todo tipo de preguntas por estar en proceso de aprendizaje, con el objetivo de levantar la mayor cantidad de información para realizar el proceso. En este caso el analista pasa de ser informado como lo se hace en los protocolos de análisis, a ser un miembro activo más del proceso y entenderlo más con la vida real y las actividades de la empresa u organización.[1]
  1. Prototyping


La técnica consiste básicamente en mostrar a los Stakeholders modelos de otros sistemas ya desarrollados o de modelos que sirven como guía para identificar la manera que se requiere que interactué un sistema de información. Las reacciones al uso de prototipos se captura a travez de entrevistas, observación, cuestionarios, sesiones JAD, entre otras. Esta técnica es principalmente usada para levantar información de requerimientos de interfaz y todo lo que tenga que ver con HCI2. La desventaja que tiene este tipo de técnica es el alto costo y tiempo para su desarrollo, pero la ventaja es que animara a los Stakeholders a desempeñar un papel mas activo para la especificación de los requerimientos.[13][14][1]
  1. Goal Based Approaches


El principal objetivo de este tipo de técnicas es descomponer el objetivo del sistema a desarrollar o del negocio. Se enfoca en proporcionar la motivación y las razones por las cuales se justifica el desarrollo de un sistema. El resultado de esta técnica es más complejo y completo que los otros métodos. Estos logran representar las relaciones de dominio entre entidades, requerimientos y los objetivos del sistema.[1][15]
  1. Escenarios


Los escenarios se usan principalmente para describir y especificar los procesos actuales del negocio y los futuros, en el cual se incluye la interacción entre los usuarios y el sistema a desarrollar. Estos están escritos en lenguaje natural y no abordan la estructura interna del sistema, los escenarios abarcan las posibles interacciones que pueden tener los usuarios con el sistema, ya que se basan en dar la descripción de la vida real. Para que sea efectivos se requiere sea haga uso de ayudas interactivas que se vallan ejecutando gradualmente. Adicional los escenarios sirven para hacer el proceso de validación y comprensión de requerimientos y en muchos casos se usan como casos de prueba.[1][16][11]
  1. Viewpoints


Es una técnica que busca modelar las diferentes maneras de pensar y puntos de vista de los diferentes Stakeholders, con el fin de elaborar una descripción completa del propósito del sistema según los Stakeholders basados en los conflictos que ellos generan con sus percepciones o maneras de pensar y puntos de vista.[11][1]

Bibliografía



  1. A. Aybüke, y C. Wohlin, Engineering and Managing Software Requirements, Berlin: Springer, 2005, pp. 25-35.

  2. X. Ferré, “Marco de Integración de la Usabilidad en el Proceso de Desarrollo Software”,[en línea]. Disponible en: http://oa.upm.es/440/1/XAVIER_FERRE_GRAU.PDF , [Consultado: Jul. 26, 2009].

  3. The Software Engineering Institute (SEI), “Domain Analysis”, Carnegie Mellon University, Jan. 11, 2007, [en linea]. Disponible en: http://www.sei.cmu.edu/domain-engineering/domain_anal.html, [Consultado: Jul. 26, 2009].

  4. J. Goguen y C. Linde, “Techniques for Requirements Elicitation”, Proceedings, Requirements Engineering '93, pp. 152-164, 1993, [en línea]. Disponible en: http://www.cs.brown.edu/courses/cs190/2006/assignments/goguen[1].pdf, [Consultado: Jul. 26, 2009].

  5. B. Gonzales, M. Laguna y J. Sampaio, “Aplicaciones de la Teoría de Constructos Personales a la Elicitación de Requisitos”, [en línea]. Disponible en: http://www.giro.infor.uva.es/Publications/2004/GLL04/AplicaTCPaGoal.pdf, [Consultado: Jul. 26, 2009].

  6. N. Niu y S. Easterbrook, “Discovering Aspects in Requirements with Repertory Grid”, [en linea]. Disponible en: http://www.cs.toronto.edu/~sme/papers/2006/Niu-EA06.pdf, [Consultado: Jul. 26, 2009].

  7. “Card Sorting: A cuántos usuarios se necesita evaluar”, ProyectoWeb - Comunidad Profesional sobre Diseño de Experiencia de Usuario, Oct, 2001. [en línea]. Disponible en: http://www.proyectoweb.org/boletin/card-sorting-a-cuantos-usuarios-se-necesita-evaluar.html, [Consultado: Jul. 26, 2009].

  8. “Lluvia de ideas (Brainstorming)”, [en línea]. Disponible en: http://cv.uoc.edu/UOC/a/moduls/90/90_156/programa/main/viu/tecniques/viu30.htm#inici, [Consultado: Jul. 26, 2009].

  9. M. Escalona y N. Koch, “Ingeniería de Requisitos en Aplicaciones para la Web – Un estudio comparativo”, Universidad de Sevilla, Dic, 2002, [en línea]. Disponible en: http://www.lsi.us.es/docs/informes/LSI-2002-4.pdf, [Consultado: Jul. 26, 2009].

  10. EBG Consulting, Inc, “Requirements Workshops”,2005, [en linea]. Disponible en: http://www.ebgconsulting.com/Services/MoreInfoOnWorkshops-EBG.pdf, [Consultado: Jul. 26, 2009].

  11. I. Sommerville, Ingeniería de Software, Séptima edición, Madrid, Pearson Educación, 2005.

  12. L. Nguyen y G. Shanks, “Using Protocol Analysis to Explore the Creative Requirements Engineering Process”, [en Linea]. Disponible en: http://epress.anu.edu.au/info_systems02/mobile_devices/ch07.html, [Consultado: Jul. 26, 2009].

  13. U. Akbar, “Empirical Studies of Requirements ValidationTechniques”, IEEE Xplore Digital Library. [en línea]. Disponible en: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4909209&isnumber=4909154, [Consultado: Jul. 27, 2009]

  14. K. Kendall y J. Kendall, “Análisis y diseño de sistemas”, Sexta Edición, México, Pearson Educación, 2005, pp. 151-160.

  15. J. Lee y K, Hsu, “Modeling Requirements with Goals in Virtual University Environment *”, IEEE Xplore Digital Library. [en línea]. Disponible en: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=897227&isnumber=19427, [Consultado: Jul. 27, 2009]

  16. A. Sutcliffe, “RE 2003 Mini-tutorial: Scenario-based Requirements Engineering”, IEEE Xplore Digital Library. [en línea]. Disponible en: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1232776&isnumber=27626,

[Consultado: Jul. 27, 2009]

1 Tomado de : http://www.sei.cmu.edu/domain-engineering/domain_anal.html , breve explicación de Domain Analysis

2 HCI: Interacción Hombre Maquina.


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal