Inicio
 > Informes e investigaciones > Blog de TEC > Criterios para seleccionar una herramienta de es...

Criterios para seleccionar una herramienta de estimación de software

Escrito por: Murali Chemuturi
Publicado: abril 25 2007

Actualmente, la subcontratación de desarrollo de software es un tema muy común que ha generado la necesidad de que el subcontratista y el proveedor lleguen a un acuerdo con respecto al tamaño, el esfuerzo de desarrollo, el costo y el programa de desarrollo del software que se está subcontratando. Con todo esto, la estimación de software ha dejado de ser un proceso visceral para convertirse en técnicas de estimación maduras y basadas en investigaciones. Asimismo, ya no se lleva a cabo de forma manual usando hojas de cálculo, sino que se recurre a herramientas.

En la estimación de software hay muchas cosas que están en juego. Cuando un proveedor subestima un proyecto, puede pensar que es poco rentable, pero si lo sobrestima, se arriesga a perderlo. De la misma forma, el subcontratista puede pagar más si se sobrestima el software, o puede salirse de presupuesto si se subestima. Si bien la estimación de software sigue siendo una tarea creativa, existen herramientas que ayudan a remediar los aspectos mundanos del proceso y que permiten que el estimador se enfoque en la creatividad.

La estimación de software tiene cuatro aspectos clave: tamaño del software, costo del software, esfuerzo necesario para el desarrollo de software y programa de entregas del software.

Existe una variedad enorme de herramientas de estimación de software y muchas veces es difícil tomar una decisión informada al comprar una de ellas. Como siempre, todos los proveedores afirman que sus herramientas son mejores que las demás porque son más científicas y se adaptan mejor a cualquier tipo de organización o proyecto de desarrollo de software.

En este artículo exploramos los criterios que sirven para seleccionar la herramienta de estimación de software correcta, y tratamos de educar a los profesionales para que puedan tomar decisiones informadas al momento de comprar una herramienta de estimación de software.

Cómo medir el tamaño del software

Todos sabemos que existen varias formas para medir el tamaño del software: líneas de código (LOC), puntos funcionales, puntos de casos de uso (UCP), puntos característicos, etc. Cada una de estas medidas tiene sus seguidores, por lo tanto, no existe un acuerdo entre los profesionales de tecnología de la información (TI) sobre cuál es la mejor. Este desacuerdo se debe a muchos factores.

Las plataformas de programación de estas medidas son extremadamente diferentes -unidades principales, midrange, computadoras personales (PC), aplicaciones en red y finalmente, aplicaciones de software por Internet. Las plataformas de desarrollo abarcan desde lenguaje COBOL hasta herramientas de interfaz gráfica de usuario (GUI), hasta lenguajes de programación por Internet. Las arquitecturas de las aplicaciones tienen ahora varios niveles.

Existen varias opiniones sobre lo que constituye una línea de código. La declaración de variables, los comentarios y la longitud de una línea de código tienen connotaciones distintas según el punto de vista. Un proveedor querría contarlo todo, pero no un comprador de software.

La programación de GUI, en donde se hace el desarrollo previo de una cantidad importante de código, agrega una dimensión más al debate sobre las líneas de código. Este tipo de programación ha dejado de orientarse a los procedimientos y se ha enfocado en los eventos. Ahora se agregan controles de GUI a las líneas de código, y no hay una idea clara sobre cómo medir el tamaño de la GUI.

Existen muchos proyectos, como aquéllos que involucran mantenimiento y pruebas del software, que no son de ciclo de vida completo de desarrollo y que provocan confusión en cuanto a la forma para medirlos.

Por lo tanto, el primer criterio para seleccionar una herramienta de estimación de software es que

  • la herramienta debe permitir el uso de varias unidades de medida para el tamaño del software

Dicho de otro modo, la herramienta debe permitir que el usuario lleve a cabo la estimación de software usando varias unidades de medida que se usan comúnmente para determinar el tamaño del software.

Las unidades de medida del tamaño del software más comunes

Ahora la cuestión es ¿cómo puede la empresa medir su productividad y su capacidad cuando se usan varias medidas del tamaño del software? Sólo es posible medir la productividad de una organización en el desarrollo de software cuando el tamaño del mismo se mide usando una sola unidad.

Por lo tanto, el segundo criterio para seleccionar una herramienta de estimación de software es que

  • la herramienta debe permitir convertir varias unidades de medida en una sola que permita que el tamaño del software se convierta en un estándar dentro de la organización

La estimación del costo del software

Al hablar de asignación de costos al software, los profesionales de TI opinan lo mismo: debe medirse en la moneda del país, ya sean dólares, euros, rupias, etc. Si bien la fuente más importante de costos en el desarrollo de software es el esfuerzo medido en días hombre, hay que tomar en cuenta otros factores al estimar el costo del software que se va a desarrollar. Es muy probable que el costo adicional sea distinto de una empresa a otra en cuanto a variedad y costo unitario. Por ello, la herramienta debe permitir establecer parámetros y mantener los factores que componen los costos (es decir, agregar, modificar y borrar información). También es probable que los costos de los días hombre varíen de un proyecto a otro.

Así, el tercero, cuarto y quinto criterios para seleccionar una herramienta de estimación de software son que

  • la herramienta debe permitir estimar el costo del software
  • la herramienta debe permitir establecer parámetros para el costo de los días hombre
  • la herramienta debe permitir dar mantenimiento a los factores que constituyen los costos

Programación del proyecto de desarrollo de software

La estimación del esfuerzo tiene tres razones de ser principales: 1) comprometerse con el cliente, la dirección o los usuarios sobre un programa de entregas, 2) estimar los recursos necesarios para llevar a cabo el proyecto y 3) estimar el costo del proyecto de forma que permita asignar los fondos precisos o asignar precios, con el fin de optimizar los costos y las ganancias.

Ya mencionamos que la herramienta de estimación de software atiende las razones 2 y 3 anteriores. De cualquier forma, el desarrollo de un programa de compromiso de entregas con las partes interesadas (la primera razón) no es de gran importancia. La programación es una actividad creativa que exige una dosis de ingenio; es decir, no se puede automatizar por completo. También hay que tomar en cuenta que no hay una forma aceptada o estándar para asignar un porcentaje del esfuerzo involucrado en un proyecto a una etapa o una actividad en particular.

Las ventajas de derivar un programa de una estimación deben ser que el programa 1) sea eficiente, 2) atienda la asignación de recursos y pueda ajustarse en consecuencia, 3) permita asignar esfuerzo en días hombre a varias etapas y 4) tenga el nivel de detalle suficiente y se pueda exportar a un archivo inmediato desde el cual se pueda llevar a un paquete completo de métodos de ruta crítica/técnica de revisión y evaluación de programas (PERT/CPM) como MS-Project y Primavera.

Así, los criterios sexto a décimo primero para seleccionar una herramienta de estimación de software son que

  • la herramienta debe permitir crear un programa para el proyecto
  • el programa debe derivarse del esfuerzo estimado
  • la herramienta debe automatizar la creación del programa hasta donde sea posible
  • la herramienta debe permitir que intervengan las personas al crear el programa
  • el programa que se genere debe tener el nivel de detalle correcto y debe poderse exportar a un programa intermedio conocido, como MS-Excel
  • la herramienta debe basarse en los días hombre estimados, pero debe permitir que los días hombre programados sean distintos a los estimados

Este décimo primer criterio se debe a que cuando estimamos con honestidad el esfuerzo en días hombre y lo programamos, el resultado supera la estimación debido a una pérdida de tiempo en asignación de personal, fragmentación del trabajo, tiempo muerto y relaciones entre el principio y el fin.

Estimación para los proyectos de ciclo de vida de las piezas

Los proyectos importantes, como los de mantenimiento de software, implementación de sistemas de planificación de recursos empresariales (ERP) y de evaluación de software no son proyectos específicos de ciclo de vida del desarrollo de software. La herramienta de estimación del software también tiene que atender este tipo de proyectos y usar técnicas tales como la estimación por tareas. Esta técnica en particular tiene parámetros para definir los distintos tipos de proyectos que puede usar la empresa.

Por lo tanto, el décimo segundo criterio para seleccionar una herramienta de estimación de software es que

  • la herramienta debe tratar la estimación de proyectos de ciclo de vida de las piezas

Capacidad de uso

Todo el software debe crearse pensando en los usuarios. Un experto es capaz de trabajar con cualquier herramienta, pero la característica principal que distingue una buena herramienta de estimación de software es que permite que una persona con experiencia promedio produzca información de nivel de un experto. Es posible lograr esta distinción creando una herramienta que tenga una interfaz intuitiva que mantenga al mínimo la necesidad de capacitar a los usuarios sobre el uso de la herramienta. Esto se puede lograr con la disponibilidad de herramientas GUI. También es posible usar los controles equivocados, pero en lugar de facilitar el uso de la herramienta, esto es una fuente de tensión para el usuario. Muchas veces, las herramientas de software se desarrollan pensando en hacer las interfaces de usuario más atractivas en lugar de funcionales, y esto complica su uso. La herramienta debe orientarse más a la funcionalidad y la capacidad de uso y no en la animación. Siempre es mejor tener una interfaz de usuario (IU) simple.

Por lo tanto, el décimo tercer criterio para seleccionar una herramienta de estimación de software es que

  • la herramienta debe crearse pensando en la capacidad de uso, y con una interfaz intuitiva que permita que una persona de habilidad promedio pueda dominarla en poco tiempo

El uso de técnicas populares de medición del tamaño del software

La estimación de software es algo tan antiguo como el desarrollo del mismo. Algunas técnicas de estimación han adquirido popularidad y se usan en muchas organizaciones. Las más comunes son LOC, análisis de puntos funcionales (FPA) y UCP. Existen otras dos que se usan mucho: puntos de objetos y puntos de características.

Por lo tanto, el décimo cuarto criterio para seleccionar una herramienta de estimación de software es que

  • la herramienta debe ofrecer tantas técnicas de estimación de software de uso común como sea posible

Capacidad de auditoría

Existe una expresión que dice que dos cabezas piensan mejor que una, y es la base de las inspecciones, las revisiones y los procesos de familiarización con el software. Por lo tanto, sobra decir que cuando es una persona la que hace la estimación, no obstante lo diligente y experta que sea, debe haber otra persona que la revise. La herramienta de estimación de software debe permitir hacer una estimación detallada que pueda ser revisada y mejorada. Esta estimación detallada también permite la conciliación con el esfuerzo real que se hace en el proyecto para obtener algún aprendizaje de la experiencia y mejorar el proceso de estimación en los proyectos posteriores.

Por lo tanto, el décimo quinto criterio para seleccionar una herramienta de estimación de software es que

  • la herramienta debe permitir hacer estimaciones que se puedan auditar

Capacidad de generación de reportes

El resultado obtenido con la estimación deberá ser enviado al cliente, la dirección o el usuario. Estos reportes no deben incluir detalles innecesarios.

Por lo tanto, el décimo sexto criterio para seleccionar una herramienta de estimación de software es que

  • la herramienta debe generar tanto un reporte resumido como uno detallado de cada estimación que se haga, así como un reporte resumido de todas las estimaciones llevadas a cabo usando la herramienta

Estimador de la productividad

Es muy importante considerar la presión que deben soportar los estimadores, que por lo general son los líderes o los directores del proyecto. La herramienta de estimación de software debe permitirles obtener con facilidad tantos datos como sea posible de una lista predefinida, para que no tengan que introducir esa información manualmente en la herramienta. También es probable que los proyectos de una organización sean de naturaleza similar, aunque no sean idénticos. Por eso, la herramienta debe permitir copiar una estimación existente y modificarla para generar una nueva. Con esto, los estimadores ahorran mucho tiempo y dinero para la organización.

Así, los dos criterios finales (décimo séptimo y décimo octavo) para seleccionar una herramienta de estimación de software son que

  • la herramienta debe permitir, en la medida de lo posible, hacer una selección a partir de la lista de opciones
  • la herramienta debe permitir que se lleve a cabo el proceso de “copiado, modificación y generación” de una estimación nueva

Resumen

La estimación de software es una actividad vital para cualquier organización que está involucrada en desarrollo de software. Una herramienta de estimación de software ayuda a que una persona que tiene habilidades promedio en estimación de software genere una estimación de calidad profesional. Es normal que las herramientas de software disponibles sean de “todos colores y sabores”, y puedan costar desde 50 hasta miles de dólares (USD). No siempre es cierto que cuanto más elevado sea el precio de una herramienta, mejor será su calidad. Los posibles compradores pueden evaluar las herramientas usando estos dieciocho criterios y tomar así la decisión más acertada para sus organizaciones.

Acerca del autor

Murali Chemuturi es profesor encargado de Ingeniería industrial del Instituto Indio de Ingeniería Industrial. Tiene una carrera de más de treinta años, durante los cuales ha adquirido experiencia al trabajar con organizaciones profesionales como ECIL, TCS, Metamor y Satyam. Inicialmente se dedicó al área de manufactura y después pasó a TI. Actualmente dirige Chemuturi Consultants, que se enfoca en productos para la industria de desarrollo de software. Ha llevado a cabo varios programas de capacitación dentro de las empresas, enfocados en gestión de proyectos de software y estimación de software. Se le puede contactar en murali@chemuturi.com

 
comments powered by Disqus