Un 25% de incremento en la complejidad del problema añade un 100% de incremento en la complejidad del software

Por cada 25% de incremento en la complejidad del problema, hay un 100% de incremento en la complejidad del software que lo soluciona. Y no hay soluciones mágicas ni “silver bullets” que eviten este problema (te recomiendo aquí este post sobre las “balas de plata”). Esta fue una de las principales aportaciones de Glass, descrita en su libro “Facts and Fallacies”. Según él comentaba, a altas complejidades del problema, se dispara la complejidad del software que lo soluciona, y esto ocurre porque se producen, entre otros, los siguientes efectos:

• El equipo humano se convierte en algo crítico. Por la necesidad de más inteligencia para resolver el problema (te recomiendo aquí el post de lo más determinante para el éxito, o fracaso, de un son las personas)
• La estimación del proyecto se hace muy compleja. Porque el software que soluciona el problema es más complicado de lo que parece la solución.
• Los requisitos se disparan. Porque al pasar de un 25% del problema al 100% de la solución, los requisitos propios del software, los no funcionales, se disparan.
• Las alternativas de diseño se incrementan. Y por ello…
• Se necesita iterar mucho más para lograr un buen diseño. Porque rara vez se logará a la primera a una buena solución.
• Una cobertura de pruebas del 100% es prácticamente imposible. Porque los caminos a probar se disparan en número.
• Los errores se incrementan. Por la dificultad de encontrar una buena solución a la primera.

Así que, ya sabes, cuando alguien te pida, o cuando tú pidas, un “pequeño” incremento en la funcionalidad, recuerda que puede tener un gran impacto en su desarrollo.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.

Últimas entradas de jgarzas (ver todo)

• 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