Propuesta para Trabajo de Grado


I.2. Descripción del Proyecto



Yüklə 435,76 Kb.
səhifə3/10
tarix01.11.2017
ölçüsü435,76 Kb.
#25557
1   2   3   4   5   6   7   8   9   10

I.2. Descripción del Proyecto

I.2.1. Visión global


Este trabajo de grado se realizó con el fin de automatizar los procesos en la gestión de proyectos de software basados en metodologías ágiles, gestión apoyada en un ambiente de desarrollo colaborativo, en este caso GForge. El trabajo elaboró una Guía metodológica, de manera que se pueda: definir un flujo de trabajo con sus respectivos estados y responsables para cada etapa del proyecto de software, dar seguimiento al avance del proyecto visualizando el estado de las entregas parciales con el progreso de sus correspondientes actividades, conocer el desempeño que obtienen los integrantes con sus respectivas tareas asignadas por medio de reportes que muestran las horas invertidas en el desarrollo de una actividad o un proceso específico.

I.2.2. Justificación


Debido a la centralización de la información obtenida en la gestión de un proyecto de software al utilizar un ambiente desarrollo colaborativo, en este caso GForge, se logra la consolidación de la información referente al estado de un proyecto, apoyando a la toma de decisiones que se requiere durante su gestión. El modelo de gestión que se propone en este trabajo de grado está basado en metodologías ágiles, teniendo en cuenta sus ventajas sobre las metodologías tradicionales [Ambysoft Inc., 2008], en donde se destacan las siguientes: el aumento en la productividad, aumento en la calidad y mayor satisfacción a los involucrados en el proyecto.

Por lo tanto, se encontró la necesidad de elaborar una guía metodológica que automatizara los procesos para la gestión de proyectos de software basados en metodologías ágiles utilizando ambientes de desarrollo colaborativo.


I.2.3. Objetivo general


Definir una guía metodológica que explique el manejo de una herramienta de software basada en ambientes colaborativos para la gestión de proyectos de software que utiliza metodologías ágiles, logrando su validación por medio de personas expertas de una casa de software reconocida en Colombia, en un plazo máximo de 192 horas por integrante del semestre 2009-III.

I.2.4. Objetivos específicos


  • Realizar el levantamiento de información en cuanto a la manera de realizar guías metodológicas, uso de metodologías ágiles, herramientas de software basadas en ambientes de desarrollo colaborativo, trackers y workflows en GForge.

  • Elaborar una comparación entre las diferentes herramientas de software basadas en ambientes de desarrollo colaborativo.

  • Instalar GForge con los plugins de Microsoft Project y el IDE Eclipse.

  • Definir un proyecto de software basado en metodologías ágiles utilizado como demostración dentro de la guía metodológica a realizar.

  • Definir los workflows y trackers para un proyecto de software que utilice metodologías ágiles en cada una de sus etapas.

  • Acoplar cada uno de los trackers y workflows basados en metodologías ágiles al proyecto de demostración dentro de GForge.

  • Documentar en una guía metodológica cómo usar GForge con las características que se necesitan para aplicar las metodologías ágiles.

I.2.5. Impacto


Para lograr una mayor difusión de los productos principales de este trabajo de grado y un uso libre por parte de la empresa privada y las universidades, se ha decidido que la Guía metodológica para la gestión de proyectos de software 
basados en metodologías ágiles, utilizando a GForge como ambiente de desarrollo colaborativo
y el Manual de instalación y configuración de GForge AS 5.6.1 se liberen por medio de la licencia de Creative Commons [Creative Commons Corp., 2010] Reconocimiento-Compartir bajo la misma licencia 2.5 Colombia, la cual permite: copiar, distribuir, comunicar públicamente la obra, hacer obras de derivadas y utilizar los contenidos para fines comerciales, bajo las condiciones de reconocer los autores y de compartir el contenido de los documentos bajo la misma licencia como se puede observar el siguiente link: http://creativecommons.org/licenses/by-sa/2.5/co/.

Gracias a la licencia Reconocimiento-Compartir que poseen la Guía metodológica para la gestión de proyectos de software basados en metodologías ágiles, utilizando a GForge como ambiente de desarrollo colaborativo y el Manual de instalación y configuración de GForge AS 5.6.1 se utilizarán estos documentos en la maestría de Ingeniería de Sistemas y Computación en la Pontificia Universidad Javeriana para el curso Tópicos Avanzados en Ingeniería de Software en donde se enseña la gestión de proyectos de software por medio de las metodologías ágiles y se desarrolla un proyecto de software utilizando GForge y la automatización de los procesos de la gestión por medio de la guía elaborada como principal producto de este trabajo de grado.








II - MARCO TEÓRICO

II.1. Marco Contextual

II.1.1. Ambiente de desarrollo colaborativo (CDE)


Un entorno de desarrollo colaborativo es un espacio virtual donde todas las
las partes interesadas de un proyecto, incluso si se están en diferente tiempo o lugar, puede negociar, hacer una lluvia de ideas, debatir, compartir conocimientos y en general trabajar en conjunto para llevar a cabo algunas tarea, la mayoría de las veces para crear un ejecutable de aplicación y sus artefactos.

La colaboración es esencial para cada rama de la ingeniería pero concretamente, se va hablar de ingenieros de software en sus tareas de diseñar la aplicación, implementación y mantenimiento de software de alta calidad haciendo uso de la Internet como base para sus interacciones sin importar que estén físicamente separados [Booch & Brown, 2002].


II.1.2. Metodologías ágiles


Las metodologías ágiles son un subconjunto de las metodologías iterativas e incrementales, en el cual el ciclo de vida de un proyecto de software está compuesto de varias iteraciones de forma secuencial [Larman, 2004].

Durante la ejecución de cada una de las iteraciones, se llevan a cabo diferentes actividades de desarrollo de software de forma secuencial como son: el diseño, la implementación y las pruebas; al finalizar se obtiene su correspondiente entrega (iteration release), tal como se puede apreciar en la Ilustración 1.

La entrega de una iteración (iteration release), consiste de un módulo funcional (conjunto de casos de uso) del sistema final, junto con sus respectivos documentos que se obtuvieron durante la realización de sus correspondientes actividades de desarrollo. También es necesario mencionar, que al iniciar una iteración, se trabaja a partir del resultado obtenido en la entrega de la iteración anterior, de tal forma que en la entrega de la iteración final, se obtiene el sistema final, tal como se puede apreciar en la Ilustración 2.

Las metodologías ágiles utilizan los fundamentos del desarrollo iterativo evolutivo y del desarrollo adaptativo. El primero implica que los requerimientos, los planes, las estimaciones y las soluciones evolucionan o son refinados a través de las iteraciones. De forma similar, el desarrollo adaptativo implica que los elementos se adaptan de acuerdo a la retroalimentación brindada por los usuarios, probadores, desarrolladores, y demás stakeholders. De tal manera que el concepto del desarrollo adaptativo es similar al del desarrollo iterativo evolutivo, con la excepción de que el término retroalimentación tiene mayor peso en la evolución [Larman, 2004].



Ilustración 1 - Agile software development1



Ilustración 2 - Iteration release2


II.1.2.1. Manifiesto ágil


En febrero de 2001 se creó el manifiesto ágil aplicado al desarrollo de software [Beedle, y otros, 2001]. Su objetivo fue definir los valores y principios para el desarrollo de software de manera ágil, teniendo en cuenta los cambios que se puedan presentar a lo largo del desarrollo del proyecto [Letelier & Penadés, 2003]. A continuación se presenta el manifiesto ágil en detalle [Beedle, y otros, 2001]:

Estamos descubriendo mejores métodos de desarrollo de software al hacerlo y ayudando a otros a hacerlo. A través de este trabajo, hemos llegado a valorar:

Los individuos e interacciones SOBRE los procesos y herramientas.

El trabajo en software SOBRE la documentación completa.

La colaboración de los clientes SOBRE la negociación en los contratos.

La respuesta al cambio SOBRE el seguimiento de un plan.

Es decir, mientras hay valor en los elementos de la derecha, nosotros valoramos más los elementos de la izquierda.

II.1.2.2. Principios del manifiesto ágil


En el manifiesto ágil se fundamenta en los siguientes principios [Beedle, y otros, 2001], en donde de acuerdo a [Letelier & Penadés, 2003], se comienza por describir el espíritu ágil (principios número 1 y 2), luego se describen algunos detalles de los procesos en el desarrollo de software (principios: 3 - 8) y se finaliza con la descripción del equipo de desarrollo (principios 9 - 12). A continuación se presentan los principios del manifiesto ágil, tomando literalmente las conclusiones expuestas en el documento de [Letelier & Penadés, 2003]:

  1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Un proceso es ágil si a las pocas semanas de empezar ya entrega software que funcione aunque sea rudimentario. El cliente decide si pone en marcha dicho software con la funcionalidad que ahora le proporciona o simplemente lo revisa e informa de posibles cambios a realizar.

  2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Este principio es una actitud que deben adoptar los miembros del equipo de desarrollo. Los cambios en los requisitos deben verse como algo positivo. Les va a permitir aprender más, a la vez que logran una mayor satisfacción del cliente. Este principio implica además que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste añadido. El paradigma orientado a objetos puede ayudar a conseguir esta flexibilidad.

  3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. Las entregas al cliente se insiste en que sean software, no planificaciones, ni documentación de análisis o de diseño.

  4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que la interacción con el equipo es muy frecuente.

  5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. La gente es el principal factor de éxito, todo los demás (proceso, entorno, gestión, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado.

  6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, éste es el principal modo de comunicación. Se pueden crear documentos pero no todo estará en ellos, no es lo que el equipo espera.

  7. El software que funciona es la medida principal de progreso. El estado de un proyecto no viene dado por la documentación generada o la fase en la que se encuentre, sino por el código generado y en funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el 50% de los requisitos ya están en funcionamiento.

  8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. No se trata de desarrollar lo más rápido posible, sino de mantener el ritmo de desarrollo durante toda la duración del proyecto, asegurando en todo momento que la calidad de lo producido es máxima.

  9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto.

  10. La simplicidad es esencial. Tomar los caminos más simples que sean consistentes con los objetivos perseguidos. Si el código producido es simple y de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir.

  11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. Todo el equipo es informado de las responsabilidades y éstas recaen sobre todos sus miembros. Es el propio equipo el que decide la mejor forma de organizarse, de acuerdo a los objetivos que se persigan.

  12. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. Puesto que el entorno está cambiando continuamente, el equipo también debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organización, sus reglas, sus convenciones, sus relaciones, etc., para seguir siendo ágil.


II.1.3. Resultados de la encuesta Agile Adoption Rate Survey Results: February 2008


De acuerdo a la encuesta Agile Adoption Rate Survey Results: February 2008 realizada por el Dr. Dobb’s [Ambysoft Inc., 2008], la cual pretendía explorar el estado en el año 2008 en la adopción y las tasas de éxito en las técnicas de desarrollo de software con metodologías ágiles, se encontró que la tasa de adopción fue la misma del año 2007 en 69%, la mayoría de los equipos ágiles tenían iteraciones de 4 o menos semanas de duración y que los equipos ágiles tenían altos niveles de éxito. También se encontró que la gente cree en promedio que los equipos ágiles están produciendo mayores niveles de calidad, son más productivos y logran mayor satisfacción de los stakeholders, todo esto a un menor costo que en las metodologías tradicionales.

A continuación se presentan las gráficas de los resultados obtenidos en la encuesta realizada por el Dr. Dobb’s:





Ilustración 3 - Productividad con las metodologías ágiles3



Ilustración 4 - Calidad con las metodologías ágiles4



Ilustración 5 - Satisfacción de los stakeholders con las metodologías ágiles5



Ilustración 6 - Tasas de éxito en las metodologías ágiles por el nivel de distribución en los miembros del equipo6



Ilustración 7 - Costo en el desarrollo del sistema con las metodologías ágiles7

De acuerdo a [Ambysoft Inc., 2008], se pudo concluir lo siguiente, con respecto a la encuesta que se nombró anteriormente:



  • El 69% de los encuestados indicaron que en sus organizaciones, uno o más proyectos están basados en metodologías ágiles. De los que todavía no habían comenzado, el 15% cree que sus compañías lo harán en el próximo año.

  • El 82% de las organizaciones que utilizan las metodologías ágiles en el desarrollo de software, se encontraban más allá de la fase del proyecto piloto.

  • Aunque en promedio los costos son más bajos en los equipos ágiles, el 23% de los encuestados creen que están experimentando los mayores costos que el promedio. 40% dijo que los costos se mantuvieron sin cambios, y el 37% que los costos eran menores.

A continuación se ilustran las razones más importantes para adoptar las metodologías ágiles en la gestión de proyectos de software, de acuerdo a [VersionOne, Inc., 2009].



Ilustración 8 - Razones por adoptar las metodologías ágiles8

II.1.4. Comparación de los ambientes de desarrollo colaborativo (CDE)


A continuación vamos a presentar una breve comparación entre los ambientes de desarrollo colaborativo (CDE): Asynchrony [Asynchrony Solutions, Inc., 2009], Freepository [Freepository, Inc., 2010], GBorg [PgFoundry Group, 2010], GForge [GForge Group, 2007], Savannah [Free Software Foundation, Inc., 2010], SEUL [SEUL Project, 2004] y SourceForge [Geeknet, Inc., 2010], los cuales fueron escogidos debido a que algunos de estos son los más populares en el mercado, y además; cuentan con características adicionales que actualmente son importantes para la gestión de proyectos de software, como lo son: las listas de correos, los foros, los repositorios del código fuente y los gestores de trackers, los cuales permiten dar seguimiento y apoyan la evolución del proyecto.

Para esta comparación se tomo como fuente principal el trabajo doctoral: “Construction of an Evaluation Model for Free/Open Source Project Hosting Sites” [Heng So, 2005] [So, Dingledine, Gordon, Minnihan, Reiniger, & Ryan, 2007] y el website del Wiki: “Comparison of open source software hosting facilities” [Wapedia Mobile Encyclopedia, 2010], debido a que estos comparan y prueban diferentes ambientes de desarrollo colaborativo (CDE), entre los cuales, los que se han escogido para esta comparación son los que se han mencionado anteriormente.




Información general




Asynchrony

Freepository

GBorg

GForge

Savannah

SEUL

SourceForge

Descripción breve

Alojamiento web de código abierto y cerrado, además de la venta de proyectos en curso.

Repositorio seguro con Subversion, con un plan básico gratis (sólo con acceso web) y las versiones que cuentan con más características son de pago.

Un sitio específico para los proyectos relacionados con PostgreSQL. Impulsado por GForge.

Una herramienta abierta colaborativa de desarrollo de software, que permite gestionar cualquier número de proyectos de desarrollo de software.

Es el ambiente de desarrollo colaborativo más popular para el desarrollo de software GNU.

Almacena un conjunto completo de aplicaciones de alta calidad disponible para la plataforma Linux.

La herramienta de desarrollo colaborativa de software más conocida y con amplias utilidades.

Dirección

Asynchrony.com Inc.

Dirigido por John Minnihan

Dirigido por el equipo de de desarrollo de GBorg.

Dirigido por un equipo encabezado por el exlíder de SourceForge: Tim Perdue

Free Software Foundation

Grupo de voluntarios "Simple End-User Linux"

VA Software Corporation

Número de proyectos

1,848

540

330

65

3,074

Más de 50

230,000

Número de miembros

33,309

783

9,475

1,046

62,453

Con acceso Shell 300 y con CVS 225.

2’000,000

Costos

Indeterminado

SVN Básico Gratis.

SVN + US$39 /año.



SVN Extremo US$189 /año.

Gratis

Gratis para proyectos con menos de 15 usuarios.

Gratis

Gratis

Gratis y la versión que se puede descargar (Collabnet - TeamForge) cuesta US$4,995 la licencia

Tipo de licencia

Propietaria

GPL

GPL

GPL

GPL

GPL

GPL

Tabla 1 - Información general de los CDEs

Herramientas para el público o desarrolladores




Asynchrony

Freepository

GBorg

GForge

Savannah

SEUL

SourceForge

Formato HTML libre

Si

No

No

Si

Si

Si

Si

Asignación de roles del proyecto

Si

Basados en los permisos que ofrece CVS

Si

Si

Si

Manual

Si

Noticias del proyecto

Si

No

Si

Si

Si

Manual

Si

Servicio de descarga

HTTP

HTTPS

FTP

File Release

FTP

HTTP, FTP

File Release

Administración de la documentación

Manual

No

FAQ, páginas generadas

DocManager

FAQ

Manual

DocManager

Estadísticas

Número de descargas de las versiones beta y número de versiones creadas.

No determinado

No

Actividad en el proyecto, tráfico en la red, estadísticas comparativas.

No determinado

Estadísticas disponibles en Internet: http://stats.seul.org/

Actividad en el proyecto, tráfico en la red, estadísticas comparativas.

Repositorio del código fuente

Servidor CVS

Servidor CVS, CVSweb, y plugin de Eclipse

Servidor CVS y ViewCVS

Servidor CVS y CVSweb

Servidor CVS y ViewCVS

Servidor CVS, ViewCVS y CVSweb

Servidor CVS y ViewCVS

Lista de mensajes

Si

No

Mailman

Mailman

Mailman

Majordomo y MHonArc

Mailman

Tracker

Petición o tarea en los cambios dentro del proyecto

No

Tareas, características y bugs.

Definido por GForge y por el usuario

Bug, soporte, parches, tarea

Jitterbug y Manual

Bugs, soporte, parches, características, tareas y sus dependencias

Foro

Si

No

No

Si

Si

Manual

Si

Wiki

No determinado

No

No

Manual

No

Manual

Manual

Encuestas

Rating definido a partir de los atributos del proyecto

No

No

Si

No determinado

Manual

Manual

Otras herramientas







Administrador de parches

Gestor de tareas y gráfico de Gantt










Tabla 2 - Herramientas para el público o desarrolladores de los CDEs


Herramientas del proyecto – Herramientas para los administradores del proyecto




Asynchrony

Freepository

GBorg

GForge

Savannah

SEUL

SourceForge

Administrador de herramientas para los desarrolladores y el público

Si

No

Si

Si

Si

Manual

Si

Historial de actividades

Desconocido

No

No

Si

Si

Manual

Si

Soporte de scripts por parte del servidor web

Desconocido

No

No

Depende de la disponibilidad de cada uno de los sitios

No

SSI, PHP3, PHP4,CGI, Embperl

PHP3, PHP4

Base de datos

Desconocido

No

No

Si

No

MySQL and PostgreSQL

MySQL

Shell

Desconocido

No

No

Si

Sólo algunas personas lo tienen.

A disposición de los desarrolladores seleccionados.

Si

Alojamiento Virtual

Si

No

No

Si

No

Si

Si

Carga de datos

FTP

CVS vía SSL

Formulario HTTP y FTP.

Formulario HTTPS

CVS vía SSH

SCP, SFTP y rsync

SCP, SFTP y FTP

Seguridad

SSH y SSL

SSL




Depende de la política de cada uno de los sitios

SSH1, SSL en web

SSH1, SSH2

SSH1, SSH2, SSL en web

Política en las copias de seguridad

Política desconocida

Política desconocida

Política desconocida

Depende de la política de cada uno de los sitios

Política desconocida

Los usuarios hacen copia de seguridad

Política de copia de seguridad (5 tipos de copia, al día)

Tabla 3 – Herramientas para los administradores del proyecto en los CDEs

Herramientas personales para los desarrolladores




Asynchrony

Freepository

GBorg

GForge

Savannah

SEUL

SourceForge

Monitoreo de Trackers/Foros/archivos

No determinado

No

Sólo para trackers

Si

Si

No

Si

Proyectos implicados

Si

No

Si

Si

Si

No

Si

Problemas desde los trackers

Asignado/Enviado

No determinado

No

No, pero se puede enviar notificación a través del sistema de monitoreo

Si

Si

No

Si

Inspección de las opiniones de los usuarios

No

No

No

Si

No

No

No

Correo electrónico

Redirigido

No

No

Redirigido

Redirigido

Manual

Redirigido

Calendario

No

No

No

Si

No

No

Si

Marcadores

No

No

No

Si

Si

No

Si

Tabla 4 - Herramientas personales para los desarrolladores que hay en los CDEs

De acuerdo a los resultados obtenidos en la comparación anterior entre los CDEs mencionados, se observa la gran importancia que hay en los servicios que buscan la privacidad y seguridad en el acceso a los documentos y demás información vital para los proyectos que se estén desarrollando, como también un bajo costo al que hay que incurrir para contar con los servicios que estos ofrecen. Además, se observa que la mayoría de los CDEs que existen actualmente, ofrecen todos sus servicios desde una plataformas web, lo que brinda una mayor accesibilidad para los stakeholders del proyecto, los cuales se conectan a los repositorios de forma remota o local, y la mayoría de proyectos que se están desarrollando por medio de esta tecnología, resultan ser en su gran mayoría, aplicaciones de software libre.

Por consiguiente, después de haber observado y analizado las funcionalidades para los CDEs anteriormente mencionados, se define para este proyecto, que después de las funcionalidades tales como la privacidad y la seguridad en los repositorios internos y las diferentes herramientas de gestión de proyectos de software anteriormente mencionadas, también es necesario tener en cuenta el precio como uno de los criterios más relevantes a la hora de escoger el CDE que se ajuste a las necesidades para una casa de software que no quiera incurrir en gastos relacionados a los costos de las licencias.

Finalmente, se puede concluir que GForge se ajusta a los criterios para este proyecto, ya que además de incluir algunas de las herramientas importantes para la gestión de proyectos de software, incorpora gestores de tareas y los diagramas de Gantt para la toma de decisiones, y además, este CDE se puede descargar como una aplicación independiente brindando la posibilidad de alojar los repositorios de forma interna con políticas de seguridad privadas, logrando mayor confidencialidad de la información.


II.1.5. Unified Software Development Process (UP)


De acuerdo a [Bruegge & Dutoit, 2004], el Unified Software Development Process, es un modelo de ciclo de vida de software iterativo caracterizado por ciclos de cuatro fases llamados: Inicio, elaboración, construcción y transición.

Yüklə 435,76 Kb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9   10




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin