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
que soporta y lo que le falta) [1]. ................................................................ 23
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
que soporta y lo que le falta) [1]. ................................................................ 26
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
que soporta y lo que le falta) [1]. ................................................................ 29
Tabla 7. Herramienta Web 2.0 Chryrp (Elementos de aprendizaje colaborativo, lo que
soporta y lo que le falta) [1]. ...................................................................... 30
Tabla 8. Herramienta Web 2.0 Pligg (Elementos de aprendizaje colaborativo, lo que
soporta y lo que le falta) [1]. ...................................................................... 31
Tabla 9. Herramienta Web 2.0 WordPress (Elementos de aprendizaje colaborativo, lo
que soporta y lo que le falta) [1]. ................................................................ 33
Tabla 10. Herramienta Web 2.0 Dotclear (Elementos de aprendizaje colaborativo, lo que
soporta y lo que le falta) [1]. ...................................................................... 34
Tabla 11. Herramienta Web 2.0 ModX (Elementos de aprendizaje colaborativo, lo que
soporta y lo que le falta) [1]. ...................................................................... 36
Tabla 12. Herramienta Web 2.0 Elgg (Elementos de aprendizaje colaborativo, lo que
soporta y lo que le falta) [1]. ...................................................................... 37
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].
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].
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].
Tiene las siguientes características:
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
soporta y lo que le falta) [1].
Herramienta Elementos de
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.
Edición colaborativa
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].
Tiene las siguientes características:
Blogging [1].
Compartir y administrar archivos de medios [1].
Enviar mensajes [1].
Construir y administrar grupos [1].
Crear relaciones entre grupos y usuarios [1].
Crear metaredes [1].
Publicar contenidos [1].
Construir foros de discusión [1].
25
Tabla 3. Herramienta Web 2.0 People Aggregator (Elementos de aprendizaje colaborativo, lo que
soporta y lo que le falta) [1].
Herramienta Elementos de
Aprendizaje
Colaborativo
Soporta Falta
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
Edición colaborativa
Habilidades para el
manejo de grupos
pequeños
Compartición de
recursos
Control de cambios
Creación de
relaciones
Resolución de
conflictos
Control de
contribuciones de
los usuarios
Google Docs: es un conjunto de productos que permite crear distintos tipos de
documentos, trabajar en ellos con otros usuarios en tiempo real y almacenar
documentos y otros archivos. Estas herramientas permiten trabajar de forma
colaborativa en documentos, hojas de cálculo, presentaciones y otro tipo de
documentos. Google Docs permite edición colaborativa, compartición de
contenidos y administración de documentos. Todo online y de forma gratuita
[32].
Tiene las siguientes características:
Crear documentos básicos [1].
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
soporta y lo que le falta) [1].
Herramienta Elementos de
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
Edición colaborativa
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].
Herramienta Elementos de
Aprendizaje
Colaborativo
Soporta Falta
Interdependencia
positiva
Soporte de grupos Evaluación de
contribuciones
Interacción Discusión grupal e Resolución de
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
Edición colaborativa
Control de
modificaciones
Confluence: es desarrollado y comercializado por Atlassian . Atlassian Confluence
dice conecta los equipos con el contenido y compañeros de trabajo que necesitan
para realizar su trabajo [34].
Tiene las siguientes características:
Crear páginas editables instantáneamente [1].
Información en tiempo real y notificaciones usando blogs [1].
Información actual a través de notificaciones [1].
Editor WYSIWYG [1].
Opciones configurables [1].
Fácil de usar y amigable [1].
Permite discusiones para grupos y equipos de trabajo [1].
Compartir y controlar archivos [1].
Creación de espacios de trabajo [1].
Modificable con añadidos [1].
29
Tabla 6. Herramienta Web 2.0 Confluence (Elementos de aprendizaje colaborativo, lo que
soporta y lo que le falta) [1].
Herramienta Elementos de
Aprendizaje
Colaborativo
Soporta Falta
Confluence
Interdependencia
positiva
Soporte de grupos Evaluación de
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
Edición colaborativa
Control de
modificaciones
Chyrp: es una herramienta Web 2.0 la cual tiene la funcionalidad de
personalizarse como sea necesario. Es configurable por medio de temas y se le
pueden añadir módulos. Se puede personalizar de la forma que al usuario le
parezca más apropiado. Chryp soporta actividades Web 2.0 como blogging,
Folksonomy, publicación de contenidos y edición de contenidos. La licencia es
GPL y es de código libre [1].
30
Tabla 7. Herramienta Web 2.0 Chryrp (Elementos de aprendizaje colaborativo, lo que soporta y
lo que le falta) [1].
Herramienta Elementos de
Aprendizaje
Colaborativo
Soporta Falta
Chyrp
Interdependencia
positiva
Soporte de grupos Evaluación de
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].
Tiene las siguientes características:
Soporta múltiples autores y usuarios [1].
Evaluación de artículos [1].
Mensajes privados [1].
Sistema avanzado de comentarios [1].
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].
Herramienta Elementos de
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].
Tiene las siguientes características:
Temas decorativos y un sistema de plantillas para la interfaz [1].
WordPress Links que se usan para crear, mantener y actualizar cualquier cantidad
de colecciones de enlaces blog a través de la interfaz administrativa [1].
Soporta literalmente cientos de añadidos [1].
Multiples categorías anidadas para artículos los cuales pueden ser expuestos a la
máquina de búsqueda [1].
Manejo de versiones y control de cambios [1].
Filtros tipográficos para formatear apropiadamente los textos y establecer estilos
[1].
Mantenimiento de páginas estáticas [1].
Soporte para multiples autores con diferentes privilegios [1].
Aplicaciones de control de enlaces para publicar blogs y agregar enlaces a las
colecciones de enlace blog con la menos cantidad de esfuerzo [1].
Control de usuarios que visitan los blog [1].
Protección contra mensajes indeseables (spam) y bloqueos de visitantes basado
en dirección de IP [1].
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
soporta y lo que le falta) [1].
Herramienta Elementos de
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
Edición colaborativa
Procesamiento de
grupo
Control de
contribuciones de
los usuarios
Control de cambios
Dotclear: es una herramienta de software Web 2.0 para publicación de
contenidos. El principal objetivo de Dotclear es ofrecer a los usuarios una
herramienta amigable para publicar contenidos con facilidad en la Web sin
importar el nivel de habilidades técnicas de usuarios. Es gratuito. Fue
desarrollado con PHP y MySQL [1].
34
Tiene las siguientes características:
Muy simple [1].
Fácil publicación [1].
Administración de archivos multimedios [1].
Edición de sintaxis dual Wiki/XHTML con traductor interno [1].
Soporte a múltiples lenguaje [1].
Cumple con código W3C [1].
Sistema de plantillas flexible [1].
Etiquetas y categorías para las páginas [1].
Permite entrada flexibles con comentarios y control de cambios [1].
Sistema configurable completo de temas de apoyo a los plugin [1].
Tabla 10. Herramienta Web 2.0 Dotclear (Elementos de aprendizaje colaborativo, lo que
soporta y lo que le falta) [1].
Herramienta Elementos de
Aprendizaje
Colaborativo
Soporta Falta
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
Edición colaborativa
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].
Tiene las siguientes características:
Soporte a estándares Web fuerte [1].
Marco de trabajo en PHP [1].
Soporte para diferentes navegadores [1].
Instalador gráfico [1].
Constructor de menús CSS [1].
Controles de metaetiquetas y palabras clave [1].
Separación de sesiones de administrador y usuario [1].
Manejo de errores y revisión de documentos mejorados [1].
Tipos de contenidos definidos por el usuario [1].
Importación de contenidos HTML [1].
Constructor de menú de navegación poderoso [1].
36
Tabla 11. Herramienta Web 2.0 ModX (Elementos de aprendizaje colaborativo, lo que soporta y
lo que le falta) [1].
Herramienta Elementos de
Aprendizaje
Colaborativo
Soporta Falta
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
Edición colaborativa
Procesamiento de
grupo
Control de
contribuciones de
los usuarios
Control de cambios
ELGG: ELGG puede parecer una red social como cualquier otra red open source, ya que
posee una amplia documentación, además del apoyo de una comunidad para resolver
dudas [37].
Pero uno de los valores agregados que nos ofrece ELGG es su amplia gama de plugins,
diseñados y construidos por los diferentes desarrolladores que pertenecen a la
comunidad, que nos permiten adicionar funcionalidades diferentes, además de las
diferentes características que nos ofrecen:
37
Tiene las siguientes características:
Administración de usuarios, objetos, archivos y el sitio en sí [37].
Repositorio de archivos que permite compartirlos entre diferentes archivos [37].
Graficación social que mapea las relaciones entre usuarios, objetos y sitios Web) [37].
Capacidad Multisitio para una misma instalación [37].
Soporte a la internacionalización extensible [37].
Búsqueda en todos los contenidos y usuarios en todo el sistema, basándose en etiquetas [37].
Control de acceso fino [37].
Múltiples vistas, permitiendo interfaces con aplicaciones móviles y widgets embebidos, y
navegadores Web [37].
API’s para manejo de eventos, extensiones y widgets [37].
Tabla 12. Herramienta Web 2.0 Elgg (Elementos de aprendizaje colaborativo, lo que soporta y lo
que le falta) [1].
Herramienta Elementos de
Aprendizaje
Colaborativo
Soporta Falta
Elgg
Interdependencia
positiva
Soporte de grupos Evaluación de
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
Edición colaborativa
Control de
contribuciones de
los usuarios
Control de cambio
Como podemos observar de la tabla 1 a la tabla 12 existe una gran disponibilidad de
sitios y herramientas de software que se pueden utilizar para implantar el aprendizaje
colaborativo usando tecnología Web 2.0. Podemos concluir que las herramientas que
mejor soportan el aprendizaje colaborativo son las denominadas ELGG y PLIGG ya que
tienen menos elementos negativos y faltantes en el aprendizaje colaborativo, y ambas
herramientas soportan el control de cambios que en la etapa de requisitos de software
es de vital importancia [1].
La Web 2.0 ha tenido un impacto social a nivel educativo, ya que a través de los últimos
años, el poder de opinión se ha venido valorando cada día más, ya que gracias a la Web
2.0 los usuarios podemos explotar la capacidad de expresarnos a través de las opciones
que tenemos en Internet ya sea por redes sociales y en estas globalizar información,
puesto que los que aportan ideas, conocimientos y deciden los contenidos no son los
creadores sino la comunidad. Un claro ejemplo de ello es la Wikipedia, donde los
usuarios construyen, editan y publican artículos y a través de este dan a conocer sus
investigaciones o conocimientos frente a un tema específico.
Teniendo en cuenta los conceptos de la Web 2.0, herramientas y características de cada
una de ellas, procedemos a conceptualizar sobre los requisitos en el software, pero para
ello, debemos iniciar por intervenir en el ciclo de vida de desarrollo de software, ya que
la elicitación de requisitos es la primera fase de este.
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.
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.
70
71
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.
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
herramientas Web 2.0.
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
herramientas Web 2.0.
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
herramientas Web 2.0.
La totalidad de los requisitos
en la etapa del desarrollo
cumplen con lo acordado en
dicha etapa, el proceso de
validación se realiza
parcialmente en herramientas
Web 2.0.
La totalidad de los requisitos
en la etapa del desarrollo
cumplen con lo acordado en
dicha etapa, el proceso de
validación no hace uso de las
herramientas Web 2.0.
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
elicitación de requisitos.
Participación pasiva en el
proceso de elicitación de
requisitos
5
4
3
2
1
80
Participación nula en el
proceso de elicitación de
requisitos.
Stakeholders 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
elicitación de requisitos.
Participación pasiva en el
proceso de elicitación de
requisitos
Participación nula en el
proceso de elicitación de
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
manera clara un requisito de
desarrollo de software.
Mayor esfuerzo al definir de
manera clara un requisito de
desarrollo de software.
5
3
1
Stakeholder Menor esfuerzo en entender y
realizar la aprobación del
requisito definido.
Igual esfuerzo en entender y
realizar la aprobación del
requisito definido.
Mayor esfuerzo en entender y
realizar la aprobación del
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
desarrollo de software.
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
Uso de la web 2.0 Metodo Tradicional
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
Uso de la web 2.0 Metodo Tradicional
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
Uso de la web 2.0 Metodo Tradicional
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
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
103
[40] users.dsic.upv.es/asignaturas/facultad/lsi/trabajos/292002.ppt