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

?