Paradojas de la estimación de software

Introducción

El desarrollo del software a creado una industria independiente, con organizaciones que ofrecen exclusivamente servicios de desarrollo de software. Debido a que quizás se encuentra en una de las etapas nacientes, los procesos de pedir servicio, ofrecer servicio y asignar precios son algo arbitrarios. El desarrollo del software cae dentro de la categoría de la industria de servicios opuesta a la industria del producto, es decir se ofrece un servicio y no un producto. Se pueden trazar varios paralelos con industrias de servicio similares. Sin embargo, la diferencia más importante entre la industria de servicio de software y otras industrias de servicio, es que el software es mucho más caro y complejo. Cuando hay complejidad y dinero, los académicos entran en acción, se conduce la investigación, se desarrolla la jerga, se proponen los conceptos y llega a la vida una nueva rama de la ciencia o ingeniería.

Existen varias paradojas inherentes a la industria de desarrollo del software. El presente artículo habla sólo de algunas de ellas. ¿Por qué no de todas? La razón es simple: todavía no existe un documento completo acerca de la suma total de paradojas, y todavía se trabaja en ello.

Paradojas de la estimación

¿Por qué se llevan a cabo estimaciones de software? Por lo general por tres razones: para asignarle un precio a los contratos de mantenimiento y desarrollo del software; para estimar los recursos; para manejar los compromisos de entrega.

Cuando se estiman los recursos o los compromisos de entrega, siempre se puede estimar cada una de las actividades, por ejemplo, para los códigos, para ir de código en código, para las pruebas, etc., para llegar a los requisitos de recursos para cada una de estas actividades. Y al resumir los requisitos individuales, se puede llegar a todos los requisitos totales de recursos para el proyecto.

La estimación del software se vuelve conflictiva, sin embargo, cuando se estima la asignación del precio del software. Se necesita llegar a un estimado que entienda el comprador del cliente, quién no necesariamente es un desarrollador del software, y quién se espera que no esté familiarizado con la estimación del software. Por lo general, el escenario es el que sigue:

1. Existen múltiples ofertas.
2. Los niveles de capacidad de los postores, y en algunos casos varían en gran medida.
3. Serán negociaciones técnico-comerciales, que son en su mayoría comerciales por naturaleza.
4. La pregunta técnica es sería algo así: "¿cómo llegó a este precio?" 5. Se espera que la respuesta no se en términos técnicos, y que facilite la comparación con otras ofertas.

Este es el escenario: Los negociantes quieren una norma universal que se pueda aplicar en plataformas, organizaciones, tecnologías, y en general. Esta es el punto clave del problema de estimación del software.

Paradoja del tamaño del software

Existe una amplia literatura acerca del tamaño del software. Se han hecho intentos para medir el software como la distancia o el peso, o para encontrar una unidad de medida que sea aceptable para todos. El resultado es que tenemos muchas medidas del tamaño del software: los ejemplos incluyen líneas de código, puntos de función, puntos de caso de uso, puntos objeto, puntos de característica, puntos de Internet, puntos de prueba, y existen muchos más. Es verdad que existen múltiples medidas para la distancia (millas y kilómetros) y para el peso (libras y kilogramos). Pero ¡las libras se pueden convertir a kilogramos y las millas a kilómetros! ¡No existe ninguna fórmula que diga que un punto de caso se uso sea igual a 1.2 puntos de función, o algo parecido!

Todo el mundo está de acuerdo en que algunas cosas no se pueden medir, como la belleza y el amor. Cada persona es bella en una forma única, y cada quien ama en su propia forma. No intentamos medir estas cosas en puntos de belleza o puntos de amor, ¿o sí?

También existen varios ejemplos en la industria. No medimos un automóvil, ¿tenemos puntos de autos para decir que un BMW tiene veinticinco puntos de auto y Toyota tiene quince, y que por lo tanto BMW es superior por diez puntos de autos? ¿Cómo se comparan los distintos automóviles? No tenemos una medida para los autos que permita que se haga una comparación.

Tampoco intentamos medir los productos del software. ¿Cuál es el tamaño de SQL Server u Oracle? Ambos son sistemas de gestión de bases de datos relacionales (RDBMS) de usuarios múltiples, pero al comprar, ¿preguntamos acerca de su tamaño para obtener una comparación justa? Tampoco tenemos una medida justa para un hardware de computadora. ¿Cómo comparamos un AS/400 con un RS/6000? ¿Existen puntos de computadora para medir su tamaño?

¿Existe alguna medida para los edificios? Un gimnasio, un teatro y una casa pueden medir diez mil pies cuadrados dimensionalmente, pero ¿todas miden lo mismo? ¿Tenemos una medida de tamaño para compararlas? Y por último, veamos el servicio de banquetes. El mismo menú servido en el mismo lugar tiene una asignación de precios completamente diferente, dependiendo del banquetero y otras especificaciones. ¿Les podemos preguntar el tamaño de sus comidas, digamos en puntos de comida?

El hecho es que no todo se puede medir. Para poderse medir, se tienen que satisfacer los siguientes criterios:

1. El objeto a medir debe ser homogéneo.
2. Tiene que ser físico y tangible.
3. Debe ser monolítico y no un ensamble de múltiples partes (físicas o metafísicas).
4. No debe tener ninguna característica cualitativa.
5. La medida debe ser física y tangible.
6. Cuando existen múltiples unidades de medida, debe ser posible utilizar un factor de conversión para convertir una medida a otras unidades de medida.

Sin embargo, los ejemplos que se analizaron, se evaluaron utilizando listas de características, descritas de forma cualitativa.

Paradojas de la productividad del software

La productividad se define como “X unidades de salida por unidad de tiempo”. La definición del tiempo estándar (productividad) es: “el tiempo estándar es la unidad de tiempo que se toma para lograr una unidad de trabajo definido llevado a cabo por un trabajador calificado después del ajuste utilizando un método dado en ciertas condiciones de trabajo establecidas a un ritmo que se puede mantener día a día sin ningún efecto dañino físicamente". Esta definición la especifica el Instituto Estadounidense de Ingenieros Industriales (AIIE).

Por lo tanto, en la industria de fabricación, la productividad no se puede establecer en un modo independiente: tiene que ir acompañado de la especificación de una unidad de trabajo definida, el ambiente de trabajo, los métodos de trabajo, las herramientas y las tecnologías utilizadas y los trabajadores calificados. Sobra decir que la productividad varía de organización en organización, incluso para las medidas bien establecidas de productividad.

Existen medidas universalmente aceptadas de tiempo, como horas hombre, días hombre (PDs), meses hombre y años hombre. Sin embargo, todavía estamos por ver una unidad de medida universalmente aceptada para la producción del software.

Podríamos ver la productividad del software como líneas de código por PD, puntos de función por PD, puntos de caso de uso por PD, puntos de objeto por PD, etc. En la fabricación de las industrias de servicio tradicional, la productividad se mide para una actividad a la vez (por ejemplo, para las actividades de cambio, molinos, colocación de ladrillos, mesas de espera, soldaduras, etc.)

Las medidas de productividad de las actividades de inspección y pruebas funcionales se miden sólo en las industrias de producción en lote o en masa, pero no se usan en la industria de órdenes de trabajo (adaptadas a las especificaciones del cliente). Las medidas de productividad de la actividad de diseño y las actividades de reparación (corrección de errores) tampoco se hacen, ya que se considera que tienen un componente creativo en el trabajo.

No se ha copiado este modelo de la industria de fabricación en la industria del desarrollo del software, y no se ha definido lo que es la productividad del software. Estas son algunas de las preguntas que surgen normalmente: ¿Productividad significa solamente códigos, o también incluye los códigos, las pruebas independientes de la unidad y la corrección de errores? ¿La productividad también incluye los análisis de sistemas y el trabajo de diseño? ¿Qué pasa con la inclusión de gastos de la gestión de proyectos?

En la mayoría de los casos se ha atestiguado que la productividad del software se especifica para todo el ciclo de vida del desarrollo, sin ningún acuerdo tácito en cuanto a o que constituye el “ciclo de vida del desarrollo”.

En la industria de la fabricación, la productividad se especifica para una actividad, y a la producción en general se llama capacidad. La capacidad de una planta o una organización toma en cuenta todas las operaciones, todos los departamentos, y todas las actividades y especifica un cifra, digamos, 300 autos por día, o 1 millón de toneladas por año, etc.

¿Le suena conocido? Debe de sonarle conocido pues con frecuencia se escuchan frases como “cincuenta líneas del código de Visual Basic por persona por día", o “¡dos días por pantalla!” Parece que se confunde la capacidad con la productividad.

La industria del software todavía no se ha comprometido con un ingeniero industrial para estudiar y obtener las medidas posibles de la productividad del software. A propósito, la industria está privada de sindicatos y de las negociaciones resultantes de ello. Quizás es por ello que no se han hecho intentos por llevar a cabo estudios científicos en el campo de la productividad del software.

Por lo tanto, aunque existen preocupaciones y problemas, también existen soluciones, tanto que no buscamos una sola medida o productividad para todo el flujo de trabajo del desarrollo del software. Lo que se tiene que lograr es una definición de una taxonomía de la productividad del software, y la publicación de un estándar de la industria. Esto facilitará el trabajo.

Paradoja de Ofrecer ofertas fijas

Varios servicios ofrecen ofertas fijas, no hay nada en especial en ello. Los arquitectos ofrecen una oferta fija una vez que reciben las ventas completas de un edificio. La industria de fabricación a pedido ofrece una oferta fija luego de recibir las especificaciones completas y la cotización incluiría también un dibujo de diseño de alto nivel. Un banquetero no ofrecería una oferta fija hasta recibir el menú y el número de invitados.

Una constructora ofrece una oferta fija, con una cláusula de escalación, una vez que recibe los planos de construcción. En la industria de la construcción, las tarifas de las unidades se ofrecen junto con un documento detallado que proporciona información a detalle de cada uno de los artículos. El costo total del edificio depende de la cantidad real de los distintos componentes del edificio. ¡El software es muy parecido a la industria de la construcción! A continuación se presenta el por qué de esta afirmación.

1. Es difícil para los usuarios visualizar el resultado final a partir de los documentos de diseño (dibujos).
2. Los usuarios constantemente piden cambios.
3. Existe una gran cantidad de características cualitativas.
4. Es muy difícil asegurar la calidad del producto final simplemente con una inspección, ya que una prueba destructiva daña el producto y lo deja inutilizable.
5. La variedad de componentes disponibles es enorme, con una gran diferencia en su calidad.
6. Las pruebas de conformidad se conducen en horas o días de lo que se construye en meses o años.
7. Con frecuencia, el usuario siente que se puede lograr algo mejor por el precio pagado, o que se debió escoger a un mejor vendedor.

Paradojas de lo real vs. lo estimado

Los datos estimados en otras áreas vienen no de las personas que hacen el trabajo, sino de ingenieros de trabajo de estudio (ingenieros industriales) que se especializan en la medición del trabajo. En la industria del software, los datos de estimación vienen de programadores o directores de proyectos, y se deriva de los datos históricos reales.

¿Por qué las otras industrias no utilizan datos históricos para llegar a los datos de estimación? Porque la cantidad real del tiempo invertido para una pieza de trabajo varía y depende de múltiples factores:

1. El nivel de habilidad de la persona que hace el trabajo (excelente, bueno, promedio, suficiente o malo).
2. El nivel de esfuerzo de la persona (excelente, bueno, promedio, suficiente o malo).
3. El nivel de motivación de la persona.
4. El ambiente en el que se lleva a cabo el trabajo.
5. Los métodos de trabajo.
6. La claridad de las instrucciones.

Se le puede dar cierta uniformidad a los últimos cuatro factores, pero los factores de habilidades y esfuerzo varían incluso dentro de la misma organización.

La paradoja de los tiempos reales se puede describir mejor como una analogía a un maratón olímpico: Se conoce la distancia que se va a correr, se conocen los tiempos reales de los maratones pasados, todos los participantes fueron entrenados para el evento y las condiciones del maratón están bien controladas, sin ningún cambio inesperado. Sin embargo, los participantes ¡no hacen el mismo tiempo al completar la carrera! Si incluso las mejores condiciones producen variaciones en los resultados reales, entonces ¿cómo un proyecto de software, con sus incertidumbres miríadas, cubren los tiempos estimados?

Otras industrias que no sean la industria del desarrollo del software (como la de fabricación, minería, etc.) siguen el concepto de “un buen día de trabajo por un buen día de paga" una estimación se basa en el esfuerzo promedio que hace una persona de habilidades promedio en ciertas condiciones. Estas industrias llevan a cabo estudios de trabajo en sus respectivas organizaciones, y llegan a tiempos estándar para la mayoría de las actividades que se realizan. También han desarrollado un número de técnicas por estimación de esfuerzo, incluyendo el estudio del tiempo, los análisis de micro-movimiento, la estimación analítica y la síntesis. El trabajo de todos se mide; si una persona tiene más habilidades y pone mayor esfuerzo, se le paga más dinero por iniciativa. El tiempo real difiere del tiempo estimado debido a las variantes en la habilidad de la persona y en el esfuerzo colocado. Esto se reconoce en la industria, y las estimaciones nunca se revisan simplemente debido a que el tiempo real tiene una variante con el tiempo estimado. Las estimaciones y las normas para la estimación se cambian sólo cuando existe un cambio en el ambiente de trabajo, herramientas, métodos o el trabajo en sí.

La industria del software nunca ha establecido estudios de trabajo para el desarrollo del software, refugiándose en la idea de que el desarrollo del software es una actividad creativa. Pero esa no es toda la verdad: el componente creativo está obviamente presente en el diseño del software, pero no en la codificación. El concepto de un buen día de trabajo para una buena paga tampoco se escucha en la industria de desarrollo del software debido a que a algunos ingenieros de software se les paga mejor que a otros.

Las normas para la estimación del desarrollo del software se derivan de proyectos anteriores, y se actualizan constantemente con base en los proyectos completados. Sin embargo, existen sólo algunos posibles escenarios:

1. El escenario del director de proyectos que “se esmera mucho en su trabajo”.
   Un estimado es dado para un director de proyectos que se esmera mucho en su trabajo (EB). Para poder complacer al jefe, el EB sobrepasa lo estimado. Por lo tanto la autopsia del proyecto concluye que el estimado se subestimó, y las normas de estimación se hacen más estrictas (en lugar de que se recompense al EB). El siguiente estimado se hace con las nuevas normas. De acuerdo a esta iteración, el EB se frustra con la falta de reconocimiento, y ya sea que retraza el proyecto o renuncia.
   
   
2. El escenario del director de proyectos que se “quiere hacer el inteligente”.
   Un estimado es dado para un director de proyectos que se quiere hacer el inteligente (SA). El SA analiza la situación y demora el proyecto hasta el punto para evitar una multa. La autopsia del proyecto concluye que el estimado es un superestimado y las normas de estimación se relajan (en lugar de que se castigue al SA). El siguiente estimado se hace con las nuevas normas. De acuerdo a esta iteración, el SA sigue con este patrón de comportamiento, sabiendo que es exitoso. La oficina del proyecto sigue relajando las normas de estimación hasta que el departamento de mercadotecnia se queja de las altas cotizaciones.
   
   
3. El escenario del director de proyectos puramente pragmático.
   Un estimado es dado para un director de proyectos puramente pragmático (PP). El PP planifica su trabajo para cubrir el estimado. La autopsia del proyecto concluye que el estimado es el estimado correcto y se mantienen las normas de estimación. De acuerdo con esta iteración, nunca se sabe si las normas de estimación estaban bien desde un inicio.

Vemos que no está claro que alguno de los estimados en cualquiera de las iteraciones sea el correcto. La validación de los estimados a través de la comparación con la realidad no produce las normas adecuadas.

Paradoja de incertidumbre

La incertidumbre es inherente a cualquier actividad humana, con algunas excepciones. Es por ello por lo que la Ley de Murphy (“si algo puede fallar, fallará") es aceptada. Y por supuesto cualquier proyecto enfrenta algunas incertidumbres fundamentales, incluyendo las variables comerciales técnicas y de tiempo. Asimismo se tiene que tomar en cuenta las variables que tienen que ver con los costos (o ganancias, o presupuestos), calidad y confiabilidad.

La planificación de un proyecto también tiene incertidumbre en cuanto a su totalidad, a la estabilidad de los requisitos, al diseño, a la confiabilidad de la plataforma de desarrollo, a la reducción de personal por retiro, renuncia o muerte en el equipo, a la reducción del personal clave del cliente, a la productividad incierta, y a las expectativas del cliente no especificadas.

A continuación se presentan algunas de las incertidumbres que se enfrentan al estimar el esfuerzo y la duración (en otras palabras, la programación): productividad, definición del tamaño, nivel de habilidades del equipo, nivel de esfuerzo del equipo y la paradoja de los "promedios". ¿Cómo se define un promedio? Existe una plétora de formas, incluyendo un simple promedio, un promedio ponderado (simple o complejo) un promedio en movimiento, una media estadística, un modo estadístico y un medio estadístico.

¿Cómo se calcula la probabilidad del éxito (o riesgo de fracaso)? ¿Cuál de las distribuciones de probabilidad se debe utilizar? ¿distribución normal, binominal, de Poisson, beta, gamma o t? La práctica general es utilizar la distribución normal o beta, pero existen preocupaciones acerca de su adecuación.

Conclusión

El propósito de este artículo es traer a la superficie todas las paradojas que se enfrentan en la industria del desarrollo del software. También es para enfocar los esfuerzos en resolver estas paradojas y poder establecer estándares de la industria. Es el momento adecuado, ahora existen suficientes medidas de tamaño de software bien entendidas. También existe un número adecuado de medidas que se están generando que están disponibles para que las analicen los investigadores.

Acerca del autor

Murali Chemuturi es ingeniero industrial del Instituto de Ingeniería industrial en India. Su carrera muestra más de treinta años de experiencia con organizaciones profesionales, incluyendo ECIL, TCS, Metamor, y Satyam. En un inicio trabajó en el sector de fabricación y luego en el de IT. Actualmente es líder de Chemuturi Consultants, que se enfoca en productos de software para la industria del desarrollo de software. Ha conducido un gran número de programas de entrenamiento para la gestión de proyectos de software y para la estimación del software. Se le puede localizar en el correo electrónico murali@chemuturi.com.