Proyecto HelpDesk sobre

plataforma Link-All

Grupo 05

Proyecto de Ingeniería de Software 2005

Proceso

Proceso

Agenda Requerimientos Diseño Implementación Implantación SCM Verificación SQA Gestión y Fases Evaluación del proceso

Reuniones de Requerimientos

Planificación de las reuniones.

Un encargado para consultar.

Realización: Dos veces por semana hasta la semana 5. Una vez por semana en la semanas 6 y 7.

Elaboración del acta Envía por mail a los clientes – semana 3 en adelante

Poseemos 2 clientes Consultas por separado.

Alcance

Primer Alcance – semana 5 27 Casos de Uso identificados. 21 Casos de Uso en el alcance. Primer alcance total del proyecto.

Segundo Alcance – semana 9 37 Casos de Uso identificados. 20 Casos de Uso en el alcance. Funcionalidades que no se podían mostrar antes.

Tercer Alcance – semana 10 38 Casos de Uso identificados. 20 Casos de Uso en el alcance. Alcance Final del Proyecto

Requerimientos

Debilidades Demora en comprender lo

que el cliente quería.

Inconsistencias en el grupo sobre “la realidad”.

Demora en la negociación del alcance.

Demoras para que el cliente pudiera “Ver” lo que se le había hecho.

Fortalezas Excelente relación con el

cliente. Acuerdo en cuanto a la

validación de Requerimientos.

Acuerdo en lo que refiere a los Casos de Uso Relevantes para la Arquitectura.

Mejoras luego de la presentación de la línea base de la arquitectura

Conclusiones

Relevamiento y validación de todos los requerimientos.

Identificación de los Casos de Uso Relevantes para la Arquitectura.

Excelente relación con los clientes.

Atraso en Fase Inicial, recuperado en Fase de Elaboración.

Diseño

Diseño

Metodología A partir de los casos de uso, se identificaron los

principales servicios, con su respectiva granularidad.

Soporte en SOA Consulta a los implementadores acerca de la

viabilidad del diseño. Modelo de Diseño innecesario para la fase de

Elaboración. Si en Construcción

Diseño

Dificultades Inexperiencia en SOA

Identificación y granularidad de servicios Herramientas a utilizar

JBPM ?¿? Alto grado de configuración del sistema Relevamiento de requerimientos Gran cantidad de documentación

Diseño

Fortalezas Se consiguió un diseño que

agradó al cliente Sé logró integrar el

HelpDesk a la plataforma Link-All

El sistema no queda atado al motor de workflow utilizado

La comunicación con el equipo de implementadores mejoró en el correr del proyecto.

Debilidades El atraso en la

documentación del diseño en fase inicial.

Documento de buena calidad o entrega en fecha?

Comunicación del diseño Falta de preocupación de

los implementadores por asegurarse de estar haciendo lo que se necesitaba.

Poco énfasis en saber si todos los implementadores sabían lo que debían hacer.

Conclusiones

Se llegó a un diseño del agrado del cliente

Se adquirió experiencia en el diseño de un sistema orientado a servicios

Actualmente se conocen cuales son las dificultades en la comunicación del diseño

Implementación

Bugs de plugin WTP de Eclipse Plugin en su primer versión

Numerosos bugs. Se encontraron caminos alternativos que permitían trabajar con la

herramienta sorteando los bugs de la misma.

Inexperiencia en tecnología J2EE Problemas con servidor JBoss

Para realizar deploy de módulos. Para ver reflejados los cambios en módulos (refrescar módulos

deployados borrando archivos temporales del servidor).

Poca documentación de JBPM Documentación escasa y no muy detallada Soluciones:

Foros. Código fuente de la herramienta. Ensayo y error.

Problemas técnicos

Implementación Fortalezas

Prototipos: De fase inicial Mitigar riesgos tecnológicos

• JBPM• Interacción con plataforma

LinkAll De fase elaboración

• Prototipo evolutivo.• Con los casos de uso

relevantes a la arquitectura.

Uso del CVS desde el comienzo de la implementación

Favoreció la implementación en paralelo.

Realización de Junit para pruebas unitarias y de integración.

Debilidades Comunicación entre los

implementadores en las etapas iniciales.

Integraciones mas extensas de lo planificado, con alto nivel de errores y complicaciones.

Alto desgaste de quienes sufrían las integraciones.

Escasa documentación técnica. Javadoc

Falta de documentación de pruebas unitarias

Conclusiones

Poca experiencia en uso de tecnologías Jugaron en contra de la productividad.

Implementación del alcance comprometido a costo de sobre dedicación. Compromiso del equipo con el producto y con el cliente.

Implantación

Manual de usuario El cliente considero que no eran necesarios, por lo que no se realizaron. Páginas de ayuda en formato html (ingles y español) por funcionalidad para Help

Contextual. Introducción del Help Desk desde el punto de vista del usuario, para presentación en

el exterior, a pedido del cliente.

Manual de configuración Detalle de cómo configurar cada una de las opciones de la aplicación.

Instalación Fácil y sin complicaciones

No mas de 15 min. de duración. Típica instalación de aplicación Web, basada en deploy de empaquetado de la

aplicación y binarios para la creación del ambiente de base de datos. Se realizaron 2 instalaciones:

Versión alfa de la aplicación Versión alfa con correcciones realizadas en transición.

Se entrega una versión posterior con algunas correcciones mas impactadas.

Implantación

SCM

Herramientas utilizadas

Plugin de eclipse para manejo de CVS Utilizado para el manejo de fuentes en el repositorio. Excelente interfaz grafica que proporciona muchas funcionalidades

integradas en el ambiente de trabajo de implementación. Fundamental para resolver conflictos, realizar merges ante la

modificación de fuentes por varios implementadores, gracias a su excelente interfaz grafica, que facilita al máximo la realización de estas tareas.

TortoiseCVS Utilizado para el manejo de documentos en el repositorio. Fue fundamental para fomentar el uso del CVS como repositorio de

documentos, ya que por su facilidad de uso, posibilito que todos los miembros del equipo pudieran utilizar el repositorio sin problemas.

SCM

Fortalezas Definición del ambiente

controlado, con buena documentación para los usuarios.

Definición de criterios de versionado.

CVS como repositorio común de documentos y de los fuentes de la aplicación.

Tags semanales y por iteración favorecieron la recuperación de versiones.

Debilidades Inexperiencia en el área Atraso en la definición

del ambiente controlado. Falta de auditorias a la

línea base.

Conclusiones

Uso intensivo del CVS. Proporciono un lugar común donde buscar las últimas versiones de

todos los documentos, estando disponibles a todos los miembros del equipo.

Favoreció el trabajo en paralelo por parte del grupo de implementadores.

Permitió mitigar los riesgos de pérdidas de versiones de documentos y fuentes.

Poca dedicación al área en etapas avanzadas de la implementación. Repercutió en pocas actividades realizadas.

Verificación

Verificación

Metodología (I) Verificación Unitaria

Especificación de pruebas• Iterativa e incremental.• Caja negra usando particiones de equivalencia.

Implementación de pruebas• Herramienta utilizada: JUnit

Verificación de Integración Especificación de pruebas

• Tiene como base la verificación unitaria• Forma de comunicación entre los módulos

Estrategia de integración: Bottom-Up Implementación de pruebas

• Drivers: JUnit implementados para el modulo

Metodología y resultados

Metodología (II) Verificación del Sistema

Se recibía una versión del producto por iteración y sobre las funcionalidades implementadas, se realizaban pruebas.

La aplicación brinda 3 tipos roles (usuario, administrador, técnico) Se hizo una paralelismo con los asistentes y se les asigno un rol a cada uno

• Cada uno de ellos verifico su rol

Los CU sin roles, se asignaban según la carga horaria Fallas encontradas se reportaban en el Bugzilla, estas eran asignadas al

responsable de cada modulo

Verificación de Documentos Para cada iteración, se verificaban los documentos planificados en base a la

disponibilidad de los mismos

Metodología y resultados

Resultados

0

50

100

150

200

250

300

350

400

F2-IT

2

F3-IT

1

F3-IT

2

Aplicación-Errores por iteración

Pruebasespecificadas

Erroresdetectados

0

5

10

15

20

25

F2-IT

1

F2-IT

2

F3-IT

1

F3-IT

2

Documentos-Errores por Iteración

Docs.Planificados

Docs.Verificados

Erroresdetectados

Verificación

Fortalezas La dinámica de detección y

corrección de errores mejoró a lo largo del proyecto

Alta dedicación a la especificación de las pruebas

Se logró dejar el producto en un nivel aceptable

Debilidades Inexperiencia en el área en

etapas tempranas Detección y corrección de

errores en fase elaboración y principio de construcción

Escaso margen entre la liberación de una versión estable y la fecha de entrega de la misma

Pocos de recursos para determinadas actividades del área (verif. docmentos)

Conclusiones

No se verificaron todos los documentos planificados Escasez de tiempo Documentos no entregados

Se corrieron las pruebas especificadas, pero no como fueron planificados

Se entregó una versión estable y funcional del producto

Gestión de Calidad

Propiedades de Calidad

Metodología Durante relevamiento de requerimientos se detectaron las

siguientes propiedades

Explícitas por el cliente Robustez Amigabilidad

Simple de usar Simple de instalar Simple de administrar

Mantenibilidad Extensible

Implícitas en el producto Correctitud Confiabilidad Performance

Actividades

Revisar las Entregas Los entregables que no se apegaban al estándar de las plantillas o no

cumplían con los requerimientos mínimos de calidad, eran corregidos por el Responsable de SQA.

Revisar el Ajuste al Proceso Durante todo el proyecto se comunicó a los integrantes del grupo los

entregables que tenían pendientes y los que tenían para entregar. Evaluar la Calidad de los Productos

Siguiendo el Plan de SQA. Se basó en Checklist. Si se encontraban errores se enviaba el informe al responsable del

documento Revisión Técnica Formal

Se basó en Checklist. Se realizó a:

Modelo de Casos de Uso Descripción de la Arquitectura

Conclusiones

Inexperiencia en el área. Dificultad para comprender las actividades. No se realizaron todas las RTF planificadas, por no

estar disponibles los documentos a tiempo para revisar.

Se realizaron el 95% de las actividades planificadas.

Se realizaron todos los entregables. Aportó a la calidad de la documentación. Aportó al apego al proceso.

Gestión de Proyecto

Proceso y Gestión

Fase Inicial Primera reunión quincenal

Roles de Verificador y SQA provisorios por P4• Agustín como SQA

Segunda reunión quincenal Que espera c/u del proyecto y que está dispuesto a dejar Objetivo como grupo para el proyecto

Tercera reunión Evaluamos la fase y decidimos no pasar Objetivos del grupo para la siguiente fase

• Coinciden los objetivos del grupo con los del proceso

1354

0

200

400

600

800

1000

1200

1400

1600

Fase Inicial

828

526

Horas de Fase Inicial y cada Iteración

LOC’s nuestras = 956Horas = 132

Productividad = 7,42

Fase Inicial

Esfuerzo por Rol

Gestión18015%

Comunicación161%

Verificación675%

Implementación18220%

Arquitecto125,510%

Analistas45238%

SQA101,58%

SCM60,55%

Fase Inicial

Esfuerzo por Área

310

99

138

44,555,5

273,5

85,5

30

184

0

50

100

150

200

250

300

350

Req Diseño Impl Verif G. SCM GP G SQA Com Estudio

Fase Inicial

Horas por integrante

90,5131

129,586

109

70,597

83

8686,5

73

0 20 40 60 80 100 120 140

J avier

Marcelo

Pablo

Hugo

Marcel

Martín

Agustín

Guzmán

Francy

Sebastián

Ignacio

Promedio

Fase Inicial

Fortalezas• Compromiso del grupo• Objetivo en común• Prototipo de JBPM• Prototipo LinkAll

Debilidades Retraso de la documentación de

Arquitectura 2 Analistas -> “Secretarias”,

digitalizan diseño Lectura de documentos

Insistimos hasta el cansancio Se manda por mail la minuta de

los doc´s importantes Registro de Actividades

Se habla con la directora

Fase Inicial

Conclusiones: Se valida la Arquitectura y el alcance

Estimación = Pts función + Esp Técnicos Alcance enorme a costa de sobre dedicación

Planificamos Elaboración para 5 semanas y Construcción de 3 Poca flexibilidad de la instanciación del proceso

Atraso de una semana. Pasaje de dos analista a implementar sin interferir

Desorganización Riesgos

10 detectados, el de congestionamiento de doc’s no.

Proceso y Gestión

Debilidades Diseño cambiante Mala planificación

Foco en el plan de desarrollo

Mala comunicación SQA conociendo el rol

= CriticaFase de Elaboración

Fortalezas El atraso se absorbe en

transición, sugerencia Directora

Se comunica el atraso al cliente, reacciona bien

Fase Elaboración

Reunión quincenal Extraordinaria, semana 7 Que hacemos???? -> “PARATE” -> “Lan PIS Party” 11 hombres con 11 máquinas, un fin de semana todos

encerrados. RESULTADO ?¿

Positivisimo!• Nos conocimos mucho, Compañerismo• Se relacionaron roles que estaban separados• Se verificó y corrigió en el momento.

• No se usó bugzilla, esta vez, por esto. Negativo

• Primera “MARATÓN”• Se faltó a trabajar

Fase Elaboración

Horas Elaboración y sus Iteraciones

1607

0

200

400

600

800

1000

1200

1400

1600

1800

951

656

LOC’s nuestras = 16809Horas = 721

Productividad = 23,3

Fase Elaboración

Integración174,513%

Administrador1189%

Comunicación312%

Verificación1017%

Implementación

18220%

Arquitecto13510%

Analistas15511%

SQA92,57%

SCM342%

Esfuerzo por Rol

Fase Elaboración

Esfuerzo por Área

42,5 139,5

720,5

131

34

219,5

7631 48 11,5

0

100

200

300

400

500

600

700

800

Req Diseño Imple Verif G. SCM GP G SQA Com Estudio Impla

Fase Elaboración

Horas por integrante

232,5

341

343

256

263,5

240

220

264

266

281,5

254,5

0 100 200 300 400

J avier

Marcelo

Pablo

Hugo

Marcel

Martín

Agustín

Guzmán

Francy

Sebastián

Ignacio

Promedio

Fase Elaboración

Conclusiones Malas estimaciones Equipo muy cansado pero comprometido con que se “use” el

producto Horas de Integración = horas de Implementación

• Se empieza a planificar Énfasis en Verificación. Junit integración y unitario. Un compañero estresado 2 semanas de atraso Presentación del prototipo evolutivo

Calma la ansiedad del cliente y la desesperación de los implementadores

Cliente asume limitaciones de tiempo, prefiere algo “redondo” si no se llega al alcance

Proceso y Gestión

Debilidades 2a. versión del prototipo

No sabemos manejar la situación

Cliente no queda de todo conforme

Tomamos nota Corregimos lo que pudimos

para satisfacerlo Maratón 2

Faltamos a trabajar “otra vez”

Fortalezas Negociamos el alcance

Surgen 2 CU nuevos y necesarios.

Se reagrupan los CU para que la aplicación sea mas usable• Positiva para el grupo

Instalación Versión BETA Muy buena aceptación Repercute

en el ánimo del equipo

Fase Construcción

Fase Construcción

Horas Construcción y sus Iteraciones

1287

0

200

400

600

800

1000

1200

1400

619

670

LOC’s nuestras = 14360Horas = 663

Productividad = 21,6

Fase Construcción

Integración17918%

Administrador52,55%

Comunicación263%

Verificación78,58%

Implementación

18220%

Arquitecto126,513%

Analistas8,51%

SQA74,57%

SCM8,51%

Esfuerzo por Rol

Fase Construcción

Esfuerzo por Área

8,528,5

625

174,5

6,5

128

7426 14

50,5

0

100

200

300

400

500

600

700

Req Diseño Imple Verif G. SCM GP G SQA Com Estudio Impla

Fase Construcción Conclusiones

Negativas Extenuados y deseando que termine

Pero concientes de que es el último tirón Prácticamente perdimos el rol de SCM

Positivas Mejora en las estimaciones Atraso de 1 semana y media

Proceso y Gestión

Fase de Transición Instalamos un Jueves, dura 4 días

Se instala la versión ALFA ya terminado el PIS

SEMANA 15 IMPLEMENTANDO !!!! Se arreglan dos funcionalidades para que el

producto quede mas acabado. Compromiso, fanatismo o enfermismo?

Fase Transición

Esfuerzo por Área

05

35 34,5

2

15

5 4

0

4

0

5

10

15

20

25

30

35

Req Diseño Imple Verif G. SCM GP G SQA Com Estudio Impla

Totales del Proyecto

22,0357142927,03571429

32,4285714335,39285714

29,28571429

25,42857143

28,2529,42857143

25,7525,5

30,03571429

0

5

10

15

20

25

30

35

40

J avier Mar celo P ablo Hugo Mar cel Mar tín Agustín Guzmán Fr ancy Sebastián Ignacio

HorasPromedio

semanales por

Integrante

Proceso y Gestión TOTALES

Horas Totales por Integrante

334

442

466,5

365

319

328

284

359

376,5

377

336,6

0 50 100 150 200 250 300 350 400 450 500

J avier

Marcelo

Pablo

Hugo

Marcel

Martí n

Agustín

Guzmán

Francy

Sebastián

Ignacio

30 créditos?

Fases y sus respectivas Iteraciones

1354,5

1607,5

1287

98

0

200

400

600

800

1000

1200

1400

1600

1800

Fase Inicial Fase elaboracion FaseConstruccion

Fase Transicion

Ho

ras

526

828

526

828670

619

Proceso y Gestión TOTALES

LOC’s nuestras = 38401Horas Totales = 1516

Productividad Equipo = 25,3

Proyecto

Conclusiones Finales Se logró el alcance de ambas fases, con atraso, pero se

logró Se logró el alcance total, en semana “15”

Se logró un producto aceptable. Se generó mucha capacidad

Relacionamiento interpersonal. Tecnologías. Experiencia en áreas desconocidas. Nos cambió la cabeza. Un antes y un después del pis.

Proyecto

Conclusiones (Cont.)

Generamos buenas relaciones Laura, Federico, Andrea.

UN GRUPO DE AMIGOS Principal objetivo definido en fase inicial

Lecciones Aprendidas

Mala distribución del trabajo en implementación se propaga durante el proyecto

• Tampoco se les podía tocar “su” código

Distribuimos en forma ineficiente los roles según las capacidades que cada uno tenía y en lo que trabaja.

• Lo queríamos así de todos modos.

Es muy complicado estimar

Evaluación del proceso

Mejoras Inestabilidad del sitio web al comienzo generó sensación

de “desconfianza” Poca flexibilidad de la instanciación del proceso

Duración de cada fase estática Lecciones aprendidas

Beneficios Base para orientarnos al comienzo La mayoría de los objetivos grupales coincidieron con los

del proceso

FIN

PREGUNTAS

Créditos

Agradecimientos Martín por la casa y la limpieza Madre Javier por las tortas Novias que están

Y a las que ya no Andrea por el Aguante!!!!

Fase Transición

Integración5

5%

Administrador25

23%

Comunicación4

4%

Verificación34,530%

Implementación

18220%

Arquitecto5

5%

Analistas0

0%

SQA5

5%

SCM2

2%

Esfuerzo por Rol