Disco Tienda Web

DISCOTIENDA WEB
Documento de Post Mrtem Ciclo 1 LOS EJEMPLARES
Los Ejemplares - IngSW

Jess Vargas Lder de Grupo Pedro Feijoo Lder de Planeacin Camilo Restrepo Lder de Calidad Andrs Gonzlez Lder de Desarrollo Wilson Guarn Lder de Soporte
Bogot D.C., Colombia 2011
[i]
Tabla de Contenido
Tabla de Figuras ................................................................................................................ iv 1 Producto ..................................................................................................................... 5 1.1 1.2 2 Contexto .............................................................................................................. 5 Producto Desarrollado ......................................................................................... 5
Evaluacin Del Producto........................................................................................... 12 2.1 Balance de Requerimientos ............................................................................... 12 Capa de Presentacin ................................................................................ 13 Capa de Lgica de Negocio........................................................................ 13 Capa de Persistencia.................................................................................. 14 Desarrollo Adicional .................................................................................... 14
2.1.1 2.1.2 2.1.3 2.1.4 2.2
Mtricas ............................................................................................................. 15 Tamao del Producto ................................................................................. 15 Productividad .............................................................................................. 18
2.2.1 2.2.2 2.3
Tiempos............................................................................................................. 19 Planeacin Individual .................................................................................. 19 Planeacin Grupal ...................................................................................... 24 Valor Ganado ............................................................................................. 26
2.3.1 2.3.2 2.3.3 3
Evaluacin del Proceso ............................................................................................ 27 3.1 Objetivos y Resultados ...................................................................................... 27 Objetivos del Grupo .................................................................................... 27 Objetivos del Proyecto ................................................................................ 29 Miembros.................................................................................................... 31 Objetivos por Roles .................................................................................... 32
3.1.1 3.1.2 3.1.3 3.1.4 3.2
Balance de Estrategias ...................................................................................... 40 Estrategia General ...................................................................................... 40 Estrategia Especfica .................................................................................. 41 Estrategia de Aseguramiento de Calidad .................................................... 44
3.2.1 3.2.2 3.2.3
3.3 Oportunidades de Mejora y Planes Concretos ....................................................... 47 4 Reflexiones ............................................................................................................... 49 4.1 Lder del Grupo.................................................................................................. 49 Desempeo del Grupo................................................................................ 49
[ii]
4.1.1
4.1.2 4.1.3 4.1.4 4.2
Desempeo del Rol .................................................................................... 50 Desempeo como Desarrollador ................................................................ 51 Reporte....................................................................................................... 53
Lder de Desarrollo ............................................................................................ 54 Desempeo del Grupo................................................................................ 54 Desempeo del Rol .................................................................................... 55 Desempeo como Desarrollador ................................................................ 56 Reporte....................................................................................................... 57
4.2.1 4.2.2 4.2.3 4.2.4 4.3
Lder de Planeacin ........................................................................................... 58 Desempeo del Grupo................................................................................ 58 Desempeo del Rol .................................................................................... 59 Desempeo como Desarrollador ................................................................ 60 Reporte....................................................................................................... 61
4.3.1 4.3.2 4.3.3 4.3.4 4.4
Lder de Calidad ................................................................................................ 62 Desempeo del Grupo................................................................................ 62 Desempeo del Rol .................................................................................... 63 Desempeo como Desarrollador ................................................................ 64 Reporte....................................................................................................... 65
4.4.1 4.4.2 4.4.3 4.4.4 4.5
Lder de Soporte ................................................................................................ 67 Desempeo del Grupo................................................................................ 67 Desempeo del Rol .................................................................................... 68 Desempeo como Desarrollador ................................................................ 69 Reporte....................................................................................................... 69
4.5.1 4.5.2 4.5.3 4.5.4 5
Acrnimos................................................................................................................. 71
[iii]
Tabla de Figuras
Figura 1 - Bsqueda en la DiscoTienda ............................................................................. 7 Figura 2 - Detalle de un lbum Seleccionado .................................................................... 7 Figura 3 - Login de la Aplicacin ........................................................................................ 8 Figura 4 - Carrito de Compras ........................................................................................... 8 Figura 5 - Checkout de la Compra ..................................................................................... 9 Figura 6 - Procesamiento de la Compra............................................................................. 9 Figura 7 - Resultado de la Compra .................................................................................. 10 Figura 8 - Correo electrnico de confirmacin de compra ................................................ 10 Figura 9 - Creacin de una Compilacin .......................................................................... 11 Figura 10 - Adicin de una Cancin a una Compilacin ................................................... 11 Figura 11 - Requerimientos Logrados: Capa de Presentacin ......................................... 13 Figura 12 - Lneas de Cdigo Implementadas y Planeadas ............................................. 15 Figura 13 - Lneas de Cdigo Implementadas y Planeadas por Capa .............................. 16 Figura 14 - Nmero de Clases Implementadas ................................................................ 17 Figura 15 - Nmero de Mtodos Implementados ............................................................. 17 Figura 16 - Tiempos por Semana: Lder de Grupo ........................................................... 19 Figura 17 - Tiempos por Semana: Lder de Desarrollo..................................................... 20 Figura 18 - Tiempos por Semana: Lder de Planeacin ................................................... 21 Figura 19 - Tiempos por Semana: Lder de Calidad ......................................................... 22 Figura 20 - Tiempos por Semana: Lder de Soporte ........................................................ 23 Figura 21 - Tiempo Planeado y Real: Grupo .................................................................... 24 Figura 22 - Tiempos por Integrante del Grupo ................................................................. 25 Figura 23 - Valor Ganado ................................................................................................ 26
[iv]
1 Producto
1.1 Contexto
La era digital, como algunos la llaman, ha marcado una tendencia muy clara con respecto a la demanda de descargas de msica legal alrededor del mundo. Su venta a travs de Internet se triplic en el 2005 en comparacin al ao anterior, as como a su vez en el primer semestre del 2006, solamente en Estados Unidos, se increment en un 77%. Debido a esta creciente demanda de msica a travs de Internet, el nmero de tiendas virtuales de canciones ha incrementado poco a poco buscando diferentes nichos de mercado. Es por esto que se ha detectado la necesidad de construir un sistema que pueda administrar la informacin de un establecimiento virtual como el anteriormente mencionado. SongStock es una aplicacin dedicada al manejo de la informacin de una tienda virtual de canciones en formato MP3. Este sistema permite visualizar un catlogo de discos, compilaciones y canciones que la tienda tiene a la venta. Cada disco tiene un nombre, un artista, un gnero y una imagen de la cartula del disco. La tienda se especializa en la venta de canciones en formato MP3 por lo que ofrece toda la informacin relevante de una cancin al usuario. Esta informacin comprende: el nombre de la cancin, su precio individual, la duracin en minutos y segundos, el tamao en megabytes (MB) y la calidad de la cancin expresada en kilobytes por segundo (Kbps). Todo lo anterior es con el objetivo de vender los discos, compilaciones o canciones agregndolas a un carrito de compras nico por usuario y pagando por medio de tarjetas de crdito con una sesin protegida por un login de autenticacin.
1.2 Producto Desarrollado

Las siguientes figuras presentan las funcionalidades del sistema. Inicialmente se realiza la bsqueda de cualquier elemento que coincida con pearl jam. El resultado de la bsqueda (Figura 1) presenta los lbumes y canciones individuales. Por simplicidad, se muestran solamente cuatro de los posiblemente ms lbumes que resulten de la bsqueda. El usuario puede seleccionar un lbum individual para ver en detalle, ya sea haciendo clic sobre la caratula de algunos de los que se muestran, o sobre el nombre del lbum en la tabla de canciones. De igual forma, puede agregar canciones directamente al carrito haciendo clic sobre el botn de la fila correspondiente a cada cancin. En este caso, el usuario selecciona el tercer lbum de los que se muestran, llevndolo a la pgina detallada de dicho lbum (Figura 2). En ella, se pueden ver las canciones de dicho lbum, su precio, gnero y cartula en mayor tamao. Al igual que en el caso
[5]
anterior, puede agregar canciones individuales del lbum al carrito de compras. Adicionalmente, es posible agregar todo el lbum al carrito del usuario. En ese orden de ideas, se pueden hacer las respectivas bsquedas por artistas, lbumes y canciones. Si as lo desea el usuario, puede escoger algn lbum para ver en detalle e ir agregando canciones y lbumes a su carrito de compras. Una vez el usuario ha terminado de agregar tems a su carrito, es probable que desee comprar su contenido. Para ello, es necesario que haga login en la tienda (Figura 3). En caso de que el usuario ya haya iniciado sesin al momento de presionar el botn de Checkout, la aplicacin desplegar el carrito con su contenido. De lo contrario, se le presentar la pgina para que introduzca sus credenciales y pueda continuar con el proceso de compra. El carrito de compras (Figura 4) presenta por separado los lbumes, canciones y compilaciones que el usuario haya agregado. En caso de haber adicionado un lbum, se presenta tanto la cartula de este, como el conjunto de canciones en la lista inferior. Una vez verificado el contenido del carrito, se puede proceder a hacer checkout de los tems especificados. Para ello, se presenta una pgina con los formularios de direccin de facturacin e informacin de pago (Figura 5). En ella, el usuario introduce los datos necesarios incluyendo la tarjeta de crdito con la que va a realizar el pago. Cuando se presiona la opcin de Confirmar Orden, se evala que el usuario haya llenado todos los campos, y se inicia el procesamiento de la orden. Mientras el sistema procesa la orden, al usuario se le despliega una pantalla de espera (Figura 6). En esos momentos, la aplicacin genera la factura de compra, actualiza las estadsticas de la tienda, le asocia la compra a dicho usuario y enva un correo electrnico con la confirmacin de la compra realizada. Si todo transcurre correctamente, el sistema mostrara una nueva pantalla explicando que la orden ha sido procesada adecuadamente (Figura 7). En ella se muestra una direccin de correo electrnico a la cual fueron enviados los datos de la compra. As, el usuario puede revisar su correo y tener registro de su actividad en la tienda (Figura 8). Un cliente registrado en la tienda tambin puede crear compilaciones a partir de las canciones que desee. Para ello, una vez iniciada su sesin, podr presionar la opcin en el men superior y especificar un nombre y un nivel de privacidad (Figura 9). Esta ltima propiedad le permitir al sistema saber si otros usuarios tienen permiso de ver dicha compilacin. Habiendo creado la compilacin, el usuario podr agrupar en ella tantas canciones desee. Para lograrlo, basta con hacer clic en la flecha al costado de la opcin de agregar al carrito, y se muestra la lista de compilaciones para que el usuario escoja en cul desea incluirla (Figura 10).
[6]
Figura 1 - Bsqueda en la DiscoTienda
Figura 2 - Detalle de un lbum Seleccionado [7]
Figura 3 - Login de la Aplicacin
Figura 4 - Carrito de Compras [8]
Figura 5 - Checkout de la Compra
Figura 6 - Procesamiento de la Compra [9]
Figura 7 - Resultado de la Compra
Figura 8 - Correo electrnico de confirmacin de compra
[10]
Figura 9 - Creacin de una Compilacin
Figura 10 - Adicin de una Cancin a una Compilacin
[11]
2 Evaluacin Del Producto

En esta seccin se presentan los logros del proyecto en trminos del producto y los recursos invertidos para alcanzarlos. Inicialmente se postulan los requerimientos a desarrollar durante el ciclo y su consecuente evaluacin para establecer cunto se alcanz de cada uno de ellos. Posteriormente se presenta el tiempo invertido en todas las actividades del ciclo y su comparacin con el tiempo que se haba planeado inicialmente para llevarlas a cabo. Por ltimo, se analizan las mtricas sobre el tamao del producto.
2.1 Balance de Requerimientos

Al iniciar el ciclo se estableci que nos centraramos en los requerimientos que involucran al cliente de la tienda. De esta forma, era posible proveer una serie de servicios iniciales que en ciclos posteriores seran complementados con funcionalidades sobre la administracin del contenido del sitio. Especficamente, se propuso el siguiente alcance para este ciclo: 1. Ver informacin de contenido de la Tienda 2. Autenticarse en el sistema 3. Ver informacin de disco 4. Agregar cancin a carrito de compras 5. Agregar disco a carrito de compras 6. Agregar Cancin a Compilacin 7. Agregar Compilacin 8. Agregar Compilacin al Carrito de Compras 9. Comprar Carrito de Compras 10. Ver Compras Realizadas
A continuacin se discrima la completitud de cada uno de estos segn la capa correspondiente de la arquitectura. Se hace esta divisin para sealar en mayor detalle los elementos logrados y faltantes de cada requerimiento, dado que cada uno de ellos es transversal a las tres capas que comprenden el sistema.
[12]
2.1.1 Capa de Presentacin Requerimientos: Capa de Presentacin 20%
Logrado No Logrado
80%
Figura 11 - Requerimientos Logrados: Capa de Presentacin
En trminos de implementacin Web, los requerimientos que no se lograron fueron los relacionados con la inclusin de una compilacin al carrito de compras y la consulta de compras realizadas. La razn ms contundente fue el aprendizaje y uso de la tecnologa Web para la creacin de interfaces grficas. Inicialmente no estbamos muy familiarizados con ella, por lo que fue necesario invertir un tiempo considerable en investigar cmo implementar los elementos grficos que visionamos al momento de proponer un prototipo. Ciertamente una de nuestras prioridades era la usabilidad y proveer un sistema que fuera intuitivo de manejar para un usuario. Por lo que no podamos dejar este aspecto a un lado, as implicara dedicarle ms tiempo a menos vistas de las propuestas. Entre otras dificultades, hubo una semana en que se presentaron confusiones sobre la librera a utilizar para implementar la interfaz grfica. En un momento dado, de tres desarrolladores Web, cada uno estaba utilizando una librera diferente (SmartGWT, GWT, y GXT). Al momento de integrar los entregables desarrollados, fue necesario volver a implementar los componentes desarrollados en SmartGWT. En el caso de GWT, se pudieron reutilizar relativamente pocos componentes desarrollados.
2.1.2 Capa de Lgica de Negocio

Para esta capa se lograron implementar todos los componentes que se haban planeado para el ciclo. Al desarrollar los elementos de esta capa no surgieron mayores inconvenientes de tecnologa ya que los encargados de esta labor ya contaban con la experiencia y el conocimiento previo para desarrollar lo solicitado. De hecho, se investigaron maneras de gestionar adecuadamente el ciclo de vida del bean de sesin del carrito de compras buscando un mejor manejo de los recursos en el contenedor de EJBs.
[13]
2.1.3 Capa de Persistencia

En lo relacionado con la persistencia del sistema, se logr implementar la totalidad del modelo de entidades utilizando el API de persistencia de Java (JPA). Al igual que en el caso de la capa de lgica de negocio, los desarrolladores ya tenan experiencia previa con esta tecnologa y no present mayores inconvenientes. Fue necesario realizar una investigacin adicional para determinar el manejo adecuado de la herencia entre algunas entidades y su materializacin en la base de datos. En comparacin con el diseo realizado, solo fue necesario agregar dos entidades que no se haban contemplado: la direccin de facturacin y datos de pago del cliente. Esto con el fin de asegurar mayor completitud en la informacin de facturas que almacena el sistema.
2.1.4 Desarrollo Adicional

Hay que resaltar que algunos requerimientos que se haban planteado para futuros ciclos tuvieron que ser implementados en buena medida durante este ciclo. Es el caso de algunas labores del administrador del sistema como poder agregar canciones, discos, artistas y compilaciones. Estos requerimientos no se plantearon para este primer ciclo pero fue necesario implementarlos por razones de pruebas. Hablando ms especficamente de las pruebas unitarias, los resultados esperados de cada prueba dependen en buena medida de los datos que almacene la base de datos en un momento dado. Como estas pruebas se parametrizaron para que un desarrollador pudiese cambiar los datos de entrada de cada prueba, fue necesario proveer medios para cargar diversas entidades en la base de datos. La forma en que se hace esto es a travs de un archivo de MS Excel, donde se introducen los datos de canciones, discos, artistas, compilaciones, clientes, entre otros, y un componente se encarga de leer dicho archivo y generar las entidades que se persisten en la base de datos. Esto quiere decir que la lgica de negocio para estas actividades ya existe y que faltara por implementar la interfaz grfica donde un administrador pudiese introducir estos datos.
[14]
2.2 Mtricas
A continuacin se hace un estudio de algunas mtricas del producto con el fin de realizar una evaluacin del mtodo de estimacin utilizado y de obtener datos que pueden ser utilizadas en futuros proyectos similares.
2.2.1 Tamao del Producto

Lneas de Cdigo (real vs. planeado) Las siguientes grficas comparan el tamao del producto en lo que respecta a la cantidad de lneas de cdigo producidas y estimadas.
Lneas de Cdigo Implementadas y Planeadas

7400 7200 7000 6800 6600 6400 6200 6400 7195
6000
Total Implementado Total Planeado
Figura 12 - Lneas de Cdigo Implementadas y Planeadas
Una problemtica que surgi mientras realizbamos esta evaluacin fue que el mtodo utilizado no permiti diferenciar el tamao en lneas de cdigo del alcance propuesto para cada ciclo de desarrollo. La estimacin de ambos ciclos unidos es prcticamente la misma que la del primero. Esto se debe a que el mtodo est basado en unos rangos muy amplios que no hacen notar las diferencias entre la cantidad de requerimientos total y la de ciclos individuales. Por lo que a futuro sera adecuado proponer un mayor nmero de rangos que asignarle a cada entidad de un modelo conceptual segn la complejidad de sus operaciones y cantidad de atributos. En nuestro caso sin embargo, subestimamos el tamao del producto por un margen no muy alarmante. Las mtricas obtenidas de esta estimacin nos permitirn actualizar los datos histricos para futuras estimaciones y as tener un registro cada vez mayor a partir del cual basarnos para destinar recursos en futuros proyectos.
[15]
Lneas de Cdigo Implementadas y Planeadas por Capa

5000 4500 4000 4262 4385
3500
3000 2500 Implementado Planeado 1243 1038 772
2000
1500 1000 500 0 Capa de Presentacin
1895
Capa de Lgica de Negocio
Capa de Persistencia
Figura 13 - Lneas de Cdigo Implementadas y Planeadas por Capa
En cuanto a la cantidad de lneas de cdigo, de la grfica por capas se puede observar que la capa de presentacin es poco ms del doble de la lgica de negocio. Lo cual, asumiendo que los desarrolladores realizaron su labor segn estndares y prcticas similares de implementacin, podramos hablar de una notable diferencia en nuestra capacidad de materializar el diseo planteado. Nuevamente, esto reflejara el empeo destinado a presentar una interfaz grfica que potencia la usabilidad. Sin embargo, existen mltiples factores que pueden afectar el nmero de lneas de cdigo. Elementos tan simples como la forma en que cada desarrollador organiza su cdigo afecta enormemente esta mtrica. Uno de los temas que debera prevalecer de estas mtricas, es poderlas relacionar con los desarrolladores, la tecnologa utilizada y las funcionalidades que se buscaban implementar favoreciendo ciertos atributos de calidad. En la medida que se estas se puedan relacionar y asociarse con un nmero de lneas de cdigo, se podr realizar una estimacin ms adecuada para futuros proyectos similares al actual. Estas mtricas de lneas de cdigo se tomarn como datos histricos que puedan ser extrapolados a nuevos requerimientos con tecnologas similares y as establecer de una mejor manera el esfuerzo requerido para cada tarea de implementacin. Las siguientes grficas presentan, a manera de estadsticas, otras mtricas de tamao del producto para este ciclo. Estas, acompaadas de la cantidad de lneas de cdigo implementadas serviran como insumo para futuras estimaciones.
[16]
Nmero de Clases Implementadas

15
Capa de Presentacin 52 Capa de Lgica de Negocio Capa de Persistencia 37
Figura 14 - Nmero de Clases Implementadas
Nmero de Mtodos Implementados
155 191 Capa de Presentacin Capa de Lgica de Negocio Capa de Persistencia
234
Figura 15 - Nmero de Mtodos Implementados
No hace falta comentar que la cantidad de clases o de mtodos implementados puede variar notablemente dependiendo de la manera en que cada desarrollador disee y estructure la aplicacin. Por lo que la evaluacin a realizar podra enfocarse ms en la calidad de la estructuracin y diseo realizado, antes que en la cantidad de stas que se hayan desarrollado. El problema que surge entonces es poder medir la manera en que los recursos pueden ser dedicados a mejorar la calidad de los elementos implementados. Otras mtricas como el costo de calidad y sus costos asociados de conformidad y no conformidad, podran ser utilizadas para arrojar algo ms de luz sobre el esfuerzo realmente invertido en materializar esos mtodos y clases.
[17]
2.2.2 Productividad
Teniendo en cuenta la cantidad de lneas de cdigo del sistema y el tiempo invertido en todo el proyecto, calculamos la productividad:
Qu quiere decir esto? Nuevamente el dato por s mismo no dice mucho si no lo relacionamos con un registro histrico de proyectos y de requerimientos y tecnologas involucradas. Podemos decir que es una estadstica que refleja nuestras prcticas como grupo que dise e implement una solucin con ciertas tecnologas bajo ciertas condiciones de aprendizaje (como sucedi con GXT). Ciertamente es una medida relativa al tiempo que como desarrolladores invertimos en codificar los elementos necesarios. Pero ms all de esto, la cantidad de lneas de cdigo y el tiempo requerido para implementarlas son influenciados por decisiones de diseo y aseguramiento de calidad que merecen un mayor anlisis y medicin. A lo largo de la implementacin, se busc minimizar las funcionalidades duplicadas, de tal forma que no tuvisemos que estar replicando cdigo y as dificultar la mantenibilidad de la aplicacin. Por lo que es un tiempo adicional que se invirti en minimizar el nmero de lneas de cdigo. Por otra parte, con el fin de hacer ms legible el cdigo, se implementaron varias instrucciones en lneas separadas, cuando pudo haberse hecho en una sola. De esta forma, nuestras prcticas como desarrolladores influencian esta mtrica de productividad a tal punto que esta contribuir a futuros proyectos en la medida que conservemos dicha actitud haca la implementacin. El factor de satisfaccin del cliente es otro elemento sumamente importante que merece ser tratado segn este enfoque. Lastimosamente, este no es claramente medible, al menos al corto plazo, puesto que est relacionado con el valor agregado que genere nuestro sistema. Solamente conociendo si estas funcionalidades desarrolladas implican valor agregado para los clientes, sabremos si nuestra productividad como grupo, bajo las condiciones en que trabajamos y las prcticas que adoptamos, fue buena o no. Ahora bien, este dato podr ser tenido en cuenta en futuros proyectos para estimar de manera integral teniendo en cuenta no solo el dato per se (cuntas lneas de cdigo resultaron de todo el tiempo invertido), sino para asociarse con todas las condiciones de xito, aseguramiento de calidad y factores tecnolgicos que la acompaan.
[18]
2.3 Tiempos
Esta seccin presenta y analiza la informacin relacionada con el tiempo que como grupo invertimos para llegar al producto obtenido. Se hace inicialmente una evaluacin por integrante y luego se estudia la dedicacin grupal para identificar puntos de mejora.
2.3.1 Planeacin Individual

2.3.1.1 Lder de Grupo
Tiempos por Semana: Jess Vargas

30
25
20 Horas 15 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 Semana Plan Real
Figura 16 - Tiempos por Semana: Lder de Grupo Sem. Plan Real 1 7.5 8.22 2 3.25 4.6 3 8.55 9.24 4 13 13.05 5 13 12.8 6 11.5 11.2 Total 150.27 166.36 7 13.9 13.05 8 11.65 10.85 9 12.9 13.6 10 18.48 21.2 11 17.23 20.73 12 19.31 27.82
Plan Real
Promedio 12.52 13.86
El lder de grupo fue el integrante que ms tiempo tena disponible para el proyecto. Su planeacin fue variando dependiendo de las necesidades de este ciclo, tanto as que al final del periodo fue necesario dedicar ms tiempo del esperado para poder concretar todos los entregables. El inicio del ciclo en cambio fue relativamente de poca planeacin debido a que en esas fases iniciales se estaba puntualizando el proyecto e iniciando labores conjuntas con los dems miembros del grupo.
[19]
2.3.1.2 Lder de Desarrollo
Tiempos por Semana: Andrs Gonzlez

8 7
6
5 Horas 4 3 Plan Real
2
1 0 1 2 3 4 5 6 7 8 9 10 11 12 Semana
Figura 17 - Tiempos por Semana: Lder de Desarrollo Sem. Plan Real 1 4.5 3.6 2 2.75 1.5 3 4.08 3.85 4 4.73 2.15 5 2.65 2.5 6 4.4 3.3 Total Plan Real 49.76 49.8 7 4.6 6.7 8 4.38 6.7 9 4.9 5.2 10 3.48 3.8 11 4.64 4 12 4.64 6.5
Promedio 4.15 4.15
Como se puede ver en las grficas, el lder de desarrollo trabaj menos del tiempo planeado durante las primeras semanas del ciclo. Lo que puede ser seal de subutilizacin del tiempo de ste, o del poco tiempo que ste le dedicaba al proyecto. Sin embargo, hacia la segunda mitad se ve un drstico cambio, enfocado en el cumplimiento del tiempo y la intensificacin del compromiso adquirido.
[20]
2.3.1.3 Lder de Planeacin
Tiempos por Semana: Pedro Feijoo

12 10 8 Horas 6 4 2 0 1 2 3 4 5 6 7 Semana 8 9 10 11 12 Plan Real
Figura 18 - Tiempos por Semana: Lder de Planeacin Sem. Plan Real 1 4.5 6.95 2 3.1 3.3 3 4.9 6.15 4 5.55 4.35 5 5.8 9.3 6 4.81 3.4 Total Plan Real 58.03 70.9 7 4.8 9.65 8 4.65 8.45 9 4.95 4.2 10 5.23 5.05 11 4.35 4.25 12 5.39 5.85
Promedio 4.83 5.91
Se observa segn la grfica de tiempos del Lder de Planeacin, que hubo desfases notorios frente a la primera semana, y en las semanas No 5, 7 y 8. Principalmente, en la primera semana se tuvo el recargo de la planeacin general del ciclo, aparte de problemas asociados a la tecnologa de DotProject en las que ste tuvo que afrontar inmediatamente tareas de Soporte para mitigarlo oportunamente. Por otra parte, la semana No 5 se presentaron sobre-tiempos en las tareas, debido a que siendo sta una semana de terminacin de la etapa de diseo, y viendo la necesidad de comenzar la implementacin en forma, hubo la realizacin de tareas de investigacin y tutora frente a las conexiones dentro del sistema a implementar. Por otra parte, tambin el Lder de Planeacin estuvo presente en decisiones de diseo asociadas al nivel de presentacin del sistema, lo que tuvo como consecuencia la ejecucin de ms tiempos de los planeados en un principio. Por ltimo, las semanas No 7 y 8, correspondientes a la etapa de implementacin, el Lder de Planeacin estuvo a cargo del desarrollo oportuno de componentes WEB, presentandose en dicho desarrollo un sobre-tiempo asociado a la tecnologa de edicin GWT a utilizar. Este sobre-tiempo se visualiza en la grfica anterior.
[21]
2.3.1.4 Lder de Calidad
Tiempos por Semana: Camilo Restrepo

10 9 8 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 Semana
Horas
Plan Real
Figura 19 - Tiempos por Semana: Lder de Calidad Sem. Plan Real 1 4.5 4.58 2 2.25 2.05 3 4.35 4.11 4 5.48 4.72 5 4.73 4.15 6 5.23 5.07 Total 51.60 53.42 7 4.6 9.06 8 4.4 3.5 9 3.55 4.13 10 3.98 3.36 11 4.14 5.03 12 4.39 3.65
Plan Real
Promedio 4.30 4.45
El lder de calidad mantuvo un proceso estable durante gran parte del ciclo. Solamente en una ocasin no le fue posible realizar el trabajo asignado, lo cual pudo reponer adecuadamente a la semana siguiente. En la semana siete cuando nos encontrbamos en la etapa de implementacin se le presentaron inconvenientes con el servidor de aplicaciones GlassFish. A esto fue necesario dedicarle ms tiempo del esperado mientras montaba las herramientas necesarias para trabajar en la lgica de negocio y la persistencia de la aplicacin que fue su principal enfoque.
[22]
2.3.1.5 Lder de Soporte
Tiempos por Semana: Wilson Guarn

10 9 8 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 Semana
Horas
Plan Real
Figura 20 - Tiempos por Semana: Lder de Soporte Sem. Plan Real 1 4 3.45 2 1.75 2.55 3 3.9 4.83 4 5.82 5.7 5 5.06 3.25 6 7.23 9.2 Total Plan Real 53.68 53.99 7 3.9 3 8 4.45 4.95 9 4.4 5.4 10 4.48 2.98 11 4.39 3.89 12 4.3 4.79
Promedio 4.47 4.50
El lder de Soporte tuvo una gran carga en la sexta semana, en la cual empezaba la etapa de implementacin, debido a que como esta era la semana de trabajo individual en la universidad, l quiso aprovechar su tiempo para dedicarlo al proyecto ya que vena de una semana en la que no haba necesitado dedicarle mucho tiempo para cumplir sus tareas y despus venia una semana que iba a tener una alta carga acadmica. Sus tareas eran en general sobre el desarrollo de algunos paneles en la interfaz grfica y averiguar tecnologas para usar junto con GWT para hacer una interfaz ms amigable.
[23]
2.3.2 Planeacin Grupal
Tiempo Planeado vs Real: Grupo

400 395 390 385 380 375 370 365 360 355 350 345 394
Horas
363
Plan
Real
Figura 21 - Tiempo Planeado y Real: Grupo
Tipo de Tarea Planeacin y Seguimiento Implementacin Soporte Reuniones Documentacin Correccin de Defectos Inspecciones Pruebas Miscelneos Total
Plan (horas) 48.90 73.45 4.15 61.00 116.37 9.71 30.15 19.60 0.00 363.34
Real (horas) 46.95 89.15 5.05 51.27 118.43 11.80 29.95 25.67 16.20 394.46
Desfase |Plan Real| 1.95 15.70 0.90 9.73 2.06 2.09 0.20 6.07 16.20 54.89
Porcentaje del Desfase Total 3.56 28.60 1.64 17.73 3.75 3.80 0.36 11.05 29.51
La Figura 21 presenta el desfase entre el tiempo que se haba planeado para este ciclo y el que realmente se invirti. El error porcentual es del 8.5% y entrando en detalle del tipo de tareas realizadas, se hace evidente que buena parte del desfase obtenido fue por causa de tareas de implementacin y miscelneos. Esto reafirma que la falta de conocimiento de las herramientas Web a utilizar fue la causa del tiempo adicional que fue necesario dedicarle a la implementacin. Lo cual, a futuro debe reflejarse en una mejor planeacin dado que ya se conoce mejor la tecnologa y contaramos con este ciclo de antecedente para estimar el tiempo requerido.
[24]
Analizando otros tipos de tareas, es notable que se planearon y dedicaron pocas horas a tareas de soporte. En buena medida, esto caus que el aprendizaje y montaje de las herramientas necesarias para el desarrollo se hiciera a medida que se trabajaba sobre la aplicacin directamente. Teniendo que encargarnos del soporte requerido dentro de las mismas tareas de implementacin elev en gran medida el desfase de este ltimo tipo de tareas. Tambin se invirti un tiempo importante en la correccin de defectos, inspecciones y pruebas. Lo anterior ratifica dos aspectos importantes: nuestra decidida actitud hacia entregables de calidad y el desconocimiento de las actitudes y aptitudes de cada integrante. En lo que concierne al segundo aspecto, por tratarse de la primera vez que trabajamos juntos era de esperarse que no fusemos conscientes de las capacidades de cada uno haca las diferentes tareas. Un ejemplo contundente es la claridad en la escritura y la correcta ortografa. Muchas tareas de correccin fueron necesarias por problemas en la semntica o en la sintaxis de la documentacin.
Tiempos Integrantes del Grupo

180 160 140 120 100 80 60 40 20 0 Jess Vargas Andrs Gonzlez Pedro Feijoo Integrante Camilo Restrepo Wilson Guarn
Horas
Plan Real
Figura 22 - Tiempos por Integrante del Grupo
La Figura 22 muestra la comparacin entre el tiempo planeado y real de cada miembro. El caso del lder del grupo es atpico debido a que deba dedicarle mayor tiempo al proyecto. Su desfase fue causado principalmente por demoras en la implementacin (a causa de la tecnologa) o por inconvenientes de otros integrantes que deban ser tratados. En cuanto a los dems miembros del grupo, ellos deban tener dedicaciones muy similares cercanas a las 48 horas durante el ciclo. Sin embargo, los tiempos que se registraban no eran contabilizados adecuadamente, sino que se basaron mucho en aproximaciones de cada uno. Lo cual, lleva a que los tiempos planeados y reales se vean muy similares.
[25]
2.3.3 Valor Ganado Valor Ganado

450 Tiempo Acumulado (Horas) 400 350 300 250 200 150 100 50 0 1 2 3 4 5 6 7 Semana 8 9 10 11 12 Valor Planeado Valor Ganado Costo Actual
Figura 23 - Valor Ganado
La grfica presentada ilustra el seguimiento en cuanto a reportes en dotProject a lo largo del ciclo realizado. Se evidencia que entre las semanas 1 y 10 hubo un delta de tiempos no reportados oportunamente, ya fuese por descuido de miembros en ciertas etapas, como tambin a la falta de completitud de tareas dentro de una etapa en especfico. No obstante, se ilustra que en la semana 10 se alcanz el total reporte de tareas frente a objetivos y labores cumplidas, aumentando el costo del proyecto. Llegando as, a observar al final del ciclo que dicho costo frente al Valor Planeado alcanz similitud, e igualmente logr superarlo. Por esto ltimo, se puede inferir que el comportamiento de tiempos a lo largo del ciclo es aceptable, siendo el costo del proyecto al final bueno frente a la planeacin efectuada.
Semana Semana 1 Semana 2 Semana 3 Semana 4 Semana 5 Semana 6 Semana 7 Semana 8 Semana 9 Semana 10 Semana 11 Semana 12 Valor Planeado Valor Ganado Costo Actual 25.00 25.00 27.30 38.10 33.10 36.80 63.08 40.20 44.54 98.46 62.65 66.18 129.70 90.21 92.15 162.88 104.05 103.85 182.28 151.88 149.62 224.21 185.73 187.08 254.91 195.38 198.31 290.56 277.21 301.00 325.31 318.11 342.11 363.34 360.14 394.46
[26]
3 Evaluacin del Proceso

Los logros de un producto no pueden ser correctamente estudiados sin tener en cuenta el proceso seguido para llegar a l. Por ello, en esta seccin se analizan los objetivos que se plantearon a nivel grupal, de roles y de cada miembro y se evala el desempeo del grupo respecto a mtricas establecidas al iniciar el ciclo. En cada seccin se hacen comentarios sobre el cumplimiento de cada objetivo y la forma en que este aport a un proceso de desarrollo adecuado.
3.1 Objetivos y Resultados

Esta seccin presenta los objetivos que se plantearon en trminos de grupo, de miembros al interior de este grupo, del proyecto y de encargados de un rol. Cada uno de estos cuenta con mtricas a partir de las cuales establecemos si el objetivo se cumpli o no. Independientemente de si se alcanzaron o no las metas de cada objetivo, a continuacin se analiza la posibilidad de que algunas mtricas o el objetivo en s mismo deban ser replanteados.
3.1.1 Objetivos del Grupo

1. Ser un grupo responsable y eficiente Mtrica 1.1 Ms del 95% de las tareas del proyecto son entregadas a tiempo Resultado No se cumpli con esta mtrica pues hubo muchas tareas que no se entregaron en una fecha inicialmente establecida. Esto debido a que en varias ocasiones la carga de trabajo era elevada y no se poda cumplir con las tareas asignadas. Esta mtrica debemos conservarla ya que es importante enfatizar en nuestra responsabilidad y aunque no tuvimos problemas graves esta vez, en otra ocasin s es probable. Mtrica 1.2 Resultado Ms del 90% de las tareas son realizadas en un tiempo no superior al 120% del tiempo planeado. No se cumpli con esta mtrica puesto que haba tareas que superaban el 200% del tiempo planeado. En ocasiones por problemas con la tecnologa y en otras porque no se tenan en cuenta la complejidad. Debemos conservar esta mtrica e intentar planear mejor el tiempo de las tareas.
2. Ser un grupo puntual Mtrica 2.1 Ms del 90% de las tareas son realizadas en un tiempo no superior al 120% del tiempo planeado. Resultado No se cumpli con esta mtrica puesto que haba tareas que superaban el 200% del tiempo planeado. En ocasiones por problemas con la tecnologa y en otras porque no se tenan en cuenta la complejidad. Debemos conservar esta mtrica e intentar planear mejor el tiempo de las tareas.
[27]
Mtrica 2.2 Resultado
Ms del 90% de las reuniones del proyecto son realizadas dentro de los tiempos establecidos y con al menos el 80% del grupo de trabajo Se cumpli esta mtrica pues todas las reuniones comenzaron a tiempo y solo hubo una reunin en la que falt ms de un miembro. Solamente tuvimos dificultades en este sentido con el lder de desarrollo, que despus de algunas semanas de incumplimiento mostr mayor inters y puntualidad.
3. Desarrollar un producto de alta calidad Mtrica 3.1 Mnimo el 90% de los requerimientos propuestos en el ciclo son desarrollados. Resultado Objetivo logrado, se implementaron los requerimientos en un 100% para las capas de lgica de negocio y persistencia, y en un 80% para la capa de presentacin. Adicionalmente, fue necesario implementar cuatro requerimientos que se haban planteado para un segundo ciclo. Esto ltimo fue causado por el desarrollo de pruebas parametrizables. Mtrica 3.2 Resultado Mnimo 90% de los requerimientos tienen casos de prueba. Se implementaron al menos dos casos de prueba para cada requerimiento teniendo en cuenta como mnimo una situacin de xito y una de fracaso. Dado esto, se puede decir que logramos cumplir la mtrica planteada. Mnimo 90% de las pruebas unitarias implementadas no presenten errores de ejecucin ni compilacin. Objetivo logrado, todas las pruebas fueron superadas.
4. Ser un grupo respetuoso y comunicativo. Mtrica 4.1 100% de los conflictos generados entre pares son resueltos de forma respetuosa y atenta con la colaboracin de los dems miembros del grupo. Resultado Fue posible cumplir esta mtrica pese a los problemas que se presentaron ms que todo con el lder de desarrollo. Estos fueron resueltos de una manera madura y respetuosa, usando el dialogo como mtodo principal.
[28]
5. Realizar un proyecto de forma eficaz y precisa. Mtrica 5.1 El error de estimacin del tamao del producto debe ser menor al 20%. Resultado El error de estimacin fue del 51% con respecto al valor planeado. Esto es muy influenciada por el mtodo que se us para estimar ya que no permita notar variaciones entre cada ciclo (i.e. Estimaciones de LOCs de ambos ciclos eran iguales al del primero). Como tal, no se puede establecer si la mtrica debe conservarse hasta que no se tenga un mtodo de estimacin que detalle ms la relacin entre LOCs y requerimientos funcionales de cada ciclo. Se pueden incorporar nuevos rangos en el mtodo de estimacin utilizado para as tener categoras ms granulares y estimar con ms detalle.
El valor real de horas de trabajo a final de ciclo no puede superar en ms de un 20% las horas de trabajo planeadas. Tuvimos un desfase del 8.5% respecto al total de horas planeadas. Si bien cumplimos esta meta, para futuras ocasiones consideramos que una planeacin adecuada nos permitir manejar menores mrgenes de error.
La fecha de entrega del proyecto no puede superar en ms de 5 das la fecha planeada. No fue posible realizar la entrega del producto de este ciclo para la fecha planeada inicialmente (primera semana de Octubre). Se dialog con los clientes sobre el trabajo realizado y estuvieron de acuerdo en que la calidad primaba por encima de una entrega rpida. Por lo que se ampliaron los plazos de este ciclo.
3.1.2 Objetivos del Proyecto

1. Desarrollar un producto de alta calidad que se fundamente en un proceso de desarrollo consistente. Mtrica 1.1 Al menos el 90% de las decisiones tomadas en el proceso de desarrollo se pueden observar en la implementacin realizada. Resultado Se cumpli, pues toda decisin tomada en el proceso de desarrollo aport de alguna forma a la implementacin de la aplicacin. Para futuras ocasiones es conveniente especificar ms esta mtrica a un conjunto definido de decisiones que deban verse reflejadas en el producto obtenido.
Mtrica 1.2
Aplicar al menos el 95% de los estndares de calidad planteados durante el proyecto para asegurar un producto adecuadamente documentado, funcional y administrable.
[29]
Resultado
Se cumpli esta mtrica, pues toda idea que surga para mejorar la calidad de los entregables era aplicada inmediatamente. Al ser un proyecto de ejemplo para los siguientes semestres nos parece primordial la calidad y que realmente se puedan basar en lo que hemos hecho.
2. Desarrollar un sistema que cumpla las expectativas tanto funcionales como no funcionales del cliente. Mtrica 2.1 El anlisis y diseo reflejan al menos el 95% de requerimientos funcionales que ha planteado el cliente. Resultado Lo cumplimos ya que los requerimientos funcionales son parte fundamental de las expectativas del cliente respecto al producto. Buena parte del tiempo que le dedicamos a nuestro diseo fue buscando plasmar estas necesidades y proponer estrategias que llevasen a una implementacin adecuada de los mismos. Mtrica 2.2 Los modelos presentados en la etapa de diseo comunican claramente la toma de decisiones respecto a los requerimientos no funcionales que se identificaron como prioritarios. No se estableci una medida para determinar si se cumpli o no esta mtrica puesto que requiere de un anlisis ms detallado teniendo en cuenta los escenarios de calidad.
Resultado
3. Entregar un sistema en el que prime la modificabilidad para facilitar la labor de futuros desarrolladores. Mtrica 3.1 El anlisis y diseo hacen nfasis en darle prioridad a la facilidad de modificar los artefactos a construir. Resultado Se alcanz esta mtrica pues al momento de disear la aplicacin se tuvo presente estrategias como el desacoplamiento en las responsabilidades de los componentes, una codificacin que permitiera mayor legibilidad y un manejo de eventos en la parte Web para comprender el flujo de actividades.
4. Cumplir con los plazos de tiempo estipulados Mtrica 4.1 El nmero de artefactos de alta prioridad entregados en una fecha posterior a la planeada debe ser igual a 0. Resultado No se cumpli esta mtrica puesto que no se contaba con suficiente tiempo para cada uno de los artefactos, es por eso que la implementacin tom ms tiempo del esperado. Es necesario especificar esta mtrica y limitarla a un grupo puntual de artefactos para mejorar su evaluacin.
[30]
3.1.3 Miembros
1. Hacer uso adecuado del tiempo disponible. Mtrica 1.1 Tiempo invertido en actividades no relacionadas con el proyecto durante una reunin grupal debe ser menor o igual a 2 minutos. Resultado No se cumpli esta mtrica debido a que en muchas varias ocasiones se hacan comentarios jocosos o se presentaban distracciones y aunque fueran interrupciones cortas, sumadas superaban este tiempo. Creemos que esta mtrica no la debemos volver a utilizar ya que un poco de distraccin ayuda con el trabajo ameno y a disminuir los niveles de estrs. Mtrica 1.2 Resultado Tiempo que toma identificar que no es posible realizar una tarea menor o igual a 10 minutos. S se cumpli gracias a que pocas tareas no eran posibles de realizar, y cuando las haba, eran identificadas inmediatamente. No creemos que se deba mantener esta mtrica ya que no aporta mucho al objetivo.
Nmero de tareas repetidas o trabajos duplicados por cada ciclo debe ser menor o igual a 4. Esta mtrica no se cumpli ya que las tareas duplicadas fueron demasiadas debido a que en ocasiones esta no se haca en varias oportunidades y era necesario replantearla. Por ejemplo, con algo tan elemental como el glosario de trminos.
2. Asumir responsabilidad con respecto al trabajo que se realiza en grupo. Mtrica 2.1 Nmero de trabajos o tareas con entrega atrasada menor o igual a 10. Resultado Esta mtrica no se cumpli, pues fcilmente hubo aproximadamente 25 tareas entregadas con retrasos. Esto debido a que todos los miembros del grupo tuvimos una alta carga acadmica y por este motivo no se poda cumplir para la semana correspondiente, aunque compensbamos el tiempo en la semana siguiente. Mtrica 2.2 Resultado Nmero de trabajos o tareas entregadas mal hechas o con errores evidentes menor o igual a 5. Esta mtrica tampoco se cumpli, pues varios miembros del grupo tenan problemas como no tener claro en ocasiones lo que se deba entregar o en otros casos se dejaba para ltima hora y por hacerlas sin el tiempo necesario quedaban mal hechas. Nmero de veces que se incumple con la palabra con respecto a lo que se dice sobre el trabajo menor o igual a 5. Esta mtrica se cumple ya que la honestidad fue algo fundamental durante el proceso, y aunque no se hicieran las tareas, los miembros dijeron en algn momento que no iba a ser posible realizarlas.
[31]
3. Ser miembros proactivos Mtrica 3.1 Nmero de opiniones por cada decisin tomada en las reuniones debe ser mayor o igual a 1. Resultado Esta mtrica se cumpli ya que cada decisin que se tomaba en las reuniones era comentada y debatida por al menos un miembro. Sin embargo, para futuras ocasiones, es importante fomentar la participacin de ms miembros en estas discusiones.
Mtrica 3.2 Resultado Cantidad de iniciativas tomadas, discutidas y documentadas debe ser mayor o igual a 3 por reunin. Se cumpli ya que en cada reunin se llevaron a cabo debates o sugerencias para el proyecto por parte de los miembros del grupo. A su vez, el lder de calidad documentaba estas discusiones en la minuta semanal.
3.1.4 Objetivos por Roles 3.1.4.1 Lder del Grupo

1. Estar al tanto de los avances en las actividades que realiza el grupo para asegurar el cumplimiento de las fechas establecidas. Mtrica 1.1 Asegurarse que todos los miembros del equipo tengan una lista claramente definida de tareas al terminar la reunin de seguimiento. Nmero de tareas sin asignar al finalizar la reunin menor al 10% del total de tareas Resultado Antes de cada una de estas reuniones se realizaba una evaluacin de las tareas desarrolladas durante la semana y se planeaban las actividades para la siguiente. Estando en la reunin esta planeacin inicial se modificaba segn lo discutido con el grupo, de tal forma que al final de ella, cada miembro ya conoca todas sus tareas.
Mtrica 1.2
Mantener una comunicacin clara y continua con los integrantes durante la semana. Nmero de tareas que se hagan sin que los dems sean conscientes menor al 5% del total de tareas Despus de cada reunin semanal los miembros podan observar un consolidado de todas las tareas planeadas para la semana. Por lo que s eran conscientes de las tareas inicialmente planteadas. Sin embargo, en ms de una ocasin se dej de lado el seguimiento de tareas de algunos miembros y si estos no comentaban sobre sus avances, llegbamos al punto en que posiblemente la tarea se desarrollaba errneamente y era necesario planear tiempo para revisiones adicionales o repeticiones de la tarea.
Resultado
[32]
2. Moderar efectivamente las reuniones del equipo Mtrica 2.1 Presentar y mantener un orden de actividades a realizar durante la reunin. Nmero de miembros que desconocen el orden a seguir de la reunin es 0 Resultado No todas las reuniones tuvieron el mismo orden, pero en general las actividades giraron en torno a comentar sobre las tareas realizadas y discutir las nuevas a realizar con base en un plan inicial propuesto por el lder del grupo. Todos los miembros del grupo se acoplaban al orden propuesto para el momento.
Mtrica 2.2
Resultado
Promover la participacin activa y constructiva de los dems miembros. Nmero de intervenciones de cada miembro es mayor o igual a 1 por cada tema a tratar No siempre participaban todos los miembros en las discusiones que surgan durante cada reunin. En algunas ocasiones fue necesario llamarle la atencin a algunos miembros para que por el contrario dejaran de hablar sobre temas no relacionados.
3. Gestionar un ambiente de trabajo adecuado al interior del grupo Mtrica 3.1 Las dificultades al interior del grupo que deterioren la calidad del trabajo debern ser tratadas en menos de 24 horas despus de presentado el inconveniente Resultado Este tipo de problemas se presentaron en repetidas ocasiones con el lder de desarrollo. En la mayora de las ocasiones se hablaba con l directamente o se le enviaban correos lo antes posible. Si la tarea era de alta prioridad, se tomaba accin de forma inmediata. Aun as, esa necesidad de estar llamndole la atencin frecuentemente llev a la conclusin de que era mejor asignarle tareas de las cuales no dependiera ninguno de los dems integrantes.
3.1.4.2 Lder de Desarrollo

1. El diseo del sistema estar correctamente planificado. Mtrica 1.1 Nmero de clases implementadas del diseo original mayor al 95%. Resultado Se logr el objetivo, sin embargo algunas clases adicionales fueron implementadas de acuerdo a como se mova el proceso de implementacin. La mtrica demuestra tener utilidad como una medida de desempeo y como una forma de medir la calidad de nuestro trabajo en comparacin con la planeacin realizada, adicionalmente nos permite saber que tan bien estamos haciendo estimaciones y cmo podramos modificar nuestras metodologas de acuerdo a los desfases y al objetivo planteado, se recomienda mantener la mtrica en prximos ciclos.
[33]
Nmero de clases adicionales que se implementen en el sistema y no se encuentren en el diseo original menor o igual a 3 El objetivo no fue logrado dado que la cantidad de clases adicionales fueron superiores a las 3 que tena el objetivo como rango de aceptacin. La mtrica no demuestra ser lo suficientemente diciente ya que 3 clases diferentes al diseo original es un caso muy posible, por lo tanto, el hecho de cumplir o no esta mtrica no nos sirve para definir bondades o debilidades acerca de nuestro trabajo como grupo. Se recomienda no mantener esta mtrica en ciclos futuros. Relaciones y requerimientos funcionales asignados a cada clase implementados segn el diseo original >90%. Se cumpli el objetivo dado que el desarrollo estuvo siempre basado en el diseo original, adems, la mayora de los cambios fueron enfocados a agregaciones ms no modificacin o eliminacin de componentes del diseo original. La mtrica permite establecer si estamos cumpliendo con las relaciones planeadas, lo cual, junto con la mtrica de clases implementadas (M1.1) nos permite medir la calidad de estimacin de nuestro grupo. Se recomienda mantener la mtrica en ciclos futuros. Nmero de prototipos de interfaz grfica presentados para elegir en consenso por el grupo mayor o igual a 3. El objetivo no se cumpli dado que no hubo suficientes prototipos de interfaz. Se recomienda no usar a futuro esta mtrica dado que como se vio durante el ciclo, tener muchos prototipos de interfaz puede resultar en un manejo ineficiente de los recursos del proyecto, principalmente manifestado en prdida de tiempo. Sin embargo, se puede proponer que se manejen varias propuestas de elementos puntuales de la interfaz grfica, ms que una propuesta completa.
2. El diseo original garantiza un estndar de calidad bueno. Mtrica 2.1 Desarrollo de requerimientos funcionales y no funcionales solicitados para el sistema mayor al 90%. Resultado El objetivo se logr dado que siempre hubo especial atencin a los requerimientos no funcionales, adems los requerimientos funcionales implementados fueron de un 100% en capas de lgica y de persistencia y aproximadamente un 80% en capas de presentacin (interfaz).Con esta mtrica pudimos medir que tan bien estamos cumpliendo con los requerimientos propuestos al inicio del ciclo, y a futuro nos sirve para mejorar la estimacin de tiempo y requerimientos a desarrollar. Se recomienda mantener la mtrica para futuros ciclos.
[34]
Cubrimiento de casos de prueba planteados para los requerimientos funcionales mayor al 90%. El objetivo no fue cumplido dado a restricciones de tiempo, sin embargo si hubo planeacin de pruebas para los requerimientos ms importantes. Esta mtrica demostr no ser lo suficientemente diciente y no se entiende claramente su propsito, se recomienda a futuro si se desea utilizar la mtrica que se haga una revisin de su propsito. Nmero de elementos de la interfaz grfica introducidos segn el diseo aprobado por consenso del grupo mayor al 90%. Objetivo logrado, se implement aproximadamente el 90% de los requerimientos propuestos de interfaz. Esta mtrica nos ayuda a definir en qu nivel somos fieles a los diseos originales en cuanto a interfaz. Se recomienda mantener esta mtrica a futuro.
3. La etapa de desarrollo del software se plantear de manera que garantice el cubrimiento total de los requerimientos solicitados. Mtrica 3.1 Desfase en los requerimientos planificados para cada ciclo menor al 10%. Resultado Objetivo logrado, dado que en este ciclo se lograron implementar ms del 90% de los requerimientos propuestos. Esta mtrica, al hacer la evaluacin de sus resultados demostr ser muy similar a otras mtricas que ya miden el nivel o porcentaje de requerimientos implementados en relacin a los propuestos, se recomienda eliminar esta mtrica dado que ya existen formas de evaluar algo similar.
4. El proceso de desarrollo del software estar guiado por mecanismos que garanticen un producto de calidad. Mtrica 4.1 Nmero de pruebas automatizadas implementadas en el prototipo final de cada ciclo, para cada requerimiento implementado mayor o igual a 1. Resultado Objetivo no logrado, dado que se implementaron pruebas nicamente a los requerimientos ms importantes. Esta mtrica es muy til para medir la cobertura de pruebas de nuestros requerimientos, sin embargo, es posible que ya existan mtricas similares, se recomienda entonces, si se va a usar la mtrica en el futuro, que se haga una definicin ms clara de sus objetivos y medidas de desempeo a evaluar.
Desarrollar cdigo mantenible - Nmero de clases, atributos y mtodos documentados igual al 90%. Objetivo logrado, actualmente se tiene ms del 90% del cdigo documentado.
[35]
Desarrollar cdigo mantenible - Porcentaje de cdigo escrito segn el estndar de codificacin de Sun = 100%. Objetivo logrado, ms del 90% del cdigo est basado en el estndar de Sun. Estas mtricas fueron tiles para medir la calidad del cdigo implementado, se recomienda seguirla usando en el futuro y, de ser posible, aumentar la exigencia de cubrimiento.
3.1.4.3 Lder de Planeacin

1. Tener correcta estimacin de tiempos y tareas por miembro para el ciclo. Mtrica 1.1 El porcentaje de tareas desfasadas temporalmente ser menor al 10% del total de tareas planeadas para el ciclo. Entindase por tarea desfasada, aquella tarea que no fue realizada por el miembro encargado, dentro del horario laboral estipulado en la planeacin especfica. Resultado El objetivo no se cumpli, dado a que el desfase presentado entre tareas para el Ciclo No 1 supera el 20%.
Por etapa, el nmero de tareas que estimen un valor temporal superior a 1.5 horas, ser menor a 2. El objetivo no se cumpli, debido principalmente a que para la etapa de implementacin se efectu la planeacin de tareas que superaban 3 horas para su desarrollo. Esto ltimo, debido a que dichas tareas no fueron posibles de atomizar an ms.
2. Notificar a tiempo las tareas a los miembros del grupo Mtrica 2.1 Al terminar el ciclo, el porcentaje de tareas notificadas a miembros tardamente ser menor al 10%. Entindase por tarea notificada tardamente aquella tarea que es actualizada en dotProject (u otra herramienta de comunicacin diferente) en un lapso superior a 1 hora de haberse efectuado la planeacin especfica bajo decisin unnime grupal. Resultado El objetivo se cumpli, mas no por la actualizacin oportuna de tareas en dotProject, dado a que para dicha actualizacin se hizo uso en totalidad de la informacin plasmada en la minuta semanal. Igualmente el 100% de tareas pactadas en cada reunin semanal fue comunicado en dotProject, como tambin puesta en marcha desde la misma reunin.
3. Llevar correcto seguimiento de tareas realizadas y por realizar. Mtrica 3.1 Al terminar el ciclo, el porcentaje de tareas no notificadas a tiempo en dotProject ser menor al 5%. Entindase por tarea no notificada aquella tarea ya finalizada que no ha recibido su detallado reporte en dotProject.
[36]
Resultado
El objetivo no fue cumplido, debido principalmente que hubo reorganizacin de tareas dentro del grupo dado el incumplimiento laboral en ciertas etapas por parte de algunos miembros. Esto conllev a que hubiese logs vacos en dotProject, siendo stos en porcentaje poco superiores al 10%.
3.1.4.4 Lder de Calidad 1. Todos los miembros hacen uso y seguimiento adecuado del proceso TSP para lograr un trabajo de calidad. Mtrica 1.1 Porcentaje de etapas del proceso TSP alcanzadas es del 100%. Resultado Nos encontramos en la etapa de Post Mrtem. Todas las etapas del proceso de desarrollo se han completado exitosamente, es decir, que se tiene una documentacin pertinente de cada entregable. Aunque nos tomamos ms tiempo en algunas etapas, logramos unos entregables completos y de calidad.
Calificacin de la calidad del proyecto mayor a 4 Todava no hemos obtenido la nota por lo que no se puede concluir.
2. Coordinar el proceso de inspeccin en cada una de las etapas del proceso. Mtrica 2.1 Porcentaje de reportes de inspeccin en cada etapa del proceso mayor al 90%. Resultado Las inspecciones se realizaron en la etapa de anlisis y diseo. No se hicieron inspecciones sobre todos los entregables. En la etapa anlisis se hicieron inspecciones sobre la documentacin de los casos de uso y los diagramas de secuencia. De catorce casos de uso documentados se hicieron catorce listas de chequeo, una para cada caso de uso. En cuanto a los diagramas de secuencia, se hicieron diez diagramas, cada uno con su lista de chequeo completa. En la etapa de diseo se hicieron inspecciones sobre las justificaciones de diseo, los diagramas del punto de vista funcional y los diagramas de secuencia. Ms detalladamente, se documentaron cuatro justificaciones de diseo. Sobre cada una de estas se hizo una lista de chequeo. Se produjeron diez diagramas del punto de vista funcional y se hicieron nueve listas de chequeo. No se realiz lista de chequeo sobre el diagrama de entidades. Por ltimo, se documentaron los mismos diez diagramas de secuencia, de forma ms detallada, y se hizo una lista de chequeo por cada uno de los diagramas documentados. En resumen, se hicieron 24 entregables en anlisis y 24 en diseo. En la etapa de anlisis se hizo el 100% de las inspecciones y en diseo el 96% de las inspecciones. En total se realizaron el 98% de las inspecciones. Dado lo anterior se puede decir que se obtuvo un porcentaje superior al
[37]
90% en cada una de las etapas y por lo tanto se cumpli con el objetivo.
3. Asegurar que la documentacin del proyecto est completa y disponible en todo momento. Mtrica 3.1 Porcentaje de reportes completos y corregidos elaborados por los miembros del equipo es del 100%. Resultado Antes de realizar el reporte se encontraron errores de redaccin y ortografa en los reportes semanales y en las minutas. Estos errores ya fueron corregidos y se obtuvo un 100% de reportes completos y corregidos. Mtrica 3.2 Resultado Porcentaje de reportes subidos a la Wiki del grupo es del 100%. Todos los reportes semanales estn completos y disponibles en la Wiki del grupo. Por lo tanto, este objetivo se cumpli. Porcentaje de reuniones adecuadamente documentadas y visibles en la Wiki del grupo es del 100%. Se realiz una minuta por cada reunin realizada a lo largo de este ciclo. La minuta de cada una de las reuniones est documentada y disponible en la Wiki del grupo. Por lo tanto, este objetivo se cumpli.
3.1.4.5 Lder de Soporte

1. Dar a conocer las herramientas necesarias para desarrollar el proyecto y su uso a todos los miembros del grupo. Mtrica 1.1 Proveer de tutoriales al grupo por lo menos sobre una de las tecnologas nuevas sobre las que se va a trabajar. Resultado Se dio a conocer un tutorial sobre GWT al grupo pues algunos no conocan esta herramienta, por eso se cumpli esta mtrica. Sin embargo, hizo falta un mayor seguimiento de las problemticas que se presentaban en torno a estas. En futuras ocasiones ser necesario adelantarse a las necesidades que puedan surgir para as estar preparado. Mtrica 1.2 Resultado Retraso grupal debido al desconocimiento de nuevas tecnologas por parte de alguno de los miembros debe ser menor a igual a 5 tareas. Se cumpli esta mtrica debido a que, aunque estuvo presente el retraso por desconocimiento de tecnologas, ninguno de los miembros alcanz a retrasar al grupo entero en ms de cinco tareas. Lo que se buscaba con esta mtrica era precisamente que ningn miembro perjudicara al proyecto por problemas con la tecnologa. Sin embargo, lo que se present fue ms un retraso generalizado antes que uno por culpa de un miembro especfico.
[38]
2. Proveer soporte de calidad a tiempo para los problemas tecnolgicos que enfrente el grupo. Mtrica 2.1 Solucionar ms del 90% de las dudas de los integrantes del grupo con respecto a las nuevas tecnologas. Resultado Durante el ciclo solo se recibi una duda del lder de calidad sobre dotProject y lo contact con una persona que conoca esa herramienta a la perfeccin. En general, los miembros del grupo preferan solucionar por su cuenta sus problemas, por eso se cumpli esta mtrica. Mtrica 2.2 Resultado
Nmero de incidentes sobre el correcto desarrollo del trabajo debido a errores tecnolgicos, debe ser menor o igual a 5. Esta mtrica no se cumpli debido a que como se ha venido tratando a lo largo del documento, los retrasos sumados de todos los miembros del grupo supera esta cantidad.
3. Generar planes de contingencia y de mitigacin adecuados para controlar los riesgos que se puedan presentar. Mtrica 3.1 Nmero de trabajos retrasados debido a riesgos mal recibidos es menor a igual a 5. Resultado Esta mtrica se cumpli porque, aunque debido a que uno de los riesgos era la sobrecarga de tareas sobre los diferentes lderes y ese fue uno de los casos de retraso ms comunes, no alcanz para que superara esta cantidad.
Nmero de errores sobre los trabajos debido a riesgos no planeados es menor o igual a 3. Se cumpli debido a que los errores en los trabajos no fueron por culpa de ningn riesgo no planeado.
[39]
3.2 Balance de Estrategias

Para el proceso seguido se plantearon una serie de estrategias que guiaran las actividades a realizar durante el desarrollo de la aplicacin. En esta seccin se evala cada estrategia para establecer su utilidad y puntos de mejora al momento de aplicarlas.
3.2.1 Estrategia General

3.2.1.1 Seguir un proceso iterativo e incremental Estrategia: Para asegurar el cumplimiento de las expectativas de los clientes y de minimizar la complejidad en posibles cambios a realizar, se seguir un esquema de entregas parciales. Cada una de estas contar con una serie de funcionalidades que sern evaluadas por los clientes para asegurar que el proyecto se encuentra adecuadamente encaminado en trminos de sus necesidades. En caso de ser necesaria alguna modificacin importante, el impacto sobre los dems elementos desarrollados no ser tan elevado comparado a si se realiza una entrega completa. Anlisis y resultados: La implementacin de esta estrategia fue uno de los puntos clave y ejes fundamentales en el ciclo, durante el desarrollo de este se planteaban tareas especficas y concretas que hacan parte de tareas ms grandes y complejas. Esta asignacin de tareas de forma granular permita una constante revisin por parte de los miembros del grupo para as poder identificar si el resultado que se iba obteniendo satisfaca las necesidades del cliente y las expectativas de los miembros del grupo, de lo contrario, se proceda a hacer una correccin adecuada de acuerdo a las crticas y retroalimentaciones recibidas. La estrategia de trabajo basado en entregas parciales permita asimilar rpidamente y de forma eficiente los cambios exigidos por los clientes, facilitando el proceso y permitiendo flexibilidad en la toma de decisiones. En general la estrategia fue adecuada y se recomienda ampliamente utilizarla para ciclos futuros, sin embargo, se debe considerar una modificacin enfocada en hacer un mayor seguimiento de tareas. Se debe hacer mayor control entre miembros del grupo para no caer en inconsistencias ya que la posibilidad de caer en problemas de coherencia entre entregas poda dar lugar a correcciones innecesarias, un pequeo ejemplo para este ciclo fue el nombramiento de entidades o elementos de diseo, los cuales podan tener nombres o funcionalidades diferentes. 3.2.1.2 Metodologa Team Software Process Estrategia: Se ha decidido utilizar TSP para aprovechar la clara estructuracin de roles y etapas que propone esta metodologa, y por las que debera pasar un proceso de desarrollo. En el lapso de tiempo disponible para la realizacin del proyecto, esta metodologa provee una serie de actividades que potencian un adecuado seguimiento, ejecucin y evaluacin de las tareas de desarrollo a realizar. Anlisis y resultados: Durante este ciclo fue evidente el uso de TSP. El proceso de desarrollo basado en entregas concretas y con un plan estructurado de desarrollo permiti tener un producto terminado de calidad y, de igual manera, el constante registro de trabajo basado en planeacin de tareas especificadas y enfocadas al rol de cada miembro permiti tener el resultado de nuestro trabajo totalmente documentado, lo que facilita no
[40]
solo su revisin en busca de errores o mejoras, sino que permite tener un proyecto altamente modificable debido a la facilidad de realizar cambios en el producto final gracias al fcil entendimiento, adecuada documentacin y estructura del proceso desarrollado. Las etapas del ciclo permitieron tambin tener un desarrollo incremental de nuestro producto final, que nos permita tomar decisiones en cada etapa soportndonos en el proceso realizado en etapas anteriores, etapas enfocadas en abordar distintos problemas de la solucin final, como diseo, estrategias de grupo, implementacin, entre otros. Esto nos permiti incrementar poco a poco y de forma segura nuestra perspectiva acerca del producto que debemos desarrollar, dando como fruto el desarrollo de una aplicacin adecuada y capaz de satisfacer las necesidades de nuestros clientes. Es recomendable continuar con este mtodo, sin embargo, la implementacin de tcnicas de desarrollo giles pueden ser de gran utilidad en semanas de implementacin. 3.2.1.3 Dos ciclos de desarrollo Estrategia: Dado el tiempo disponible para realizar la entrega del sistema, se realizar el desarrollo de la aplicacin en un marco de dos ciclos. Cada uno de estos contar con sus respectivas etapas y entregables claramente definidos para cumplir las expectativas del cliente. Anlisis y resultados: Esta estrategia no pudo ser completada dado el tiempo real que se tena para hacer el desarrollo del proyecto. Se tenan estimados dos ciclos para este semestre, sin embargo, dado que no se dispona con mucho tiempo para realizar el ciclo, y nuestra necesidad de tener un ciclo con entregables de calidad, nos limitamos a realizar slo uno. 3.2.1.4 Sistema con calidad de produccin Estrategia: El resultado de estos dos ciclos deber ser un sistema capaz de desplegarse y sostener un funcionamiento adecuado teniendo en cuenta las circunstancias en las que debera funcionar como acceso de mltiples clientes concurrentes y capacidad de modificacin para agregar nuevas caractersticas al producto. Anlisis y resultados: Como se dijo anteriormente, no se pudieron realizar dos ciclos, sin embargo el producto implementado cumple con todas las funcionalidades de forma adecuada, con los atributos de calidad propuestos y flexibilidad para realizar cambios sobre esta, haciendo que se cumpliera el propsito general de esta estrategia, la cual se sugiere debe seguirse implementando dado que permite tener un objetivo sobre la aplicacin a desarrollar, objetivos que no solo se limitan al cumplimiento de los requerimientos funcionales.
3.2.2 Estrategia Especfica

3.2.2.1 Anlisis Estrategia: Con la ayuda del cliente se proceder a levantar la informacin que permita comprender la totalidad del mundo del problema resolviendo y entendiendo las necesidades del usuario haciendo uso preciso de casos de uso.
[41]
Anlisis y resultados: La comunicacin constante con el cliente consultando y pidiendo retroalimentacin acerca del proceso y de nuestra perspectiva de lo que debe ser el producto final permitieron tener un producto muy cercano a las necesidades de este, permitiendo no solo aprovechar de forma eficiente el tiempo del ciclo, sino evitando problemas de entendimiento del problema y de esa forma no realizar un proyecto de forma errnea. La implementacin de esta estrategia es muy importante y debe seguirse realizando para futuros ciclos, dado que propicia un ambiente de colaboracin entre clientes y desarrolladores en donde a partir de crtica constructiva y retroalimentacin se mejoran cada vez ms el producto final y el proceso de desarrollo que lo rodea. 3.2.2.2 Diseo Estrategia: Teniendo en cuenta el anlisis previo de la informacin obtenida, junto con los requerimientos funcionales y los atributos de calidad se proceder a disear los diferentes componentes de la aplicacin. Cada componente debe tener una responsabilidad bien definida y debe, en alguna medida, favorecer los atributos de calidad ya definidos. Dado que la etapa de implementacin depende fuertemente de esta etapa, se tendrn que realizar diagramas para especificar los componentes, paquetes y clases del sistema de tal forma que se ajusten lo mejor posible a la aplicacin. Esto con el fin de evitar retrasos en el cronograma de implementacin. Es muy importante poder disear teniendo como prioridad la modularidad del sistema con el fin de poder dividir el trabajo de desarrollo entre los miembros. Anlisis y resultados: El resultado de la etapa fue tener una aplicacin que no se diferenciaba mucho del diseo propuesto, esto se debe a que la etapa de diseo y en general todos los procesos enfocados a la profundizacin de nuestra idea de cmo debe ser la aplicacin real fueron realizados buscando la satisfaccin del cliente. Para la etapa de diseo se procedi a concretar todas las ideas que tena el grupo acerca de la aplicacin y definir claramente el camino a seguir la implantacin de esta, se procedi entonces a realizar los diagramas pertinentes y los planes de implementacin a seguir. El resultado es evidencia de la importancia de esta etapa y de su uso como estrategia especfica del equipo para dirigir sus esfuerzos, es importante seguir con su uso en ciclos futuros y mejorar paso a paso este proceso para tener mejores diseos acordes con la realidad. 3.2.2.3 Implementacin Estrategia: Para el desarrollo de esta fase la idea es asignar responsabilidades muy especficas. A cada miembro del grupo se le asignar trabajo de desarrollo equitativamente teniendo en cuenta la especializacin y la disponibilidad de cada uno. Dependiendo de la experiencia y conocimiento de cada integrante se pueden distribuir las tareas de implementacin para facilitar el desarrollo. El lder de desarrollo debe velar porque la estructura del diseo se mantenga a la hora de la implementacin. Anlisis y resultados: Esta estrategia, si bien no fue aplicada al pie de la letra, fue una referencia importante en la implementacin dado que se busc la asignacin de tareas especializadas y enfocadas a la disponibilidad de cada miembro, explotando habilidades y
[42]
conocimientos. Sin embargo, el seguimiento del diseo propuesto estuvo ms que todo a cargo del lder del grupo y no del lder de desarrollo, el cual, dado que tena ms cantidad de tiempo estuvo a cargo de gran parte de la implementacin, lo que le permita tener control sobre lo que se haca. La aplicacin de esta estrategia fue exitosa en general, se lograron tener la gran mayora de los componentes de la aplicacin a tiempo y con las funcionalidades requeridas, por lo cuales recomienda usarla en el futuro. 3.2.2.4 Pruebas Estrategia: Las pruebas se desarrollarn paralelamente a la implementacin de los requerimientos funcionales. La idea en este punto es atacar los riesgos de mayor impacto e identificar y corregir los errores al momento de terminar la implementacin de cada requerimiento funcional en orden de prioridad. El lder de desarrollo debe verificar los casos de prueba para cada requerimiento y la implementacin de los mismos. El lder de calidad debe velar por la estandarizacin a la hora de escribir las pruebas. Anlisis y resultados: La estrategia de pruebas tambin tuvo un cambio en su forma de implementacin dado que el lder de desarrollo tuvo mayor influencia en la implementacin de estas. Sin embargo, las pruebas implementadas mostraron ser coherentes con los requerimientos que requeran una verificacin de que se estaban comportando de manera correcta. Esta implementacin de pruebas nos permiti encontrar posibles casos de prueba en que el cdigo implementado poda fallar, lo cual nos ayud a corregir a priori posibles problemas de implementacin. Se recomienda revisar esta estrategia dado que su uso tuvo problemas a la hora de planificar las pruebas a realizar, dado que hubo un poco de desorden en su planificacin, y aun siendo satisfactorio el resultado, esta planificacin debe tener mejor estructura para lograr mejores resultados. 3.2.2.5 Comunicacin Estrategia: En este punto se definen dos elementos importantes. Por un lado, se define la comunicacin entre los miembros del grupo. Para esta comunicacin el lder de soporte propuso utilizar Google Wave puesto que ya lo haba utilizado en proyectos anteriores y fue un mecanismo exitoso. Por otro lado, se define la comunicacin con los clientes. Se deber mantener una comunicacin constante (semanal) con ellos para evitar el desarrollo de una aplicacin o de funcionalidades que no satisfacen las necesidades de los mismos. Anlisis y resultados: La estrategia de comunicacin demostr ser exitosa, ya que adems de tener un canal de comunicacin, tambin permita tener una plataforma de colaboracin y revisin de comunicacin, lo que facilitaba el trabajo, la consulta de responsabilidades, y la bsqueda de ayuda en caso de que algn miembro no supiera como hacer una tarea. Sin embargo, este mtodo de comunicacin tena problemas a la hora de controlar que los miembros del grupo estuvieran realmente informados acerca de nuevas noticias sobre el proyecto, dado que cada uno deba registrarse y buscar en la plataforma por nuevas noticias, lo que haca que no fuera seguro que todos los mensajes llegaran con la misma efectividad a todos los miembros del grupo.
[43]
Se recomienda revisar formas de controlar la consulta de informacin por parte de cada miembro. El uso de este tipo de plataformas de trabajo ser recomienda sea implementado en otros ciclos dada la facilidad de colaboracin.
3.2.3 Estrategia de Aseguramiento de Calidad

3.2.3.1 Modelo en V para pruebas Estrategia: Dependiendo de la etapa del ciclo en que se encuentre el proyecto, se disearan las pruebas sobre los entregables ms importantes. Durante la etapa de anlisis se definirn las pruebas de aceptacin con base en las cuales se evaluar si el producto entregado corresponde a las demandas del cliente. En cuanto a la etapa de diseo, se plantearan pruebas de integracin de los diferentes componentes del sistema. Por ltimo, en la etapa de implementacin, se desarrollarn las pruebas unitarias sobre los mtodos ms crticos de la aplicacin. Anlisis y resultados: Si bien hubo un desarrollo del modelo en V, este fue realizado durante la etapa final del ciclo, es decir se realizaron pruebas de aceptacin, integracin, unitarias, y dems tipos de pruebas de acuerdo con el modelo en V, pero estas pruebas fueron diseadas durante el final del ciclo, lo cual no se ajusta a nuestra estrategia inicial de realizar estos tipos de prueba durante el desarrollo del mismo. Para el futuro se espera poder implementar esta estrategia de una forma completamente ajustada a nuestros objetivos y metodologa, en donde se plantea que cada una de las pruebas sea realizada durante la etapa que corresponde realizarla. Esta estrategia vale la pena mantenerla en el futuro ya que nos permite tener un lineamiento de cmo hacer pruebas de distintos tipos de forma correcta. Sin embargo, es importante implementarlo de forma acorde a los objetivos propuestos en la estrategia. 3.2.3.2 Inspecciones con listas de chequeo a nivel de diseo e implementacin Estrategia: Se utilizarn formatos que contengan los diferentes tems a revisar en los entregables de las etapas de diseo e implementacin. La intencin de esto es cubrir los errores ms comunes tanto en la codificacin como en la realizacin de los modelos de la etapa de diseo. A su vez, esto permite establecer un estndar para las diferentes entregas y facilitar la comprensin por parte de futuros desarrolladores del proyecto. Anlisis y resultados: Como se dijo en el numeral anterior, algunas revisiones se realizaron mediante listas de chequeo, las cuales abarcaron no solo diseo e implementacin, sino para anlisis y pruebas, ya que el uso de estas listas permita tener un mtodo estndar de revisin y no basado en la percepcin individual del miembro evaluador. Esta estrategia fue efectiva y permiti conocer la calidad de los trabajos realizados, y mediante esta evaluacin mejorar aspectos y detalles asociados a las crticas recibidas y los tems evaluados en la lista. Se recomienda seguir usando esta estrategia en ciclos futuros.
[44]
3.2.3.3 Formato estndar del cdigo fuente Estrategia: Se establecer el uso de las convenciones de programacin en Java para el formato del cdigo fuente. Ver:http://www.oracle.com/technetwork/java/codeconventions136091.html#262 Anlisis y resultados: Todo el cdigo implementado se realiz usando este tipo de convenciones. Se tuvieron ciertos problemas en la documentacin de los mtodos el cual fue rpidamente resuelto. Es necesario continuar con esta estrategia en ciclos futuros ya que permite tener un cdigo fcil de leer, estticamente cmodo y de ms fcil entendimiento para modificaciones futuras.
3.2.3.4 Estructura del Repositorio SVN y su modificacin Estrategia: El repositorio tendr una estructura que diferencie claramente las diferentes versiones del sistema que se vayan desarrollando. Las entregas parciales sern almacenadas de forma separada de la versin principal del mismo. Para evitar inconvenientes en la actualizacin del cdigo, se deber sincronizar con el estado actual del repositorio antes de subir las modificaciones a ste. Anlisis y resultados: El uso del repositorio permiti realizar una implementacin concurrente e independiente del lugar de trabajo de los miembros de grupo, un requerimiento que demostr ser necesario y eficiente para el desarrollo de la aplicacin. Su uso en ciclos futuros es vital para tener un producto de calidad en un periodo corto de tiempo. 3.2.3.5 Estndares de nombramiento para paquetes, clases, atributos y mtodos Estrategia: En general, los nombres asignados a estos elementos debern ser significativos y expresivos, con el fin que se pueda identificar, relativamente fcil, su funcin en el sistema. Las convenciones para la programacin en Java tambin se utilizarn para esta estrategia. En el caso de las interfaces que deban ser implementadas por otras clases, sus nombres debern empezar por la letra I. Anlisis y resultados: Esta estrategia se utiliz intensivamente en el desarrollo de la aplicacin y cobr particular importancia a la hora de hacer modificaciones al cdigo, crear proyectos aparte para pruebas, y consultar cdigo realizado por otros miembros del grupo. Los nombres de proyectos, paquetes, clases y mtodos fueron lo suficientemente dicientes para entender su funcionamiento y papel en el proyecto. Se recomienda hacer un nfasis en la documentacin del cdigo ya que es un requerimiento que no siempre se realizaba y pudo traer problemas a la hora de hacer pruebas y modificaciones. Afortunadamente no surgieron problemas pero se recomienda en ciclos futuros, si se va a usar esta estrategia hacer mayor nfasis en la documentacin para cubrirnos contra riesgos de entendimiento de cdigo y tener un proyecto ms ordenado. 3.2.3.6 Distribucin efectiva de las responsabilidades en el grupo Estrategia: Se asegurar que cada uno de los miembros tenga su tiempo adecuadamente planeado para que evitar tanto la saturacin de trabajo, como la falta del mismo. De igual forma, se intentar minimizar la ocurrencia de tareas inesperadas que afecten el desempeo del grupo en general.
[45]
Anlisis y resultados: El tiempo asignado a cada miembro de grupo y la estimacin de tiempos para cada tarea demostr no ser muy efectiva debido a que algunas tareas tomaban ms tiempo del planeado, lo que causaba retrasos en la entrega de tareas en algunas ocasiones, se recomienda revisar adecuadamente los tiempos asignados y, con el uso de las mtricas de este ciclo en cuanto a tiempo planeado vs tiempo real, desarrollar una metodologa de estimacin de tiempos ms adecuada con el fin de no saturar de trabajo a algunos miembros del grupo. 3.2.3.7 nfasis en escritura correcta Estrategia: Se verificar que los entregables del proyecto hagan uso de una correcta ortografa y que tengan una semntica adecuada para evitar futuros malentendidos y promover la comprensin de lo que se quiere expresar. Anlisis y resultados: Esta estrategia se us de forma intensiva a lo largo del proyecto. El lder del grupo realiz inspecciones a todas las entregas de los dems miembros y anot, adems de correcciones, errores ortogrficos, semntica, o de falta de informacin que fueron acatados y corregidos por los dems miembros. El uso de esta estrategia prob ser efectivo y se recomienda utilizar en ciclos futuros.
[46]
3.3 Oportunidades de Mejora y Planes Concretos

A continuacin se presentan las situaciones sobre las que se puede trabajar para mejorar diferentes aspectos de trabajo grupal. Para cada una de estas se plantean actividades que buscan disminuir su efecto negativo. Las reuniones de seguimiento consumen una porcin considerable del tiempo disponible para trabajo de la mayora de los integrantes. Realizar reuniones de seguimiento ms cortas donde estemos todos los miembros, dependiendo del tipo de tareas que deban realizarse y la necesidad de que todos escuchen el tema que se est tratando. Llevar a cabo reuniones adicionales donde el Lder de Grupo discuta sobre las tareas puntuales a realizar con cada miembro y sobre el avance de las que se hayan realizado.
Iniciar la semana de trabajo un viernes por lo general hace que ese da no se realice mayor cantidad de tareas. Buscar un espacio al inicio de la semana para realizar la/las reunin(es) grupales. Preferiblemente lunes. En varias ocasiones algunos miembros que no comprendan claramente alguna tarea que deban realizar, la llevaban a cabo sin consultar a nadie al respecto, o no lo hacan. Promover proactividad entre miembros para mitigar dudas antes de la realizacin de tareas haciendo uso de un foro de dudas. Al finalizar cada reunin, preguntarle a cada miembro por una breve explicacin de las tareas ms importantes o complejas que le fueron asignadas. En varias etapas del ciclo hubo miembros que no pudieron realizar sus tareas debido a una fuerte carga acadmica que impidi dedicacin al proyecto. Efectuar planeacin especfica no frente al total posible de horas laborales por semana (generalmente 4 horas por miembro), sino de forma acumulativa y frente a la posibilidad fsica de dedicacin por parte del miembro en ciertas etapas.
Hubo necesidad de llevar a cabo gran cantidad de tareas de inspeccin y correccin de errores dado que el desarrollo de stas presentaba tanto incoherencias como falta de perfeccin en detalles. Llevar a cabo el desarrollo de tareas de documentacin en parejas o grupos de trabajo. Esto con el fin de cohibir la posibilidad de que se presenten errores a posteriori, siendo stos mitigados en el transcurso de su desarrollo.
[47]
Cada miembro del grupo debe ser responsable por sus tareas y no depender nicamente de la Minuta Semanal para saber sus responsabilidades. Cada miembro debe anotar y estar al tanto de sus propias tareas desde la reunin en que le fuesen asignadas. De esta forma, el Lder de Calidad tendra dedicacin frente a aspectos ms especficos de seguimiento en cada minuta. La tecnologa es un factor importante y puede generar retrasos y costos adicionales. Por esto, se debe afrontar la tecnologa desde un principio. El Lder de Soporte debe efectuar tareas de capacitacin tcnica a los miembros del grupo, con el fin de mitigar inconvenientes que se puedan presentar frente a nuevas tecnologas. Se propone el efectuar tutoras bajo consentimiento unnime del grupo hacia cada una de las tecnologas utilizadas en el transcurso del proyecto.
Durante el ciclo las tareas se subieron a DotProject al final de cada semana, lo que evita un registro de tiempos preciso: Mejorar las mediciones de tiempo de las tareas. Las tareas deben subirse en el transcurso de la reunin, con el fin de actualizar logs de forma realista a travs de la realizacin de diferentes labores.
La solucin a problemas comunes puede evitar la prdida de tiempo, haciendo que ste se aproveche mejor. Adicionalmente, se puede tener una base de conocimiento ms amplia y utilizable por otras persona: Desarrollar un centro de conocimiento para el grupo. Documentar y mantener un lugar donde se especifiquen cada problema encontrado y la solucin adecuada que se implement para resolverlo.
[48]
4 Reflexiones
Esta seccin concluye este documento con las reflexiones individuales de cada miembro respecto a su desempeo como integrante de un grupo, con un rol especfico y encargado de ciertas labores de desarrollo. Cada miembro analiza diferentes facetas del proyecto y del grupo como tal para tenerlas en cuenta en futuras ocasiones.
4.1 Lder del Grupo

4.1.1 Desempeo del Grupo
Qu nos falt como grupo en este ciclo? Al grupo le hizo falta una consistencia que prevaleciera a lo largo del ciclo. Se presentaba un compromiso intermitente hacia el trabajo por parte de algunos miembros del grupo y las soluciones planteadas para contrarrestar esto no dieron siempre los resultados esperados. A su vez, esta situacin traa inseguridad sobre si asignar una tarea de mayor urgencia a algunos de estos integrantes, puesto que no haban garantas de que la actividad fuese a ser realizada. Hay que sealar tambin que era necesaria una mayor apropiacin del proyecto por parte de algunos miembros. Era frecuente observar que estos se dedicaban nicamente a las tareas asignadas sin entender las implicaciones a nivel global de lo que hacan. De igual forma, una participacin ms proactiva en las reuniones y en las decisiones tomadas hubiese llevado a un mayor aporte de todos los miembros y no de algunos solamente. Cmo debera ser el proceso en el prximo ciclo? Hay que enfatizar en una mayor proactividad y participacin en las decisiones que se tomen en el ciclo. Las reuniones grupales deberan ser un espacio para discutir rpidamente el mejor camino a tomar en torno a alguna actividad del proyecto, y no solamente para asignar tareas como ocurri en algunas ocasiones. Sera tambin adecuado tener ms en cuenta las semanas en que algunos miembros del grupo se encuentren atareados por razones ajenas a este proyecto. De esta forma, se podr realizar una asignacin de tareas ms acorde a la carga de trabajo que maneje cada uno en su momento y as disminuir los retrasos. Qu etapas fueron las ms difciles? Por qu? Las etapas de mayor dificultad fueron la realizacin de la estrategia y la implementacin. En el caso de la estrategia, y por tratarse de la primera vez que trabajbamos juntos, se presentaban problemas de comunicacin donde tareas no se realizaban de la forma esperada y donde algunos miembros no comentaban sobre sus actividades durante la semana. Durante la implementacin y parte del diseo, se hizo insoportable la falta de compromiso del lder de desarrollo y fue necesario aislarlo de estas tareas para evitar retrasos. Sus actividades quedaron limitadas a revisiones de entregables anteriores y tareas de menor prioridad. Tratar esta dificultad con l no fue fcil ya que ni el dilogo en persona ni por medios virtuales daba el resultado a largo plazo que se esperaba. Si uno hablaba con l, se comprometa por el momento y con las tareas de la ocasin solamente.
[49]
Toda esta situacin llev a la necesidad de seleccionar al lder de calidad para que en conjunto realizramos tareas relevantes como la definicin de la arquitectura de la aplicacin, sin la presencia del lder de desarrollo.
Qu no me gust del ciclo? Principalmente la necesidad de presionar a varios integrantes a que realizaran sus actividades para la fecha estipulada. Es una labor que consume tiempo que puede ser invertido en el avance del proyecto, pero que en cambio toca utilizarlo para encontrar a la persona, hablar con ella y recalcar la importancia de la tarea. Dejando a un lado la actitud del lder de desarrollo (que se trat anteriormente), hay que sealar la falta de atencin que a veces surga de los lderes de planeacin y soporte. Al momento de discutir temas relevantes con otros miembros, ellos formaban discusiones fuera del foco del proyecto y apoyaban la distraccin de los dems integrantes. En trminos generales, es un tema a tratar a nivel de grupo: la atencin a lo que se dice para evitar malos entendidos. Lo cual, se present y un claro ejemplo fue el desarrollo de unos paneles en SmartGWT por parte del lder de planeacin, y en GWT por parte del lder de soporte, cuando en realidad se haba recalcado que se iba a trabajar en GXT.
4.1.2 Desempeo del Rol

Cmo manej Ud. su rol? Qu funcion? Qu no funcion? Intent enfatizar en el manejo de dos aspectos fundamentales: la coordinacin eficiente del grupo y lograr un producto de calidad. En lo que respecta a la coordinacin del grupo, asign tiempo inamovible semanalmente para revisar las actividades de cada miembro, hacer los comentarios respectivos y con base en ello establecer una planeacin para la siguiente semana. Durante las reuniones buscaba siempre llegar con esta planeacin para proponerla y que fuese tema de discusin dependiendo de las opiniones de los dems integrantes. Sin embargo, a veces suceda que no haba mucha discusin al respecto y cada miembro aceptaba sus tareas, inclusive sin realmente comprender de qu se trataba. Lo cual, llev en ms de una ocasin a que se dejaban incompletas o quedaban mal hechas. Por otra parte, no pens que las dificultades con el lder de desarrollo fuesen a alcanzar el punto en que llegramos a considerar sacarlo del proyecto. Esto se contempl de forma algo desesperada, dada su incapacidad de responder a los repetidos reclamos y quejas de todo el grupo. La bsqueda de un producto de calidad se bas en asignarle a cada miembro labores de anlisis, diseo e implementacin segn sus fortalezas. Lo cual, implicaba ir conociendo a los integrantes del grupo para identificar qu tipo de tareas asignarles. Ah fue cuando not la motivacin de los lderes de soporte y planeacin por trabajar en la capa Web, mientras que el lder de calidad estaba ms interesado en la lgica de negocio y el manejo de la base de datos. Sin embargo, la calidad del producto se busc desde los inicios del mismo ciclo, llevando a cabo actividades de prototipado, aseguramiento de calidad y pruebas de concepto. Todas estas, unidos a una importante labor junto con el lder de calidad para proponer la arquitectura del sistema, concluyeron un proceso de diseo que estableci unas bases slidas para la implementacin. Lo que ciertamente no funcion como se esperaba durante la etapa de implementacin, ms que todo en lo relacionado con tecnologa Web, fue comprender la magnitud de trabajo que bamos a
[50]
llevar a cabo y el tiempo que poda ser necesario para realizar correcciones. Hizo falta visin en ese sentido para replantear la estrategia de implementacin cuando ya se empezaban a evidenciar retrasos en las metas de codificacin. Cmo el rol puede ser mejor desempeado la prxima vez (no auto critica sino gua para la prxima persona que desempear el rol)? Se debe tener cierta capacidad de previsin de dificultades que puedan surgir. Tanto a nivel de grupo, teniendo en cuenta la motivacin de los miembros, su disposicin y atencin hacia el trabajo, como a nivel de producto contemplando los puntos dbiles del grupo respecto a las tecnologas a utilizar. En la medida que como lder se pueda tener esa sospecha de que un miembro pronto empezar a retrasar el proyecto o de que en el grupo se perciben dudas o inseguridades tecnolgicas y conceptuales, ser posible tomar accin y plantear actividades para disminuir su efecto negativo. Considero es algo que mejora con la experiencia y conociendo al grupo de trabajo. Por lo que es de suma importancia tener una nocin adecuada de las aptitudes de cada integrante.
4.1.3 Desempeo como Desarrollador

Cmo fue mi contribucin en la construccin de cada uno de los entregables del ciclo? Particip de manera activa en todos y cada uno de los entregables del ciclo. Aun cuando algunos no los haya realizado, siempre estuve atento para comentar al respecto y realizar los arreglos que fuesen necesarios. Le dediqu especial atencin a los entregables de diseo buscando que la implementacin se basara en l lo ms posible y en que cada desarrollador tuviese un fundamento adecuado y no improvisaran para cumplir con sus labores de implementacin. En general, mi contribucin gir en torno a establecer una base o propuesta inicial para la mayora de los entregables, que pudiese ser discutida con los dems miembros y luego de llegar a un acuerdo de su realizacin, asignar encargados que lo desarrollaran. Donde por cuestiones de horas de trabajo, yo era el que le deba dedicar mayor tiempo. Cmo puedo mejorar la calidad de lo que hice? Considero que realizando revisiones en pares con mayor frecuencia. En muchas ocasiones, mi trabajo no era evaluado por algn otro miembro del grupo, lo cual sera provechoso ya que siempre existe la posibilidad de que se encuentren maneras de mejorar la calidad de un entregable o de realizar las correcciones necesarias. Por cuestiones de tiempo, ocurra que junto con otros integrantes del grupo inicibamos una tarea, pero el nico que estaba presente al momento de finalizarla era yo. Esto no contribua a una correcta evaluacin de calidad ya que no haba un seguimiento adecuado en el proceso de realizacin de la tarea. Implicando as, que la nica posible revisin de calidad fuese al final cuando ya se ha perdido la traza de las intenciones y los motivadores que se tenan cuando se estaba llevando a cabo la actividad.
[51]
Cmo puedo mejorar la integracin con las dems personas del grupo? En general considero que la relacin de trabajo con los miembros del grupo fue buena. Con los lderes de calidad y de planeacin se pudo dialogar adecuadamente todos los temas referentes al proyecto llegando siempre a conclusiones que aportaban al trabajo del momento. Con respecto al lder de desarrollo, toda la problemtica causada por su falta de compromiso hizo que no me motivara a trabajar con l, sino solamente aislarlo en tareas que pudiese realizar de forma independiente. Aun as, a finales de este ciclo y despus de mltiples discusiones y reclamos, l se comprometi decentemente con el proyecto. Si preserva esa actitud, yo debera esforzarme en formar nuevamente una disposicin a trabajar y tratar temas de relevancia para el proyecto con l. El lder de soporte por su parte mostraba una disposicin de limitarse nicamente a lo que le era asignado y no ir ms all de eso. Teniendo esto en cuenta, resultara adecuado poder dialogar ms con l y promover una participacin proactiva.
Qu aprend en este ciclo con respecto al desarrollo? El proyecto contribuy a varios aspectos de mi aprendizaje como desarrollador. Un tema relevante en esto fue manejar todo un ciclo de actividades, desde la concepcin de lo que debamos lograr, hasta un sistema funcional. Poder integrar todas esas ideas, diseos y propuestas, para luego materializarlos en una aplicacin me permiti obtener nueva experiencia y afianzar una visin integral del proceso de desarrollo. Personalmente, fue muy satisfactorio ver que el diseo que concebimos se puede ver sumamente reflejado en el producto final. Lo que quiere decir que el esfuerzo dedicado a proponer la arquitectura del sistema rindi dividendos para una implementacin ms documentada sin dejar decisiones importantes a merced del programador. El aprendizaje de herramientas para el desarrollo de esta aplicacin tambin fue de gran importancia. Sin importar de qu tecnologa se tratara, frecuentemente fue necesario investigar sobre ellas para materializar nuestra propuesta. Por lo que este proyecto contribuy a afianzar y mejorar mis conocimientos sobre manejo de sesiones con EJBs, manejo de entidades persistentes con JPA, conexin de una capa Web con la lgica de negocio y montaje de herramientas adicionales como un servidor de aplicaciones, base de datos, entre otros. Sin embargo, la mayor parte de las cosas que aprend se relacionan con el uso de la librera GXT para desarrollar la interfaz Web. Antes del proyecto ya contaba con algo de experiencia al respecto, pero no la suficiente para implementar toda nuestra propuesta grfica. As que por eso fue necesario invertir un tiempo considerable en comprender diferentes aspectos de su funcionamiento y fue la causa de mltiples demoras en la implementacin Web por no tener experiencia midiendo el esfuerzo necesario para desarrollar la interfaz esperada.
[52]
4.1.4 Reporte
A mi manera de verlo, este ciclo en general tuvo unos resultados adecuados, en medio de ciertas dificultades tanto tecnolgicas como del grupo de trabajo. Iniciando el ciclo haba incertidumbre sobre la forma en que cada integrante iba a encarar el proyecto. El hecho de no conocerlos ya planteaba un reto en cuanto a poder formar un autntico equipo de trabajo donde cada uno aportara al trabajo del otro y que se pudiesen formar discusiones productivas. Como era de esperarse, algunos miembros mostraron una clara motivacin desde el principio, pero otros necesitaban ser presionados para que realizaran sus tareas. A medida que avanzaba el tiempo, se volvi evidente que poda y deba trabajar ms en el compromiso de algunos de ellos hacia el proyecto. Sin embargo, siempre estuvo presente la limitante de tiempo de los dems miembros. La cantidad de horas que ellos deban dedicarle al proyecto era significativamente menor a la que yo deba, causando despreocupacin en algunos integrantes. Lidiar con esta situacin fue quizs la mayor problemtica para asegurar un buen desempeo como grupo. Para ello, se establecieron una serie de compromisos y reglas que debamos cumplir, y buscando aprovechar al mximo el tiempo de ellos. Aun as, en mltiples ocasiones el poco tiempo que deban dedicarle resultaba ms un problema ya que las tareas se realizaban al final de la semana, dejando poco tiempo para las revisiones necesarias. A esto hay que sumarle que ciertas semanas ellos no pudieron realizar sus tareas por compromisos ajenos al proyecto. As que caamos en actividades recurrentes como estar replanteando las tareas, asignndole nuevos encargados y planeando revisiones que no se pudieron hacer en la semana que la actividad fue realizada. Las reuniones grupales son otro tema importante que debe ser manejado con cuidado. Dedicarle poco tiempo puede causar que no todos los miembros comprendan la totalidad de tareas que deben realizar. Pero dedicarle ms tiempo puede llevar a que algunos se distraigan y empiecen a hablar de temas no relacionados con el proyecto. Dependiendo de la ocasin, llegamos a variar ese tiempo desde 30 hasta 90 minutos. Pero independiente de eso, lo que ms funcion fue mantener en la reunin a aquellos que realmente deban escuchar lo que se estaba tratando. Si alguien tena tareas muy puntuales, se hablaba con esa persona primero y as se poda retirar de la reunin para tener ms tiempo de trabajo disponible. No siempre aplicamos esta estrategia, por lo que no era extrao que se presentaran distracciones. De igual manera, las reuniones ms productivas fue cuando yo no llegaba con una lista de tareas ya claramente distribuida, sino que con una propuesta inicial hablbamos de los logros que necesitbamos para la semana siguiente y con base en ello detallar la planeacin y asignacin de actividades. Para manejar el rol de lder en futuras ocasiones hay una gran variedad de cuestiones por tratar. Considero que ms que una lista de elementos a tener en cuenta, cada grupo que se lidere debe ser manejado acorde a las circunstancias que se presenten. Uno de los aspectos que pienso debe ser clave es poder adaptarse al grupo de personas con el que se est tratando y explotar sus habilidades en los momentos adecuados. Saber a quin recurrir para una actividad determinada es entonces vital para llegar a la resolucin efectiva de un proyecto. Finalmente, lo que se busca es manejar la complejidad de cada ser humano y enfocarla lo necesario para lograr unos objetivos. Si existe la suficiente motivacin e integracin del grupo, la parte del trabajo referente a analizar, disear y codificar es ms una experiencia de aprendizaje y de logros antes que una obligacin.
[53]
4.2 Lder de Desarrollo

Qu nos falt como grupo en este ciclo? Hubo falta de compromiso por parte de algunos miembros (incluyndome) derivada en parte a la carga acadmica o a distintos problemas o situaciones, sin embargo en mi opinin el compromiso generalizado fue bueno. Una falla importante como grupo fue generar presin sobre los medios de comunicacin utilizados, ya que en algunas ocasiones algunos miembros no revisaban el medio de comunicacin acordado (Google Wave) por periodos de tiempo prolongados, lo que generaba malentendidos que si bien fueron muy pocos durante el ciclo pudieron generar problemas de fondo en el ciclo, afortunadamente no hubo problemas de este tipo pero es importante ser precavidos al respecto. El seguimiento de tareas fue difcil ya que en algunas ocasiones estas tareas eran subidas a dotProject muy tarde, incluso despus de que la tarea era realizada, haciendo que fuera necesario seguir las tareas de forma manual o realizar un estimado de tiempo (a veces inadecuado) a la hora de documentar el tiempo de estas tareas. En general los vacos del grupo no fueron en ninguna medida un obstculo para realizar el proyecto, sin embargo a futuro podemos pensar en estrategias de mejora para estos problemas pequeos cuya solucin hara ms ameno el desarrollo del proyecto. Cmo debera ser el proceso en el prximo ciclo? Hay que hacer un nfasis en el auto seguimiento de tareas, la autocrtica y reflexin semana a semana del trabajo realizado, buscando siempre la mejora constante de la calidad del trabajo realizado de forma individual. Mejorar la comunicacin y trabajo en equipo es importante, ya que en algunas ocasiones se realizaban tareas de forma aislada al contexto del proyecto, lo que poda generar errores de coherencia o simplemente no era lo que el grupo esperaba, por lo cual es necesario implementar un sistema de revisin de trabajo entre miembros del grupo que se realice durante la semana de trabajo, permitiendo no solo asegurar la calidad del trabajo, sino hacerlo en menos tiempo y satisfaciendo mejor las expectativas del grupo. Qu etapas fueron las ms difciles? Por qu? La etapa de mayor dificultad fue la etapa de implementacin, ya que durante el comienzo de esta yo me encontraba en conferencias en el exterior (dado que era la semana de receso), dificultando en gran medida mi comunicacin con el grupo, dificultad que fue informada al grupo la semana anterior. Al volver al pas a afrontar y adelantar mis tareas se me informo que estas ya haban sido asignadas a otra persona, haciendo no solo esta etapa del proyecto frustrante, sino afectando enormemente mi relacin con el grupo la cual de por s ya estaba deteriorada por culpa de malentendidos y falta de compromiso de
[54]
mi parte por culpa de priorizar mis compromisos acadmicos y con la universidad por encima del proyecto. En general el desarrollo del proyecto tuvo problemas de mi parte con los dems miembros del grupo, derivadas de mi forma de trabajar y el da que yo tena disponible para realizar las tareas asignadas, lo cual en ningn momento es excusa de la falta de trabajo que en algunos casos se vio reflejada en tareas con entregas tarde. Al final del ciclo esta relacin mejoro un poco y se puede afirmar que hacia las ltimas semanas del ciclo el trabajo fue ms ameno que al principio. Qu no me gust del ciclo? En general el ciclo fue muy interesante, sin embargo la actitud tomada por parte de algunos miembros del grupo frente a las problemticas para desarrollar las tareas en un tiempo determinado, especialmente en la semana de receso, fue un factor desmotivante que gener una alta frustracin. Por otro lado, las exigencias de tiempo de entrega, formato, y capacidad de respuesta ante comunicados, causaron malestar no solo a la hora de entregar las tareas, sino en mi relacin con el grupo, y ms general, con mis grupos de trabajo en otras materias de maestra que tambin exigan trabajo de mi parte. Como mejora podramos enfatizar en el uso de mtodos ms conciliadores a la hora de afrontar problemas, hacerlo de forma privada y mediante el uso de medios de comunicacin ms efectivos, tambin buscar un mtodo de flexibilizacin de entrega de tareas, la cual, a mi modo de ver fue demasiado estricta ya que si bien en varias ocasiones entregaba las tareas tarde, en la mayora se entregaban justo a tiempo, lo que interpretaban como que se hacan a ltima hora.

Cmo manej Ud. su rol? Qu funcion? Qu no funcion? Como integrante del grupo manej mi rol de forma muy espordica, ms especficamente las labores propias de este fueron desarrolladas por mi hasta la semana de receso, momento en el que se decidi pasar algunas de mis tareas de rol a otro miembro, sin embargo, durante el tiempo de trabajo se hizo un trabajo interesante en las etapas de anlisis y en parte diseo, en donde ayudando al lder del grupo se logr tener un diseo de anlisis que nos permiti tener una perspectiva clara del producto a desarrollar, y donde los primeros diagramas fueron un punto de partida para desarrollar los diagramas de diseo que finalmente fueron implementados. Desde la perspectiva de mi rol no funcion mi trabajo realizado en cuanto aport al producto desde el punto de vista de desarrollo durante las ltimas semanas, dado que se me asignaron tareas de revisin y pruebas que poco tenan que ver con la implementacin y diseo final del producto, sin embargo, es respetable la decisin del grupo de cambiar mis responsabilidades, sin embargo no la comparto dado que el detonante de esta decisin fue un viaje en la semana de receso en donde se anunci que no iba a haber muchas posibilidades de comunicacin.
[55]
Cmo el rol puede ser mejor desempeado la prxima vez (no auto critica sino gua para la prxima persona que desempear el rol)? El rol de desarrollo debe tener un componente importante de comunicacin con el lder de grupo ms afianzado que con otros miembros, en particular se hubiera podido tener un ciclo ms productivo si yo hubiera tenido muchas ms empata con el lder de grupo, dado que por experiencia en proyectos de desarrollo a nivel empresarial, s que la falta de comunicacin efectiva, con baja empata entre miembros, es una frmula para el fracaso que afortunadamente no fue el caso de este grupo en este ciclo particular. Por otro lado, como rol de desarrollo he identificado que lo ms importante es desarrollar las tareas semanales de forma paulatina durante la semana y no asignar un espacio de tiempo largo y especfico para realizar todas las tareas al mismo tiempo, este aprendizaje debe ser tenido en cuenta en el prximo ciclo a la hora de planear tareas, las cuales deben poder ser desarrolladas por partes.

Cmo fue mi contribucin en la construccin de cada uno de los entregables del ciclo? Mi contribucin fue clara al principio del ciclo en donde tuve participacin en la definicin de requerimientos a desarrollar, planteamiento de la solucin en las etapas de anlisis, estrategia, y en parte diseo, igualmente de mi parte hubo revisin de los dems entregables buscando las correcciones de formato y ortografa que exiga el lder del grupo. Sin embargo, esta contribucin estuvo limitada a los entregables que se me asignaban, a modo de autocrtica, hubiera sido mucho mejor mi contribucin si hubiera tenido una posicin crtica hacia los entregables de los dems miembros del grupo. Hacia el final del ciclo mi labor estuvo concentrada en las pruebas del producto final y en la revisin de entregables pasados, siendo tambin una importante tarea pero aun as de menor importancia a las realizadas a principios del ciclo. En general mi contribucin en los entregables tuvo serias falencias a la hora de entregar las tareas a tiempo segn lo que pedio el grupo, sin embargo considero que fue aceptable este aporte en el grupo. Cmo puedo mejorar la calidad de lo que hice? Creo que la calidad de mi trabajo puede ser mejorada mediante comunicacin constante y desarrollando un esquema de trabajo mejor al implementado en la mayora del ciclo actual, el cual estaba basado en hacer todos los entregables de la semana en un mismo da por un periodo prolongado de tiempo, se propone entonces que como se dijo anteriormente, las tareas tengan revisin por parte de otros miembros ajenos al lder para dar una perspectiva ms completa de lo que se quiere como grupo, y que las tareas puedan ser realizadas de manera paulatina a lo largo de la semana. Con estas implementaciones se esperara mejorar la calidad del trabajo y tambin mejorar la productividad del grupo.
[56]
Cmo puedo mejorar la integracin con las dems personas del grupo? Mediante una comunicacin oportuna, parte de mis problemas con el grupo se derivaron de mi falta de revisin de los medios de comunicacin acordados de forma peridica, igualmente, la calidad de mi trabajo, y la productividad relativa hubiera sido mucho mejor si hubiera tenido una comunicacin constante con el lder del grupo, ya que era el quien ordenaba las correcciones a realizar, las cuales muchas veces derivaban de malentendidos entre lo que deseaba el lder del grupo y lo que perciba deba realizarse, como problemas de formato o contenido. Qu aprend en este ciclo con respecto al desarrollo? Aprend del uso de herramientas como GWT, la cual complementa el conocimiento ya adquirido sobre EJB y Beans de Entidad, sin embargo, lo ms importante que aprend sobre el desarrollo es la importancia de una comunicacin eficiente, la cual durante el inicio del ciclo fue un poco turbulenta pero que al final, y en particular con la implementacin del producto final, fue muy productiva e interesante, permitiendo realizar un buen producto. La estructuracin temprana y a conciencia de los lineamientos a seguir durante el ciclo, una buena planificacin, y un diseo apoyado en el trabajo incremental de cada miembro del grupo como pilares fundamentales y la frmula del xito, es la leccin ms importante que me deja este ciclo, de donde espero reflexionar acerca del trabajo con visin crtica y participativa.
4.2.4 Reporte
Desde mi punto de vista, el producto final cumple con la gran mayora de los requerimientos propuestos desde el inicio del ciclo, siendo este un producto que sirve como un buen ejemplo para el curso de desarrollo de software en equipos. En general, el desarrollo completo del ciclo, con todos sus problemas, fallas, logros y bondades, sirven para dar un ejemplo de aplicacin en la vida real en donde se tiene que lidiar con problemas como se lidiaron y documentaron en este ciclo. Mi desempeo de rol pudo ser mucho mejor, en particular en la entrega de tareas a tiempo y en la comunicacin con el grupo de forma oportuna y rpida, ya que como se dijo anteriormente la mayora de los problemas se originaban de falta de comunicacin, lo que generaba falta de entendimiento o errores al entender lo que el grupo requera en sus entregables. Sin embargo, mi participacin en el proyecto no dejo de ser importante en el proceso de desarrollo del ciclo y en la implementacin final del producto. Mi experiencia en este ciclo tuvo muchos componentes interesantes y que enriquecieron mi desarrollo profesional, como el hecho de trabajar en un proyecto real con metas reales, la obligacin a trabajar en grupo de forma coherente, y ms que todo la experiencia de trabajar en un ambiente un poco alejado del ambiente acadmico que rodea la materia de la cual deriva este proyecto. Sin embargo, hubo tambin muchas experiencias frustrantes como lo fue la falta de comunicacin que tuve con los dems miembros del grupo y el aislamiento de responsabilidades por culpa de circunstancias u oportunidades que se me presentaron a lo largo del semestre.
[57]
A futuro el trabajo del lder de desarrollo, como se dijo anteriormente, debe ser un trabajo que tenga como piedra angular la comunicacin efectiva y rpida con los dems miembros del grupo, ya que las responsabilidades de este no permiten falencias de asistencia o falta de comunicacin como se vio en mi caso particular.
4.3 Lder de Planeacin

Qu nos falt como grupo en este ciclo? Personalmente considero que falt comunicacin dentro del grupo frente a ciertas situaciones presentadas en etapas de este ciclo. Por ejemplo, con el caso del Lder de Desarrollo, hubo en dos etapas la necesidad de reasignar tareas hacia otros miembros dado a que no fueron cumplidas por l como se haba pactado en las reuniones. Esto ltimo, refleja falta de comunicacin, porque por ms que se llev a cabo la utilizacin de Google Wave como medio de dilogo, el Lder de Desarrollo en dichas etapas no comunic su situacin sino hasta que se exiga visualizar resultados y objetivos cumplidos, conllevando as, al atraso de ciertas tareas como tambin a la asignacin de tareas de correccin de errores. Para mitigar esta problemtica considero pertinente el que se haga fuerte seguimiento de miembros a lo largo de cada etapa, exigiendo resultados no al final de stas sino en el transcurso de las mismas. Esto ltimo con el fin de que en caso fallido del cumplimiento de labores, se pueda hacer reasignacin de tareas antes de terminar cada etapa y no despus. Cmo debera ser el proceso en el prximo ciclo? El proceso no fue del todo malo, aunque creo que pudo ser bastante mejor. Para un siguiente ciclo considero importante el hacer uso de otros medios de comunicacin aparte de Google Wave para plantear inquietudes. Aparte de esto, considero que la minuta de reunin debe ser actualizada al momento de terminarse sta, buscando as subir las tareas de cada etapa a dotProject el mismo da de la reunin para as tener resultados de tiempos ms acertados. Qu etapas fueron las ms difciles? Por qu? Considero que la etapa de mayor dificultad para el grupo fue la de Diseo. Esto ltimo dado a que en esta etapa hubo necesidad de reasignar tareas, y fue la primera etapa en que una semana de trabajo se nos qued corta. Aparte de esto, fue la primera etapa en que se vio el grupo en la obligacin de asignar tareas de revisin y correccin de errores en documentos previos, por lo que cada miembro tuvo exceso de tiempos a trabajar en las tareas asignadas.
[58]
Qu no me gust del ciclo? Hubo varios aspectos que no fueron de mi agrado. Primero, el que no hubiera habido proactividad frente a labores de soporte para el desarrollo de tutoriales y el aprendizaje frente a nuevas tecnologas. Frente a este ltimo aspecto, hago nfasis en cuanto al desarrollo de la capa Web de la aplicacin, en la cual hubo en un principio malentendidos frente a las tecnologas a utilizar, no habiendo por parte del Lder de Soporte la apropiacin de un papel crtico y de respuesta para mitigar tanto tiempo extra trabajado frente a la capacitacin en cuanto a tecnologas. Segundo, no me agrad en nada el papel del Lder de Desarrollo al inicio del ciclo. Falt bastante proactividad frente a su papel en las etapas de anlisis y diseo de la aplicacin, teniendo varias tareas sin realizar, y consecuentemente, forzando al grupo al desarrollo de tareas de correccin y a la reasignacin de labores en dichas etapas. Personalmente, creo que el Lder de Desarrollo pudo haber entregado bastante ms en este ciclo, porque confo y conozco sus capacidades. Luego de estas etapas, desarroll un mejor papel, pero frente al tema del Liderazgo en cuanto a Desarrollo, estuvo bastante crudo. Por ltimo, no me gust la energa que se manej dentro del grupo en este ciclo. Por ms que poseo buen trato con varios miembros dentro de ste, considero que se pudieron haber manejado mejor situaciones presentadas en etapas en especfico. Frente a la situacin que involucra al Lder de Desarrollo, considero que las crticas hubieran sido ms efectivas si se hubieran llevado a cabo de frente en las reuniones de trabajo, desde un principio. Es por esto que creo pertinente que se re-evalen los canales de comunicacin, porque hablando de frente la gente se expresa y entiende mejor.

Cmo Ud. manej su rol? Qu funcion? Qu no funcion? Considero que tuve un desempeo de rol bastante bueno en este ciclo, no tanto por la publicacin de tareas en dotProject, sino por mi participacin activa en la decisin de stas en cada una de las reuniones. Funcion tener seguimiento de logs semanales frente a las tareas efectuadas, lo cual permiti llevar a cabo crticas en cuanto a la planeacin especfica por etapa dentro del ciclo. No funcion el no haber podido subir tareas a dotProject en la misma reunin (falta de internet en la sala de juntas), ni poderlas subir temprano en cada semana dado a la dependencia frente a la minuta de reunin. Considero que para un prximo ciclo se debe poder tener las tareas actualizadas en dotProject al momento de terminarse la reunin, con el propsito de establecer resultados de tiempos ms precisos y reales. Cmo el rol puede ser mejor desempeado la prxima vez (no auto critica sino gua para la prxima persona que desempear el rol)? Para mejorar el desempeo de este rol, considero que es crucial subir las tareas de cada etapa del ciclo al inicio de sta. Dado que se depende de la minuta de reunin, buscar medios que mitiguen dicha dependencia para permitir la actualizacin de tareas oportunamente.
[59]
Por otra parte, es clave dentro del seguimiento de tareas, ser bastante exigente frente al desempeo de roles en cuanto a tiempos y entregables, para as de esta manera, lograr visualizar posibles problemas a futuro, mitigndolos a partir de la toma oportuna de decisiones frente a responsables. Por ltimo, considero crucial el que el Lder de Planeacin lleve a cabo la planeacin especfica de cada etapa frente a la presencia de otras actividades de peso para cada miembro (Ejemplo: Parciales, Proyectos...), con el fin de mitigar la presencia de tareas en blanco que conlleven a una futura reasignacin de responsables, y a la vez, de tiempos.

Cmo fue mi contribucin en la construccin de cada uno de los entregables del ciclo? Durante todo el ciclo estuve participando activamente, ya fuese organizando con el Lder de Grupo responsables frente a tareas, como tambin actuando como desarrollador en la capacitacin frente a nuevas tecnologas, como tambin en el desarrollo de componentes requeridos para la aplicacin (principalmente en la capa Web). A lo largo del ciclo entregu trabajos de calidad, optando siempre por la opinin de un compaero (generalmente el Lder de Grupo) con el fin de visualizar errores antes y no despus de la fecha pactada de entrega. Por ms que tuve trabajos fuertes a lo largo del semestre, como tambin otras obligaciones, siempre mantuve contacto con el Lder de Grupo y no dej de realizar tareas ni de efectuar mi rol de Planeacin oportunamente. Cmo puedo mejorar la calidad de lo que hice? Considero que la calidad de mi trabajo fue buena, aunque alcanc en ciertas etapas del ciclo a tener problemas frente al tiempo por cada entregable dado a la presencia de otras actividades extra-laborales. Creo que es crucial para mejorar la calidad de mi trabajo, el dedicar ms tiempo en auto-correccin de errores o detalles con el fin de mitigar posibles tareas de revisin y correccin. Cmo puedo mejorar la integracin con las dems personas del grupo? Dentro del contexto del actual proyecto, considero que consegu buena relacin con los miembros del grupo. El nico miembro que no conoca era mi Lder de Grupo, con quin llev a cabo el desarrollo de tareas oportunamente, y creo que consegu con l tener una buena dinmica laboral. Siento que como miembro, persona y amigo fall en cuanto a dialogar oportunamente con el Lder de Desarrollo cuando decay como trabajador dentro del proyecto. A partir de esta falla, considero que la manera en que puedo mejorar la integracin dentro del grupo, es participando como actor y camino al dilogo dentro de ste, con el fin de lograr prever inconsistencias como tambin situaciones catalogadas como difciles.
[60]
Qu aprend en este ciclo con respecto al desarrollo? Considero que aprend bastante. Antes de efectuar el desarrollo de este proyecto no tena conocimiento concreto de GWT y su interaccin con JEE. En cursos previos tuve la oportunidad de trabajar con JEE en forma, integrando tecnologas tanto de lgica como de persistencia, pero siendo stas de la misma plataforma. Considero que el haberme capacitado en GWT me permiti abrirme a nuevas herramientas de desarrollo, y en otras palabras, me capacit frente a la creciente necesidad de adaptarme a nuevos entornos y problemticas. Desde un punto de vista ms tico, considero que reforc bastante mis conocimientos en cuanto a la Ingeniera de Software, viviendo en carne propia la necesidad de tener un buen anlisis y un buen diseo antes de optar por tener la primera lnea de cdigo implementada. Experiment lo que es el desarrollo de software en un contexto ms real que el acadmico (planteado por la materia), y creo rotundamente que la experiencia adquirida en este proyecto es valiosa para mi profesin y mi futuro desempeo laboral.
4.3.4 Reporte
En este ciclo particip activamente en varias actividades desarrolladas en el transcurso de cada etapa. Principalmente, tuve un enfoque fuerte hacia la asignacin de tareas y responsables, estando pendiente frente al estado de los entregables a nivel de tiempos y reportes. Hubo problemas al principio del ciclo, porque nunca antes habamos trabajado en grupo los miembros que efectuamos este proyecto, siendo el Lder de Grupo alguien completamente desconocido al momento de iniciar labores, y pues la adaptacin del entorno de trabajo y la ganancia de confianza entre miembros siempre alcanz a tomar su tiempo. Se presentaron problemas frente a las bases de datos que soportaron a DotProject, siendo yo el responsable de ir a hablar y mitigar este problema directamente en la oficina de administracin de TIs del Departamento de Ingeniera de Sistemas y Computacin, algo que no estaba dentro de mi labor, siendo principalmente parte del rol de Soporte dentro del grupo. A lo largo del ciclo estuve desarrollando tareas de documentacin, revisin e implementacin, vindome enfrentado a repasar y fortalecer temas de la Ingeniera de Software que tena fros desde que vi la materia formalmente. Por el lado de tecnologas, me vi en la obligacin de encarar nuevas tecnologas como GWT, EJB y JPA con Eclipse, editor con el cual nunca haba trabajado JEE en forma (tena conocimiento en NetBeans), por lo cual adquir habilidades de adaptacin tecnolgica fuertes. En el transcurso del ciclo estuve en contacto directo con el Lder de Grupo, reportando labores y socializando el avance del proyecto. No fue fcil llevar a cabo el rol de Lder de Planeacin, dado a que hubo necesidad de replantear tareas, no tenamos un banco de datos frente a los tiempos requeridos para labores administrativas de monitorias (calificaciones y sustentaciones), y aparte en un principio se haba estimado un alcance de proyecto para dos ciclos, terminando solamente en la ejecucin de uno debido a la exigencia alta en estndares y criterios de calidad.
[61]
No obstante, considero que mi desempeo dentro de este rol fue satisfactorio y retroalimentativo. Sostengo que la informacin adquirida a lo largo de este ciclo permitir para futuras ocasiones hacer uso de la planeacin del proyecto de forma ms profesional. Esto claro, partiendo de la alta experiencia adquirida a lo largo del primer (y nico) ciclo del Proyecto realizado.
4.4 Lder de Calidad

Qu nos falt como grupo en este ciclo? Como grupo nos falt proactividad por parte de algunos miembros. En especial, del lder de desarrollo que no estuvo muy pendiente del proyecto en las etapas de anlisis y diseo. Estas dos etapas son muy importantes en el proceso de desarrollo ya que definen la arquitectura de la aplicacin a desarrollar. En este caso se desarroll nicamente un solo ciclo pero es importante resaltar que la arquitectura debe permitir el desarrollo de uno o ms ciclos adicionales. Aunque logramos disear una arquitectura que satisface los atributos de calidad e implementar la aplicacin, se debe tener cuidado con la contribucin de cada uno de los miembros del grupo. Para mitigar este problema se puede pensar en tener una reunin con los miembros que no estn aportando mucho al proyecto. Esta reunin debe permitir aclarar los problemas para mantener un buen grupo de trabajo. Es importante detectar esto anticipadamente para evitar conflictos posteriores. Si el problema persiste se puede pensar en el cambio de roles entre ciertos miembros del grupo para permitir una distribucin de tareas diferente y as no sacrificar las tareas de unos por las de otros. Cmo debera ser el proceso en el prximo ciclo? Me parece que el proceso funcion bien. Sin embargo, se puede pensar en mejorar la planeacin para tener datos ms precisos y tratar de ajustarnos mejor al tiempo disponible de cada integrante. Dado el problema mencionado anteriormente, se puede pensar en reasignar los roles. Para este ciclo se hizo una escogencia de roles a gusto de cada uno. Puede ser ms productivo que para el siguiente ciclo se haga una asignacin de roles basada en el trabajo desempeado en el ciclo anterior. Puede que no sea necesario reasignar todos los roles.
Qu etapas fueron las ms difciles? Por qu? En general me parece que ninguna de las etapas fue difcil. Sin embargo hubo problemas de tiempo en la mayora de etapas, lo cual retras considerablemente el ciclo. Estos retrasos no se dieron por incompletitud de tareas o problemas entre los miembros del grupo si no por una gran cantidad de revisiones que fue necesario realizar de cada entregable para poder tener una presentacin homognea.
[62]
Qu no me gust del ciclo? No me gustaron dos cosas. Primero, no me gust que surgieran problemas de tecnologa de la parte de interfaz grfica. Este problema afect y retras la etapa de implementacin. Aunque en un principio se hicieron pruebas en investigaciones no fue suficiente para afrontar la tecnologa y no tener problemas con esta. Aunque yo no trabaj en la parte de interfaz grfica me parece que los involucrados en este desarrollo tuvieron que gastar mucho ms tiempo del planeado en el desarrollo de los componentes grficos. La utilizacin de ms tiempo no implica que exista mayor dificultad. Segundo, no me gust el trabajo del lder de desarrollo. El lder de desarrollo no aport lo suficiente y lo esperado. Muchas de sus tareas tenan que volverse a realizar o asignarlas a otros miembros. Fue necesaria la intervencin de Rafael Meneses para lograr cambiar su trabajo. Aunque esto funcion, durante el resto del ciclo no se le asignaron tareas crticas. La mayora de tareas eran de revisin y correccin de la presentacin de la wiki.

Cmo Ud. manej su rol? Qu funcion? Qu no funcion? Creo que manej bien mi rol. Sin embargo tuve unos retrasos importantes con la publicacin de las minutas. Estos retrasos afectan directamente a los otros integrantes ya que la minuta es donde se documentan las tareas a realizar en el siguiente ciclo. Por esto, se debe mejorar la publicacin de las minutas y hacer lo las pronto posible despus de la reunin. En cuanto a otros aspectos, considero que se sigui de forma correcta el proceso de desarrollo, permitiendo la documentacin e implementacin de un producto de calidad. Cada etapa del proceso se document adecuadamente. Aunque algunas etapas tomaron ms tiempo del esperado, se logr completar cada una de ellas. Otro aspecto importante a discutir son las reuniones semanales. En las reuniones semanales mi rol era ms que todo el de secretario, tena que llevar registro de las tareas asignadas por el lder del grupo. No era necesaria mi intervencin como moderador ya que el lder del grupo era el que conduca las reuniones, dando a conocer lo que haba que corregir y lo que faltaba. En general todos los miembros aceptaban las tareas que l asignaba sin ni siquiera preguntar o estar seguros de los que haba que hacer. Cmo el rol puede ser mejor desempeado la prxima vez (no auto critica sino gua para la prxima persona que desempear el rol)? Para mejorar el desempeo del rol es importante tener en cuenta la responsabilidad de las minutas. Este entregable debe ser publicado lo ms pronto posible para que cada integrante del grupo conozca sus tareas de la semana. Al retrasarse en esta tarea se retrasa todo el grupo ya que no saben que tareas deben hacer. Otro aspecto a mejorar es la revisin de la ortografa y la sintaxis. Aunque realic revisiones de calidad en todas las etapas del ciclo, no hice revisiones de las minutas y de los reportes de los otros integrantes. En las minutas no lo hice porque olvid que otros
[63]
integrantes contribuan en el desarrollo de este entregable. Es importante mantener una revisin constante de estos entregables para no perder tiempo y tener que planear tareas de revisin para todos los integrantes.

Cmo fue mi contribucin en la construccin de cada uno de los entregables del ciclo? Durante todo el ciclo tuve una participacin activa. Contribu en la documentacin de todas las etapas y en la construccin del producto. Adicionalmente, las revisiones de calidad en cada una de las etapas me permitieron tener una visin general de todo el trabajo y una idea del producto que se iba a desarrollar. Esto me permiti poder proponer ideas para mejorar o resolver algunos problemas presentados a lo largo del ciclo. Cmo puedo mejorar la calidad de lo que hice? La calidad de mi trabajo en general fue buena. Sin embargo, en general existe un intercambio de tiempo por calidad. Esto se debe a que por falta de tiempo se realizan las tareas sin tener en cuenta la calidad de estas. Por esto, para mejorar la calidad, tal vez es necesario intentar dedicarle unos cinco a diez minutos a cada tarea para revisar que lo que se est haciendo corresponde a lo que se ha solicitado y que lo que ha realizado est bien hecho. Cmo puedo mejorar la integracin con las dems personas del grupo? La integracin con las personas es un factor crtico en todos los grupos de trabajo. En este caso, conoca a dos de los integrantes, con los cuales se mantuvo una buena relacin de trabajo. Con respecto a los otros dos integrantes, no conoca al lder del grupo. Sin embargo, logr establecer una buena relacin de trabajo con l. En la mayora de etapas del ciclo trabaj con l y logramos producir buenos entregables. En cuanto al lder de desarrollo, no lo conoca y no lo conozco. Como se presentaron inconveniente de trabajo y compromiso con l, no me interes establecer una relacin de trabajo con l. Su desinters por el grupo y el trabajo no me motivaron a hablar con l. Este ltimo aspecto es algo que debera mejorar. En muchos casos es importante conocer que est sucediendo con las personas y as entender por qu no trabajan.
Qu aprend en este ciclo con respecto al desarrollo? Con respecto al desarrollo revis el desarrollo en la plataforma JEE. Esta plataforma tiene muchas cosas que se olvidan a lo largo del tiempo por la falta de utilizacin de la misma. Esto se debe a que la mayor parte del tiempo realizo desarrollo que no requieren de esta tecnologa. En cuanto al proceso como tal, me pareci muy interesante ya que se dividieron las tareas de forma adecuada y fue posible desarrollar un producto completo entre varias personas. Esta experiencia fue mucho ms interesante y provechosa que la experiencia que tuve al ver el curso. Esto se debe a que mi grupo de trabajo del curso no fue
[64]
particularmente bueno, lo que gener un desinters y falta de compromiso que se vio reflejada en un trabajo que no tena la calidad esperada.
4.4.4 Reporte
Durante el ciclo uno, realic diferentes tareas para cada una de las etapas del proceso. En la etapa de Lanzamiento hice los objetivos del rol de lder de calidad. Ayud a definir los objetivos del grupo, de los participantes y de los miembros del grupo. Tambin ayude a definir las reglas del grupo. En la etapa de estrategia realic la estrategia de aseguramiento de calidad y la estrategia especfica. En anlisis ayude a hacer los requerimientos no funcionales, la definicin de las listas de chequeo y la verificacin de algunos casos de uso y diagramas. En diseo continu haciendo listas de chequeo. Con el lder del grupo planteamos los principales componentes e interfaces a desarrollar as como las clases y mtodos especficos a cada componente. Tambin realic inspecciones de los diagramas y de otros entregables. En implementacin desarroll Entity Beans y BOs as como las consultas necesarias a la base de datos y unas listas de chequeo de unos diagramas faltantes. Despus ayude en la implementacin de los EJBs y de la implementacin de las pruebas unitarias. A lo largo del ciclo hice revisin de los documentos entregados para verificar las correccin, completitud y coherencia de los mismos. Esto permiti tener entregables ms elaborados y en cierta forma una homogeneidad a lo largo de toda la documentacin. En muchos casos mis tareas se realizaban en conjunto con el lder del grupo, ya que decidimos realizar tareas en pares. Al realizar estas tareas en pares era ms fcil y se obtenan mejores resultados ya que se tenan dos opiniones diferentes. En cuanto a las tareas que tena que realizar solo intentaba realizarlas a lo largo de la semana para no dejarlas para el ltimo momento. Realic todas mis tareas. Hubo una semana en la que no hice las tareas pero estas fueron replaneadas para la siguiente semana. Este inconveniente surgi a causa de una gran cantidad de trabajo para dicha semana. El reporte de la reunin semanal es una tarea prioritaria ya que ah se especifican las tareas de la siguiente semana y los otros lderes necesitan este documento para poder hacer su trabajo. Las otras tareas que realic no tenan un prioridad como tal ya que otras tareas no dependan de mis tareas. Cmo va a mejorar su contribucin al grupo? Para mejorar mi contribucin al grupo voy a tener una mejor disciplina con las minutas de cada reunin. En muchas ocasiones olvid subir la minuta al principio de la semana para que estuviera disponible para el grupo. Adicionalmente en las minutas es necesario especificar lo cumplido y lo faltante de la semana as como los objetivos de la semana que comienza. En varias ocasiones no saba que poner y haca descripciones muy breves. Es importante resaltar que las minutas permiten tener un control de lo que
[65]
sucede semana a semana y es importante documentar esto de manera adecuada. Por esto, mejorare la documentacin en las minutas, detallando y especificando cada elemento de forma adecuada. Evala si los estndares fueron adecuados y si los procesos de inspeccin se llevaron a cabo y fueron exitosos. En un principio se definieron dos procesos de inspeccin. El primer proceso de inspeccin consiste en la verificacin de la correccin, completitud y coherencia de los entregables. En este caso se busca obtener entregables que cumplan con las normas de sintaxis y ortografa para poder tener un estndar de calidad en este aspecto. En este proceso se hicieron varias revisiones a lo largo del ciclo, una inspeccin cada semana. Durante estas inspecciones se encontraron y corrigieron errores. Por lo tanto, se puede decir que este proceso contribuy a mejorar la calidad del trabajo. El segundo proceso consiste en la creacin y verificacin de los entregables con listas de chequeo. Para realizar esto se definieron listas de chequeo en la etapa de anlisis y se completaron en la etapa de diseo. De esta forma es posible verificar la calidad de los entregables de la etapa de diseo. Se hicieron inspecciones de las justificaciones de diseo, diagramas del punto de vista funcional y para los diagramas de secuencia. En cuanto a otras estrategias como el formato estndar del cdigo, nombramiento de paquetes clases, mtodos y atributos, y la estructura del SVN se puede decir que se obtuvieron muy buenos resultados. El formato estndar del cdigo, nombramiento de paquetes, clases, mtodos y atributos permiti tener un cdigo entendible y legible para todos los miembros del grupo. No se generaron confusiones o problemas a nivel de cdigo. La estructura del SVN se mantuvo durante todo el ciclo y no fue necesario utilizar backups o volver a versiones anteriores. El respeto de la regla de update antes de commit permiti mantener el SVN y evitar problemas con el repositorio que hubieran podido retrasar la implementacin. Por ltimo, la calidad del trabajo, en general, fue buena. Esto se debi a dos factores principales. Por un lado el equipo de trabajo cumpli con sus tareas y desarrollo entregables de buena calidad desde un principio. Por otro lado, la planeacin de tareas especficas permiti tener claro que hacia cada integrante en cada semana. Al tener una granularidad tan alta se puede controlar ms fcilmente el tiempo planeado y el tiempo real de cada tarea permitiendo aprovechar adecuadamente el tiempo de cada integrante del grupo. Qu hay que tener en cuenta para mejorar el trabajo de su rol? Para mejorar el trabajo del rol de lder de calidad se proponen las siguientes estrategias: Primero, definir estndares de calidad ms altos, es decir que se deben definir formatos estndar para cada entregable. En este formato se tiene en cuenta tanto la presentacin en la wiki como la presentacin del entregable. Al definir estos estndares de calidad, la revisin se vuelve ms sencilla, lo que permite dedicarle ms tiempo a otras tareas.
[66]
Segundo, definir listas de chequeo para la mayora de entregables. En este ciclo se hicieron listas de chequeo para algunos entregables a partir de la etapa de diseo. Se puede pensar en la definicin de listas de chequeo para entregables de las etapas anteriores. Al realizar estas listas de chequeo se puede validar y documentar cada entregable de forma adecuada. Evaluar la disciplina del grupo: grado en el cual los ingenieros midieron su trabajo, siguieron el proceso, usaron las medidas para mejorar, aportaron al PIP. En muchos casos se cumplieron los estndares de calidad propuestos. Sin embargo hubo varios problemas en cuanto a disciplina. En varias semanas los reportes semanales de cada integrante no eran realizados a tiempo. Las reuniones semanales deben ser ms estrictas para lograr establecer los objetivos de la semana siguiente con todos los lderes y no entre algunos lderes. Esto quiere decir que la reunin no consiste nicamente en conocer las tareas de la semana siguiente. Aunque este es uno de los objetivos de esta, se debe tener en cuenta que existe un proceso de diseo en el que se deben tomar decisiones no solo para el producto si no para el proceso tambin.
4.5 Lder de Soporte

Qu nos falt como grupo en este ciclo? Nos falt tiempo. En muchas ocasiones superamos el tiempo designado para este proyecto y fue uno de los problemas ms grandes que tuvimos durante el ciclo. Estoy seguro que con ms tiempo el proyecto se hubiera realizado con ms calidad y ms completo. Hubo tambin falta de compromiso por parte de todo el grupo, pues el compromiso se daba de manera irregular, debido a no tener el tiempo suficiente para el desarrollo del producto segn la semana en la que nos encontrbamos. En ocasiones pasaban semanas en las que alguno de los miembros no cumpla con ninguno de los entregables o faltndole varios, esto hacia retrasar la entrega del producto cada vez ms. Estas faltas en muchos casos no eran debido a que a los miembros les interesara poco, sino que el tiempo no era suficiente dado que existan deberes acadmicos de las dems materias que se ponen primero que el desarrollo de este proyecto.
Cmo debera ser el proceso en el prximo ciclo? El siguiente ciclo deberamos intentar planear mejor las tareas a cada uno de los miembros del grupo, no solo pensando en el tiempo que cada uno debera tener disponible para el proyecto, sino tambin pensando en la carga acadmica que cada uno de ellos tenga en cada semana. Aparte me parece que se deberan asignar tareas ms granuladas, pequeas y especficas, de tal manera que ninguna tarea supere una hora en su planeacin. Esto nos
[67]
ayudara a que cada uno de los miembros sepa que significa cada tarea, que debe hacer para cumplirla y no solo eso sino como garantizar su calidad. Qu etapas fueron las ms difciles? Por qu? Difciles realmente ninguna, pero etapas en las que nos hayamos retrasado prcticamente todas. La nica que tal vez fue difcil llevar a cabo fue la de planeacin debido a que existan errores con las tecnologas. Adems en general todas las etapas se hacan difciles debido a que tenamos que realizar constantemente revisiones de lo que ya se haba hecho con el fin de garantizar una mayor calidad. Para terminar, la etapa de implementacin represento una dificultad al principio en su organizacin, debido a que fue necesario quitarle las tareas propias de desarrollo al lder de desarrollo, con el fin de no atrasarnos por sus fallas. Despus de organizado esto, y que el lder de calidad supli este vaco, la etapa se desarroll de una mejor manera. Qu no me gust del ciclo? El fallo de las tecnologas al principio del ciclo, que no estuvieran debidamente instaladas para ser correctamente utilizadas como lo fueron las bases de datos para dotProject. Aparte no me gust el manejo que le dimos al tiempo, pues en ocasiones era incmodo fallarle al grupo, pero la carga acadmica lo exiga, es decir, el tiempo que le dedicamos al proyecto fue ms de lo que en un principio pensbamos que le bamos a dedicar y esto llevo a confusiones, retrasos y discusiones en el grupo.

Cmo Ud. manej su rol? Qu funcion? Qu no funcion? Creo que manej mi rol de una buena manera. Fue muy til que ya conociera la herramienta GWT para guiar un poco al grupo al comienzo del ciclo, mientras algunos se ponan al da con los conocimientos. El seguimiento de riesgos era necesario y rindi sus frutos al principio cuando tenamos problemas de comunicacin entre nosotros y decidimos usar Google Wave, el cual solucion en buena parte el riesgo, gracias a que uno de los riesgos tena que ver con los problemas de comunicacin. En las semanas ms cargadas tambin se identific el riesgo de no tener suficiente tiempo disponible, y esto fue comunicado al lder de grupo, quien intento planear un poco menos de tiempo en general a todos los miembros del grupo. No funcion que no haya podido ayudar mucho al principio con los problemas con dotProject y las bases de datos, debido a que era un problema de la Administracin de Laboratorios de Ingeniera de Sistemas principalmente. Cmo el rol puede ser mejor desempeado la prxima vez (no auto critica sino gua para la prxima persona que desempear el rol)? Tener presentes en todo momento los conocimientos sobre las herramientas con las que se va a trabajar o se est trabajando. Definir en lo posible todos los riesgos posibles al principio del ciclo. Intentar crear planes de mitigacin y de contingencia tiles para cada uno de ellos. Saber que no siempre se van a poder definir todos los riesgos al principio y que por lo tanto se deber estar preparado para recibir ms riesgos, mitigarlos y contenerlos.
[68]

Cmo fue mi contribucin en la construccin de cada uno de los entregables del ciclo? Estuve presente en todas las etapas del ciclo, mis entregables eran generalmente buenos y realizaba las correcciones necesarias con cuidado. Algunos de los entregables fue necesario realizarle ms de una revisin y corregirlos debido a que quedaban mal hechos. En ocasiones era por falta de conocimiento sobre lo que se buscaba alcanzar con la tarea y en otras ocasiones por falta de tiempo para desarrollarla. Cmo puedo mejorar la calidad de lo que hice? Tal vez dedicando ms tiempo a los entregables que se me asignen, e intentar poner ms cuidado en la calidad de los mismos. Tambin es necesario que yo mismo revise las tareas que entrego y las corrija, pues muchos de mis errores eran menores por causa del poco tiempo que le dedicaba y dedicar tiempo a otras tareas para corregir este tipo de errores me parece que es una prdida de tiempo. Cmo puedo mejorar la integracin con las dems personas del grupo? Creo que tal y como se trabaj estuvo muy bien, la comunicacin con todos era buena y la integracin no era difcil con ninguno de ellos. Con alguno de ellos me encontraba frecuentemente gracias a que nuestros lugares de trabajo son muy cercanos y con los otros por medio de las redes sociales o buscndolos en sus lugares de trabajo siempre estaban prestos a brindarme el apoyo que necesitaba o para aclararme algn tema. Qu aprend en este ciclo con respecto al desarrollo? Que debemos tener en cuenta los conocimientos de los dems sobre las herramientas y aprovecharlos. Adems aprend que el compromiso de cada uno de los miembros es una pieza fundamental para que el grupo funcione correctamente. Adems en ocasiones ocurrirn cosas inesperadas o con las que no se contaba, toca superarlas e intentar seguir adelante sin problemas. Por ejemplo al principio no contbamos con que uno de los miembros del grupo no cumpliera con las tareas que se le asignaban para la hora que tocaba, pero se supo sobrellevar para que esto no nos retrasara la entrega del producto, asignndole tareas ms sencillas y no tan crticas.
4.5.4 Reporte
Reporta la logstica del desarrollo del proyecto y anota problemas y sugerencias de mejora Las tareas deben ser subidas a dotProject un poco ms detalladas y no tan generales. Se debe tener ms presente el tiempo lmite que se le puede dedicar a este proyecto. Adems cada uno deber llevar atenta nota en las reuniones sobre las tareas que debe realizar durante la semana para evitar malentendidos.
[69]
Comenta sobre el control de cambios y el manejo de las versiones del proyecto El manejo de versiones del proyecto se llev por medio de un repositorio SVN al cual todos actualizbamos. Se present un error en una ocasin y creamos un proyecto nuevo, dado que el repositorio no dejaba hacer commit. Adems del repositorio, partes del proyecto se trabajaron en mquinas virtuales por separado y al ser terminadas se suban al repositorio en sus posiciones correspondientes. Efectividad del grupo para manejar y hacer seguimiento a los riesgos Los riesgos se siguieron rigurosamente todas las semanas, y en ocasiones fue necesario que se hicieran propuestas para que los riesgos propensos dejaran de serlo, como lo fue la herramienta Google Wave que funcion muy bien. En otra ocasin se habl tambin del riesgo de retrasarnos debido a que la carga era demasiada y tambin se habl en las reuniones para intentar bajar el tiempo planeado sobre todos los miembros en general. Estrategia de reutilizacin? Sin duda reutilizaremos Wave pues fue una herramienta que nos funcion muy bien para comunicarnos y estar atentos a anuncios generales. Adems de ello creo que las mquinas virtuales fueron de gran ayuda para varios de los miembros pues al tenerlas no era necesario cargar un porttil para poder trabajar, ni tener que instalar los programas y complementos necesarios en ms de una mquina, ser importante seguir con ellas. Algunos de las mtricas podrn reutilizarse, mas no todas. Dado que identificamos que algunas de ellas no tenan sentido para nuestro modo de trabajo, y otras no aportaban mucho al grupo.
[70]
5 Acrnimos
BO EJB GWT JEE JPA Kbps LOC MS SVN Business Object Enterprise Java Bean Google Web Toolkit Java Enterprise Edition Java Persistence API Kilobits per Second Lines Of Code Microsoft SubVersion
[71]

Disco Tienda Web

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Disco Tienda Web

Transféré par

Droits d'auteur :

Formats disponibles

DISCOTIENDA WEB

Documento de Post Mrtem Ciclo 1 LOS EJEMPLARES

Los Ejemplares - IngSW

Bogot D.C., Colombia 2011

2.1.1 2.1.2 2.1.3 2.1.4 2.2

2.2.1 2.2.2 2.3

2.3.1 2.3.2 2.3.3 3

3.1.1 3.1.2 3.1.3 3.1.4 3.2

3.2.1 3.2.2 3.2.3

4.1.2 4.1.3 4.1.4 4.2

4.2.1 4.2.2 4.2.3 4.2.4 4.3

4.3.1 4.3.2 4.3.3 4.3.4 4.4

4.4.1 4.4.2 4.4.3 4.4.4 4.5

4.5.1 4.5.2 4.5.3 4.5.4 5

1.2 Producto Desarrollado

Figura 1 - Bsqueda en la DiscoTienda

Figura 2 - Detalle de un lbum Seleccionado [7]

Figura 3 - Login de la Aplicacin

Figura 4 - Carrito de Compras [8]

Figura 5 - Checkout de la Compra

Figura 6 - Procesamiento de la Compra [9]

Figura 7 - Resultado de la Compra

Figura 8 - Correo electrnico de confirmacin de compra

Figura 9 - Creacin de una Compilacin

Figura 10 - Adicin de una Cancin a una Compilacin

2 Evaluacin Del Producto

2.1 Balance de Requerimientos

2.1.1 Capa de Presentacin Requerimientos: Capa de Presentacin 20%

2.1.2 Capa de Lgica de Negocio

2.1.3 Capa de Persistencia

2.1.4 Desarrollo Adicional

2.2.1 Tamao del Producto

Lneas de Cdigo Implementadas y Planeadas

Figura 12 - Lneas de Cdigo Implementadas y Planeadas

Lneas de Cdigo Implementadas y Planeadas por Capa

Capa de Lgica de Negocio

Figura 13 - Lneas de Cdigo Implementadas y Planeadas por Capa

Nmero de Clases Implementadas

Capa de Presentacin 52 Capa de Lgica de Negocio Capa de Persistencia 37

Figura 14 - Nmero de Clases Implementadas

Nmero de Mtodos Implementados

155 191 Capa de Presentacin Capa de Lgica de Negocio Capa de Persistencia

2.3.1 Planeacin Individual

Tiempos por Semana: Jess Vargas

Promedio 12.52 13.86

2.3.1.2 Lder de Desarrollo

Tiempos por Semana: Andrs Gonzlez

Promedio 4.15 4.15

2.3.1.3 Lder de Planeacin

Tiempos por Semana: Pedro Feijoo

Promedio 4.83 5.91

2.3.1.4 Lder de Calidad

Tiempos por Semana: Camilo Restrepo

Promedio 4.30 4.45

2.3.1.5 Lder de Soporte

Tiempos por Semana: Wilson Guarn

Promedio 4.47 4.50

2.3.2 Planeacin Grupal

Tiempo Planeado vs Real: Grupo

Figura 21 - Tiempo Planeado y Real: Grupo

Tiempos Integrantes del Grupo

Figura 22 - Tiempos por Integrante del Grupo

2.3.3 Valor Ganado Valor Ganado

Figura 23 - Valor Ganado