Proyecto HelpDesk sobre plataforma Link-All Grupo 05 Proyecto de Ingeniería de Software 2005 Proceso.

Presentación del tema: "Proyecto HelpDesk sobre plataforma Link-All Grupo 05 Proyecto de Ingeniería de Software 2005 Proceso."— Transcripción de la presentación:

1 Proyecto HelpDesk sobre plataforma Link-All Grupo 05 Proyecto de Ingeniería de Software 2005 Proceso

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

3 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.

4 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

5 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

6 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.

7 Diseño

8 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

9 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

10 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.

11 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

12 Implementación

13 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

14 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

15 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.

16 Implantación

17 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

18 SCM

19 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.

20 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.

21 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.

22 Verificación

23 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

24 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

25 Resultados

26 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)

27 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

28 Gestión de Calidad

29 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

30 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

31 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.

32 Gestión de Proyecto

33 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

34 Fase Inicial 828 526 Horas de Fase Inicial y cada Iteración LOC’s nuestras = 956 Horas = 132 Productividad = 7,42

35 Fase Inicial Esfuerzo por Rol

36 Fase Inicial Esfuerzo por Área

37 Fase Inicial Horas por integrante Promedio

38 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

39 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.

40 Proceso y Gestión Debilidades Diseño cambiante Mala planificación Foco en el plan de desarrollo Mala comunicación SQA conociendo el rol = Critica Fase de Elaboración Fortalezas El atraso se absorbe en transición, sugerencia Directora Se comunica el atraso al cliente, reacciona bien

41 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

42 Horas Elaboración y sus Iteraciones 951 656 LOC’s nuestras = 16809 Horas = 721 Productividad = 23,3

43 Fase Elaboración Esfuerzo por Rol

44 Fase Elaboración Esfuerzo por Área

45 Fase Elaboración Horas por integrante Promedio

46 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

47 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

48 Horas Construcción y sus Iteraciones 619 670 LOC’s nuestras = 14360 Horas = 663 Productividad = 21,6

49 Fase Construcción Esfuerzo por Rol

50 Fase Construcción Esfuerzo por Área

51 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

52 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?

53 Fase Transición Esfuerzo por Área

54 Totales del Proyecto Horas Promedio semanales por Integrante

55 Proceso y Gestión TOTALES Horas Totales por Integrante 30 créditos?

56 Proceso y Gestión TOTALES LOC’s nuestras = 38401 Horas Totales = 1516 Productividad Equipo = 25,3

57 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.

58 Proyecto Conclusiones (Cont.) Generamos buenas relaciones Laura, Federico, Andrea. UN GRUPO DE AMIGOS Principal objetivo definido en fase inicial

59 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

60 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

61 FIN PREGUNTAS

62 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!!!!

63 Fase Transición Esfuerzo por Rol