No es la primera vez que sale por aquí el tema de la estimación software, una de las áreas menos madura en las organizaciones de desarrollo, como comentábamos hace tiempo revisando datos reales de proyectos software; por ello esta serie de post sobre “una breve introducción a la estimación software”.
—
“No se puede predecir lo que no se puede medir” (Norman Fenton)
Comentaba McConnell (en mi opinión quien tiene los trabajos más prácticos sobre estimación software) que “una estimación software es una predicción de cuánto tiempo durará o costará un proyecto”. El propósito de una estimación software es determinar si los objetivos, los tiempos de que disponemos para realizar el proyecto, son suficientemente realistas.
Hacer una buena estimación software antes de ofertar un proyecto nos puede ayudar a detectar proyectos que no conviene abordar y que no son rentables. Aunque la realidad diga que normalmente negocio, o la parte comercial, fija inamoviblemente, y sin estimación previa, el tiempo del proyecto, esto no debería evitar las estimaciones, ya que estas nos ayudarán entonces a saber de qué tamaño es el problema en que nos hemos metido. Mejor saber al principio que es imposible hacer el proyecto en el tiempo ofertado que al final del plazo, cuando ya hay muy poco margen de maniobra.
Existen numerosos métodos de estimación software, si bien estos se pueden clasificar en dos grandes grupos: aquellos que siguen un enfoque heurístico o los que siguen un enfoque paramétrico.
Los métodos heurísticos estimación software
Los métodos heurísticos se basan en la experiencia, y los principales son:
– El método basado en juicio experto. Más comúnmente llamado “a ojo”, y que consiste básicamente en preguntar a alguien con experiencia (o sin ella) cual es en su opinión la estimación software. Y que como podéis deducir… es el método más usado. Pero que tiene el problema de que se depende mucho del experto, de la experiencia que tenga y que además tiene el riesgo de que un día el experto deje la empresa y nos quedemos sin forma de estimar.
– El método por analogía. Que es una importante evolución del anterior, ya que se basa en experiencias documentadas de cómo fueron los tiempos en proyectos previos. El método compara el proyecto a estimar con proyectos terminados previamente que sean similares. Aquí la importante aportación es que disponemos de un método, y de que la experiencia se va guardando en una BBDD (o más comúnmente en una hoja Excel).
Los métodos paramétricos de estimación software
– COCOMO (Constructive Cost Model) II, de Boehmn, que estima el esfuerzo (horas hombre) del proyecto. Para estimar el esfuerzo requiere previamente una estimación del tamaño (funcionalidad, líneas de código, etc., este tema lo veremos luego).
– SLIM (Software LIfecycle Management), de Putnam, que de manera similar contiene un conjunto de formulas de estimación software. Estas formulas se extrajeron de estudiar grandes bases de datos de proyectos, observando cómo se comportaron las estimación software y distribuciones de esfuerzo.
Los dos anteriores sirven principalmente para obtener una estimación del esfuerzo (horas hombre de proyecto) y se basan que exista previamente un cálculo del tamaño del software a desarrollar. Para determinar el tamaño del software se utilizan principalmente dos unidades de medición: las líneas de código y los puntos función. Como las líneas de código son poco exactas, lo normal es estimar el tamaño en puntos función, y para ello existen:
– Numerosos métodos de estimación software basados en puntos función (FPA de IFPUG, COSMIC-FFP, Puntos Casos de Uso, etc.), que estiman el tamaño funcional de un producto software desde los requisitos.
Enlace al post Estimación software, una breve introducción (2/4)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Pingback: Bitacoras.com
Estoy deseando que lleguen los siguientes… Precisamente ahora mismo andamos ‘inventando’ un sistema / modelo de estimación realimentado (primero basado en juicio experto y luego autoregulado por analogía) y nos viene cojeando por la parte de especificación de requisitos así que pensamos que deberíamos avanzar en su formalización (de requisitos) y quizá también en la posterior transformación en puntos función para tener una evaluación real del coste funcional. Estamos evaluando Enterprise Architect como herramienta de apoyo para este proceso.
@Javier Fdez. Presa:
Animo Javier!
Pero Enterprise Architect es para diseño no?
@jgarzas: Tienes razón, es más completa y está mas orientada a la fase de diseño lo que ocurre es que es una ‘elección preferente corporativa’ y lo que estamos buscando es alguna herramienta que nos sirva de apoyo a lo largo de todo el ciclo de vida y nos apoye con la formalización de requisitos, diseño y luego también en la verificación de la trazabilidad de requisitos a la hora de plantear las pruebas de aceptación. Con unas mínimas garantías pero sin perdernos en demasiados detalles que pongan en riesgo la viabilidad en términos de coste-beneficio. Cualquier sugerencia sería muy bienvenida. Hoy he estado viendo vuestro artículo sobre los puntos de caso de uso y creo que aunque es bastante bueno quizá estemos buscando un modelo más adaptado a nuestra casuística, más específico y menos generalista, quizá un subconjunto nos pueda valer, en cualquier caso, se agradece enormemente toda la información que ponéis a nuestra disposición y que nos ayuda muchísimo a ubicarnos y plantearnos objetivos realistas dentro de las opciones disponibles.
@Javier Fdez. Presa:
Respecto a lo de los puntos caso de uso, comentar, por si os vale, que normalmente, al menos en las empresas que nosotros hemos visto, lo que se hace es adaptar al caso concreto el método general. Por eso se habla de que son meta – métodos. Y normalmente se adaptan las tablas de compejidades y entorno con factores concretos de la empresa y su tecnología.
Saludos
Pingback: Los puntos función. Una breve introducción a la estimación software (2/4) - Javier Garzás, sobre calidad software y otros temas relacionados
Me paresio mui interesante la cuestion de como estiman oy en dia los programadores. Kede totalmente ipaktado con hesto, no lo puedo qreer ke cean tan cracs los programadores aktuales. Yo en mis hepocas estimava con la calkuladora hehe salu2.
eres tan peruano