Barra Superior

PMOinformatica.com
La oficina de proyectos de informática
La web sobre gerencia de proyectos de informática, software y tecnología.
Síguenos en:     

lunes, 5 de mayo de 2014

5 pasos para elaborar estimaciones de proyectos de software

Imagen de: ContruSteel
La elaboración de estimaciones de proyectos de software, que consiste en identificar cuantas horas hombre o jornadas tomará el implementar un sistema informático, ha sido y continuará siendo uno de los aspectos cruciales en el desarrollo de software en todas las organizaciones.

De hecho, según estadísticas de la industria, aproximadamente el 40% de los proyectos de software son cancelados debido a estimaciones parcial o completamente erradas, he allí la importancia de aplicar una metodología probada en la elaboración de la estimación.

Aquí les dejamos un artículo con 5 pasos para elaborar estimaciones de proyectos de software: Revisar los requerimientos y el alcance, Dimensionar el trabajo a realizar (desglose de trabajo), Elaborar un primer estimado base, Identificar y analizar los riesgos, y por último Validar y revisar el estimado.

PMOInformatica.com, “La Oficina de Proyectos de Informática” presenta 5 pasos para elaborar estimaciones de proyectos de software:

Lectura recomendada: ¿Buscas información sobre métodos de estimación de proyectos de software?

Guía Práctica de Estimación y Medición de Proyectos Software: ¿Por qué?, ¿Para qué? y ¿Cómo? (En Español)  Ver Reseña
Edición Kindle. Autor: Julián Gómez
>> Comprar en Latinoamérica (amazon.com)
>> Comprar en España (amazon.es)



Primero establezcamos algunos conceptos

  • Los estimados son mediciones del trabajo a realizar, expresados en jornadas u horas.
  • Por sí sólo no puede determinar el presupuesto o plan. 
  • Si pueden usarse para medir esfuerzo, dimensiones e inclusive un preliminar de los costos.

Y ahora sí, los 5 pasos para elaborar estimaciones de proyectos de software, los cuales mostramos en esta figura:



Los 5 pasos para elaborar estimaciones de proyectos de software

1.- Revisar los requerimientos y el alcance

  • Primero se establecen las expectativas de los interesados en cuanto a la exactitud del estimado:
    • Se expresan en un rango (por ejemplo más o menos 50%, 10% o 1%). 
    • A mayor información disponible, mayor exactitud.
    • Por ejemplo, no se puede esperar un estimado de 1% cuando los requerimientos son vagos o no se han analizado todavía lo suficiente.
    • Luego debemos obtener los requerimientos funcionales: 
      • ¿Existe una solicitud formal de requerimientos o especificación de diseño funcional?
      • Si trabajamos con una metodología ágil, debemos hacer énfasis en entrevistas y en entender lo más posible los requerimientos para poder estimarlos.
      • ¿Están todos los puntos claramente definidos o existen ambigüedades por resolver?
      • A mayor resolución de las ambigüedades, mayor exactitud del estimado.
    • Prestar atención a los requerimientos no funcionales:
      • Por ejemplo de seguridad, tiempo de respuesta, tiempos para mantenimientos, entre otros.
      • Su no observancia puede hacer fracasar un proyecto.
    • Debe indagarse sobre la mayor cantidad de detalles técnicos, las dependencias externas y los requerimientos originales del negocio que componen el estimado.
    • Establecer claramente cuales funcionalidades estarán incluidas en el estimado y mencionar explícitamente cuáles no.
    • Evaluar las premisas, por ejemplo:
      • ¿Estamos asumiendo que vamos a reutilizar software?, ¿ese software reutilizado está en producción?, ¿fue probado adecuadamente?
      • ¿Estamos asumiendo recursos que estarán disponibles, por ejemplo ciertas personas expertas?, ¿qué ocurriría con el estimado sino estuvieran disponibles y tuviera que reclutarse personas (con la correspondiente curva de aprendizaje)?
      • Debe evaluarse cualquier aspecto que sea fuente de incertidumbre.

    2.- Dimensionar el trabajo a realizar (desglose de trabajo)

    • En este paso, nos enfocamos en el “Que” vamos a estimar.
    • Debemos identificar los componentes que vamos a desarrollar, el nivel de indagación y detalle dependerá del grado de exactitud que queremos dar a nuestro estimado.
    • Este dimensionamiento no implica definir en detalle cada componente, no esperamos definir con precisión sus entradas, salidas, posibles valores, líneas de código, etc. Sin embargo, si esperamos poder identificarlos individualmente y asignarles niveles de complejidad.
    • Esta es la fase más importante para lograr una estimación acertada, estudios demuestran que es la dimensión la que más influye en el estimado.
    • Debe identificarse el nuevo software a desarrollar, pero ¿Qué hay del existente?, modificaciones de componentes, pruebas para ver si funcionan y otros aspectos deben tomarse en cuenta.
    • Para identificar los componentes, puede recurrirse a la opinión de los expertos, una metodología formal (desglosar por funciones o por casos de uso por ejemplo), e inclusive dimensionamiento estadístico si disponemos de información histórica de estimados pasados.

    3.- Elaborar un primer estimado base del proyecto de software

    Pues bien, ya sabemos que vamos a estimar, ahora debemos enfocarnos en el “¿Cómo?”, para esto existen una amplia gama de técnicas de estimación, por ejemplo:
    • Métodos de medición de Proyectos: Estimación de 3 puntos, Técnicas Delphi, COCOMO, Putman, y más recientemente Planning Poker (para proyectos con metodología ágil).
    • Métodos de medición de Puntos Función: FPUG FPA, MKII-FPA, COSMIC FFP, FiSMA, Estimación temprana de NESMA, SiFP o Puntos Función 3D.
    • Otros métodos de medición funcional: Puntos de características (Feature Points), Puntos de Casos de Uso o Puntos Objeto.
    • Métodos de medición no funcional: Lógica Difusa (Fuzzy Logic), Catalogo de Componentes (Standard Components), Puntos de Historia, T-SHIRT Sizing o SNAP.

    Entre los métodos de medición de proyectos (clásicos) más usados, está la estimación de 3 puntos, que consiste en tomar el desglose de trabajo y establecer un estimado optimista, moderado y pesimista por un experto. Otra de las técnicas clásicas es la Delphi, que consiste en enviar la información a 3 expertos independientes y ponderar sus estimados.

    Las técnicas clásicas dependen del conocimiento del experto, mientras que las técnicas de puntos función o medición funcional, se basan más en metodologías que calculan con precisión cada componente, ponderando la complejidad de cada uno, e introduciendo modificadores según lo estable del sistema o experiencia del equipo.

    ¿Cuál es el método más adecuado?, pues depende de la situación y además es un tema con suficientemente amplitud para escribir otro post sobre él.

    4.- Identificar y analizar los riesgos

    • El riesgo no necesariamente es una amenaza si se gestiona adecuadamente.
    • Se deriva de la incertidumbre existente en cada componente a desarrollar. Por ejemplo:
      • Si una actividad depende de una premisa, existe el riesgo que esta no se cumpla y esto tenga un impacto.
      • Todas las actividades tienen insumos (un producto previo) y recursos, si estos no están disponibles, ocurre un impacto. Ej. Proyectos externos, recursos escasos, personal no disponible o costoso.
    • Se caracteriza por pérdida de tiempo, costo, calidad, a esta pérdida se le conoce como el impacto del riesgo.
    • Para responder al riesgo se establecen acciones y planes de respuesta, por ejemplo:
      • Hacer provisiones en los estimados (agregar holgura).
      • Agregar trabajo (más actividades y por ende mayor es la estimación), para contemplar el trabajo que se está haciendo para mitigar el riesgo.

    5.- Validar y revisar el estimado

    • Por último, siempre es una buena práctica realizar una evaluación formal de los estimados.
    • Para que sea objetiva debe ser realizada por alguien que no participó en la elaboración de la estimación.
    • En la evaluación, se revisa:
      • Las bases del estimado, desglose de tareas, premisas, restricciones.
      • Si el procedimiento de estimación cumplió la metodología establecida.
    • Debe enfocarse en identificar:
      • Premisas no ciertas o con alta probabilidad de no cumplirse.
      • Riesgos no identificados.
      • Posibles requerimientos extraordinarios.
      • Requerimientos ocultos no identificados. 

    Ya tengo el estimado, ¿y ahora qué?

    • Pues lo que tengo es el número de horas de trabajo o jornadas asignadas a cada componente, la agregación de estos componentes dan una estimación de esfuerzo del proyecto.
    • Sin embargo, si tengo una medición de la dimensión, e inclusive puedo estimar un costo, multiplicando las jornadas (u horas) por la tarifa de los recursos comprometidos.

    ¿Y tú? ¿Qué opinas?

    ¿Cuáles son los pasos para estimar desarrollos de software que utilizan en tu organización?, ¿Cuáles métodos de estimación utilizas?, ¿Qué opinas de la importancia que tienen los métodos de estimación de desarrollo de software?. Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web). Asimismo, te invitamos a suscribirse por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica, a nuestra página de Facebook o al feed RSS.

    Lectura recomendada: ¿Buscas información sobre métodos de estimación de proyectos de software?

    Guía Práctica de Estimación y Medición de Proyectos Software: ¿Por qué?, ¿Para qué? y ¿Cómo? (En Español) Ver Reseña
    Edición Kindle. Autor: Julián Gómez
    >> Comprar en Latinoamérica (amazon.com)
    >> Comprar en España (amazon.es)



    Referencia

    Galorath, D. The 10 Step Software Estimation Process For Successful Software Planning, Measurement and Control

    Open-works.org. Effort Estimation for Software Development


    Otros artículos en “La Oficina de Proyectos de Informática”

    Gestión de Desarrollo de Software


    Software y Herramientas


    2 comentarios :

    1. Excelente Post chicos...a la verdad que es un aspecto muy crítico dentro del procesos de desarrollo y pocos le dedican la atención merecida, lo cual repercute en el éxito o no, del producto final. Nos gustaría que participaran como autor invitado en nuestra Comunidad Joobdo , y compartieran vuestras experiencias con nuestra Comunidad de programadores/desarrolladores Freelance,,,¿que os parece?

      ResponderEliminar
    2. Muy buen post!
      Creo que agregaría algo. La técnica de planning poker aparece más fuerte con las metodologías ágiles pero se puede utilizar perfectamente en cualquier metodología, ya que se basa en conocimiento y discusión sobre un punto a desarrollar y se discuten argumentos, lo cual aclara en mucho e incluso surgen repreguntas para los clientes o solicitantes.
      Otro punto que es indispensable es revisar las estimaciones con frecuencia durante el proyecto. Muchas veces tomamos supuestos, o calibramos con métricas existentes y no modificamos esto cuando con el tiempo, podemos tener mayores certezas sobre el supuesto o se modificaron los ratios de las métricas (caso de adquisición de expertise o por el contrario, perdida de jugadores claves).
      Gracias por compartir!!

      ResponderEliminar

    Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.