Web 2.0 en la elicitación de requisitos de software

Transcripción

1 Web 2. en la elicitación de requisitos de software Jennifer Herrera Vega Facultad de Ingeniería en Sistemas Universidad de San Buenaventura Santiago de Cali Andres Mauricio Rojas Libreros Facultad de Ingeniería en Sistemas Universidad de San Buenaventura Santiago de Cali Este proyecto de grado tiene como propósito proponer una herramienta Web 2. que nos colabore en el proceso de elicitación de requisitos en el desarrollo de software; a partir de la investigación realizada sobre herramientas colaborativas, metodologías ágiles, Web 2. y redes sociales las cuales se tomó como base para su desarrollo. I. INTRODUCCIÓN En la etapa de elicitación de requisitos en el ciclo de vida de software, es donde se expresa las necesidades y condiciones sobre el producto de software que se va a crear, esta etapa que es de vital importancia ya que se debe interpretar lo que el cliente quiere, la persona encargada de esta parte debe ser consciente de la dificultad del usuario para describir lo que realmente desea, en muchas ocasiones hay omisión de información y limitación de tiempo. Para ello, se cree conveniente usar una herramienta la cual nos proporcione facilidad a la hora de interactuar con el cliente, de esta forma el cliente puede estar pendiente de cómo va el proceso de los requisitos, realizar sugerencias, esto con el fin de que en dicha etapa de levantamiento de requisitos se minimice los problemas de comunicación y haya más participación del cliente. II. QUE ES WEB 2.? El término Web 2. fue acuñado por O Reilly Media y se refiere a una nueva generación de aplicaciones Web que provee participación, colaboración e interacción en línea a los usuarios. En general, estas aplicaciones actuales intentan ser más dinámicas y se caracterizan como comunidades sociales donde el mayor énfasis se da a la contribución y participación de los usuarios [1]. A. Caracteristicas de la Web 2. La Web es una plataforma: Ya que ahora tenemos la facilidad de tener servicios de software accesibles online. La Web es funcional: Ayuda en la transferencia de información y servicios desde páginas web. La Web es simple: Facilita el uso y acceso a los servicios web a través de pantallas más agradables y fáciles de usar. La Web es ligera: Los modelos de desarrollo, los procesos y los modelos de negocio se vuelven ligeros. La ligereza está asociada con la habilidad para compartir la información y los servicios de forma fácil y hacerlo posible a través de la implementación de intuitivos elementos modulares. La Web es social: Las personas crean la Web Popularizan la Web mediante la socialización y el movimiento gradual de los miembros del mundo físico hacia el mundo online. La Web es un flujo: Los usuarios son vistos como codesarrolladores. La Web es flexible: El software se encuentra en un nivel más avanzado porque este nivel permite el acceso a contenidos digitales a los que antes no se podía llegar. La Web es combinable: La expansión de códigos para poder modificar las aplicaciones web permite a los individuos, que no tienen por qué ser profesionales de los ordenadores para crear nuevas aplicaciones. La Web es participativa: La Web 2. ha adoptado una estructura de participación que alientan a los usuarios mejorar la aplicación mientras la utilizan, en vez de mantenerla rígida y controlada. La Web está en nuestras manos: El aumento de la organización de la información enfatiza el uso amistoso de la misma a través de los enlaces. Gracias al fenómeno social del etiquetado cada vez es más fácil acceder a la información [2].

2 B. Por que la Web 2. y para que puede servir? Actualmente cualquier tipo de persona tiene conocimientos del uso de alguna de las herramientas de la Web 2. e incluso se puede considerar que estas herramientas juegan un papel importante en la vida de las personas, tanto así que desde los lugares de trabajo, de estudio e incluso desde sus hogares el tiempo libre es invertido en visitar las redes sociales, foros, Wikipedia, entre otros; en vista de estas circunstancias el uso de la Web 2. es una opción a considerar en la investigación porque estas herramientas ya son parte de la vida de las personas y las usan con naturalidad y Por qué no hacer uso de estas en las labores cotidianas de trabajo, o en un proceso de desarrollo de software? Se considera la posibilidad de que el uso natural de estas, facilita la elaboración de ideas que se transforman en requisitos y la claridad en la necesidad del cliente, puesto que no se limita a una reunión previa o a un horario estrictamente laboral; siendo algo beneficioso para la elicitación de requisitos y del producto final de esta etapa. III. INGENIERÍA DE REQUISITOS La ingeniería de requisitos es un área de investigación que procura atacar un punto fundamental en el proceso de desarrollo de software, que es la definición de lo que se quiere producir. Davis [3], complementa la definición de la IEEE, mediante la definición de un requisito como "una necesidad del usuario o una característica necesaria, función o un atributo de un sistema que puede ser detectado desde una posición externa a ese sistema". Kotonya y Sommerville, afirman que los requisitos definen lo que el sistema debe hacer y las circunstancias que se requiere para funcionar. La ingeniería de requisitos suele ser vista como una actividad al inicio del ciclo vida de desarrollo de software. La ingeniería de requisitos es necesaria a través del ciclo de vida del desarrollo incluyendo las interacciones que sean necesarias cuando se utiliza un enfoque incremental interactivo [4]. Tabla 1. Cuadro de Número de herramientas para Ingeniería de requisitos [3]. Número de herramientas para Ingeniería de Requisitos Herramienta Elicitación de requisitos 37 Análisis de requisitos 36 Especificación de requisitos 16 Verificación y validación de 34 requisitos Administración de requisitos 17 Otras 17 Total 17 Número En la tabla 1 podemos observar, que existen 37 herramientas que soportan el proceso de elicitación de requisitos, teniendo en cuenta que es la fase que tiene más herramientas, frente a las de análisis de requisitos que cuenta con 36 herramientas, la especificación de requisitos que cuenta con 16, verificación y validación de requisitos con 34 y la administración de requisitos con 17 herramientas. IV. REDES SOCIALES En 199, cuando apareció la primera red social llamada classmates.com diseñada por Randy Conrads, la cual tenía como objetivo recuperar y mantener contacto entre compañeros de colegio, instituto y universidad. Ya en el 22 se empieza a volver famoso el término de redes sociales y es ahí cuando aparecen sitios como MySpace, Xing, entre otras. Las redes sociales han tenido un importante crecimiento en los últimos años, ya que son más las personas que lo usan para estar en contacto con familiares, amigos, compañeros, estas también son usadas para compartir información entre sus contactos []. Las redes sociales han venido jugando últimamente un papel fundamental en las actividades diarias de las personas tanto en su vida diaria como organizacional []. Las redes sociales han cambiado las maneras de interactuar con la Web buscando que todos los intereses de los usuarios queden satisfechos []. Las redes sociales han revolucionado las formas de interacción creando nuevos escenarios de comunicación []. V. AMBIENTE COLABORATIVO Dos de los problemas que tiene la gestión de los proyectos de software es la escasa participación de los usuarios y la defectuosa comunicación ya que hay un desconocimiento de las herramientas y ambientes que apoyan el desarrollo colaborativo de este [6]. Un ambiente colaborativo para el desarrollo de proyectos de software es un espacio Web común que sirve para comunicarse, tener un seguimiento y control de actividades que se estén realizando en un proyecto de software [6].

3 En la ilustración 2, podemos observar que la red social denominada Facebook es pionera, con más de 2 millones de usuarios, lo anterior indica que en dicho sitio es donde se encuentran más personas interactuando y compartiendo información entre sí. VI. METODOLOGÍAS ÁGILES PARA LOS REQUISITOS EN EL DESARROLLO DE SOFTWARE Ilustración 1. Diagrama ambiente colaborativo En la ilustración 1, vemos un ejemplo de ambiente colaborativo el cual posee tres tipos de facilidades como: Facilidad para la comunicación entre desarrolladores y clientes: el poder contactar y compartir de manera ágil eleva la velocidad de la producción global [6]. Facilidad para apoyar la gestión diaria de un proyecto: automatizado el seguimiento de las actividades para elevar el cumplimiento y la calidad de la producción [6]. Facilidad para apoyar el control y proyección de un proyecto: mediante reportes permanentes de mediciones sobre el progreso de un proyecto, que permiten al gerente corregir la gestión global [6]. Con los años hemos podido observar el incremento de uso de los medios sociales como Twitter, Facebook, mensajería instantánea, etc. El proceso de ingeniería de software implica interacción entre clientes, desarrolladores, arquitectos, gerentes, etc. Y el uso de las redes sociales permitiría, mejorar la comunicación entre las partes implicadas, trabajar en equipo más rápida y eficazmente, ya que vemos el auge que estas tienen en estos momentos a nivel mundial [7]. Ilustración 2. Usuarios de redes sociales Hasta hace poco el proceso de desarrollo llevaba asociada un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado de formalización en el proceso [8]. Ante las dificultades para utilizar metodologías tradicionales que consideren las restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la ingeniería del software, asumiendo el riesgo que ello conlleva. En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto. Tabla 2. Diferencias entre metodologías agiles y no agiles Metodologías Ágiles Basadas en heurísticas provenientes de prácticas de producción de código Especialmente preparados para cambios durante el proyecto Impuestas internamente (por el equipo) Proceso menos controlado, con pocos principios No existe contrato tradicional o al menos es bastante flexible El cliente es parte del equipo de desarrollo Grupos pequeños (<1 integrantes) y trabajando en el mismo sitio Pocos artefactos Pocos roles Menos énfasis en la arquitectura del software Metodologías Tradicionales Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo Cierta resistencia a los cambios Impuestas externamente Proceso mucho más controlado, con numerosas políticas/normas Existe un contrato prefijado El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos grandes y posiblemente distribuidos Más artefactos Más roles La arquitectura del software es esencial y se expresa mediante modelos

4 En la tabla 2, vemos las diferencias entre la metodología ágil y la metodología tradicional. En la metodología ágil soporta los cambios durante el proyecto mientras que en la metodología tradicional tiene resistencia a los cambios de un proyecto y este es uno de los puntos importantes en esta investigación. También las metodologías tradicionales tienen problemas a la hora de abordar proyectos por varias razones, costosas fases previas a educción de requisitos, el desarrollo es más lento. A. Porque XP es la mejor opción? Hay dos posibles metodologías agiles, que fomentan la interacción con el cliente de manera amplia, de una manera más activa que las demás que aunque lo fomentan no se ven tan representativo, estas metodologías son SCRUM y XP. Para determinar cuál de las metodologías agiles es la mejor opción? debemos centrarnos en que el objetivo principal de la Web 2.. Es crear un ambiente colaborativo, que permita la interacción de los diferentes usuarios de manera activa y constante, basándose en esta premisa y en el contexto que nos determina XP, donde el cliente posee un rol bien definido y de colaboración constante en todo el ciclo del desarrollo de software; se puede determinar que la metodología ágil más acorde con el objetivo principal planteado es XP, teniendo en cuenta que la interacción y las sugerencias del cliente van a ser en cualquier momento el cual causa de que los requisitos no sean lo suficientemente estables y pueden variar así una funcionalidad se encuentre terminada, también partimos del hecho que los tiempo promedio de las entregas que sugiere XP son de 1 3 semanas entre cada una, mientras que SCRUM son de 2 4 semanas, lo cual nos puede dar el indicador que la interacción del cliente podría ser más constante que usando la metodología ágil SCRUM. VII. PROCESO DE SELECCIÓN DE HERRAMIENTAS A. Etapa 1 Se realizó una revisión de herramientas comúnmente usadas en la gestión de requisitos (Aclaro DFSS, Aligned Elements, Avengo PEP, Blueprint, Bright Green Projects, Caliber RM, Cameo Reqirements, CASE Spec, Cognition Cockpit, Cradle, GMARC, intgreat, irqa, jucmnav, Leap SE, MacA&D, MKS Integrity, PACE, Polarion Requirements, Psoda, OFDcapture, QPack, RaQuest, Rational Doors, ReqMan, Rational Requirements Composer, TopTeam Analyst, TraceCloud, TrackStudio y VisibleThread) en busca del uso de herramientas Web 2.. el costo de implementación e instalación que tiene esta herramienta es superior a los $1 dólares. B. Etapa 2 Tabla 3. Comparación de herramientas Web 2. HERRAMIENTA SOFTWARE LIBRE SOFTWARE GRATUITO Se realizó un estudio de doce herramientas Web 2. (MindMeister, Media Wiki, People Aggregator, Google Docs, Twiki, Confluence, Chyrp, Pligg, WordPress, DotClear, ModX y Elgg ), con el fin de escoger la más viable, para el proceso de elicitación de requisitos de software. Después de realizar el proceso de selección y comprobar que las herramientas actuales de elicitación de requisitos realizan poco o nada el uso de las herramientas Web 2. se determina seleccionar la herramienta ELGG, por que suple con las etapas del proceso de elicitación de requisitos, además posee un gran apoyo por parte de la comunidad y la capacidad de integrar plugins que mejora la funcionalidad de esta; la estabilidad de la red social nos lleva a pensar que es un proyecto que seguirá creciendo y no abandonará en cualquier momento al soporte de esta. VIII. PRUEBA DE CONCEPTO Se tendrán en cuenta las siguientes escalas de calificación para determinar la viabilidad del uso de la tecnología: Tabla 4. Indicadores de evaluación en el uso de las herramientas Web 2.. DOCUMENTACIÓN MindMeiser NO NO MUY BUENA Media Wiki SI SI BUENA People Aggregator NO SI MALA Google Docs NO SI BUENA Twiki SI SI MUY BUENA Confluence NO NO BUENA Chryp SI SI MEDIO Pligg PARCIAL PARCIAL MEDIO WordPress NO PARCIAL BUENA DotClear SI SI BUENA ModX NO SI BUENA ELGG SI SI MUY BUENA Al finalizar la etapa se determina que existen muchas herramientas que tienen interfaz Web pero ninguna de estas aplica conceptos de la Web 2., existe una en la que se ven relacionados los conceptos de la Web 2. el único problema es

5 IX. RESULTADOS DE PRUEBA DE CONCEPTO A. Industria A continuación se presenta un análisis de cada una de las preguntas realizadas y las respuestas dadas por los expertos encuestados: 1. Consideras útil el uso de herramientas Web 2.? El objetivo de esta pregunta era conocer el concepto que se tiene acerca de la Web 2., y si los expertos en la industria de software ven una utilidad en su entorno de trabajo a estas herramientas. Se logra concluir que la industria del software está abierta a las posibilidades del trabajo colaborativo y si considera de utilidad estas herramientas si se busca la manera de aplicarlas en actividades relacionadas con la industria.

6 1 SI; 1 que se hicieron sugerencias para ser implementadas posteriormente. 1 1 SI; 12 SI Expertos NO; 1 NO 1 SI Expertos NO; 4 NO 2. Crees que el uso de un ambiente colaborativo sea viable para el proceso de elicitación de requisitos de software? El propósito de la pregunta era conocer el pensamiento de las personas de la industria de software acerca de involucrar de una manera más íntima al stakeholder estrechando el vínculo que tiene el desarrollador con el analista de software. Se puede concluir que la industria de software esta de mente abierta al uso de estas nuevas herramientas y saben que la interacción con el usuario es algo crucial en todo proceso de desarrollo, además, de que el uso de estas puede mejorar la calidad de los requisitos que surgen en la primera etapa de desarrollo. 1 1 SI; 14 SI NO; 2 NO 4. Actualmente, Crees que todo el proceso de desarrollo de software debe comenzar a adaptarse al uso de las herramientas Web 2.? El propósito de la pregunta era validar que las herramientas Web 2. no solo aportan un valor agregado en la primera etapa como es la elicitación, si no que se puede buscar un acercamiento de estas herramientas en el resto del proceso de desarrollo de software. Se puede concluir que la industria está en la espera de una herramienta que sea capaz de suplir las necesidades de comunicación e interacción con los stakeholders, no solo en la etapa de elicitación, si no a lo largo del todo el proceso y que estas etapas se contemplaran en proyectos posteriores. 1 SI; 1 SI Expertos NO; 6 NO Expertos B. Prueba de Campo 3. Crees que la herramienta ELGG, puede ser de gran importancia en el proceso de elicitación de requisitos de software? El propósito de la pregunta era corroborar que la herramienta seleccionada después de la investigación realizada, si cumplía con las condiciones para suplir la etapa de elicitación de requisitos, y que las funciones ofrecida por esta era lo suficientemente completas para esto. Se logra concluir que aunque la interacción con la herramienta fue relativamente poca creó expectativa en los expertos del apoyo que brinda la herramienta en el proceso de elicitación de requisitos, además de Después de terminar la iteración en la que se realizó la prueba de campo se realiza una encuesta tanto a desarrolladores, como a los stakeholder implicados que hicieron uso de la herramienta, y los desarrolladores y stakeholder que no hicieron uso de la herramienta y se obtuvieron los siguiente resultados: 1. Cuál fue el esfuerzo invertido en la elicitación de requisitos en una de las iteraciones del proyecto comparando la herramienta ELGG con la manera tradicional? (Pregunta realizada solo a los desarrolladores que hicieron uso de la herramienta)

7 Esta pregunta se realiza con el fin de conocer el sentimiento que tuvieron los desarrolladores al finalizar la etapa de elicitación, en la cual todos respondieron que el esfuerzo fue menor, y el motivo básicamente era la reducción del tiempo en el desplazamiento de los desarrolladores a las reuniones establecidas con el cliente, también influye que la retroalimentación, ideas y sugerencias provenientes del stakeholder eran realizadas en menor tiempo y podían percatarse de los errores en el proceso más tempranamente. A la hora de solucionar dudas provenientes de los desarrolladores se realizan en menor tiempo, sin tener que esperar una reunión con el stakeholder. 3. Como fue la satisfacción de las necesidades del cliente con el planteamiento de los requisitos realizados? Esta pregunta tenía el fin de establecer la percepción de los desarrolladores al finalizar la etapa de elicitación de requisitos con respecto al cumplimiento de la necesidad del cliente, logramos ver que la mayoría de los desarrolladores que hicieron uso de la herramienta Web 2., consideran que la satisfacción fue total, cosa contraria a los desarrolladores que hicieron uso de las metodología tradicional, el cual piensan que la satisfacción fue parcial MENOR; 3 IGUAL; MAYOR; MENOR IGUAL MAYOR Esta satisfacción se determina de los comentarios y sugerencias realizadas por parte de los stakeholder a la hora de finalizar la etapa y realizar la entrega formal de requisitos, se tiene en cuenta que los requisitos no sean interpretados de manera ambigua, si no por el contrario sean entendibles por cualquier usuario. Desarrolladores 2. Como fue la participación y la comunicación con el stakeholder? 2 1 Parcial; 12 Total; Total; 2 2 Parcial; 1 Nula; Nula; Total Parcial Nula Al realizar esta pregunta a ambos grupos de desarrolladores ( los que usaron la Web 2. y los que siguieron el método tradicional ) obtuvimos que una gran parte de los desarrolladores que siguen el método tradicional piensan que la participación del stakeholer es pasiva, puesto que se limitaba a las reuniones para resolver dudas causando pequeños lapsos de tiempo muerto, mientras los que hiceron el uso de la herramienta en su totalidad pensaron que era de manera activa, por la pronta solución de dudas, y retroalimentación constante dejado por el stakeholder. 1 Pasiva; 1 Activa; Activa; 3 4 Pasiva; Nula; Nula; Activa Pasiva Nula Uso de la web 2. Metodo Tradicional 4. Como fue el proceso de refinamiento de requisitos a lo largo de la iteración del proyecto de software? El fin de la pregunta era conocer la percepción de los desarrolladores con respecto a lo refinado que son los requisitos resultantes después de la etapa de elicitación de requisitos, al ver los resultados se interpretan que tanto los usuarios que usaron la metodología tradicional y los desarrolladores que usaron la herramienta Web 2. consideran que sus requisitos no se encuentran lo totalmente refinados y que pueden mejorarse aún más. Por medio de la herramienta no hay forma de validar el refinamiento de los requisitos y por lo tanto no apoya mucho esta etapa de la elicitación de requisitos. Uso de la web 2. Metodo Tradicional

8 2 Parcial; 13 Total; Total; 1 Parcial; 3 Nula; Nula; Total Parcial Nula 1, MENOR; IGUAL; MAYOR; 1 MENOR IGUAL MAYOR Uso de la web 2. Encuesta a los Stakeholder: Metodo Tradicional 1. Como fue la participación con los desarrolladores comparando la herramienta ELGG con manera tradicional? Al realizar esta pregunta queríamos saber la percepción de los stakeholder con respecto a los desarrolladores que lo hacen de manera tradicional y los que usan la Web 2., el stakeholder considera que la participación activa es por parte de los dos grupos de desarrolladores y se logra concluir que la participación puede ser activa incluso en los métodos tradicionales de desarrollo, en este caso el uso de la herramienta Web 2. no mejora de ninguna forma la participación de los desarrolladores. Stakeholder 3. Como fue la facilidad para identificar la claridad del requisito comparando la herramienta ELGG con la manera tradicional? Al realizar esta pregunta se buscaba determinar que requisitos presentaban más claridad al finalizar la etapa, la respuesta dada es que el uso de la herramienta Web 2. y la constante retroalimentación del stakeholder, logra realizar un requerimiento que a la larga es más claro que uno realizado de la manera tradicional, esto no quiere decir que de la manera tradicional no se puedan realizar requisitos claros, si no que gracias a la retroalimentación y la participación más activa del stakeholder se logró más claridad en los requisitos resultantes. 1 Total; 1 1 Activa; 3 Activa; 9 Pasiva; Pasiva; Nula; Nula; Activa Pasiva Nula, Parcial; Nula; Total Parcial Nula Stakeholder Uso de la web 2. Metodo Tradicional 2. Cuál fue el esfuerzo invertido en la elicitación de requisitos en una de las iteraciones del proyecto comparando la herramienta ELGG con la manera tradicional? Como conclusión se logra determinar que el uso de las herramientas Web 2. en la etapa de elicitación de requisitos realiza mejoras notables en una iteración del desarrollo de un producto de software y que el apoyo de estas herramientas puede mitigar el riesgo de los requisitos mal redactados o poco entendibles, que la participación activa es una parte fundamental para conseguir los resultados esperados. Con respecto al esfuerzo invertido por parte del stakholder en la etapa de elicitación de requisitos realizando uso de la herramienta Web 2. fue mayor, pero aunque haya sido mayor el cliente quedo más satisfecho al finalizar dicha etapa, y enfatizo que el esfuerzo aplicado fue realizado en cualquier momento del día, lo cual era un poco más favorable ya que no tenía que realizar aplazamiento de actividades más prioritarias para él, y pudo realizar la retroalimentación pertinente de los avances presentados con mayor tranquilidad, lo cual mostraba un avance mayor a lo largo del proceso.

9 C. Calificación de los criterios a evaluar Tabla. Calificación de los criterios a evaluar Indicador Concepto Valoración Refinamiento de los requisitos. Satisfacción de la necesidad del cliente. Forma usada para la extracción del requisito. 3 Facilidad para identificar el origen del requisito. Claridad del requisito Cumple con la necesidad. Desarrolladores 4 La Web 2. es un concepto relativamente nuevo y aún le queda mucho camino por recorrer, el desarrollo de software debe buscar hacer uso de este concepto para establecer una metodología que minimice el riesgo de fracaso que actualmente tiene el desarrollo de software tradicional. El uso de las herramientas Web 2. en una metodología de desarrollo ágil facilita la interacción con el cliente de manera activa, así este se encuentre geográficamente distante reduciendo el limitante de tiempo que posiblemente el cliente tiene para dedicar al proyecto de software y, sin olvidar los principios del desarrollo ágil. Participación de las partes implicadas en las herramientas Web 2. Stakeholders 3 El uso de la Web 2. en la etapa de elicitación de requisitos podría mejorar la calidad de los requisitos entregados en esta etapa, causando así una disminución en el ciclo de vida del desarrollo de un proyecto de software. Esfuerzo de las partes implicadas en las herramientas Web 2.. Desarrolladores Stakeholder 3 REFERENCIAS Con respecto a los criterios a evaluar se determina que el uso de la Web 2. es viable en la etapa de elicitación de requisitos, pero que hay aspectos en los que hay que enfatizar y profundizar con el ánimo de plantear una metodología en la cual el proceso de elicitación se lleve de manera correcta y sea considerablemente mejor, tanto para los desarrolladores como para los stakeholder. X. CONCLUSIONES Vivimos en una época donde las barreras de comunicación se están rompiendo muy rápidamente, en donde comunicarse con alguien geográficamente distribuido ya no es un problema, tenemos que comenzar a evolucionar el desarrollo de software que conocemos para el uso de los nuevos alcances de nuestro entorno, buscando mitigar los problemas con los que se cuenta actualmente. Se entiende que la elicitación de requisitos es una parte crucial en todo desarrollo de software, pero buscar que las partes interesadas estén en constante interacción desde esta etapa de desarrollo permite una mayor probabilidad de que el proyecto sea un éxito. [1] Fahad, J., & Abdul, M. (29). Herramientas Web 2. para el Aprendizaje Colaborativo. Reading. [2] Caracteristicas de la Web internet-ha-cambiado-y-tu.html [3] Davis, A. M. (1993) Software Requirements: Objects, Functions, and States. UpperSaddle River, NJ:Prentice Hall. [4] Propuesta_Proyecto_Investigacion. (n.d.). [] Bindplanning-Proyectos Personales. (n.d.). [6] Franky, M. C. (211). colaborativos Temática. [7] Black, S., Harrison, R., & Baldwin, M. (21). A Survey of Social Media Use in Software Systems Development. Analysis, 1-. [8] Canós, J. H., Letelier, P., Penadés, C., & Valencia, D. P. D. (n.d.). Métodologías Ágiles en el Desarrollo de Software. Development, 1-8.