Trabajo PrácticoTaller de Desarrollo de Proyectos 2

Septiembre Septiembre 20092009

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/11/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 aprendidas1/11/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/31/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/32/3

Planificación

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

3/33/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 tutor1/21/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/22/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/11/1

Arquitectura y diseño técnico

• Arquitectura de redes de Cliente-Servidor• Arquitectura de Software MVC

1/11/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/21/2

Seguimiento y Control de Cambios

• Gestión de Riesgos– Según la metodología adoptada.

2/22/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/11/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/21/2

Pruebas

• Seguimiento de Bugs– Bugzilla

– Maven

1/21/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/11/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/11/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/11/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/11/1