1 FIUBA 2.0 Grupo 3 Orlando Gerbolés Tomas Niño Kehoe Gustavo Narcisi Sabrina Marcus.
-
Upload
lorencio-corral -
Category
Documents
-
view
8 -
download
0
Transcript of 1 FIUBA 2.0 Grupo 3 Orlando Gerbolés Tomas Niño Kehoe Gustavo Narcisi Sabrina Marcus.
1
FIUBA 2.0Grupo 3
Orlando GerbolésTomas Niño KehoeGustavo NarcisiSabrina Marcus
2
ÍNDICE
Metodología Métricas Desvíos Solución elegida Lecciones aprendidas Herramientas Demo
3
METODOLOGÍA
4
METODOLOGIA
Utilizamos de guía los lineamientos de PMBOK en conjunto con conceptos básicos de LEAN Capítulo 5, 6, 7, 9, 10, 11 Alcance – Calendario – Estimación – EV – EP – CP Equipo de trabajo – Comunicaciones – Riesgos Lean es básicamente todo lo concerniente a
obtener las cosas correctas en el lugar correcto, en el momento correcto, en la cantidad correcta, minimizando el desperdicio, siendo flexible y estando abierto al cambio.
Haciendo foco en lo más importante para el cliente
5
MÉTRICASAnálisis de las métricas utilizadas
EVOLUCION DEL PROYECTO
EV
0
50
100
150
200
250
300
350
400
450
Tiempo
Co
sto
(H
H) PV
EV
AC
CPI (Trabajo completado por cada peso gastado): 0,91
SPI (Trabajo completado por peso planificado a completar): 1
CPI: 0,70
SPI: 0,95
SPI (Trabajo completado por peso planificado a completar): 0,70
CPI: 0,84
6
INDICADORES DE CONTROL
EP
CP
Evolución de la Prueba
0
20
40
60
80
100
120
140
160
Tiempo
Defe
cto
s
Defectostotales
Cerrados
Pendientes
Suspendidos
Cobertura de la Prueba
0
20
40
60
80
100
120
140
Tiempo
Caso
s d
e P
rueb
a
Planificados
Disponibles
Ejecutados
Ejecutados OK
7
8
DESVÍOSAnálisis de un desvío ocurrido
9
Cambio de lenguaje y herramientas de desarrollo
Se detecta un riesgo con alto impacto. R1 – Técnico - Los desarrolladores no conocen el lenguaje
de programación. (Documento de análisis de riesgos)
El riesgo se materializa al cabo de 4 semanas del inicio del proyecto.
Se informa al cliente la situación y el plan de contingencia y se toma la decisión en conjunto de aplicarla.
Se aplica el plan de contingencia cambiando de lenguaje y tecnología de desarrollo.
Las métricas se deben rehacer, se re-planifica el proyecto en cuanto a calendario, desarrollo, testing, etc.
10
SOLUCIÓN ELEGIDA
11
SOLUCION ELEGIDA
Lenguaje: ASP.NET - Framework 3.5 – C#
Base de datos MS SQL Express 2005
12
LECCIONES APRENDIDAS
13
SIN RESPONSABLES ASIGNADOS NO HAY COMPROMISO Y CALIDAD EN LAS TAREAS.
Tareas sin responsables fueron ejecutadas pero no se realizaron en forma completa.
No se testearon en su totalidad. Desorientación del equipo a la hora de
asignar un responsable para su finalización. Asignar responsables nos ayudo a dividir las
tareas y organizar mejor el trabajo.
14
DEMOSTRAR AL CLIENTE QUE TOMAMOS UNA MALA DECISION PERO TENEMOS ACCIONES PARA CORREGIR EL DESVIO NO ES UNA MUESTRA DE DEBILIDAD SINO DE MADUREZ
Selección inicial del lenguaje: Python Primer entrega desarrollada en Python y sin
funcionalidad completa Cambio de tecnología
ASP.NET Consecuencias
Motivación para desarrollar (tecnología conocida) Retrabajo – se reescribió lo pactado para la
primer entrega y se incluyó lo pactado para la segunda en una sola iteración.
Reestructuración de roles. Eliminación de riesgos
Se dejó de depender de la disponibilidad de una sola persona para el desarrollo, con lo cual la probabilidad de ocurrencia descendió.
15
ANALIZAR EL CONTEXTO NOS PERMITIO TOMAR EL CAMINO CORRECTO Contexto
Necesidad de desarrollo rápido La aplicación no evolucionará con el tiempo Aplicación no presenta alta complejidad Transacciones simples
Solución: Arquitectura basada en Transaction Script (Fowler - Patterns of Enterprise Application Architecture ) Sin modelo de dominio Acceso a los datos desde la capa de
presentación/servicios Consecuencias:
Velocidad en desarrollo Dificultad de agregar pruebas automatizadas Simplicidad (aprovechamos las herramientas que nos
brinda la IDE) Alcanzamos la funcionalidad acordada
16
AGREGAR FUNCIONALIDAD NO SOLICITADA ES UNA PERDIDA DE TIEMPO Y DINERO SIN NUNGUN AGREGADO AL PROYECTO
¿Qué es Gold-Plating? Implementar más funcionalidad o incluir
requerimientos adicionales desde el principio del proyecto resultando en una extensión del calendario, y generando valor artificial.
El cliente debiera en el tiempo pactado esperar y recibir exactamente lo que se especificó, ni más ni menos
En FIUBA20 Inclusión de funcionalidad no relevada:
Solicitud de alta y baja de grupo Funcionalidad no especificada se elimino luego de
mostrar los prototipos o las funcionalidades en reuniones formales
Retrabajo
17
LA CLAVE DE UN BUEN CONTROL ES APLICAR UN MODELO Y NO ENTRAR EN DETALLES QUE REQUIEREN MUCHO ESFUERZO
Se comenzó ponderando las horas trabajadas con el rol de cada integrante. Esto causo confusión y complicaciones a la hora de calcular en AC
Se dejó de ponderar con el rol, y se paso a sumar las horas cargadas directamente.
Como consecuencia se obtuvo un calculo mas sencillo, claro y comprensible por el cliente.
18
EL PROYECTO AVANZA SI QUEDA CONSTANCIA DE ELLO
Se tomó conciencia de que se necesitaba la registración por parte del cliente de los distintos artefactos del proyecto.
Se firmaron pruebas de aceptación de usuario.
La práctica de aceptación por parte del cliente es algo que se tiene que trabajar para que se logre la constancia.
Al no firmar los CU, el cliente podía llegar a rechazar el UAT sin siquiera ejecutarlo.
19
AL TRABAJAR EN UN GRUPO DISPERSO GEOGRAFICAMENTE, LA COMUNICACIÓN, GESTION Y TRAZABILIDAD ES LA CLAVE DEL EXITO
Grupo google y Skype.Administración del proyecto on-line.Seguimiento de los issues con comentarios
al hacer commits.Reuniones de avance semanalmente con
el cliente, con un entregas incrementales cada dos semanas.
20
CAMBIO DE ROLES SEGÚN NECESIDADES
Adaptación de los distintos integrantes a distintos roles
Con el cambio del lenguaje se readaptaron los roles
Versatilidad permitió que se pudiera avanzar dependiendo de disponibilidad de tiempo de cada uno
21
UNIFICACION DE CRITERIOS Diferentes criterios en definición de bugs
Qué es bug y qué no Cuándo un bug está cerrado y cuándo no
Solución buscada Determinar los criterios para establecer estándar propio
del grupo. Se consiguió aplicar en forma parcial. Se trató de unificar la forma de cerrar los bugs. Si lo que
se declaró en el issue está completado y se encuentra un nuevo bug, cerrarlo y abrir uno nuevo.
Cómo prevenirlo a futuro Preparar documentos de testing en forma conjunta y
antes de iniciar el desarrollo. Asegurarse de que todos los involucrados estén de
acuerdo con el documento.
22
PRUEBAS UNITARIAS Y SEPARACIÓN DE CAPA DE SERVICIOS
Separación de capa de servicios Desde distintas clases se acceden a sus métodos. Métodos probados con tests unitarios que garantizan
correcto funcionamiento de los mismos. Puede ser utilizada en distintos proyectos de la solución
Pruebas unitarias Ahorró de tiempo al probar modificaciones realizadas Se pueden generar en forma independiente de los datos
que contiene la base de datos. No se aplicó TDD debido a la arquitectura utilizada.
Se realizó la separación a la capa de servicios en forma posterior.
Se genera retrabajo. Es conveniente realizarlos en forma temprana y de ser posible
aplicar TDD
NO MANTENER LA UNIFORMIDAD EN LA USABILIDAD DEL DESARROLLO IMPACTA NEGATIVAMENTE EN EL PROYECTO Y EN EL CLIENTE
Detalles como indicar campos obligatorios, formato de las fechas o de las direcciones de correo electrónico no agrega funcionalidad no pedida, agrega valor al producto al evitar errores del usuario.
Una aplicación menos reactiva tiene como consecuencia una mejor experiencia de usuario.
Mantener un estándar en toda la aplicación. Quitar controles innecesario, confunden al
usuario. No confundir Usabilidad con Gold – Plating.
23
24
HERRAMIENTAS
25
HERRAMIENTAS
Visual Studio 2008 NUnit SQL Server 2005 Assembla (Seguimiento de incidentes y SVN) Tortoise SVN Client Enterprise Architect Word / Excel – Open Office
26
DEMO
27
?