WEB 2.0 EN LA ELICITACIÓN DE REQUISITOS DE SOFTWARE

Transcripción

1 WEB 2.0 EN LA ELICITACIÓN DE REQUISITOS DE SOFTWARE Jennifer Herrera Vega Código Andres Mauricio Rojas Libreros Código Universidad de San buenaventura Facultad de ingeniería Programa de ingeniería de sistemas Seccional Cali Santiago de Cali 2012

2 WEB 2.0 EN LA ELICITACIÓN DE REQUISITOS DE SOFTWARE Jennifer Herrera Vega Código Andres Mauricio Rojas Libreros Código Proyecto de Grado Director: Ph.D. Luis Mérchan Paredes Doctorado en Investigación Universidad de San buenaventura Facultad de ingeniería Programa de Ingeniería de Sistemas Seccional Cali Santiago de Cali

3 Notas de aceptación: Firma del jurado Firma del jurado Firma del jurado 2

4 TABLA DE CONTENIDO GLOSARIO... 8 RESUMEN INTRODUCCIÓN PLANTEAMIENTO DEL PROBLEMA JUSTIFICACIÓN OBJETIVOS DEL PROYECTO MARCO CONCEPTUAL WEB Ingeniería de Requisitos Redes Sociales Ambiente Colaborativo Metodologías Ágiles para los Requisitos en el Desarrollo de Software SCRUM XP CRYSTAL CLEAR DSDM- DYNAMIC SYSTEMS DEVELOPMENT METHOD FDD- FEATURE DRIVEN DEVELOPMENT ASD- ADAPTIVE SOFTWARE DEVELOPMENT XBREED- SCRUM WRAPPER FOR XP Requisitos en XP Por qué XP es la mejor opción? SOLUCIÓN DEL PROBLEMA Proceso de selección de la herramienta a usar Herramienta Web 2.0 seleccionada Prueba de concepto

5 5.4. Funcionalidades de la Herramienta seleccionada TRABAJOS FUTUROS CONCLUSIONES ANEXOS ANEXO A: Análisis de resultados Cuestionario a expertos en la industria del software ANEXO B: Análisis de resultados Prueba de Campo BIBLIOGRAFÍA

6 LISTA DE TABLAS Tabla 1. Herramienta Web 2.0 MindMeister (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 2. Herramienta Web 2.0 Media Wiki (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 3. Herramienta Web 2.0 People Aggregator (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 4. Herramienta Web 2.0 Google Docs (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 5. Herramienta Web 2.0 Twiki (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 6. Herramienta Web 2.0 Confluence (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 7. Herramienta Web 2.0 Chryrp (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 8. Herramienta Web 2.0 Pligg (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 9. Herramienta Web 2.0 WordPress (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 10. Herramienta Web 2.0 Dotclear (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 11. Herramienta Web 2.0 ModX (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 12. Herramienta Web 2.0 Elgg (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1] Tabla 13. Herramientas de Ingeniería de Requisitos [3] Tabla 14. Cuadro de Número de herramientas para Ingeniería de requisitos [3] Tabla 15. Diferencias entre metodologías ágiles y no ágiles [11] Tabla 16. Comparación entre Metodologías agiles [14] Tabla 17. Uso de la Web 2.0 en herramientas de uso común Tabla 18. Comparación de herramientas Web

7 Tabla 19. Indicadores de evaluación en el uso de las herramientas Web Tabla 20. Calificación de los criterios a evaluar

8 LISTA DE ILUSTRACIONES Ilustración 1. Diagrama de ambiente colaborativo [6] Ilustración 2. Usuarios de redes sociales [7] Ilustración 3. Modelo de desarrollo utilizando SCRUM [12] Ilustración 4. Descripción de cada fase en la que se subdivide el ciclo de vida XP [14]. 56 Ilustración 5. Fases del proceso de desarrollo DSDM [40] Ilustración 6. Los cinco procesos dentro de FDD [14] Ilustración 7. El ciclo de vida adaptativo ASD [14] Ilustración 8. Actividades del ciclo de vida adaptativo ASD [14] Ilustración 9. Requisitos en la metodología XP Ilustración 10. Gestión de requisitos en XP [21] Ilustración 11. Pantalla Inicial Ilustración 12. Adjuntar archivo Ilustración 13.Notificación de archivo subido Ilustración 14. Comentarios en archivos Ilustración 15. Archivos adjuntos de amigos Ilustración 16. Mensajes y chat

9 GLOSARIO Comunidades sociales: son páginas que permiten a las personas conectar con sus amigos, incluso realizar nuevas amistades, a fin de compartir contenidos, interactuar, crear comunidades sobre intereses similares: trabajo, lecturas, juegos, amistad, relaciones interpersonales. [22] Blogging: Es un sitio web periódicamente actualizado que recopila cronológicamente textos o artículos de uno o varios autores, apareciendo primero el más reciente, donde el autor conserva siempre la libertad de dejar publicado lo que crea pertinente [16]. Bookmarks: Es una herramienta que tienen algunas aplicaciones que almacena direcciones de páginas web que el usuario desea acceder fácilmente. En Internet Explorer esta herramienta es llamada Favoritos [17]. API: significa Interfaz de Programación de Aplicaciones Una API es una "llave de acceso" a funciones que nos permiten hacer uso de un servicio web provisto por un tercero, dentro de una aplicación web propia, de manera segura. Es una interfaz para dar un acceso limitado a la base de datos de un servicio web, evitando que se conozca o acceda al propio código fuente de la aplicación original [23]. Licencia GPL: La licencia GPL o General Public License, desarrollada por la FSF o Free Software Foundation. Puedes instalar y usar un programa GPL en uno o varios ordenadores, sin limitación. También puedes modificar el programa para adaptarlo a lo que se desea que haga. Además, podrás distribuir el programa GPL tal cual o después de haberlo modificado [24]. 8

10 Modelo en casada: Es un paradigma que sugiere un enfoque sistemático, secuencial, hacia el desarrollo del software, que se inicia con la especificación de requisitos del cliente y que continua con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado [25]. Elicitación de requisitos: Es la primera actividad del ciclo de vida en la Ingeniería de requisitos. Especificación de requisitos: Es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software [26]. Requisito: Terminología Estándar de Ingeniería de Software (IEEE: Standard Glossary of Software Engineering Terminology) define al requisito como: Condición o capacidad que necesita un usuario para resolver un problema o lograr un objetivo. Condición o capacidad que tiene que ser alcanzada o poseída por un sistema o componente de un sistema para satisfacer un contrato, estándar, u otro documento impuesto formalmente. Una representación en forma de documento de una condición o capacidad como las expresadas en 1 o en 2 [27]. Product backlog: Es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requisitos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI). Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido [28]. 9

11 StakeHolders: (Clientes, Proveedores, Vendedores, etc) Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint [28]. Sprint Backlog: Es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser divida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno [28]. Sprint: Es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia. [28]. Scrum Master: El ScrumMaster no es el líder del equipo (porque ellos se autoorganizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan [28]. Sprint planning meeting: Reunión de Planificación del Sprint (Sprint Planning Meeting) Al inicio del ciclo Sprint (cada 15 o 30 días), una Reunión de Planificación del Sprint se lleva a cabo. Seleccionar qué trabajo se hará. Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo. Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint. Ocho horas como límite [28]. 10

12 Daily scrum: Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto [28]. Sprint review meeting: Reunión de Revisión del Sprint (Sprint Review Meeting) Revisar el trabajo que fue completado y no completado. Presentar el trabajo completado a los interesados (alias demo ). El trabajo incompleto no puede ser demostrado. Cuatro horas como límite [28]. Release: Es el proceso de entregas de software nuevo o de actualizaciones del software [29]. Wiki: es un espacio web corporativo, organizado mediante una estructura hipertextual de páginas (referenciadas en un menú lateral), donde varias personas elaboran contenidos de manera asíncrona. Basta pulsar el botón "editar" para acceder a los contenidos y modificarlos. [38]. 11

13 RESUMEN Este documento presenta el desarrollo del proyecto cuyo propósito es proponer una herramienta Web 2.0 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.0 y redes sociales las cuales se tomó como base para su desarrollo. Adicionalmente, se incluye la investigación realizada, sobre la Web 2.0, herramientas colaborativas, redes sociales, Metodologías ágiles y el análisis que se realizó para llegar a la herramienta a utilizar. Finalmente, el documento incluye encuestas de satisfacción, lo cual nos confirma que la herramienta propuesta es de gran utilidad en la primera fase del desarrollo de software. 12

14 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. El documento incluye una investigación sobre herramientas Web 2.0, redes sociales, herramientas colaborativas, Metodologías ágiles y el análisis realizado para escoger la herramienta más óptima, la cual nos va a servir de apoyo para realizar la primera fase del desarrollo de software, para esto el documento se ha dividido en los siguientes capítulos: Capítulo 1: Planteamiento del problema. Explica y argumenta el problema que dio origen al trabajo de grado. Capítulo 2: Justificación. Sustenta el por qué el trabajo de grado y la forma en como se llevó a cabo. Capítulo 3. Objetivos. Es el resultado que se espera lograr al finalizar el trabajo de grado. Capítulo 4. Marco conceptual. Conocimientos teóricos ya existentes sobre el tema investigación del trabajo de grado. Capítulo 5. Solución del problema. Herramienta seleccionada, criterios de evaluación y funcionalidades de la herramienta seleccionada. 13

15 1. PLANTEAMIENTO DEL PROBLEMA En el siglo XXI, las redes sociales han marcado una pauta muy importante en nuestra sociedad, ya que el hombre siente necesidad de transmitir y compartir sus conocimientos, gustos, con el fin de realizar negocios, hacer amistades, posicionamiento web. Las herramientas informáticas, manejan tres ámbitos que son la comunicación, comunidad y cooperación. En la comunicación, que es donde podemos tener todos nuestros conocimientos en común, la comunidad, nos ayuda a descubrir comunidades y la cooperación, que es el poder hacer cosas juntas. En el proceso de la elicitación de requisitos, vemos la importancia que tienen dos ámbitos que nos brinda las redes sociales que son comunicación y cooperación. A partir de lo planteado anteriormente, surge la pregunta Cómo contribuir en la comunicación y cooperación entre cliente y elicitador, para realizar de forma eficaz el proceso elicitación de requisitos en el ciclo de vida de software? El desarrollo del proyecto responderá al problema planteado, mediante la investigación de herramientas Web 2.0, redes sociales, ingeniería de requisitos, metodologías agiles y ambientes colaborativos. Todo esto con el propósito de analizar que herramientas nos pueden contribuir para realizar el proceso de elicitación de requisitos entre el cliente y la persona encargada de los requisitos de una forma eficiente. 14

16 2. JUSTIFICACIÓN Actualmente, cuando el desarrollo de software se vuelve más común, a cada segundo, nos enfrentamos al problema, de cómo realizar la definición de requisitos no solo de manera clara para que un desarrollador lo entienda fácilmente, si no lo suficientemente completo para lograr suplir todas las necesidades de los clientes y lograr una satisfacción en ellos. Intentando mitigar esta situación se hizo una revisión de las herramientas con las que actualmente se cuenta en la ingeniera de requisitos, como son Doors, CaliberRM, RequisitePRO, entre otros. Pero estas fueron diseñadas para apoyar un grupo relativamente pequeño de expertos en la captación, estructuración, desarrollo y gestión de los requisitos de software. Pero la participación de los stakeholders sigue siendo complicada, ya que normalmente son grupos de actores no entrenados que solo tienen poca experiencia en la ingeniería de requisitos. Además, las soluciones que brindan estas herramientas proporcionan un apoyo limitado a la interacción y la colaboración de las partes interesadas. Por esta razón los participantes se ven obligados a cambiar a otras herramientas (Correo electrónico, mensajería instantánea) o cara a cara para lograr realizar un contacto de colaboración en este proceso de ingeniería de requisitos. Sin embargo, si los participantes están geográficamente distribuidos un contacto cara a cara es poco probable, el uso de las herramientas adicionales de colaboración posiblemente requieran más instalaciones y un cambio del entorno de aplicación que resulta en un mayor esfuerzo y una barrera para la participación de las partes interesadas. Pero el problema principal de toda la colaboración entre las partes interesadas es que ocurre de manera independiente a las herramientas de gestión de requisitos y por lo tanto proporciona poca o ninguna transparencia y trazabilidad: Por ejemplo, el proceso de colaboración que tiene lugar antes de que un requisito se introduce en la herramienta de gestión a menudo es insuficientemente documentados y por lo tanto difícil de justificar en una previa ocasión. 15

17 Con base en estas ideas, se presenta el siguiente proyecto de investigación que busca ofrecer un soporte ligero para la ingeniería de requisitos haciendo uso de la tecnología Web 2.0. Con el fin de permitir un gran número de actores distribuidos geográficamente que promueva la colaboración, discutir, enriquecer semánticamente y evaluar los requisitos del software de una manera más activa con los diferentes stakeholders. En este proyecto se presenta características seleccionadas de las herramientas Web 2.0 que ilustran cómo los conceptos del software social se podrían ver aplicados de forma integrada con el proceso de elicitación de requisitos y podría alentar a grupos de interés que no utilizan las herramientas convencionales de ingeniería de requisitos para participar y colaborar activamente en el desarrollo de software. 16

18 3. OBJETIVOS DEL PROYECTO Objetivo General Realizar una investigación de herramientas Web 2.0, redes sociales, herramientas colaborativas y Metodologías ágiles con el fin de escoger la más óptima para el proceso de elicitación de requisitos. Objetivos Específicos 1. Generar una base conceptual sobre los aspectos relacionados con herramientas Web Identificar que herramienta Web 2.0 es la más viable. 3. Generar una base conceptual sobre los aspectos relacionados con redes sociales. 4. Realizar investigación sobre Metodologías ágiles. 5. Identificar que Metodología ágil es la más recomendable. 6. Evaluar un conjunto de herramientas que nos sirva de colaboración para la etapa de elicitación de requisitos. 17

19 4. MARCO CONCEPTUAL 4.1. WEB 2.0 El término Web 2.0 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]. Se comparten documentos en los que varias personas pueden trabajar al mismo tiempo, se utilizan interfaces dinámicas y atractivas que se acercan a las aplicaciones de escritorio, se comparte información, en ocasiones en tiempo real, por medio de interfaces de programación y comunicación que permite el desarrollo rápido de nuevas aplicaciones y permiten la participación de la comunidad en el etiquetamiento, clasificación y toma de decisiones [1]. La Web 2.0 (blogs, compartición de medios y otras herramientas de la Web social) puede usarse para crear entornos colaborativos que comparten objetos de aprendizaje. A través de estos entornos se crea un esfuerzo conjunto de aprendizaje colaborativo en que cada participante ayudará en entregar aprendizaje efectivo a los demás. Específicamente, la Web 2.0 ha sido llamada la Web social y colaborativa [1]. La Web 2.0 posee las siguientes características: La Web es una plataforma: Ya que ahora tenemos la facilidad de tener servicios de software accesibles online [15]. La Web es funcional: Ayuda en la transferencia de información y servicios desde páginas web [15]. 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 [15]. 18

20 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 [15]. 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 [15]. La Web es un flujo: Los usuarios son vistos como co-desarrolladores [15]. 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 [15]. 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 [15]. La Web es participativa: La Web 2.0 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 [15]. 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 [15]. A continuación se presentan algunos de los tipos Aprendizaje Colaborativo: de herramientas Web 2.0 para Blogging Bookmarks Community Collaborative 19

21 Education Management Project Management RSS Feeds Tagging Wiki Dado que hay literalmente una innumerable cantidad de aplicaciones Web 2.0 disponibles en la Internet, es difícil determinar cuáles de ellos pueden soportar programas educativos. Se propone un análisis de las mismas a partir de los siguientes criterios de selección: [1] Soporte para comunicación y colaboración entre los participantes. Nivel de soporte para evaluar el nivel de participación de grupos e individuos. Número de actividades Web 2.0 y herramientas que se soportan. Que sea de código libre con licencia GPL y que sea libre de usar y modificar. Calidad del API Web 2.0, incluyendo soporte. Buena documentación y guías para usuarios y desarrolladores. Interfaz de usuario rica con buen diseño. La Web 2.0, son aplicaciones que generan colaboración, nos ayudan a compartir información ya que permite interactuar con otros usuarios. La Web 2.0 está basado en una serie de tecnologías, que se encuentran en constante evolución. De la tabla 1 a la tabla 12 podemos observar varias herramientas Web 2.0, con sus respectivos elementos de aprendizaje colaborativo, lo que soporta cada una de ellas y a su vez lo que le hace falta. 20

22 Las posibles herramientas Web 2.0 a usar son: MindMeister: es una línea de mapas mentales de software que permite a sus usuarios visualizar su forma de pensar. Permite crear, administrar y compartir en cualquier momento desde cualquier lugar. La forma de trabajar es sencilla: se alimenta una lista ordenada de artículos que puede ser editada o formateada para formar mapas mentales. MindMeister ofrece a los usuarios tres mapas gratuitos con todas las funciones, pero cobra una cuota de suscripción para mapas adicionales [30]. Tiene las siguientes características: Colaboración en tiempo real [1]. Compartir contenidos [1]. Fácil de usar [1]. Interfaz gráfica excelente [1]. Exportar e importar mapas mentales [1]. Controlar las contribuciones de los usuarios [1]. Mejoras a la navegación y al formato [1]. Opciones para publicar en blogs y otros sitios Web [1]. 21

23 Tabla 1. Herramienta Web 2.0 MindMeister (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva. División de tareas. Soporte a grupos. Interacción. Toma de decisiones. Discusión grupal e interacción. Rendición de cuentas y responsabilidad individual. Compartición de recursos. Votación y evaluación de contribuciones. MindMeister Habilidades para el manejo de grupos pequeños. Edición colaborativa en tiempo real. Evaluación de contribuciones. Procesamiento de grupo. Control de contribuciones de los usuarios. Control de cambios. Resolución de conflictos. Media Wiki: Es un software para wikis libre programado en el lenguaje PHP. Ha tenido una gran expansión desde el año 2005, existiendo un gran número de wikis basados en este software que no mantienen relación con dicha fundación, aunque sí comparten la idea de la generación de contenidos de manera colaborativa [1]. Tiene las siguientes características: Buena interfaz gráfica [1]. Extensiones multimedia [1]. 22

24 Registro de modificaciones [1]. Verificación de estructura y sintaxis [1]. Editor WYSIWYG [1]. Foros de discusión [1]. Soporte multilenguaje [1]. Buen modelo de permisos y seguridad [1]. Buen motor de búsqueda [1]. Alimentación RSS para verificar cambios de contenidos [1]. Tabla 2. Herramienta Web 2.0 Media Wiki (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva. Soporte de grupos. Toma de decisiones. Interacción. Discusión grupal e interacción. Votación y evaluación de contribuciones. Media Wiki Rendición de cuentas y responsabilidad individual. Habilidad para el manejo de grupos pequeños. División de tareas. Compartición de recursos. Resolución de conflictos. Evaluación de contribuciones. Procesamiento de grupo. Edición colaborativa de textos. 23

25 Control de cambios. People Aggregator: Es un servicio web en la red social. La idea es descargar el código y crear un sitio y los usuarios pueden entrar a un sitio alojado y hacen clic en un botón y empiezan a usar su propia red. Es una herramienta de redes sociales con las siguientes características: es una red social tradicional, es una red de meta lo que es posible genera sus propias redes o grupos con el clic, habrá una versión descargable de la misma que se puede configurar en su propio servidor y contendrá los servicios web externos de Mashup con los servicios existentes [31]. Tiene las siguientes características: Blogging [1]. Compartir y administrar archivos de medios [1]. Enviar mensajes [1]. Construir y administrar grupos [1]. Crear relaciones entre grupos y usuarios [1]. Crear metaredes [1]. Publicar contenidos [1]. Construir foros de discusión [1]. 24

26 Tabla 3. Herramienta Web 2.0 People Aggregator (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Soporte de grupos Toma de decisiones Interacción Discusión grupal e interacción División de tareas Rendición de cuentas y responsabilidad individual Votación y evaluación de las contribuciones Edición colaborativa People Aggregator Habilidades para el manejo de grupos pequeños Compartición de recursos Control de cambios Creación de relaciones Resolución de conflictos Control de contribuciones de los usuarios Google Docs: es un conjunto de productos que permite crear distintos tipos de documentos, trabajar en ellos con otros usuarios en tiempo real y almacenar documentos y otros archivos. Estas herramientas permiten trabajar de forma colaborativa en documentos, hojas de cálculo, presentaciones y otro tipo de documentos. Google Docs permite edición colaborativa, compartición de contenidos y administración de documentos. Todo online y de forma gratuita [32]. Tiene las siguientes características: Crear documentos básicos [1]. 25

27 Subir archivos en una variedad de formatos incluyendo DOC, XLS, ODT, ODS; RTF; CSV, PPT, etc. [1]. Los editores tienen las herramientas más comunes de las aplicaciones de escritorio [1]. Edición colaborativa [1]. Compartición instantánea [1]. Importar/exportar en diversos formatos, incluyendo pdf [1]. Administración de documentos [1]. Publicación en línea y control de accesos [1]. Registros de cambios y control de versiones [1]. Tabla 4. Herramienta Web 2.0 Google Docs (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva División de tareas Manejo de grupos Interacción Toma de decisiones Discusiones grupales Rendición de cuentas y responsabilidad individual Compartición de recursos Evaluación de contribuciones Google Docs Habilidades para el manejo de grupos pequeños Procesamiento de grupo Edición colaborativa Control de contribuciones de los usuarios Control de cambios 26

28 Resolución de conflictos Twiki: permite el desarrollo de aplicaciones web basadas en formularios sin necesidad de programación así como control de acceso sofisticado opcional. Soporta también variables de configuración, búsquedas, anexos de archivos, etc. La interfaz de aplicación para extensiones es utilizada por más de cien extensiones disponibles para acceso a bases de datos, diagramas, ordenamiento de tablas, hojas de cálculo, dibujos, seguimiento de proyectos y muchas otras posibilidades [33]. Twiki permite: Trabajar juntos para crear y editar documentos para diferentes propósitos [1]. Los usuarios pueden colaborar para hacer modificaciones [1]. Utilizar un sistema de mensajes internos tipo tabla de boletines [1]. Administrar y compartir documentos [1]. Soporte multilenguaje [1]. Registrar juntas y discusiones [1]. También proporciona una base de conocimientos y un sistema de preguntas frecuentes [1]. Tabla 5. Herramienta Web 2.0 Twiki (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Soporte de grupos Evaluación de contribuciones Interacción Discusión grupal e Resolución de 27

29 interacción conflictos Twiki Rendición de cuentas y responsabilidad individual Habilidades para manejo de grupos pequeños Procesamiento de grupo Manejo de grupos División de tareas Compartición de recursos Edición colaborativa Control de modificaciones Confluence: es desarrollado y comercializado por Atlassian. Atlassian Confluence dice conecta los equipos con el contenido y compañeros de trabajo que necesitan para realizar su trabajo [34]. Tiene las siguientes características: Crear páginas editables instantáneamente [1]. Información en tiempo real y notificaciones usando blogs [1]. Información actual a través de notificaciones [1]. Editor WYSIWYG [1]. Opciones configurables [1]. Fácil de usar y amigable [1]. Permite discusiones para grupos y equipos de trabajo [1]. Compartir y controlar archivos [1]. Creación de espacios de trabajo [1]. Modificable con añadidos [1]. 28

30 Tabla 6. Herramienta Web 2.0 Confluence (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Soporte de grupos Evaluación de contribuciones Interacción Manejo de grupos Resolución de conflictos Confluence Rendición de cuentas y responsabilidad individual Habilidades para el manejo de grupos pequeños Procesamiento de grupo Interacción y discusión grupal Compartición de recursos Edición colaborativa Control de modificaciones Chyrp: es una herramienta Web 2.0 la cual tiene la funcionalidad de personalizarse como sea necesario. Es configurable por medio de temas y se le pueden añadir módulos. Se puede personalizar de la forma que al usuario le parezca más apropiado. Chryp soporta actividades Web 2.0 como blogging, Folksonomy, publicación de contenidos y edición de contenidos. La licencia es GPL y es de código libre [1]. 29

31 Tabla 7. Herramienta Web 2.0 Chryrp (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Soporte de grupos Evaluación de contribuciones Interacción Compartición de recursos División de tareas Chyrp Rendición de cuentas y responsabilidad individual Edición colaborativa Resolución de conflictos Habilidades para el manejo de grupos pequeños Control de contribuciones de los usuarios Procesamiento de grupo Control de modificaciones Pligg: Es un CMS de código abierto (Content Management System) que puede descargar y utilizar de forma gratuita. Pligg CMS ofrece software de publicación social que anima a los visitantes se registren en su sitio web para que puedan presentar los contenidos y conectarse con otros usuarios [35]. Tiene las siguientes características: Soporta múltiples autores y usuarios [1]. Evaluación de artículos [1]. Mensajes privados [1]. Sistema avanzado de comentarios [1]. 30

32 Sistema de módulos con bibliotecas que permite mejorar la aplicación [1]. Plantillas Smarty [1]. Verificación de sintaxis [1]. Soporte para múltiples lenguajes [1]. Perfiles de usuarios [1]. Alimentaciones RSS [1]. Importar artículos de noticias y alimentaciones RSS [1]. Ordenar artículos [1]. Alimentaciones de noticas en vivo usando Ajax [1]. Control de enlaces con URL Blocklist [1]. Tabla 8. Herramienta Web 2.0 Pligg (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Soporte de grupos Resolución de conflictos Interacción Compartición de recursos Rendición de cuentas y responsabilidad individual División de tareas Habilidades para el manejo de grupos pequeños Discusiones grupales Pligg Procesamiento de grupo 31

33 Control de contribuciones de los usuarios Control de cambios Evaluación de las contribuciones WordPress: es una avanzada plataforma semántica de publicación personal orientada a la estética, los estándares web y la usabilidad. WordPress es libre y, al mismo tiempo, gratuito [36]. Tiene las siguientes características: Temas decorativos y un sistema de plantillas para la interfaz [1]. WordPress Links que se usan para crear, mantener y actualizar cualquier cantidad de colecciones de enlaces blog a través de la interfaz administrativa [1]. Soporta literalmente cientos de añadidos [1]. Multiples categorías anidadas para artículos los cuales pueden ser expuestos a la máquina de búsqueda [1]. Manejo de versiones y control de cambios [1]. Filtros tipográficos para formatear apropiadamente los textos y establecer estilos [1]. Mantenimiento de páginas estáticas [1]. Soporte para multiples autores con diferentes privilegios [1]. Aplicaciones de control de enlaces para publicar blogs y agregar enlaces a las colecciones de enlace blog con la menos cantidad de esfuerzo [1]. Control de usuarios que visitan los blog [1]. Protección contra mensajes indeseables (spam) y bloqueos de visitantes basado en dirección de IP [1]. 32

34 Soporte para etiquetas [1]. Editor de contenidos WYSIWYG [1]. Importación simple desde otras plataformas [1]. Fácil instalación y actualizaciones [1]. Tabla 9. Herramienta Web 2.0 WordPress (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Compartición de recursos Manejo de grupos Interacción División de tareas Evaluación de contribuciones WordPress Rendición de cuentas y responsabilidad individual Discusión y panel de control Resolución de conflictos Habilidades para el manejo de grupos pequeños Edición colaborativa Procesamiento de grupo Control de contribuciones de los usuarios Control de cambios Dotclear: es una herramienta de software Web 2.0 para publicación de contenidos. El principal objetivo de Dotclear es ofrecer a los usuarios una herramienta amigable para publicar contenidos con facilidad en la Web sin importar el nivel de habilidades técnicas de usuarios. Es gratuito. Fue desarrollado con PHP y MySQL [1]. 33

35 Tiene las siguientes características: Muy simple [1]. Fácil publicación [1]. Administración de archivos multimedios [1]. Edición de sintaxis dual Wiki/XHTML con traductor interno [1]. Soporte a múltiples lenguaje [1]. Cumple con código W3C [1]. Sistema de plantillas flexible [1]. Etiquetas y categorías para las páginas [1]. Permite entrada flexibles con comentarios y control de cambios [1]. Sistema configurable completo de temas de apoyo a los plugin [1]. Tabla 10. Herramienta Web 2.0 Dotclear (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Compartición de recursos Manejo de grupos Interacción Manejo de archivos de medios Evaluación de contribuciones Rendición de cuentas y responsabilidad individual División y panel de control Resolución de conflictos Dotclear Habilidades para el manejo de grupos pequeños Edición colaborativa Procesamiento de Control de contribuciones de 34

36 grupo los usuarios Control de cambios ModX: es un sistema de manejo de contenidos y plataforma de aplicaciones de código libre desarrollado en PHP y Ajax. Es fácil de usar y tiene una arquitectura flexible y modular. Proporcionar optimización de contenidos y de búsqueda de los mismos basándose en meta etiquetas y palabras clave para hacer que las búsquedas sean más amigalbes. ModX puede realizar blogging, administración de contenidos, publicación de contenidos, edición de contenidos,alimentaciones RSS y recomendaciones [1]. Tiene las siguientes características: Soporte a estándares Web fuerte [1]. Marco de trabajo en PHP [1]. Soporte para diferentes navegadores [1]. Instalador gráfico [1]. Constructor de menús CSS [1]. Controles de metaetiquetas y palabras clave [1]. Separación de sesiones de administrador y usuario [1]. Manejo de errores y revisión de documentos mejorados [1]. Tipos de contenidos definidos por el usuario [1]. Importación de contenidos HTML [1]. Constructor de menú de navegación poderoso [1]. 35

37 Tabla 11. Herramienta Web 2.0 ModX (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Compartición de recursos Manejo de grupos Interacción División de tareas Evaluación de contribuciones ModX Rendición de cuentas y responsabilidad individual Discusiones Resolución de conflictos Habilidades para el manejo de grupos pequeños Edición colaborativa Procesamiento de grupo Control de contribuciones de los usuarios Control de cambios ELGG: ELGG puede parecer una red social como cualquier otra red open source, ya que posee una amplia documentación, además del apoyo de una comunidad para resolver dudas [37]. Pero uno de los valores agregados que nos ofrece ELGG es su amplia gama de plugins, diseñados y construidos por los diferentes desarrolladores que pertenecen a la comunidad, que nos permiten adicionar funcionalidades diferentes, además de las diferentes características que nos ofrecen: 36

38 Tiene las siguientes características: Administración de usuarios, objetos, archivos y el sitio en sí [37]. Repositorio de archivos que permite compartirlos entre diferentes archivos [37]. Graficación social que mapea las relaciones entre usuarios, objetos y sitios Web) [37]. Capacidad Multisitio para una misma instalación [37]. Soporte a la internacionalización extensible [37]. Búsqueda en todos los contenidos y usuarios en todo el sistema, basándose en etiquetas [37]. Control de acceso fino [37]. Múltiples vistas, permitiendo interfaces con aplicaciones móviles y widgets embebidos, y navegadores Web [37]. API s para manejo de eventos, extensiones y widgets [37]. Tabla 12. Herramienta Web 2.0 Elgg (Elementos de aprendizaje colaborativo, lo que soporta y lo que le falta) [1]. Herramienta Elementos de Aprendizaje Colaborativo Soporta Falta Interdependencia positiva Soporte de grupos Evaluación de contribuciones Interacción División de tareas Resolución de conflictos Elgg Rendición de cuentas y responsabilidad individual Habilidades para el manejo de grupos pequeños Compartición de recursos Manejo de comunidades colaborativas 37

39 Procesamiento de grupo Edición colaborativa Control de contribuciones de los usuarios Control de cambio Como podemos observar de la tabla 1 a la tabla 12 existe una gran disponibilidad de sitios y herramientas de software que se pueden utilizar para implantar el aprendizaje colaborativo usando tecnología Web 2.0. Podemos concluir que las herramientas que mejor soportan el aprendizaje colaborativo son las denominadas ELGG y PLIGG ya que tienen menos elementos negativos y faltantes en el aprendizaje colaborativo, y ambas herramientas soportan el control de cambios que en la etapa de requisitos de software es de vital importancia [1]. La Web 2.0 ha tenido un impacto social a nivel educativo, ya que a través de los últimos años, el poder de opinión se ha venido valorando cada día más, ya que gracias a la Web 2.0 los usuarios podemos explotar la capacidad de expresarnos a través de las opciones que tenemos en Internet ya sea por redes sociales y en estas globalizar información, puesto que los que aportan ideas, conocimientos y deciden los contenidos no son los creadores sino la comunidad. Un claro ejemplo de ello es la Wikipedia, donde los usuarios construyen, editan y publican artículos y a través de este dan a conocer sus investigaciones o conocimientos frente a un tema específico. Teniendo en cuenta los conceptos de la Web 2.0, herramientas y características de cada una de ellas, procedemos a conceptualizar sobre los requisitos en el software, pero para ello, debemos iniciar por intervenir en el ciclo de vida de desarrollo de software, ya que la elicitación de requisitos es la primera fase de este. 38

40 Existen dos tendencias básicas en el modelo de ciclo de vida de desarrollo de software: el secuencial o modelo en cascada, y el modelo de desarrollo interactivo incremental. La diferencia básica entre estos dos modelos es que en el desarrollo secuencial el desarrollo se realiza por etapas secuenciales y en el interactivo incremental se va desarrollando en pequeños incrementos y en varias interacciones posteriores [2]. Sommerville, establece las etapas para el desarrollo de software secuencial. Estas etapas son la definición de requisitos, diseño del sistema y del software, implementación, pruebas unitarias, integración y pruebas del sistema, operación y mantenimiento [2]. Según Schach, el desarrollo de software iterativo consiste en un conjunto de iteraciones seguidas unas tras otras. Las fases de cada interacción incluyen la especificación, diseño, implementación y pruebas, las cuales pueden llegar a sobreponerse en algunos casos [2]. Por lo anterior podemos decir entonces que el ciclo de vida de un sistema de información es entonces un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista, diseñador, desarrollador y del usuario [2] Ingeniería de Requisitos La ingeniería de requisitos (presente en ambos modelos) 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. Jackson [2] afirma que la ingeniería de requisitos se ubica en el punto de encuentro entre lo informal y lo formal del desarrollo de software. La ingeniería de requisitos cubre todas las actividades relacionadas con la elicitación, especificación y mantenimiento. 39

41 Wiegers [18], define un requisito como una propiedad que un producto debe tener para ofrecer valor a un usuario. Sin embargo, "requisito" no es un término sin ambigüedades, ya que diferentes autores lo definen de manera diferente y hacen hincapié en diferentes puntos de vista en sus definiciones. Por ejemplo, un estándar IEEE [19] define el término como: Condición, capacidad o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Condición o capacidad que debe tener un sistema para satisfacer un contrato, norma, especificación o de otro tipo impuesta por un documento formal. Una representación documentada de una condición o capacidad como en 1 y 2. Davis [20], 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. Por lo tanto se llega a la conclusión que la definición más acertada para este problema es la que plantea Davis; ya que tiene en cuenta la necesidad del usuario un punto importante desde la perspectiva de la Web 2.0. 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 [2]. 40

42 La ingeniería de requisitos es el enfoque disciplinado y sistemático para obtener, especificar, analizar, comprometerse, validar y gestionar los requisitos teniendo en cuenta al usuario, las necesidades técnicas, económicas y de negocios. Se extiende el ciclo de vida, a menudo con equipos distribuidos y cadenas de suministro. Se cuentan con herramientas para facilitar la coherencia y eficiencia en la gestión de requisitos [3]. Las herramientas para ingeniería de requisitos (Ver tabla 13) están evolucionando rápidamente, el desarrollo ágil, la colaboración en todo el mundo y software avanzado están cambiando la forma de gestionar requisitos [3]. 41

43 Tabla 13. Herramientas de Ingeniería de Requisitos [3]. 42

44 En la tabla 13, podemos ver un listado de herramientas más usadas para el soporte en cada una de las etapas del proceso de ingeniería de requisitos y si cuentan con plataformas que usen las herramientas de la Web 2.0, Puntuación: ++: muy alta, +: alta, 0: medio, -:baja, -: muy baja. Tabla 14. Cuadro de Número de herramientas para Ingeniería de requisitos [3]. Número de herramientas para Ingeniería de Requisitos Herramienta Número Elicitación de requisitos 37 Análisis de requisitos 36 Especificación de requisitos 16 Verificación y validación de requisitos 34 Administración de requisitos 17 Otras 17 Total 157 En la tabla 14 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. 43

45 4.3. Redes Sociales En 1995, 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 2002 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. A las redes sociales se les pueden entender como una estructura de nodos que bajo cierto dominio representa a individuos u organizaciones. Sobre esta definición se establece que las mismas son construidas sobre dos pilares fundamentales: la fuerza e impacto de las relaciones entre los miembros y la verdad que los mismos tengan sobre su activa participación [4]. Las redes sociales han venido jugando últimamente un papel fundamental en las actividades diarias de las personas tanto en su vida diaria como organizacional [4]. Las redes sociales han cambiado las maneras de interactuar con la Web buscando que todos los intereses de los usuarios queden satisfechos [4]. Las redes sociales han revolucionado las formas de interacción creando nuevos escenarios de comunicación [4]. En las organizaciones se está empezando a considerar las redes sociales en su infraestructura de gestión del conocimiento para capturar el conocimiento virtual, social e individual [5]. La creación de redes de la comunidad es una parte importante de la gestión del conocimiento, especialmente para el conocimiento virtual. La integración 44

46 de las redes sociales en los sistemas de gestión del conocimiento puede aumentar las interacciones entre los empleados, que a su vez puede aumentar su nivel de confianza y fomentar una colaboración y comunicación más eficaz [5] 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]. Ilustración 1. Diagrama de ambiente colaborativo [6]. 45

47 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]. 46

48 Ilustración 2. Usuarios de redes sociales [7]. En la ilustración 2, podemos observar que la red social denominada Facebook es pionera, con más de 200 millones de usuarios, lo anterior indica que en dicho sitio es donde se encuentran más personas interactuando y compartiendo información entre sí. La Web 2.0 facilita compartir información, interactuar y realizar un trabajo colaborativo, los servicios de red social es uno de los ejemplos de la Web 2.0. Las herramientas Web 2.0 se han convertido en una forma económica y eficaz para crear una ventaja competitiva en las organizaciones, esto con el fin de permitir a los usuarios compartir y mejorar ideas en conjunto [8]. Los ingenieros de software por lo general deben pasar gran parte de su jornada de trabajo intercambiando conocimientos y coordinando el trabajo compartido. Investigadores han venido considerando que las redes sociales tienen el potencial para mejorar la comunicación y coordinación entre los compañeros de trabajo, los diversos medios de comunicación como correo electrónico, mensajería instantánea, web, motores de búsqueda y audio y video, han ayudado a los compañeros de trabajo crear y mantener relaciones con sus colegas [9]. 47

49 La actual generación de la tecnología conocida como Web 2.0 hace fácil para los usuarios compartir información con otras personas en su red social, su utilización aumenta la producción y el consumo de información, ya que obtienen la información más relevante y está disponible con rapidez. La Web 2.0 tiene como filosofía crear comunidad, las redes sociales se han constituido en un fenómeno de gran impacto, existen varias plataformas en las cuales se ha venido incrementando su uso, como por ejemplo Facebook, Twitter, LinkedIn, Tuenti, entre otras [10]. Actualmente cualquier tipo de persona tiene conocimientos del uso de alguna de las herramientas de la Web 2.0 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.0 es una opción a considerar en el trabajo de 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. 48

50 4.5. Metodologías Ágiles para los Requisitos en el Desarrollo de Software 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 [11]. 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 [11]. Tabla 15. Diferencias entre metodologías ágiles y no ágiles [11]. 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 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 49

51 No existe contrato tradicional o al menos es bastante flexible Existe un contrato prefijado El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio Pocos artefactos Pocos roles Menos énfasis en la arquitectura del software Grupos grandes y posiblemente distribuidos Más artefactos Más roles La arquitectura del software es esencial y se expresa mediante modelos En la tabla 15, 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. Las Metodologías Ágiles más utilizadas son: SCRUM SCRUM es el término que describe una forma para desarrollar productos iniciada en Japón. No se trata de un concepto nuevo, sino que ya en 1987 Ikujiro Nonaka y Hirotaka Takeuchi acuñaron este término, una estrategia utilizada en rugby en la que todos los integrantes del equipo actúan juntos para avanzar la pelota y ganar el partido, para denominar un nuevo tipo de proceso de desarrollo de productos. Escogieron este nombre por las similitudes que consideraban que existían entre el juego del rugby y el tipo de proceso que proponían: adaptable, rápido, auto-organizable y con pocos descansos [12]. 50

52 SCRUM es un proceso para la gestión y control del producto que trata de eliminar la complejidad en estas áreas para centrarse en la construcción de software que satisfaga las necesidades del negocio. Es simple y escalable, ya que no establece prácticas de ingeniería del software sino que se aplica o combina, fácilmente, con otras prácticas ingenieriles, metodologías de desarrollo o estándares ya existentes en la organización [12]. SCRUM se concentra, principalmente, a nivel de las personas y el equipo de desarrollo que construye el producto. Su objetivo es que los miembros del equipo trabajen juntos y de forma eficiente obteniendo productos complejos y sofisticados [12]. Ilustración 3. Modelo de desarrollo utilizando SCRUM [12]. 51

53 SCRUM se enfoca en el hecho de que procesos definidos y repetibles sólo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles [13]. SCRUM divide un proyecto en iteraciones (que ellos llaman carreras cortas) de 30 días. Antes de que comience una carrera se define la funcionalidad requerida para esa carrera y entonces se deja al equipo para que la entregue. El punto es estabilizar los requisitos durante la carrera [13]. SCRUM define un proceso empírico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptación de la naturaleza caótica del desarrollo de software, y la utilización de prácticas tendientes a manejar la impredictibilidad y el riesgo a niveles aceptables. SCRUM es un método iterativo e incremental que enfatiza prácticas y valores de project management por sobre las demás disciplinas del desarrollo. Al principio del proyecto se define el Product Backlog, que contiene todos los requisitos funcionales y no funcionales que deberá satisfacer el sistema a construir. Los mismos estarán especificados de acuerdo a las convenciones de la organización ya sea mediante: features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog será definido durante reuniones de planeamiento con los stakeholders. A partir de ahí se definirán las iteraciones, conocidas como Sprint en la juerga de Scrum, en las que se irá evolucionando la aplicación evolutivamente. Cada Sprint tendrá su propio Sprint Backlog que será un subconjunto del Product Backlog con los requisitos a ser construidos en el Sprint correspondiente. La duración recomendada del Sprint es de 1 mes. Dentro de cada Sprint el Scrum Master (equivalente al Líder de Proyecto) llevará a cabo la gestión de la iteración, convocando diariamente al Scrum Daily Meeting que representa una reunión de avance diaria de no más de 15 minutos con el propósito de tener realimentación sobre las tareas de los recursos y los obstáculos que se presentan. Al final de cada Sprint, se realizará un Sprint Review para evaluar los artefactos construidos y comentar el planeamiento del próximo Sprint [14]. 52

54 XP La metodología de XP trabaja estrechamente con el cliente, se hace pequeñas iteraciones cada dos semanas, donde no existe más documentación que el código en sí; cada versión contiene las modificaciones necesarias según como el cliente caya retroalimentándose al sistema, por eso es necesaria la disponibilidad del cliente durante el desarrollo [39]. XP utiliza historias de usuarios la cual no puede demorar en desarrollarse más de una semana. En XP se debe definir un estándar en el tipo de codificación, lo cual le permite a los programadores tener definido un solo estilo al momento de programar. Al igual debe haber un testing en cada iteración con el fin de corregir mientras se programa [39]. La metodología XP pretende que el desarrollo de un proyecto de software sea un desarrollo ágil, disciplinado y aporte soluciones sencillas. XP se fundamenta en los siguientes principios: Acortar los ciclos de desarrollo. Involucrar al cliente desde el principio hasta el final de cada ciclo [39]. ROLES Y RESPONSABILIDADES EN XP Existen diferentes roles y responsabilidades en XP para diferentes tareas y propósitos durante el proceso: Programador: responsable de decisiones técnicas, construir el sistema, diseñar, programar y realizar pruebas. Cliente: determina que construir y cuándo, escribe test funcionales para determinar cuándo está completo un determinado aspecto. 53

55 Entrenador: líder que toma decisiones importantes, principal responsable del proceso. Rastreador: conserva datos históricos. Probador: ayuda al cliente con las pruebas funcionales, asegura de que los test funcionales se ejecuten [39]. CICLO DE VIDA El ciclo de vida de XP según una iteración de desarrollo es el tiempo en el que se realiza un conjunto de funciones determinadas que en XP corresponden a un conjunto de historias de usuarios. Las iteraciones son cortas ya que entre más rápido se le entreguen los desarrollos al cliente mucha más retroalimentación se va a obtener, lo cual significa una mejor calidad del producto a largo plazo [39]. FASES DEL CICLO DE VIDA EN XP Fase de exploración: en esta fase la historia de usuarios es de gran interés para la primera entrega del producto, lo que permite al equipo de desarrollo familiarizarse con las herramientas, tecnológicas y prácticas que se utilizará en el proyecto [39]. Fase de planeamiento: Los programadores consideran el esfuerzo que requiere cada historia y a partir de allí se define el cronograma. Para el primer reléase, la duración del cronograma no excede más de dos meses, se toma en cuenta varias iteraciones para lograr un reléase. La primera iteración crea un sistema con la arquitectura del sistema completo, esto se hará seleccionando las historias que harán cumplir la construcción de la estructura para el sistema completo. Las historias serán seleccionadas por el cliente para cada iteración, al final de la última iteración el sistema estará listo para la producción [39]. Fase de producción: requiere prueba y comprobación extra del funcionamiento del sistema antes de que esta pueda liberar al cliente. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas, las ideas y las 54

56 sugerencias que se pospongan se documentan para una puesta en práctica posterior, por ejemplo en la fase de mantenimiento [39]. Fase de mantenimiento: requiere de un mayor esfuerzo para satisfacer las tareas del cliente. Así la velocidad del desarrollo puede desacelerar después de que el sistema esté en la producción. La fase de mantenimiento puede requerir la incorporación de nueva gente y cambiar la estructura del equipo [39]. Fase de muerte: es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema, se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también puede ocurrir cuando el sistema no genere los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo [39]. XP impone un alto nivel de disciplina entre los programadores. El mismo permite mantener un mínimo nivel de documentación, lo cual a su vez se traduce en una gran velocidad en el desarrollo. Sin embargo, una desventaja que deviene de esta falta de documentación es la incapacidad de persistir la arquitectura y demás cuestiones de análisis, diseño e implementación, aún después de que el proyecto haya concluido [14]. 55

57 Ilustración 4. Descripción de cada fase en la que se subdivide el ciclo de vida XP [14] CRYSTAL CLEAR Alistair Cockburn es el propulsor detrás de la serie de metodologías CRYSTAL. Las mismas presentan un enfoque ágil, con gran énfasis en la comunicación, y con cierta tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por XP. CRYSTAL CLEAR es la encarnación más ágil de la serie y de la que más documentación se dispone. La misma se define con mucho énfasis en la comunicación, y de forma muy liviana en relación a los entregables [Cockburn, 2001b]. CRYSTAL maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra de las cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma part time para realizar validaciones sobre la Interface del Usuario y para participar en la definición de los requisitos funcionales y no funcionales del software. Las personas involucradas escogen aquellos principios que les resultan efectivos y mediante la aplicación de la metodología en diversos proyectos agregan o remueven principios en base al consenso grupal del equipo de desarrollo [14]. 56

58 DSDM- DYNAMIC SYSTEMS DEVELOPMENT METHOD DSDM es la única de las metodologías surgida de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de El objetivo del Consorcio era producir una metodología de dominio público que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid Application Development). Dado el enfoque hacia proyectos de características RAD esta metodología encuadra perfectamente en el movimiento de metodologías ágiles. La estructura del método fue guiada por estos nueve principios [40]: El involucramiento del usuario es imperativo [40]. Los equipos de DSDM deben tener el poder de tomar decisiones [40]. El foco está puesto en la entrega frecuente de productos [40]. La conformidad con los propósitos del negocio es el criterio esencial para la aceptación de los entregables [40]. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solución del negocio [40]. Todos los cambios durante el desarrollo son reversibles [40]. Los requisitos están especificados a un alto nivel [40]. El testing es integrado a través del ciclo de vida [40]. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial [40]. 57

59 Ilustración 5. Fases del proceso de desarrollo DSDM [40]. Las dos primeras fases del ciclo de vida de DSDM son secuenciales: Estudio de viabilidad: calcular los costes, ver si es técnicamente viable y asegurarse de que DSDM sea el enfoque adecuado [40]. Estudio de negocio: Modelado del proceso del negocio y fuerte colaboración cliente-equipo de desarrollo [40]. Iteración funcional del modelo: refinar aspectos funcionales del negocio [40]. Iteración de diseño y construcción: el producto se vuelve apto para los usuarios [40]. 58

60 Las dos fases consisten en ciclos de 4 actividades: identificación, planeación, producción y validación [40] FDD- FEATURE DRIVEN DEVELOPMENT FDD se estructura alrededor de la definición de features que representan la funcionalidad que debe contener el sistema, y tienen un alcance lo suficientemente corto como para ser implementadas en un par de semanas. FDD posee también una jerarquía de features, siendo el eslabón superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en común del negocio. Por último, establece el major feature set como el más alto nivel de agrupación de funcionalidad que abarca diferentes feature sets que contribuyen a proveer valor al cliente en relación a un subdominio dentro del dominio completo de la aplicación. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario común que fomente que los desarrolladores tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo común del negocio [14]. Ilustración 6. Los cinco procesos dentro de FDD [14]. 59

61 La primera actividad consiste en Desarrollar un Modelo Global, que sugiere un cierto paralelismo con la construcción de la arquitectura del software. En la creación de este modelo participan tanto los expertos en el dominio como los desarrolladores. Mediante el esfuerzo de ambas partes se intenta lograr lo que el modelo en espiral proponía con sus primeras iteraciones: un conocimiento global de la aplicación a construir, el entendimiento del negocio en que esta embebida, un primer bosquejo de las features del software, y la definición de restricciones y cuestiones no funcionales. Para esto, se desarrollarán: diagramas de los paquetes, con las clases esenciales y las responsabilidades de las mismas; un documento similar al de Visión en donde se plasmen los objetivos del proyecto y como el mismo ayuda al negocio; un documento con los requisitos no funcionales detectados; por último, el documento que podríamos llamar arquitectura y en el que figuran las opciones de modelado surgidas durante esta actividad [14]. La segunda actividad, Construir una Lista de Features, comienza tomando el bosquejo de features formulado durante la actividad anterior para refinar las funcionalidades incluidas. Una vez que se han identificado las mismas se las agrupa jerárquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorización de las mismas basándose en la satisfacción al cliente las prioridades sugeridas para las features por FDD son: A (debe tener), B (sería útil tener), C (agregar si es posible), o D (futuro); finalmente, se pondera la importancia de cada una para su posterior implementación en caso que existan features que requieran más de dos semanas de desarrollo en esta actividad se particionarán para lograr ubicarlos en iteraciones [14]. La tercera actividad, Planificar por Feature, toma como input la lista priorizada de la fase anterior y establece los tiempos las futuras iteraciones. En esta actividad participan el líder de proyecto, el líder de desarrollo y el programador jefe. A medida que se realiza la planificación se delinean los hitos de finalización de las iteraciones, dejando asentado cuales son los features y features sets que estarán construidos en dichos hitos. Parte de también incluye la delegación de responsabilidades a los programadores jefe 60

62 que serán dueños de los features, estos a su vez asignarán las clases a dueños de clases seleccionados del equipo [14]. Las últimas dos actividades, Diseñar por Feature y Construir por Feature, están relacionadas con la parte productiva del proceso en que se construye la aplicación de manera incremental. Empezando por el diseño que toma los features correspondientes a la iteración, el equipo de programadores liderado por el programador jefe identifica las clases, atributos y métodos que realizan la funcionalidad requerida. Mediante la utilización de diagramas de secuencia de UML, se verifica que el diseño pueda ser implementado. Se realizará también una inspección del diseño en los casos en que la complejidad de la funcionalidad lo requiera. Posteriormente, en la fase de Construir por Feature, se procede a desarrollar las clases definidas en la actividad anterior. Cada programador implementará los métodos de las clases por las que este es responsable, extendiendo las clases base de prueba para construir las pruebas unitarias. Una vez que la clase pasa todas las pruebas, se inspecciona el código. Esta actividad será realizada por el equipo asignado al feature en cuestión, y una vez que finaliza se promueve el código al Build correspondiente, siendo entregado a Administración de la Configuración [14]. En relación a las actividades de management en FDD se recomienda una reunión semanal entre el Líder de proyecto y los programadores jefe; la misma debe ser breve, de no más de 30 minutos, y en la cual se reporta el status de los features que están siendo construidos por cada grupo. Por cada feature set que es implementado se tendrá la información [14]. 61

63 ASD- ADAPTIVE SOFTWARE DEVELOPMENT ASD consiste en un cambio de filosofía en las organizaciones pasando de la transición del modelo Comando-Control al modelo Liderazgo-Colaboración. Basado en los conceptos de los Sistemas Adaptativos Complejos relacionada con la Inteligencia Artificial. Comenzando por un cambio en el modelo de desarrollo determinista, tomado del ciclo de Deming, en que se aplica la secuencia Planificar-Ejecutar-Evaluar. Dicho esquema es llevado a la práctica con el modelo en cascada, en que se realiza una precisa planificación inicial mediante el WBS, el Gantt, y el Pert definiendo las tareas a realizar en detalle, luego se tiene las fases de construcción, y finalmente, se tiene el testing que brinda el feedback en relación al producto construido. El proyecto comienza con una fase de especulación en que en que se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se irán realizando. En esta etapa se fija un rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento que no será el lugar en que finalizará el proyecto. En cada iteración, se aprenderán nuevas funcionalidades, se entenderán viejas cuestiones, y cambiarán los requisitos. Gracias a centrarse en la especulación, ASD permite administrar estos proyectos de alto cambio y rápido desarrollo que se encuentran en el borde del caos. Respecto a la especulación, se recomienda realizar un component breakdown structure en vez del muy conocido y tradicional work breakdown structure (WBS) en el cual mediante una grilla u hoja de cálculo se pueda conocer la funcionalidad a ser liberada en cada ciclo. La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se construye la funcionalidad definida durante la especulación. ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo. Durante cada iteración el equipo colabora intensamente para liberar la funcionalidad planificada [14]. CARACTERISTICAS Iterativo [14]. Orientado a los componentes de software más que a las tareas en las que se va a alcanzar dicho objetivo [14]. 62

64 Tolerante a los cambios [14]. Guiado por los riesgos [14]. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo [14]. Ilustración 7. El ciclo de vida adaptativo ASD [14]. ADS tiene tres componentes que son: especular, colabora y aprender. 63

65 Ilustración 8. Actividades del ciclo de vida adaptativo ASD [14]. Especular Una primera fase de iniciación para establecer los principales objetivos y metas del proyecto en su conjunto y comprender las limitaciones con las que operará el proyecto. En ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir desviaciones. Sin embargo, estas son necesarias para la correcta atención de los trabajadores que se mueven dentro de plazos de forma que puedan priorizar sus tareas. Se decide el número de iteraciones para consumir el proyecto, prestando atención a características que pueden ser utilizadas por el cliente al final de la iteración. Son por tanto necesarios, marcar objetivos prioritarios dentro de las mismas iteraciones. Colaborar Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cíclica. Un trabajo importante es la coordinación que asegure que lo aprendido por un equipo se transmite al resto y no tenga que volver a ser aprendido por los otros equipos. 64

66 Aprender La última etapa termina con una serie de ciclos de colaboración su trabajo consiste en capturar lo que se ha aprendido, tanto positivo como negativo. Es un elemento crítico para la eficacia de los equipos XBREED- SCRUM WRAPPER FOR XP XBreed ofrece una de las primeras fusiones exitosas entre metodologías ágiles. Tomando las fuerzas en el management de Scrum y uniéndolas con las prácticas de XP nace una de las más modernas metodologías alrededor del Mike Beedle es la mente detrás de XBreed y su objetivo es tomar las mejores prácticas del universo ágil y unificar estas en un marco de trabajo que permita el desarrollo concurrente de múltiples proyectos usando metodologías ágiles [14]. Tabla 16. Comparación entre Metodologías agiles [14]. Metodología Acrónimo Creación Tipo de modelo Característica Adaptive Software Development ASD Highsmith 2000 Prácticas + Ciclo de vida Inspirado en sistemas adaptativos complejos Agile Modeling AM Ambler 2002 Metodología basada en la práctica Suministra modelado ágil a otros métodos Crystal Methods CM Cockburn 1998 Familia de metodologías MA con énfasis en modelo de ciclos Agile RUP dx Booch, Martin, Newkirk 1998 Framework / Disciplina XP dado vuelta con artefactos RUP Dynamic Solutions Delivery Model DSDM Stapleton 1997 Framework / Modelo de ciclo de vida Creado por 16 expertos en RAD Evolutionary Project Management Evo Gilb 1976 Framework adaptativo Primer método ágil existente Extreme XP Beck 1999 Disciplina en prácticas Método ágil radical Programming de ingeniería Feature-driven development FDD De Luca & Coad 1998 Palmer & Felsing 2002 Metodología Método ágil de diseño y construcción Lean Development LD Charette 2001, Mary y Tom Poppendieck Forma de pensar Modelo logístico Metodología basada en procesos productivos Microsoft Solutions Framework MSF Microsoft 1994 Lineamientos, Disciplinas, Prácticas Framework de desarrollo de soluciones Rapid Development RAD McConnell 1996 Survey de técnicas y modelos Selección de best practices, no método Rational Unified Process RUP Kruchten 1996 Proceso unificado Método ( ágil?) con modelado Scrum Scrum Sutherland Schwaber 1995 Proceso (framework de management) Complemento de otros métodos, ágiles o no 65

67 4.6. Requisitos en XP Ilustración 9. Requisitos en la metodología XP REQUISITOS EN XP Historias del usuario Establecen los requisitos del cliente Trozos de funcionalidad que aportan valor Se les asigna tareas de programación con un # de horas de desarrollo Las establece el cliente Son la base para las pruebas funcionales Ilustración 10. Gestión de requisitos en XP [21]. Describe Historia de Usuario Cliente Ordenan Educción de Requisitos Se asigna para tener una Interacción concreta Devolución por refinamiento Esta asignada a un -Realiza * * Educción de Requisitos Programador Que se encarga de programarla y validarla 66

68 La Gestión de Requisitos Orientada a Funcionalidades se realiza siguiendo el enfoque de la metodología extreme Programming en la que: El cliente describe una Historia de Usuario [21]. Los programadores intentan estimarla o, en caso de no ser suficientemente concreta, la devuelven al cliente para su refinamiento [21]. Los clientes las ordenan por orden de importancia lo que permite asignarlas a una Iteración concreta [21]. La historia de usuario está asignado a un programador determinado que será el encargado de programarla y validarla [21] Por qué XP es la mejor opción? En esta etapa nos encontramos con 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.0. 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 67

69 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. 68

70 5. SOLUCIÓN DEL PROBLEMA 5.1. Proceso de selección de la herramienta a usar. 1. Etapa 1: Revisión de herramientas comúnmente usadas en la gestión de requisitos en busca del uso de herramientas Web 2.0 (las herramientas a revisar son las mencionadas en la tabla 13) Tabla 17. Uso de la Web 2.0 en herramientas de uso común. 69

71 70

72 71