La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Proyecto de Ingeniería de Software 2010 Proceso

Presentaciones similares


Presentación del tema: "Proyecto de Ingeniería de Software 2010 Proceso"— Transcripción de la presentación:

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

2 Agenda Evaluación 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 Evaluación Equipo Modelo de Proceso Cliente Director

3 Introducción Equipo: Modelo de proceso: Producto: Tecnología: Cliente:
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 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 Usuario final: Hexacta S.R.L.

5 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

6 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

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 Requerimientos Evaluación de Requerimientos: Lecciones aprendidas:
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 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

10 Diseño Metodología: 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 La visión y cooperación de las 3 áreas ayudó a diseñar mejor

11 Diseño Evaluación de Diseño: Lecciones aprendidas:
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 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

13 Implementación Metodología:
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 Mayor prevención ante la introducción de errores Todos los integrantes conocen la solución implementada Pérdida de horas hombre

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

16 Verificación Herramientas: Actividades: Pruebas Unitarias
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 Actividades: Pruebas Unitarias Pruebas de Integración Pruebas del sistema Pruebas de Stress

17 Verificación Pruebas Unitarias Pruebas de Integración
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 Verificación Evaluación de Verificación: Lecciones aprendidas:
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 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

20 Gestión de Calidad Actividades: 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

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 RTF’s son necesarias, errar es humano Evitar la famosa cascada de Mizuno

22 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

23 Gestión de la Configuración
Actividades: 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

24 Gestión de la Configuración
Actividades (cont.): 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 Herramientas: Repositorio Tortoise SVN Espacio brindado por Assembla

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

27 Gestión de Proyecto Actividades: 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 LOC’s

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

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

30 Herramienta utilizada: NDepend
Gestión de Proyecto LOC’s Herramienta utilizada: NDepend

31 Gestión de Proyecto Estimaciones vs Reales

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 Fases Distribución temporal Fase Inicial Fase de Elaboración
Fase de Construcción Fase de Transición

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

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

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

37 Fase Inicial Duración Logros Errores 4 semanas 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 Fase Inicial Horas por Disciplina

39 Fase Inicial Horas por Rol

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

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

42 Fase de Elaboración Duración Logros Errores 4 semanas
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 Fase de Elaboración Horas por Disciplina

44 Fase de Elaboración Horas por Rol

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

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

47 Fase de Construcción Duración Logros Errores 5 semanas
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 Fase de Construcción Horas por Disciplina

49 Fase de Construcción Horas por Rol

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

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

52 Fase de Transición Duración Logros Errores 1 semanas
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 Fase de Transición Horas por Disciplina

54 Fase de Transición Horas por Rol

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

56 Evaluación Equipo Modelo de Proceso Cliente Director
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


Descargar ppt "Proyecto de Ingeniería de Software 2010 Proceso"

Presentaciones similares


Anuncios Google