Inicio
 > Informes e investigaciones > Blog de TEC > Productividad para los estimadores de software

Productividad para los estimadores de software

Escrito por: Sarada Kaligotla
Publicado: mayo 30 2007

La estimación de software, específicamente el tamaño, el esfuerzo, el costo y el programa (la duración) del software están provocando animadas discusiones con bastante frecuencia en la comunidad de estimadores de software. Normalmente son los líderes de proyecto y los gerentes de proyecto quienes se encargan de esta actividad.

El desarrollo de software involucra varias actividades dispares que exigen que se cuente con conocimientos especializados, particularmente en reunión, análisis y gestión de requisitos; diseño, codificación, verificación y validación independientes de software e implementación, instalación y puesta en funcionamiento. Existe una persona competente que es responsable de cada una de estas actividades y que para llevarlas a cabo utiliza varias herramientas cuyas complejidades varían.

Productividad

La productividad es la tasa de salida que se obtiene con ciertas entradas. Se expresa en "tantas unidades de salida al día" o "tantas unidades de salida por hora" y también se define como la proporción entre salida y entrada.

En el contexto de este artículo, la productividad se refiere a la tasa relacionada con la producción de una unidad de salida usando un conjunto de entradas en una unidad de tiempo específica.

Preocupaciones con la estimación del tamaño del software

Actualmente en la industria del software se usan varias unidades de medida para determinar el tamaño del software. Algunas de ellas son puntos de función, puntos de casos de uso, puntos de objeto, puntos de característica, puntos de Internet, puntos de prueba, análisis de puntos de función Mark II, líneas de código, etc. Sin embargo, no existe una forma generalmente aceptada para convertir el tamaño del software de una unidad de medida a otra.

Uno de los aspectos más particulares de estas medidas es que el tamaño del software se ajusta (aumenta o disminuye) dependiendo de ciertos factores, como la complejidad. Pero el tamaño es algo que no cambia. Por ejemplo, un kilo de queso no se vuelve más pesado o más ligero dependiendo de la experiencia que tiene la persona que lo pesa o de que la balanza sea mecánica o electrónica. Un kilómetro sigue siendo un kilómetro si la persona que lo recorre a pie es joven o vieja, o si se mide en una carretera o una calle pequeña.

Lo que sí cambia es la velocidad con que se obtienen resultados. Usando los ejemplos anteriores, lo más probable es que la persona mayor tarde más en caminar un kilómetro que la joven, y viajar en carretera puede ser más rápido que viajar en una calle pequeña.

Además, no hay un acuerdo sobre cómo contar las líneas de código. ¿Hay que contar los enunciados lógicos o los enunciados físicos? ¿Qué hacemos con la documentación en línea? ¿Debemos contarla?

Estos son sólo algunos de los problemas principales de la medición del tamaño.

Preocupaciones con la productividad

En el mundo del desarrollo de software hay una obsesión por tener una sola cifra para la productividad, que sea empírica y que todo lo abarque.

Se ha tratado de especificar la productividad como 10 horas hombre por punto de función, pero con la condición de que las horas hombre por punto de función pueden variar de 2 a 135, dependiendo del tamaño del producto, el tamaño del equipo y otros factores. Con “especificar la productividad” se pretende asignar un número que represente el esfuerzo en horas hombre necesarias para desarrollar una unidad de tamaño de software para convertir este último en puntos de función para el esfuerzo de desarrollo de software en horas hombre. En lugar de hacer esto, se dan algunos rangos, como 15 a 30 horas por punto de caso de uso. Otras veces se deducen fórmulas empíricas que dependen de varios factores, como sucede con el constructive cost model (COCOMO, o modelo de costos constructivo).

Una de las preocupaciones con estas cifras de productividad es que agrupan todas las actividades -análisis, diseño, revisión y pruebas de los requisitos, entre otras- en una sola medida. Pero las competencias necesarias para llevar a cabo estas actividades son distintas, al igual que las herramientas utilizadas, las entradas y las salidas. Agruparlas bajo el título "desarrollo de software" y dar una sola cifra de productividad sólo puede dar lugar a una estimación muy general e imprecisa.

La ruta de la productividad

El desarrollo de software comprende las actividades siguientes:

  • Actividades preliminares del proyecto, como un estudio de viabilidad, creación de presupuestos financieros y obtención de aprobaciones para el proyecto (es decir, tanto financiera como técnica y “luz verde” para iniciar el proyecto).

  • Actividades de arranque del proyecto, como identificar el gerente de proyecto, nombrar el equipo del proyecto y establecer el ambiente de desarrollo, realizar la planificación del proyecto, definir varios protocolos, específicamente las formalidades para los informes de avance del proyecto y los acuerdos de nivel de servicios, y dar la capacitación necesaria relacionada con el proyecto

  • Actividades de ingeniería de software, como análisis de los requisitos de los usuarios; análisis de los requisitos del software; diseño, codificación y pruebas de las unidades del software; varios tipos de pruebas -de integración, funcional, negativa, del sistema y de aceptación- y preparación de la creación y la documentación.

  • Actividades de implementación, como instalación del hardware y el software del sistema, establecimiento de la base de datos, instalación del software de aplicación, pruebas piloto, capacitación para los usuarios, operación paralela del sistema e implementación.

  • Actividades de limpieza del proyecto, como documentación de las prácticas correctas e incorrectas, análisis del proyecto (post mórtem), archivo de registros, liberación de recursos, liberación del gerente del proyecto e inicio del mantenimiento al software.

Ahora, cuando hablamos de los procedimientos de sentido común que tiene la industria para productividad, no resulta muy claro cuáles de las actividades anteriores se incluyen. A nadie le gustaría apostarle a la cifra de productividad, a pesar de que es un principio básico comúnmente aceptado en la industria.

Veamos la naturaleza de estas actividades:

  1. Análisis de los requisitos: comprender y documentar lo que el usuario necesita, quiere y espera, para que los diseñadores de software entiendan perfectamente y puedan diseñar un sistema conforme a dichos requisitos. Depende altamente de factores externos.

  2. Diseño del software: considerar las alternativas de hardware, software del sistema y plataformas de desarrollo; encontrar la opción ideal para cada uno de estos elementos y diseñar una arquitectura que cumpla con los requisitos enunciados y satisfaga las expectativas –el cliente. Dicha arquitectura debe ser compatible con las tecnologías actuales y el diseño debe documentarse de forma que los programadores puedan entenderlo y crear un producto que se apegue a las especificaciones originales del usuario. Existen varias alternativas, y debido a que el diseño del software es una de las actividades estratégicas, los errores pueden tener consecuencias graves.

  3. Codificación: desarrollar código de software que cumpla con el diseño y que tenga tan pocos fallos como sea posible (es sumamente fácil dejar errores sin quererlo).

  4. Revisión del código: recorrer el código que escribió otro programador, descifrar su funcionalidad y tratar de predecir los errores que el cliente podría encontrarse al usar el software.

  5. Pruebas: tratar de descubrir todos los defectos que puede tener todavía el software. Sin embargo, en la industria se sabe que encontrar el 100 por ciento de los defectos es imposible. Además, probar el 100 por ciento del software es una tarea poco práctica.

Ahora, la naturaleza de estas actividades es muy variada, por lo tanto, es obvio que su productividad no puede ser uniforme (es decir, no puede ser la misma cifra). El ritmo de trabajo es distinto para cada una de ellas.

Estas actividades no dependen de la cantidad de código de software que se produce, sino de otros factores, como los siguientes:

  1. Los requisitos, que dependen de la eficacia y la claridad de su fuente (ya sean los usuarios o la documentación).
  2. El diseño, que depende de la complejidad del procesamiento, las alternativas disponibles y las restricciones del lugar donde se utilizará la funcionalidad.
  3. La revisión del código, que depende del estilo de codificación.
  4. Las pruebas, que dependen de qué tan bien escrito esté el código (cuanto más errores tenga, mayor tiempo se necesitará para probarlo una y otra vez).
  5. La codificación misma, que depende de la calidad del diseño.

Por lo tanto, es necesario tener cifras de productividad distintas para cada una de estas actividades.

Si hacemos un paralelo con la industria de la manufactura –hacer hoyos en una hoja-, las actividades siguientes son las que hay que realizar: 1) preparación de la máquina, 2) preparación de las herramientas, 3) carga del trabajo, 4) hacer el hoyo, 5) desbarbar el hoyo, 6) limpieza y 7) entrega de la hoja a la operación siguiente.

Si se hacen varios hoyos, el tiempo “por hoyo” se reduce, ya que las actividades de preparación sólo deben realizarse una vez.

Por lo tanto, si queremos codificar una unidad, por ejemplo, las actividades a realizar podrían ser 1) recibir las instrucciones, 2) estudiar el documento de diseño, 3) codificar la unidad, 4) probar y eliminar los errores de la unidad para mejorar la funcionalidad, 5) probar y eliminar los errores de la unidad durante el uso no contemplado, 6) borrar el código basura de la unidad, 7) hacer pruebas regresivas de la unidad y 8) liberar la unidad para que prosiga al paso siguiente.

De forma similar podemos crear micro actividades para cada una de las etapas de desarrollo de software.

¿Cifras empíricas o estudiadas?

Cada una de las actividades anteriores tiene una tasa de realización diferente. Hay que definir los tiempos estándar para cada una de ellas. Una vez hecho esto, hay que usar técnicas de estudio del trabajo, como síntesis o estimación analítica, para obtener el tiempo general necesario para completar el trabajo.

Ya sea que las técnicas de estudio del tiempo se usen para llegar a estudios de productividad individuales o reunir datos empíricos, la respuesta a la pregunta anterior es que debe reconocerse que el desarrollo de software no es de naturaleza completamente mecánica ni completamente creativa. Asimismo, no resulta práctico medir el tiempo de las actividades que tienen un componente creativo, ya que los métodos de estudio de trabajo permiten este aspecto del desarrollo de software. Se están llevando a cabo muchos estudios sobre "productividad de los trabajadores profesionales" y es probable que en el futuro se creen métodos para medir el tiempo de las cifras de productividad en desarrollo de software. Actualmente, la solución más utilizada parece ser la información empírica.

¿De dónde se obtienen los datos empíricos? Una forma de obtenerlos es mediante estudios de tiempo que usan técnicas de ingeniería industrial. Otra, que es más fácil y confiable, es a partir de los datos históricos que se encuentran en las hojas de tiempo.

Gran parte del software de hojas de tiempo que hay actualmente en el mercado y en la industria se orienta a nómina y facturación. No captura los datos en el nivel micro que servirían para llegar a los datos de la productividad. La mayor parte del tiempo, estas hojas capturan datos en uno o dos niveles además de la fecha y la hora. Un proyecto siempre está en el primer nivel, y estos segundo y tercer niveles pueden ser el módulo y el componente, el componente y la actividad o una combinación similar. Además de la fecha y la hora de trabajo de cada empleado, las hojas de tiempo deben capturar datos en cinco niveles, es decir, el proyecto, el módulo, el componente, la fase de desarrollo y la tarea realizada. Así se contaría con la información necesaria para establecer los datos de productividad de forma empírica pero realista.

Actualmente, todas las actividades de desarrollo de software se enfocan en la macro productividad. Esto tiene que cambiar; es necesario enfocarse en la micro productividad para todas las actividades. Para hacerlo, hay que cambiar nuestras hojas de tiempo y la profundidad de la información que reúnen.

Algunas de las ventajas de estudiar la productividad en el nivel micro son las siguientes:

  • Una mejor capacidad para predecir el desarrollo del software.
  • Mejores estimaciones de calidad para la asistencia en la asignación de precios durante las etapas de adquisición y aprobación del proyecto.
  • Establecimiento de objetivos más precisos al asignar el trabajo, lo que mejora el ánimo entre los desarrolladores de software.
  • Más precisión en la estimación de costos.

Conclusión

Es importante comprender la diferencia entre los términos productividad y capacidad. La productividad es la tasa de realización de una micro actividad que implica esfuerzo humano, mientras que la capacidad es la tasa de realización de las instalaciones (la fábrica, la empresa, etc.), y se incluyen varias actividades en la cifra que denota la capacidad. Cuando hablamos de estimación de software, el enfoque debe pasar de la macro productividad (capacidad) a la productividad (micro actividades). Es más aconsejable tener una reunión de datos empíricos para poder llegar a las cifras de productividad de varias actividades de desarrollo de software, ya que las técnicas de estudio de tiempos y movimientos no dan resultados satisfactorios cuando existe un componente de creatividad (como sucede en el desarrollo de software). Una forma para reunir los datos empíricos es mejorar las hojas de tiempo, especialmente para calcular las cifras de productividad en el nivel micro.

Acerca de los autores

Murali Chemuturi es miembro de Ingeniería Industrial del Instituto Indio de Ingeniería Industrial. Cuenta con más de treinta años de experiencia con organizaciones profesionales, como ECIL, TCS, Metamor y Satyam. Inicialmente trabajó en manufactura y después en TI. Actualmente es director de Chemuturi Consultants, una firma de consultoría que se especializa en productos informáticos para la industria de desarrollo de software. Ha realizado varios programas de capacitación en las empresas para gestión de proyectos de software y estimación de software. Se le puede contactar en murali@chemuturi.com.

Sarada Kaligo tiene una maestría en aplicaciones informáticas y es profesional certificado en gestión de proyectos (PMP) del Project Management Institute (PMI), así como analista certificado de calidad del software (CSQA) del Quality Assurance Institute (QAI). Actualmente trabaja para Blue Cross Blue Shield de Massachusetts. Cuenta con seis años de experiencia en la industria del software y en desarrollo y gestión de proyectos. Se le puede contactar en sarada14@yahoo.com.

 
comments powered by Disqus

Búsquedas recientes:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others