View
108
Download
0
Category
Preview:
Citation preview
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
Recommended