WEB 2.0 EN LA ELICITACIÓN DE REQUISITOS DE SOFTWARE

WEB 2.0 EN LA ELICITACIÓN DE REQUISITOS DE SOFTWARE

Jennifer Herrera Vega

Código 1080024

Andres Mauricio Rojas Libreros

Código 1080263

Universidad de San buenaventura

Facultad de ingeniería

Programa de ingeniería de sistemas

Seccional Cali

Santiago de Cali

2012

1

WEB 2.0 EN LA ELICITACIÓN DE REQUISITOS DE SOFTWARE

Jennifer Herrera Vega

Código 1080024

Andres Mauricio Rojas Libreros

Código 1080263

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

2012

2

Notas de aceptación:

______________________________

______________________________

______________________________

______________________________

______________________________

______________________________

Firma del jurado

______________________________

Firma del jurado

______________________________

Firma del jurado

3

TABLA DE CONTENIDO

GLOSARIO ................................................................................................ 8

RESUMEN ............................................................................................... 12

INTRODUCCIÓN ........................................................................................ 13

1. PLANTEAMIENTO DEL PROBLEMA ............................................................. 14

2. JUSTIFICACIÓN................................................................................... 15

3. OBJETIVOS DEL PROYECTO .................................................................... 17

4. MARCO CONCEPTUAL ........................................................................... 18

4.1. WEB 2.0 ........................................................................................ 18

4.2. Ingeniería de Requisitos ..................................................................... 39

4.3. Redes Sociales ................................................................................ 44

4.4. Ambiente Colaborativo ...................................................................... 45

4.5. Metodologías Ágiles para los Requisitos en el Desarrollo de Software .............. 49

4.5.1. SCRUM ....................................................................................... 50

4.5.2. XP ............................................................................................ 53

4.5.3. CRYSTAL CLEAR ............................................................................ 56

4.5.4. DSDM- DYNAMIC SYSTEMS DEVELOPMENT METHOD ................................... 57

4.5.5. FDD- FEATURE DRIVEN DEVELOPMENT ................................................. 59

4.5.6. ASD- ADAPTIVE SOFTWARE DEVELOPMENT ............................................ 62

4.5.7. XBREED- SCRUM WRAPPER FOR XP ...................................................... 65

4.6. Requisitos en XP ............................................................................. 66

4.6.1. ¿Por qué XP es la mejor opción? ........................................................ 67

5. SOLUCIÓN DEL PROBLEMA ..................................................................... 69

5.1. Proceso de selección de la herramienta a usar. ........................................ 69

5.2. Herramienta Web 2.0 seleccionada ....................................................... 76

5.3. Prueba de concepto ......................................................................... 77

4

5.4. Funcionalidades de la Herramienta seleccionada. ..................................... 82

6. TRABAJOS FUTUROS ............................................................................ 87

7. CONCLUSIONES .................................................................................. 88

8. ANEXOS ........................................................................................... 89

ANEXO A: Análisis de resultados “Cuestionario a expertos en la industria del software”

........................................................................................................ 89

ANEXO B: Análisis de resultados “Prueba de Campo” ....................................... 93

9. BIBLIOGRAFÍA ................................................................................... 101

5

LISTA DE TABLAS

Tabla 1. Herramienta Web 2.0 MindMeister (Elementos de aprendizaje colaborativo, lo

que soporta y lo que le falta) [1]. ................................................................ 22

Tabla 2. Herramienta Web 2.0 Media Wiki (Elementos de aprendizaje colaborativo, lo


Tabla 3. Herramienta Web 2.0 People Aggregator (Elementos de aprendizaje

colaborativo, lo que soporta y lo que le falta) [1]. ............................................ 25

Tabla 4. Herramienta Web 2.0 Google Docs (Elementos de aprendizaje colaborativo, lo


Tabla 5. Herramienta Web 2.0 Twiki (Elementos de aprendizaje colaborativo, lo que

soporta y lo que le falta) [1]. ...................................................................... 27

Tabla 6. Herramienta Web 2.0 Confluence (Elementos de aprendizaje colaborativo, lo


Tabla 7. Herramienta Web 2.0 Chryrp (Elementos de aprendizaje colaborativo, lo que


Tabla 8. Herramienta Web 2.0 Pligg (Elementos de aprendizaje colaborativo, lo que


Tabla 9. Herramienta Web 2.0 WordPress (Elementos de aprendizaje colaborativo, lo


Tabla 10. Herramienta Web 2.0 Dotclear (Elementos de aprendizaje colaborativo, lo que


Tabla 11. Herramienta Web 2.0 ModX (Elementos de aprendizaje colaborativo, lo que


Tabla 12. Herramienta Web 2.0 Elgg (Elementos de aprendizaje colaborativo, lo que


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

Tabla 14. Cuadro de Número de herramientas para Ingeniería de requisitos [3]. ........ 43

Tabla 15. Diferencias entre metodologías ágiles y no ágiles [11]. .......................... 49

Tabla 16. Comparación entre Metodologías agiles [14]. ...................................... 65

Tabla 17. Uso de la Web 2.0 en herramientas de uso común. ................................ 69

Tabla 18. Comparación de herramientas Web 2.0 .............................................. 72

6

Tabla 19. Indicadores de evaluación en el uso de las herramientas Web 2.0. ............. 78

Tabla 20. Calificación de los criterios a evaluar............................................... 100

7

LISTA DE ILUSTRACIONES

Ilustración 1. Diagrama de ambiente colaborativo [6]. ........................................ 45

Ilustración 2. Usuarios de redes sociales [7]. .................................................... 47

Ilustración 3. Modelo de desarrollo utilizando SCRUM [12]. .................................. 51

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]. ................................... 58

Ilustración 6. Los cinco procesos dentro de FDD [14]. ......................................... 59

Ilustración 7. El ciclo de vida adaptativo ASD [14]. ............................................ 63

Ilustración 8. Actividades del ciclo de vida adaptativo ASD [14]. ........................... 64

Ilustración 9. Requisitos en la metodología XP ................................................. 66

Ilustración 10. Gestión de requisitos en XP [21]. ............................................... 66

Ilustración 11. Pantalla Inicial ..................................................................... 82

Ilustración 12. Adjuntar archivo. .................................................................. 83

Ilustración 13.Notificación de archivo subido. .................................................. 84

Ilustración 14. Comentarios en archivos ......................................................... 84

Ilustración 15. Archivos adjuntos de amigos. .................................................... 85

Ilustración 16. Mensajes y chat. ................................................................... 86

8

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

http://tecnologia.glosario.net/terminos-tecnicos-internet/fsf-732.html

http://tecnologia.glosario.net/terminos-tecnicos-internet/free-software-726.html

http://tecnologia.glosario.net/terminos-tecnicos-internet/free-software-726.html

http://tecnologia.glosario.net/terminos-tecnicos-internet/programa-1366.html



9

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

http://es.wikipedia.org/wiki/Casos_de_uso

http://www.ecured.cu/index.php/Software

http://es.wikipedia.org/wiki/Retorno_de_la_inversi%C3%B3n

http://es.wikipedia.org/w/index.php?title=Grosso_modo&action=edit&redlink=1

10

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 auto-

organizan), 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].

11

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

12

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.

13

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.

14

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.

15

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.

16

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.

17

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 2.0.

2. 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.

18

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

19

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 de herramientas Web 2.0 para

Aprendizaje Colaborativo:

Blogging

Bookmarks

Community

Collaborative

20

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.

21

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

22

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

MindMeister

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.

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


Buena interfaz gráfica [1].

Extensiones multimedia [1].

23

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



Aprendizaje

Colaborativo

Soporta Falta

Media Wiki

Interdependencia

positiva.

Soporte de grupos. Toma de decisiones.

Interacción. Discusión grupal e

interacción.

Votación y

evaluación de

contribuciones.

Rendición de

cuentas y

responsabilidad

individual.

División de tareas. Resolución de

conflictos.

Habilidad para el

manejo de grupos

pequeños.

Compartición de

recursos.

Evaluación de

contribuciones.

Procesamiento de

grupo.


de textos.

24

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


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

25

Tabla 3. Herramienta Web 2.0 People Aggregator (Elementos de aprendizaje colaborativo, lo que



Aprendizaje

Colaborativo

Soporta Falta

People Aggregator

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


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


Crear documentos básicos [1].

26

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



Aprendizaje

Colaborativo

Soporta Falta

Google Docs

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

Habilidades para el

manejo de grupos

pequeños


Procesamiento de

grupo

Control de

contribuciones de

los usuarios

Control de cambios

27

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


Aprendizaje

Colaborativo

Soporta Falta

Interdependencia

positiva

Soporte de grupos Evaluación de

contribuciones

Interacción Discusión grupal e Resolución de

28

Twiki

interacción conflictos

Rendición de

cuentas y

responsabilidad

individual

Manejo de grupos

Habilidades para

manejo de grupos

pequeños

División de tareas

Procesamiento de

grupo

Compartición de

recursos


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


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

29

Tabla 6. Herramienta Web 2.0 Confluence (Elementos de aprendizaje colaborativo, lo que



Aprendizaje

Colaborativo

Soporta Falta

Confluence

Interdependencia

positiva


contribuciones

Interacción Manejo de grupos Resolución de

conflictos

Rendición de

cuentas y

responsabilidad

individual

Interacción y

discusión grupal

Habilidades para el

manejo de grupos

pequeños

Compartición de

recursos

Procesamiento de

grupo


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

30

Tabla 7. Herramienta Web 2.0 Chryrp (Elementos de aprendizaje colaborativo, lo que soporta y

lo que le falta) [1].


Aprendizaje

Colaborativo

Soporta Falta

Chyrp

Interdependencia

positiva


contribuciones

Interacción Compartición de

recursos

División de tareas

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


Soporta múltiples autores y usuarios [1].

Evaluación de artículos [1].

Mensajes privados [1].

Sistema avanzado de comentarios [1].

31

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


Aprendizaje

Colaborativo

Soporta Falta

Pligg

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

Procesamiento de

grupo

32

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


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

33

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



Aprendizaje

Colaborativo

Soporta Falta

WordPress

Interdependencia

positiva

Compartición de

recursos

Manejo de grupos

Interacción División de tareas Evaluación de

contribuciones

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


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

34


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



Aprendizaje

Colaborativo

Soporta Falta

Dotclear

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

Habilidades para el

manejo de grupos

pequeños


Procesamiento de Control de

contribuciones de

35

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


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

36

Tabla 11. Herramienta Web 2.0 ModX (Elementos de aprendizaje colaborativo, lo que soporta y

lo que le falta) [1].


Aprendizaje

Colaborativo

Soporta Falta

ModX

Interdependencia

positiva

Compartición de

recursos

Manejo de grupos

Interacción División de tareas Evaluación de

contribuciones

Rendición de

cuentas y

responsabilidad

individual

Discusiones Resolución de

conflictos

Habilidades para el

manejo de grupos

pequeños


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:

37


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


Aprendizaje

Colaborativo

Soporta Falta

Elgg

Interdependencia

positiva


contribuciones

Interacción División de tareas Resolución de

conflictos

Rendición de

cuentas y

responsabilidad

individual

Compartición de

recursos

Habilidades para el

manejo de grupos

pequeños

Manejo de

comunidades

colaborativas

38

Procesamiento de

grupo


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.

39

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

4.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.

http://www.monografias.com/trabajos16/proyecto-inversion/proyecto-inversion.shtml#CICLO

http://www.monografias.com/trabajos13/diseprod/diseprod.shtml

http://www.monografias.com/trabajos11/norma/norma.shtml

http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE

40

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

41

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

42

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

43

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.

44

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

45

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

4.4. 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].

46

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

47

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

48

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.

49

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 Metodologías Tradicionales

Basadas en heurísticas provenientes de

prácticas de producción de código

Basadas en normas provenientes de

estándares seguidos por el entorno de

desarrollo

Especialmente preparados para cambios

durante el proyecto

Cierta resistencia a los cambios

Impuestas internamente (por el equipo) Impuestas externamente

Proceso menos controlado, con pocos

principios

Proceso mucho más controlado, con

numerosas políticas/normas

50

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

Grupos grandes y posiblemente

distribuidos

Pocos artefactos Más artefactos

Pocos roles Más roles

Menos énfasis en la arquitectura del

software

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:

4.5.1. 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].

51

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

52

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

53

4.5.2. 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.

54

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

55

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

56

Ilustración 4. Descripción de cada fase en la que se subdivide el ciclo de vida XP [14].

4.5.3. 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].

57

4.5.4. 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 1994. 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].

58

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

59

Las dos fases consisten en ciclos de 4 actividades: identificación, planeación,

producción y validación [40].

4.5.5. 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].

60

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

61

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

62

4.5.6. 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].

63

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.

64

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.

65

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.

4.5.7. 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 2000. 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 SoftwareDevelopment

ASD Highsmith 2000 Prácticas + Ciclo devida

Inspirado en sistemasadaptativos complejos

Agile Modeling AM Ambler 2002 “Metodología basada enla práctica”

Suministra modelado ágila otros métodos

Crystal Methods CM Cockburn 1998 “Familia demetodologías”

MA con énfasis enmodelo de ciclos

Agile RUP dX Booch, Martin, Newkirk1998

Framework / Disciplina XP dado vuelta conartefactos RUP

Dynamic SolutionsDelivery Model

DSDM Stapleton 1997 Framework / Modelo deciclo de vida

Creado por 16 expertosen RAD

Evolutionary ProjectManagement

Evo Gilb 1976 Framework adaptativo Primer método ágilexistente

ExtremeProgramming

XP Beck 1999 “Disciplina en prácticasde ingeniería”

Método ágil radical

Feature-drivendevelopment

FDD De Luca & Coad 1998Palmer & Felsing 2002

“Metodología” Método ágil de diseño yconstrucción

Lean Development LD Charette 2001, Mary yTom Poppendieck

“Forma de pensar” –Modelo logístico

Metodología basada enprocesos productivos

Microsoft SolutionsFramework

MSF Microsoft 1994 Lineamientos,Disciplinas, Prácticas

Framework de desarrollode soluciones

Rapid Development RAD McConnell 1996 Survey de técnicas y

modelos

Selección de best

practices, no método

Rational UnifiedProcess

RUP Kruchten 1996 Proceso unificado Método (¿ágil?) conmodelado

Scrum Scrum Sutherland 1994 -Schwaber 1995

“Proceso” (frameworkde management)

Complemento de otrosmétodos, ágiles o no

66

4.6. Requisitos en XP

Ilustración 9. Requisitos en la metodología XP

Ilustración 10. Gestión de requisitos en XP [21].

Cliente

Programador

Historia de UsuarioDescribe

Educción deRequisitos

-Realiza

* *

Devolución por refinamiento

OrdenanEducción deRequisitos

Se asigna para tener una

Interacciónconcreta

Esta asignada a un

Que se encarga de programarla y

validarla

REQUISITOS EN XP

Historias del usuario

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

Establecen los

requisitos del

cliente

67

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

4.6.1. ¿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

68

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.

69

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.

72

Al finalizar la etapa se determina que existen muchas herramientas que

tienen interfaz web pero ninguna de estas aplica conceptos de la Web 2.0,

existe una en la que se ven relacionados los conceptos de la Web 2.0 el único

problema es el costo de implementación e instalación que tiene esta

herramienta el cual es superior a los $1000 dólares.

2. Etapa 2: Revisión de herramientas Web 2.0 con el fin de encontrar una

herramienta que supla el proceso de elicitación.

Tabla 18. Comparación de herramientas Web 2.0

HERRAMIENTA SOFTWARE

LIBRE

SOFTWARE

GRATUITO

PLUGINS

FAVORABLES

DOCUMENTACIÓN APORTE A LA

ETAPA DE

ELICITACIÓN DE

REQUISITOS

MindMeiser NO NO N/A MUY BUENA

Permite realizar

mapas mentales

para claridad de

ideas en los

clientes.

Media Wiki SI SI N/A BUENA

Repositorio de la

documentación del

desarrollo de

software.

People

Aggregator NO SI MUY POCOS MALA

Red Social, el

aporte es bajo

considerando los

pocos plugins y

que se encuentra

en una versión

beta.

Google Docs NO SI N/A BUENA

Facilidad en la

redacción de

documentos casi

en tiempo real y

73

de manera

colaborativa

Twiki SI SI N/A MUY BUENA

Repositorio de la

documentación,

mensajes y

versionamiento.

Confluence NO NO POCOS BUENA

Permite distribuir

roles en los

equipos de trabajo

y llevar un

repositorio de la

documentación,

repositorio de

archivos.

Chryp SI SI N/A MEDIO

Permite la

publicación de

contenidos estilo

blog.

Pligg PARCIAL PARCIAL NO MEDIO

Permite la

publicación de

contenido, dejar

comentarios,

evaluar

contribuciones.

WordPress NO PARCIAL N/A BUENA

Permite la

publicación de

contenido tipo

blog.

DotClear SI SI N/A BUENA

Permite la

publicación de

contenido tipo

blog, repositorio

de archivos.

ModX NO SI NO BUENA

Permite la

publicación de

contenido tipo

blog, edición de

contenido de

74

manera

colaborativa,

comentarios,

repositorio de

archivos.

ELGG SI SI MUCHOS MUY BUENA

Suple con la

publicación de

contenido, control

de cambios, chat,

comentarios,

repositorio de

archivos,

integración con

otras redes

sociales, evaluar

contribuciones.

KUNE NO SI NO MUY BUENA

Suple con la

publicación de

contenido, control

de cambios, chat,

comentarios,

repositorio de

archivos,

integración con

otras redes

sociales, evaluar

contribuciones.

Yogurt SI SI NO MEDIO

Suple con la

publicación de

contenido, control

de cambios,

comentarios,

repositorio de

archivos.

Scuttle SI SI NO MALA

Permite la

publicación de

contenido, la

intervención de

usuarios,

75

comentarios.

OzCode SI SI NO MEDIO

Se encuentra en

versión alpha,

permite la

publicación de

contenido,

comentarios.

76

5.2. Herramienta Web 2.0 seleccionada

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.0 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.

En la herramienta escogida ELGG, tiene varios pluggins los cuales nos pueden servir a la

hora de realizar la etapa de la gestión de requisitos:

SW Archivos Filter Pro: Un plugin que permite cierto tipo de archivos a subir con el

plugin de archivo en elgg

Los mensajes de transferencia de archivos: Permite a los usuarios enviar archivos desde

el plugin de archivo como archivos adjuntos a los mensajes internos

Chat: Chatear funcionalidad sitio para elgg 1.8 con el script php chat gratis.

Charlar: Chat-como plug-in para discutir con uno o múltiples usuarios.

Elgg 1.8: lastlogin: Visualización de tiempo del último acceso, fecha y unirse GUID del

usuario en las páginas de perfil.

GDocs vista previa de archivos: Este plugin permite a los usuarios vista previa de los

archivos de MS Office (doc, docx, xls, xlsx, ppt, pptx), las páginas de Apple iWork, EPS

de Adobe y archivos zip utilizando el Visor de Google Docs archivos.

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dplugins%2Belgg%26hl%3Des%26biw%3D1280%26bih%3D699%26prmd%3Dimvns&rurl=translate.google.com.co&sl=en&u=http://community.elgg.org/plugins/1095821/riaseri/sw-files-filter-pro&usg=ALkJrhiT0pdjtI-gB-nFwdAuvjYpEf7LFQ

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dplugins%2Belgg%26hl%3Des%26biw%3D1280%26bih%3D699%26prmd%3Dimvns&rurl=translate.google.com.co&sl=en&u=http://community.elgg.org/plugins/1092561/1/messages-file-transfer&usg=ALkJrhg8ewljiZGd6lS5G3H6H0H24w42lA

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dplugins%2Belgg%26hl%3Des%26biw%3D1280%26bih%3D699%26prmd%3Dimvns&rurl=translate.google.com.co&sl=en&u=http://community.elgg.org/plugins/883207/1.8.5.1/chat-room&usg=ALkJrhi-Z8xep4H18FZnG0DKUJkn-Lld2w

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dplugins%2Belgg%26hl%3Des%26biw%3D1280%26bih%3D699%26prmd%3Dimvns&rurl=translate.google.com.co&sl=en&u=http://community.elgg.org/plugins/879242/1.8/chat&usg=ALkJrhgF-zx6nL5pxs4j32BPSgKXIfWCYQ

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dplugins%2Belgg%26hl%3Des%26biw%3D1280%26bih%3D699%26prmd%3Dimvns&rurl=translate.google.com.co&sl=en&u=http://community.elgg.org/plugins/874298/1.8.2/elgg-18-lastlogin&usg=ALkJrhjZj62MJzjlDHYYq3UMP3RtrNcs4g

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dplugins%2Belgg%26hl%3Des%26biw%3D1280%26bih%3D699%26prmd%3Dimvns&rurl=translate.google.com.co&sl=en&u=http://community.elgg.org/plugins/874265/1.02/gdocs-file-previewer&usg=ALkJrhjZcFtPhEFM0Oq-jF2f0pcpJWcR4Q

77

5.3. Prueba de concepto

Se dará conocer la herramienta y lo que es posible hacer con esta, mostrándole la forma

en que pueden subir archivos, como dejar comentarios, como realizar chats con otras

personas, mostrando que se comporta como una red social, se le explicará el motivo de

la prueba en donde se determinara que la idea es lograr un acercamiento mayor con el

stakeholder logrando crear un ambiente colaborativo entre las partes interesadas.

La idea principal será realizar una iteración de un desarrollo de software usando la

herramienta, en donde se propondrá a los desarrolladores que suban un avance en lo

posible diario, para que el usuario final esté al tanto de todos los cambios realizados en

el producto que desea adquirir, dando una aprobación a lo que suben o simplemente

dejando ideas o comentarios con lo que se plantea. El usuario final podrá estar

disponible para resolver dudas puntuales dejando un simple comentario en el muro o

realizando un chat, lo cual evitara una reunión formal con el cliente el cual trae como

consecuencia tiempo que posiblemente las partes implicadas no tienen.

Se parte del hecho que el uso de una red social se hará en cualquier momento y no

necesariamente en horarios laborales, lo cual disminuirá la presión en dar una respuesta

en una hora en específico y lograra que se plasmen ideas que constantemente tendrán

una aprobación o que surjan en un momento fuera del horario laboral establecido, se

tiene en cuenta que la herramienta se convierte en una especie de acta en el cual el

cliente podrá aprobar y desaprobar ideas y se usará como constancia a la hora de hacer

la validación de los requisitos finalmente entregados.

Al final de realizar el proceso de elicitación de requisitos en la iteración se recogerá la

información resultante en el cual se tendrá en cuenta el refinamiento de los requisitos

resultantes, si suplen la necesidad del cliente en dicha etapa, la participación que

tuvieron las partes implicadas (stakeholders y desarrolladores) y el esfuerzo final hecho

de las partes implicadas. Esto con el fin de determinar la viabilidad del uso de las

herramientas web2.0 en esta etapa del desarrollo de software, si estas herramientas ya

se encuentran lo suficientemente diseñadas para implementarlas en este proceso tan

determinante en un proyecto de desarrollo.

78

Se tendrán en cuenta las siguientes escalas de calificación para determinar la viabilidad

del uso de la tecnología:

Tabla 19. Indicadores de evaluación en el uso de las herramientas Web 2.0.

Indicador Concepto Parámetros Valoración

Refinamiento de

los requisitos.

Forma usada

para la

extracción del

requisito.

Uso de herramientas Web 2.0

en toda el proceso de

extracción.

Uso parcial de herramientas

Web2.0 en el proceso de

extracción

No uso de herramientas Web

2.0 en el proceso de

extracción.

5

3

1

Facilidad para

identificar el

origen del

requisito.

Trazabilidad en las

herramientas Web 2.0 en el

momento de definir el

requisito

Trazabilidad parcial en las

herramientas Web 2.0 en el

momento de definir el

requisito

Trazabilidad en otras

herramientas o ninguna

trazabilidad.

5

3

1

Claridad del

requisito

Claridad de los requisitos se

tiene en cuenta que pueda ser

entendido por cualquier

persona no experta, sin causar

ambigüedad, con uso de


Claridad de los requisitos con

las mismas condiciones con un

uso parcial de las herramientas

5

3

1

79

Web 2.0.

Claridad de los requisitos bajo

las mismas condiciones sin

realizar uso de las


Satisfacción de

la necesidad del

cliente.

Cumple con la

necesidad.

La totalidad de los requisitos

en la etapa del desarrollo

cumplen con lo acordado en

dicha etapa, el proceso de

validación se realiza en






validación se realiza

parcialmente en herramientas

Web 2.0.





validación no hace uso de las


5

3

1

Participación de

las partes

implicadas en

las herramientas

Web 2.0

Desarrolladores Participación activa en todo el

proceso de elicitación de

requisitos.

Participación activa en la

mayoría del proceso de

elicitación de requisitos.

Participación activa en una

pequeña parte del proceso de


Participación pasiva en el


requisitos

5

4

3

2

1

80

Participación nula en el


requisitos.

Stakeholders Participación activa en todo el


requisitos.

Participación activa en la

mayoría del proceso de


Participación activa en una

pequeña parte del proceso de


Participación pasiva en el


requisitos

Participación nula en el


requisitos.

5

4

3

2

1

Esfuerzo de las

partes

implicadas en

las herramientas

Web 2.0.

Desarrolladores Menor esfuerzo al definir de

manera clara un requisito de

desarrollo de software.

Igual esfuerzo al definir de



Mayor esfuerzo al definir de



5

3

1

Stakeholder Menor esfuerzo en entender y

realizar la aprobación del

requisito definido.

Igual esfuerzo en entender y


requisito definido.

Mayor esfuerzo en entender y


5

3

1

81

requisito definido.

Si desea conocer los resultados de la prueba de campo y su respectivo análisis, observar

el “ANEXO B: Análisis de resultados “Prueba de Campo””

82

5.4. Funcionalidades de la Herramienta seleccionada.

La herramienta seleccionada cuenta con diferentes funcionalidades que apoyan la etapa

de elicitación de requisitos; comenzando por la pantalla inicial (ver Ilustración 11)

donde el usuario ingresa a la herramienta, puede observar las actividades realizadas

últimamente para darse cuenta de lo que ha sucedido.

Ilustración 11. Pantalla Inicial

En el momento que el usuario a ingresado puede realizar varias acciones entre las cuales

puede ser el subir un archivo (ver Ilustración 12) en el cual le pedirá un titulo, una

descripción, tags de búsqueda y el acceso al archivo que puede ser público, privado o

amigos.

83

Ilustración 12. Adjuntar archivo.

Los usuarios implicados en el proyecto recibirán una notificación (ver Ilustración 13)

donde se les notifica que un archivo fue subido, para que tengan presente de revisarlo y

comentar en el (ver Ilustración 14).

84

Ilustración 13.Notificación de archivo subido.

Ilustración 14. Comentarios en archivos

85

Los usuarios podrán visualizar los archivos subidos por sus amigos y en que momento fue

subido para una rápida gestión de ellos (ver Ilustración 15).

Ilustración 15. Archivos adjuntos de amigos.

Adicionalmente los usuarios podrán enviar mensajes (ver Ilustración 16) entre ellos con

el animo de intercambiar información, preguntar acerca del proceso y preguntar o

resolver dudas; para estos mismos intereses pueden hacer uso del chat (ver Ilustración

16).

86

Ilustración 16. Mensajes y chat.

87

6. TRABAJOS FUTUROS

Uno de los objetivos del proyecto era lograr un acercamiento de las herramientas Web

2.0 en la etapa de elicitación de requisitos de un proceso de desarrollo de software, más

adelante se espera:

1. Realizar una prueba de concepto en la totalidad del desarrollo de un producto de

software en una empresa real y verificar al final el esfuerzo invertido y la calidad

de los requisitos obtenidos.

2. Establecer un estudio en una empresa de desarrollo de software con el fin de

validar si la calidad de los requisitos han mejorado en el transcurso de varios

proyectos después de haber implementado el concepto de Web 2.0 en su proceso

de elicitación de requisitos.

3. Realizar una metodología de la implementación de los conceptos de la Web 2.0

en el proceso de elicitación de requisitos de software.

4. Aplicar los conceptos de las herramientas de la Web 2.0 en las demás etapas del


5. Realizar una herramienta que permita gestionar todo el proceso de desarrollo

aplicando los conceptos de la Web 2.0 y que además sea lo suficientemente

completa e integrada como las herramientas con las que se cuenta actualmente.

88

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

La Web 2.0 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.0 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.

El uso de la Web 2.0 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.

89

8. ANEXOS

ANEXO A: Análisis de resultados “Cuestionario a expertos en la industria del software”

Con el fin de cumplir los objetivos planteados al inicio de esta tesis, se realiza un

cuestionario a dieciséis personas expertas de la industria del software, después de

realizar una presentación sobre la temática tratada.

A continuación se presenta un análisis de cada una de las preguntas realizadas y las

respuestas dadas por los expertos encuestados:

I. Consideras útil el uso de herramientas Web 2.0 ?

El objetivo de esta pregunta era conocer el concepto que se tiene acerca de la

Web 2.0, 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.

SI; 15

NO; 1

0

5

10

15

SI NO

Expertos

Observaciones:

Pero la pregunta debería orientarse a actividades específicas.

Siempre y cuando se evidencien las ventajas de estas tecnologías sobre los

métodos tradicionales.

Útiles a nivel colaborativo y de posibilidades de interacción y

enriquecimiento de contenidos que aumentan el interés y la usabilidad.

90

II. 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.

SI; 14

NO; 2

0

5

10

15

SI NO

Expertos

Observaciones:

Depende de las actividades y el propósito y el alcance proceso elicitación

No se debe perder de vista la interacción con el usuario

El incluir la Web 2.0 como trabajo colaborativo podría ser interesante para

disminuir la brecha entre el stakeholder y el ing. Requisitos

Sería ideal si la herramienta proporcionara un valor agregado como por

ejemplo un cronograma en línea con el estado en proceso

La retroalimentación es muy importante no solo en la elicitacion si no

durante todo el proceso de desarrollo y estas herramientas lo facilitarían

Viable en cuanto a oportunidad en la expresión de sugerencias, ajustes de

documentación, apoyo a entrevistas grupales que suplan el problema de

disponibilidad de los stakeholders

91

De verdad no tengo claro la efectividad además colocas una barrera entre

cliente y analista

III. 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 que se hicieron sugerencias para

ser implementadas posteriormente.

SI; 12

NO; 4

0

5

10

15

SI NO

Expertos

Observaciones:

No la conozco, pero lo presentado me parece interesante

Sin embargo se debe explicar la forma en que esta herramienta aporta al

proceso

No sabría responder dado que solo se expusieron las funcionalidades básicas,

habría que mirar como aporta al tema de versionamiento de documentos,

puede ser de interés

Puede ser importante siempre y cuando se le dé un manejo a nivel workflow

No se ve muchas ventajas que ofrezca con respecto a la elicitación

tradicional

Pero creando cultura y procesos de optimización

92

IV. Actualmente, Crees que todo el proceso de desarrollo de software debe

comenzar a adaptarse al uso de las herramientas Web 2.0 ?

El propósito de la pregunta era validar que las herramientas Web 2.0 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.

SI; 10

NO; 6

0

2

4

6

8

10

SI NO

Expertos

Observaciones:

No solo para elicitación puede considerar para otros aspectos

Sin duda serian de gran ayuda pero vale la pena pensar en un herramienta

que muestre funciones que aporten más al proceso

Pues de acuerdo al concepto expuesto considero que si aplica ya que la

colaboración es vital en dicho proceso

De hecho hay varias herramientas comerciales explorando ese campo, la idea

es detectar debilidades en estas y buscar complementos

Depende

El uso o mejor el desarrollo debe adaptarse a la necesidad no a una

tecnología.

93

ANEXO B: Análisis de resultados “Prueba de Campo”

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:

Encuesta a los desarrolladores:

I. 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)

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.

MENOR; 3

IGUAL; 0 MAYOR; 00

0,5

1

1,5

2

2,5

3

MENOR IGUAL MAYOR

Desarrolladores

94

II. Como fue la participación y la comunicación con el stakeholder?

Al realizar esta pregunta a ambos grupos de desarrolladores ( los que usaron la

Web 2.0 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.

Activa; 3Activa; 4

Pasiva; 0

Pasiva; 10

Nula; 0 Nula; 0

0

2

4

6

8

10

Activa Pasiva Nula

Uso de la web 2.0 Metodo Tradicional

95

III. 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.0, 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.

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.

Total; 2Total; 2Parcial; 1

Parcial; 12

Nula; 0 Nula; 0

0

2

4

6

8

10

12

Total Parcial Nula


96

IV. 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.0 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.

Total; 0Total; 1

Parcial; 3

Parcial; 13

Nula; 0 Nula; 0

0

2

4

6

8

10

12

14

Total Parcial Nula


97

Encuesta a los Stakeholder:

I. 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.0, 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.0 no

mejora de ninguna forma la participación de los desarrolladores.

Activa; 3

Activa; 9

Pasiva; 0

Pasiva; 5

Nula; 0 Nula; 0

0

2

4

6

8

10

Activa Pasiva Nula


98

II. 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?

Con respecto al esfuerzo invertido por parte del stakholder en la etapa de elicitación de

requisitos realizando uso de la herramienta Web 2.0 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.

MENOR; 0 IGUAL; 0

MAYOR; 1

0

0,2

0,4

0,6

0,8

1

MENOR IGUAL MAYOR

Stakeholder

99

III. 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.0 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.

Total; 1

Parcial; 0 Nula; 0

0

0,2

0,4

0,6

0,8

1

Total Parcial Nula

Stakeholder

Como conclusión se logra determinar que el uso de las herramientas Web 2.0 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.

100

Calificación de los criterios a evaluar.

Tabla 20. Calificación de los criterios a evaluar

Indicador Concepto Valoración

Refinamiento de

los requisitos.

Forma usada para la extracción del requisito. 3

Facilidad para identificar el origen del requisito. 5

Claridad del requisito 5

Satisfacción de

la necesidad del

cliente.

Cumple con la necesidad. 5

Participación de

las partes

implicadas en

las herramientas

Web 2.0

Desarrolladores 4

Stakeholders 3

Esfuerzo de las

partes

implicadas en

las herramientas

Web 2.0.

Desarrolladores 5

Stakeholder 3

Con respecto a los criterios a evaluar se determina que el uso de la Web 2.0 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.

101

9. BIBLIOGRAFÍA

[1] Fahad, J., & Abdul, M. (2009). Herramientas Web 2 . 0 para el Aprendizaje

Colaborativo. Reading.

[2] Propuesta_Proyecto_Investigacion. (n.d.).

[3] Gea, J. M. C. D., Nicolás, J., Alemán, J. L. F., Toval, A., Ebert, C., & Vizcaíno, A.

(n.d.). Requirements Engineering Tools. Scenario, 86-91.

[4] Bindplanning-Proyectos Personales. (n.d.).

[5] Anderson, S., Mohan, K., & College, B. (2011). in Knowledge Management. Field

Studies, (August), 24-28.

[6] Franky, M. C. (2011). colaborativos Temática.

[7] Black, S., Harrison, R., & Baldwin, M. (2010). A Survey of Social Media Use in

Software Systems Development. Analysis, 1-5.

[8] Bajic, D., & Lyons, K. (2011). Leveraging social media to gather user feedback for

software development. Proceeding of the 2nd international workshop on Web 2.0 for

software engineering - Web2SE ’11, 1-6. New York, New York, USA: ACM Press.

doi:10.1145/1984701.1984702.

[9] Begel, A., Deline, R., & Zimmermann, T. (n.d.). Social Media for Software

Engineering. Challenges, 33-37.

[10]

http://detodounpoco.weblog.discapnet.es/Asp/articulo.aspx?urlblog=detodounpoco&idA

=2144&AspxAutoDetectCookieSupport=1

[11] 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.

[12] De, A. (2008). Estudio de la aplicación de metodologías ágiles para la evolución de

productos software.

[13] Metodologias Agiles. (n.d.).

[14] Hernán, S. M. (2004). Diseño de una Metodología Ágil de Desarrollo de Software .

[15] http://vitodibari.com/es/las-diez-caracteristicas-de-la-web-2-0-internet-ha-cambiado-y-

tu.html

[16] http://es.wikipedia.org/wiki/Blog

http://detodounpoco.weblog.discapnet.es/Asp/articulo.aspx?urlblog=detodounpoco&idA=2144&AspxAutoDetectCookieSupport=1

http://detodounpoco.weblog.discapnet.es/Asp/articulo.aspx?urlblog=detodounpoco&idA=2144&AspxAutoDetectCookieSupport=1

http://vitodibari.com/es/las-diez-caracteristicas-de-la-web-2-0-internet-ha-cambiado-y-tu.html

http://vitodibari.com/es/las-diez-caracteristicas-de-la-web-2-0-internet-ha-cambiado-y-tu.html

http://es.wikipedia.org/wiki/Blog

102

[17] http://www.alegsa.com.ar/Dic/bookmark.php

[18] Wiegers, K. (2003) Software Requirements, second edition. Redmond, WA: Microsoft

Press.

[19] IEEE Std 610.12.-1990 IEEE Standard Glossary of Software Engineering Terminology.

[20] Davis, A. M. (1993) Software Requirements: Objects, Functions, and States.

UpperSaddle River, NJ:Prentice Hall.

[21] Programming, X. (n.d.). Herramienta que implementa eXtreme Programming para la gestión de requisitos.

[22] http://es.wikipedia.org/wiki/Redes_sociales_de_internet

[23] http://www.desarrollodeweb.com.ar/blog/tecnologia-software-aplicaciones-y-

servicios-web/331

[24] http://tecnologia.glosario.net/terminos-tecnicos-internet/gpl-781.html

[25] http://es.slideshare.net/Kamisutra/modelo-en-cascada-7381831

[26] http://es.wikipedia.org/wiki/Especificaci%C3%B3n_de_requisitos_de_software

[27] http://www.ecured.cu/index.php/Requisitos_de_Software

[28] http://es.wikipedia.org/wiki/Scrum

[29] http://es.wikipedia.org/wiki/Release_Management

[30] http://en.wikipedia.org/wiki/MindMeister

[31] http://www.socialnetworking-weblog.com/50226711/peopleaggregator.php

[32] http://support.google.com/docs/bin/answer.py?hl=es&answer=49008

[33] http://es.wikipedia.org/wiki/TWiki

[34] http://en.wikipedia.org/wiki/Confluence_(software)

[35] http://pligg.com

[36] http://es.wordpress.org/

[37] http://es.scribd.com/doc/33517331/Herramientas-para-el-trabajo-colaborativo [38] http://es.wikipedia.org/wiki/Web_2.0 [39]http://www.slideshare.net/johitaamiga/modelo-xp-para-desarrollo-de-proyecto

http://www.alegsa.com.ar/Dic/bookmark.php

http://es.wikipedia.org/wiki/Redes_sociales_de_internet

http://www.desarrollodeweb.com.ar/blog/tecnologia-software-aplicaciones-y-servicios-web/331

http://www.desarrollodeweb.com.ar/blog/tecnologia-software-aplicaciones-y-servicios-web/331

http://tecnologia.glosario.net/terminos-tecnicos-internet/gpl-781.html

http://es.slideshare.net/Kamisutra/modelo-en-cascada-7381831

http://es.wikipedia.org/wiki/Especificaci%C3%B3n_de_requisitos_de_software

http://www.ecured.cu/index.php/Requisitos_de_Software

http://es.wikipedia.org/wiki/Scrum

http://es.wikipedia.org/wiki/Release_Management

http://en.wikipedia.org/wiki/MindMeister

http://www.socialnetworking-weblog.com/50226711/peopleaggregator.php

http://support.google.com/docs/bin/answer.py?hl=es&answer=49008

http://es.wikipedia.org/wiki/TWiki

http://en.wikipedia.org/wiki/Confluence_(software)

http://pligg.com/

http://es.wordpress.org/

http://es.scribd.com/doc/33517331/Herramientas-para-el-trabajo-colaborativo

http://es.wikipedia.org/wiki/Web_2.0

http://www.slideshare.net/johitaamiga/modelo-xp-para-desarrollo-de-proyecto

103

[40] users.dsic.upv.es/asignaturas/facultad/lsi/trabajos/292002.ppt

WEB 2.0 EN LA ELICITACIÓN DE REQUISITOS DE SOFTWARE

Documents

Transcript of WEB 2.0 EN LA ELICITACIÓN DE REQUISITOS DE SOFTWARE