Trabajo Práctico Taller de Desarrollo de Proyectos 2 Septiembre 2009

Características Destacadas del Proyecto FIUBA – Trabajo Práctico Red Social Alcance General Especificado Solo 3 estadísticas quedan por definir. Equipo definido, cuatro personas. Parte del calendario prefijado, cierre: Diciembre. Contacto directo con el Cliente (la cátedra). Disponibilidad de reuniones semanales con el Cliente. Dedicación part-time de todos los integrantes del equipo. Tecnología y licencias sin restricciones. No se requiere Mantenimiento. 1/1

Administración del Proyecto Planificación Análisis Configuración y versionado Arquitectura y Diseño técnico Pruebas Unitarias automatizadas Seguimiento y Control Comunicación Pruebas Trazabilidad Plan y estrategia de despliegue Criterios de Aceptación de la entrega Cierre y lecciones aprendidas 1/1

Planificación Alcance –Documento inicial de la Cátedra –WBS –Puntos de Función –Casos de Uso –Los riesgos económicos del proyecto son despreciables Estimaciones –Por Experto (ya realizada) –Por Casos de Uso (inicial para comparar) –Por Puntos de Función (inicial y de control continuo) Equipos –. –Alejandro Ferrer 1/3

Planificación Roles –Administrador de Proyecto –Responsable de Negocio –Responsable de Desarrollo –Responsable de Pruebas –Responsable de Configuración –Desarrollador –Controlador de Calidad de Producto –Controlador de Calidad de Proceso (Auditor) –Cliente –Responsable de Usuarios Metodología –Variación de Scrum adaptada para este contexto. Resulta algo muy similar a APF (Adaptative Project Framework) con CU. Calendarización –Iteraciones de quince (15) días. 2/3

Planificación Asignación de Tareas –A realizar en base a la Asignación de Roles (no resuelta aún). 3/3

Análisis Identificación de Requerimientos –No funcionales (basado en el documento de cátedra) Tecnología de libre decisión No hay especificaciones de Prestación de Servicios. No hay especificaciones de Tiempos de Respuesta. No hay restricciones de acceso a medios de almacenamiento o recursos de procesamiento. No hay condicionamientos por parte de la cultura de la organización. –Funcionales A profundizar con el tutor 1/2

Análisis Especificación Funcional –Casos de Uso –Diagramas UML –Puntos de Función Riesgos reconocidos al Inicio –Es la primera vez que trabajamos juntos en equipo. –No tenemos la misma experiencia en el desarrollo de este tipo de sistemas. –El alcance está poco especificado 2/2

Configuración y Versionado Tecnología de desarrollo JAVA 5 Herramienta de desarrollo Eclipse Frameworks –Sprint –Struts 2 –Hibernet –JUnit Servidor de Aplicaciones Tomcat Servidor de Base de Datos PostgreSQL Herramientas de documentación: Enterprise Architect y JavaDoc Controlador de versiones Subversion Seguimiento de tareas Bugzilla Ambientes de Desarrollo, Pruebas y Producción diferenciados, operando según la metodología. Administración del proyecto con Maven Herramienta de pruebas JMeter. 1/1

Arquitectura y diseño técnico Arquitectura de redes de Cliente-Servidor Arquitectura de Software MVC 1/1

Seguimiento y Control de Cambios Indicadores y Métricas –Como no vamos a aportar a una base de conocimiento de proyectos, no utilizaremos métricas con esos fines. –Como no tenemos riesgos económicos no utilizaremos esas métricas. –Como los Cambios de Alcance están acotados por definición no utilizaremos métricas de Pedidos de Cambios. –Como la organización es de baja madurez (es nuestro primer proyecto juntos) no utilizaremos métricas de retrabajo. –Métrica por Puntos de Función para defectos, pruebas completas y código completo. –Métrica EVM para performance del proyecto. 1/2

Seguimiento y Control de Cambios Gestión de Riesgos –Según la metodología adoptada. 2/2

Comunicación Reuniones quincenales con el Cliente. Reuniones semanales con el Equipo. Jerarquía de la comunicación en base a los roles. Centralización en base al objetivo de la misma. –Sobre administración del proyecto al Administrador del Proyecto. –Sobre pruebas al Responsable de Pruebas. –Etc. Copia de todas las comunicaciones (escritas o no –en forma de minuta-) al Administrador del Proyecto. Comunicación con el Cliente en base a Reuniones (con minutas), documentación entregada y exposiciones. 1/1

Pruebas Planificación y criterios de aceptación –Planificación por Casos de Uso o Puntos de Función, según el caso. –Aceptación bajo ejecución exitosa de todos los flujos involucrados. Diseño –Administrador del Proyecto (De Sistema, De Aceptación) –Responsable de Usuarios (De Aceptación, De Usabilidad) –Responsable de Pruebas (De Integración, De Sistema, De Aceptación, De Performance, De Volumen, De Usabilidad) –Responsable de Negocio (De Aceptación, De Usabilidad) –Desarrollador (Unitarias) –Documentado en Maven Ejecución –Desarrollador –Controlador de Calidad –Responsable de Usuarios 1/2

Pruebas Seguimiento de Bugs –Bugzilla –Maven 1/2

Trazabilidad Identificación única de los Requerimientos, de los Casos de Uso, de los Casos de Prueba, de los Puntos de Función y de cada versión de un Documento. Identificación por Marcas (Tags) en el Controlador de Versiones y/o dentro del código fuente. 1/1

Plan y Estrategia de Despliegue Entregas Incrementales semanales al Responsable de Pruebas. Entregas Incrementales por cada ciclo de desarrollo (quincenal) al Responsable de Usuarios. Una única versión al Cliente, final del cuatrimestre. 1/1

Criterio de Aceptación de la Entrega Basados en que entregamos una DEMO esto es una propuesta al Cliente: –En Casos de Uso: Todos los acordados con el Cliente. –En Puntos de Función, deducidos de ese alcance y especializándolo: 100% de los Esenciales (funcionalidad acordada) 85% de los Importantes (control de errores, solidez) 50% de los deseables (interfaz de usuario, etc.) 1/1

Cierre y Lecciones Aprendidas Se realizará una Reunión de Cierre al finalizar el proyecto para analizar las estadísticas entre todo el equipo de trabajo y el Cliente. 1/1