La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Proyecto de Ingeniería de Software 2010 Proceso Grupo 8 Directora: Leticia Pérez Facultad de Ingeniería.

Presentaciones similares


Presentación del tema: "Proyecto de Ingeniería de Software 2010 Proceso Grupo 8 Directora: Leticia Pérez Facultad de Ingeniería."— Transcripción de la presentación:

1 Proyecto de Ingeniería de Software 2010 Proceso Grupo 8 Directora: Leticia Pérez Facultad de Ingeniería

2 Introducción Presentación del Proyecto Líneas de trabajo Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto Fases Duración temporal Inicial Elaboración Construcción Transición Agenda 2 Evaluación Equipo Modelo de Proceso Cliente Director

3 3 Introducción Equipo: 13 integrantes Modelo de proceso: MUM - Modularizado, Unificado y Medible Producto: Sistema de Gestión de Horas Sistema de Gestión de Currículum Vitae Tecnología:.NET Cliente: Matías Bergengruen – Hexacta S.R.L. Directora: Leticia Pérez

4 4 Presentación del Proyecto Diseño de un proceso de registro de horas 3 macro funcionalidades: Registro de horas Presupuesto de proyectos Base de datos del personal Resultados esperados: Proyecto metodológicamente bien organizado Cumplir con las diferentes etapas de un proyecto de ingeniería de Software Producto final con altos estándares de calidad Hexacta S.R.L. Usuario final: Hexacta S.R.L.

5 Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto 5 Líneas de Trabajo

6 Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto 6 Líneas de Trabajo

7 7 Requerimientos Metodología: 2 reuniones semanales durante la primer iteración De ahí en adelante 1 reunión por semana Apuntes para luego realizar actas de requerimientos Requerimientos ordenados por prioridad, sirvió para definir el alcance

8 8 Requerimientos Evaluación de Requerimientos: Captamos principales intereses del cliente Manejamos con cierta flexibilidad los cambios propuestos Documentos con alto grado de especificación y calidad Lecciones aprendidas: Discernir entre requerimientos críticos y superficiales El cliente presenta cambios de acuerdo a sus facilidades de uso Importancia de la validación de los requerimientos

9 Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto 9 Líneas de Trabajo

10 10 Diseño Semana a semana Adelantado una semana con respecto a implementación Se retenía perfectamente el diseño ante una posibilidad de cambio Involucrados: Arquitecto – Martín Rodríguez Responsable de especialistas técnicos – Juan Pablo Perata Responsable de analistas – Cecilia Brown Metodología: La visión y cooperación de las 3 áreas ayudó a diseñar mejor

11 11 Diseño Evaluación de Diseño: Metodología ordenada desde un principio Se completó diseño en fase de elaboración Resultados muy buenos, consecuencia de Análisis exitoso Alta calidad en los documentos de diseño Lecciones aprendidas: Es bueno contar con diferentes visiones a la hora de diseñar Tener presente patrones de diseño y criterios GRASP Importancia de la documentación de Diseño

12 Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto 12 Líneas de Trabajo

13 13 Implementación Investigación de tecnologías y Preparación de ambiente Esfuerzo considerable, pero necesario Reuniones periódicas para llevar a cabo la implementación Ventajas En caso de surgir dudas a un integrante, el apoyo es fundamental Desventajas Posible dispersión... No fue nuestro caso, grupo muy aplicado Funcionalidades críticas implementadas en conjunto Ventajas Mayor prevención ante la introducción de errores Todos los integrantes conocen la solución implementada Desventajas Pérdida de horas hombre Metodología:

14 14 Implementación Metodología (cont.): Luego de finalizar cada CU se realizaban pruebas unitarias Ventajas Reducción de errores en etapa de Verificación Evaluación de Implementación: Equipo de implementación lógica muy organizado, siempre adelantado Alto grado de correctitud en lo implementado Problemas con la interfaz gráfica, abordaje de nuevas tecnologías Lecciones aprendidas: Seguir fielmente la planificación realizada Abordar cuanto antes las nuevas tecnologías

15 Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto 15 Líneas de Trabajo

16 16 Verificación Actividades: Pruebas Unitarias Pruebas de Integración Pruebas del sistema Pruebas de Stress Visual Studio Team System Mantis Bug Tracker para reportar incidentes de la aplicación Open STA para automatización de pruebas Fiddler2 para captura de tráfico HTTP Herramientas:

17 17 Verificación Pruebas Unitarias Capa lógica Realizadas por el equipo de implementación lógica para cada liberación del producto Interfaz gráfica Menos formal, realizadas por el equipo de GUI Pruebas de Integración Realizadas por el equipo de GUI luego de integración Pruebas del Sistema Se generó un ambiente similar al de Hexacta Testing Planificado Exploratorio basado en sesiones Pruebas de Stress Simulamos hasta 20 usuarios virtuales concurrentes

18 18 Verificación Evaluación de Verificación: Estricta verificación, resultados muy buenos. Cliente muy satisfecho Metodología de manejo de incidentes muy organizada y eficaz Otorgamos al cliente un usuario en Mantis Lecciones aprendidas: La verificación debe ser planificada con anterioridad No se pueden descuidar errores de estética, ortografía, etc. Verificar en mismo ambiente donde se utilizará el sistema Importancia de documentación de Verificación para continuar el desarrollo por parte de la empresa

19 Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto 19 Líneas de Trabajo

20 20 Gestión de Calidad Elaborar Plan de Calidad Identificar propiedades de calidad Revisión de documentos críticos Especificación de Requerimientos Especificación de la Arquitectura Modelos de Casos de Usos Modelo de Diseño Revisión técnica formal (RTF) Estándares de Implementación HEXACTA Estándar W3C para la Web Validación de la Arquitectura – Estándar ATAM Apoyo a otras líneas de trabajo Verificación - calidad del software Gestión de Proyecto - estimaciones Actividades:

21 21 Gestión de Calidad Evaluación de Gestión de Calidad: Documentos entregados de muy alta calidad Correcto apego al modelo de proceso Sistema construido con altos estándares de calidad Lecciones aprendidas: Las RTFs son necesarias, errar es humano Evitar la famosa cascada de Mizuno

22 Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto 22 Líneas de Trabajo

23 23 Gestión de la Configuración Planificar la configuración de SCM Organización sugerida por el proceso MUM Definición de ambiente controlado Definición de elementos de configuración Nomenclatura bien definida Seguimiento de la línea base Semanal Documentación de SCM Descripción y notas de las versiones Plan de SCM Informe final de SCM Actividades:

24 24 Gestión de la Configuración Control de cambios Solicitud Evaluación y análisis Esfuerzo estimado vs satisfacción/necesidad del cliente Imposible llevar a cabo todos los cambios Aprobación o no Comité de Control de Cambios toma la decisión Implementación Actividades (cont.): Repositorio Tortoise SVN Espacio brindado por Assembla Herramientas:

25 25 Gestión de la Configuración Evaluación de SCM: Se realizó una correcta gestión de la configuración Se siguió de manera adecuada la planificación Lecciones aprendidas: Aprender a evaluar los cambios propuestos por el cliente Versiones de respaldo organizadas Aprender a trabajar con trunk, branches y tag

26 Requerimientos Diseño Implementación Verificación Gestión de Calidad Gestión de la Configuración Gestión de Proyecto 26 Líneas de Trabajo

27 27 Gestión de Proyecto Planificación del proyecto Cliente sugiere armar el plan cuanto antes. Acatamos, gran consejo Lenguaje común, Microsoft Project Seguimiento del proyecto Semanal, entregando la planificación actualizada al cliente Gestión de riesgos Buena organización desde el comienzo Algunos riesgos no contemplados Inconvenientes con el ambiente de Hexacta Estimaciones y mediciones Puntos de función Juicio de expertos Conversión de horas estimadas a LOCs Actividades:

28 28 Gestión de Proyecto Horas dedicadas por semana Total horas proyecto : 3652 hs Promedio equipo por sem: 261 hs Promedio integrante por sem: 20.1 hs Total horas proyecto : 3652 hs Promedio equipo por sem: 261 hs Promedio integrante por sem: 20.1 hs

29 29 Gestión de Proyecto Horas dedicadas por fase Promedio equipo por fase: 913hs Promedio integrante por fase: 70.2 hs Promedio equipo por fase: 913hs Promedio integrante por fase: 70.2 hs

30 30 Gestión de Proyecto LOCs Herramienta utilizada: NDepend

31 31 Gestión de Proyecto Estimaciones vs Reales

32 32 Gestión de Proyecto Evaluación de Gestión de Proyecto: Documentos entregados de muy alta calidad Buenas estimaciones Planificación muy organizada Seriedad y prolijidad Lecciones aprendidas: No se aprende a estimar sino estimando Es bueno planificar en grupo Tener una visión global del proyecto y del proceso Incentivar a los integrantes para mejor funcionamiento

33 33 Fases Distribución temporal Fase Inicial Fase de Elaboración Fase de Construcción Fase de Transición

34 34 Fases Distribución temporal Fase Inicial Fase de Elaboración Fase de Construcción Fase de Transición

35 35 Distribución temporal Fase Inicial 4 semanas Fase Elaboración 4 semanas Fase Construcción 4 semanas Fase Transición 2 semanas Realizado Propuesto Fase Inicial 4 semanas Fase Elaboración 4 semanas Fase Construcción 5 semanas Fase Transición 1 semana

36 36 Fases Distribución temporal Fase Inicial Fase de Elaboración Fase de Construcción Fase de Transición

37 37 Fase Inicial Duración 4 semanas Logros Adaptación al proceso Requerimientos Maquetación de prototipo. Interfaz gráfica muy prolija Alcance definido Errores No se especificaron algunas bajas y modificaciones Atraso en la Validación de requerimientos No formalizar el diseño del prototipo de riesgos técnicos

38 38 Fase Inicial Horas por Disciplina

39 39 Fase Inicial Horas por Rol

40 40 Fase Inicial Horas por Integrante Total : 1060 hs Prom sem: 20.4 hs

41 41 Fases Distribución temporal Fase Inicial Fase de Elaboración Fase de Construcción Fase de Transición

42 42 Fase de Elaboración Duración 4 semanas Logros Estabilización de la Arquitectura Diseño completo Funcionalidades críticas implementadas Planificación cumplida Errores Desconocer el esfuerzo requerido para interfaz gráfica No investigar soluciones más eficientes. Pérdida de tiempo

43 43 Fase de Elaboración Horas por Disciplina

44 44 Fase de Elaboración Horas por Rol

45 45 Fase de Elaboración Horas por Integrante Total : 860 hs Prom sem: 16.5 hs

46 46 Fases Distribución temporal Fase Inicial Fase de Elaboración Fase de Construcción Fase de Transición

47 47 Fase de Construcción Duración 5 semanas Logros Construcción completa del sistema Aprendizajes de nuevas tecnologías Planificación cumplida Errores Descuidar errores ortográficos Corrección de errores en Trunk en vez de realizar branch versión de testing No finalizar documentación técnica

48 48 Fase de Construcción Horas por Disciplina

49 49 Horas por Rol Fase de Construcción

50 50 Fase de Construcción Horas por Integrante Total : 1434hs Prom sem: 22 hs

51 51 Fases Distribución temporal Fase Inicial Fase de Elaboración Fase de Construcción Fase de Transición

52 52 Fase de Transición Duración 1 semanas Logros Instalación en la empresa Documentación de usuario y técnica completa Satisfacción del cliente Errores Comunicación menos organizada Ambiente acordado no disponible Atrasos en la validación final

53 53 Fase de Transición Horas por Disciplina

54 54 Horas por Rol Fase de Transición

55 55 Fase de Transición Horas por Integrante Total : 295hs Prom sem: 22,7 hs

56 Evaluación 56 Equipo Primeras semanas un poco desorientados Integrantes muy responsables Muy buena integración, algunas áreas menos homogéneas Muy enriquecedor haber compartido esta experiencia juntos Modelo de Proceso Aceptable y Completo Cliente Trato cordial, respetuoso y con confianza Experiencia en desarrollo de software Buena predisposición, alta disponibilidad Muy exigente Director 100% de la confianza depositada en nosotros Muy optimista, siempre alentando al equipo, gran apoyo

57 Preguntas 57


Descargar ppt "Proyecto de Ingeniería de Software 2010 Proceso Grupo 8 Directora: Leticia Pérez Facultad de Ingeniería."

Presentaciones similares


Anuncios Google