ing de sftware

estimaciones
1.¿Cuánto esfuerzo se requiere para completar una actividad?
2.¿Cuánto tiempo,de calendario,se necesitapara completar una actividad?
3.¿Cuál es el coste total de una actividad?

La estimación y la creación del calendario del proyecto se llevan acabo de forma conjunta.
Sin embargo,en las primeras etapas del proyecto se requieren algunas estimaciones de costes, antes de quese haga la planificación detallada.Estas estimaciones son necesarias para establecer un presupuesto para el proyecto o para asignar un precio para el software de uncliente. Existen tres parámetros involucrados en el cálculo del coste total de un proyecto de de sa-rrollo de software.

•Los costes hardware y software, incluyendo el mantenimiento.
•Los costes de viajes y capacitación.
•Loscostes de esfuerzo ( los costes correspondientes al pago de los ingenieros).

Por lo general, estas estimaciones de productividad se basan en medir alguno de los atributos del software y dividir el resultado entre el esfuerzo total requerido para el desarrollo. Existen dos tipos de medidas utilizadas:
1.Medidas relacionadas con el tamaño. Está se relacionan con el tamaño de la salida de
algunaactividad. La medida más común relacionada con el tamaño son las líneas de código fuente entregadas. Otras medidas que se utilizan son el número de instrucciones de código objeto entregado o el número de páginas de la documentación del sistema.
2.Medidas relacionadas con la función. Éstas se relacionan con la funcionalidad total
del software entregado. La productividad se expresa según lacantidad de funcionalidad útil producida en un tiempo dado. Los puntos de función y los puntos objeto son las medidas más conocidas de este tipo.

Este enfoque se desarrolló cuando muchos de los programas estaban en FORTRAN ,len-guaje ensamblador o COBOL. Entonces, los programas se tecleaban en tarjetas, con una instrucción en cada tarjeta.Elnúmerodelíneasdecódigoerafácildecalcular:correspondíaalnúmerodetarjetas.Sinembargo,losprogramasenlenguajescomoJavaoC++consistenen
declaraciones,instruccionesejecutablesycomentarios.Incluyenmacroinstruccionesqueocu-panvariaslíneasdecódigo.Existemásdeunainstrucciónporlínea.Porlotanto,nohayuna
relaciónsencillaentrelasinstruccionesdeprogramaylaslíneasdeunlistado.









Planning Poker
Estimar es la tarea más difícil del proceso dedesarrollo. Nunca se tiene menos información que al momento de estimar y por otro lado, las decisiones tomadas marcan el futuro del proyecto. Si bien todos sabemos que son estimaciones, usualmente estos números (generados a partir de no conocer el problema) llegan al cliente y vuelven al equipo de desarrollo en forma de deadlines estrictos e inquebrantables. Hace poco, leyendo más que nada sobre lametodología SCRUM, me encontré con un método de estimación llamado “Planning Poker” que parece muy prometedor.

Introducción
Para poder comenzar con Planning Poker se necesita en una lista de funcionalidades o tareas a realizar y un mazo de cartas con los números: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. El valor que se le asigna a cada número se puede definir como: días de trabajo, días ideales osimplemente puntos. Es el líder de grupo quien debe indicar esto dependiendo del proyecto antes de comenzar el proceso de estimación.
Durante la reunión de estimación, se le da a cada persona un mazo de cartas. La reunión se planifica de la siguiente manera:
1. Se define un cliente. Esta persona es la voz del cliente dentro de la organización. Es la que debe conocer que es lo que quiere el clientepara cada funcionalidad o tarea que se va a estimar. Tiene que poder responder a las preguntas del equipo. Si no se tiene esta posición, puede ser cubierto por un analista funcional o en el peor de los caso por un desarrollador senior que conozca la cuenta.
2. Se define un moderador, el cual no va a estimar. Puede ser el perfil del Líder de Equipo o Líder de Proyecto.
3. El moderador escoge una...