Ingeniería de software

36 errores clásicos en el desarrollo de software de Steve Mcconnell

McConnell definió a los “errores clásicos” como aquellos que se han repetido tantas veces,
y por tanta gente, que debieran ser previsibles y siempre se deberían gestionar.

La lista está agrupada en 4 grupos en función de a que está relacionado el fracaso: las
Personas, los Procesos, el Producto o la Tecnología.

Éstos son algunos de los errores clásicos relacionados con las personas.

1. Motivación débil.- Estudio tras estudio se ha mostrado que la motivación probablemente

tiene mayor efecto sobre la productividad y la calidad que ningún otro factor.

2. Personal Mediocre.- Después de la motivación la capacidad individual de los miembros

del equipo, así como sus relaciones como equipo, probablemente tienen la mayor
influencia en la productividad.

3. Empleados problemáticos incontrolados.- Un fallo al tratar con personal problemático

también amenaza la velocidad de desarrollo. Es un problema habitual, y se ha
comprendido bien, al menos desde que Gerald Weinber publicó Psychology of Computer
Programming en 1971. Un fallo al tomar una decisión cuando se trata con un empleado
problemático es una de las quejas más comunes que tienen los miembros del equipo
respecto de sus responsables (Larson y LaFasto, 1989)

4. Hazañas.- Algunos desarrolladores de software ponen un gran énfasis en la realización

de hazañas en los proyectos. Pero lo que hacen tiene más de malo que de bueno.

5. Añadir más personal a un proyecto retrasado. Esta es quizás el más clásico de los errores
clásicos. Cuando un proyecto se alarga, añadir más gente puede quitar más productividad
a los miembros del equipo existente de la que añaden los nuevos miembros. Fred Brooks
compara añadir gente a un proyecto retrasado con echar gasolina en un fuego.

6. Oficinas repletas y ruidosas.- La mayoría de los desarrolladores consideran sus

condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no
tienen suficiente silencio ni privacidad.

7. Fricciones entre los clientes y los desarrolladores.- Las fricciones entre los clientes y los
desarrolladores pueden presentarse de distintas formas. A los clientes puede parecerles que
los desarrolladores no cooperan cuando rehúsan comprometerse con el plan de desarrollo
que desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores
puede parecerles que los clientes no son razonables porque insisten en planes irreales o
cambios en los requerimientos después de que estos hayan sido fijados. En el caso medio,
las fricciones entre clientes y desarrolladores de software llegan a ser tan severas que ambas
partes consideran la cancelación del proyecto.

8. Expectativas poco realistas.- Una de las causas más comunes de fricciones entre los
desarrolladores y sus clientes o los directivos son las expectativas poco realistas. Una
inspección de Standish Group marcó las expectativas realistas como uno de los cinco
factores principales necesarios para asegurar el éxito de los proyectos internos de software
de gestión.

9. Falta de un promotor efectivo del proyecto.- Para soportar muchos de los aspectos del
desarrollo rápido es necesario un promotor del proyecto de alto nivel, incluyendo una

Mtra. Adriana García Vargas

P á g i n a 1|5
 Ingeniería de software

planificación realista, el control de cambios y la introducción de nuevos métodos de

desarrollo. El consultor Australiano Rob Thomsett afirma que la falta de un promotor efectivo
garantiza virtualmente el fracaso del proyecto.

10. Falta de participación de los implicados.- Todos los principales participantes del esfuerzo
de desarrollo de software deben implicarse en el proyecto. Incluyendo a los promotores,
ejecutivos, responsables del equipo, miembros del equipo, personal de ventas, usuarios
finales, clientes y cualquiera que se juegue algo con el proyecto.

11. Falta de participación del usuario.- La inspección de Standish Group descubrió que la
razón número uno de que los proyectos de Sistemas de Información tuviesen éxito es la
implicación del usuario.

12. Política antes que desarrollo.- Larry Constantine indico que si hay cuatro equipos hay
cuatro tipos diferentes de orientaciones políticas. Los políticos están especializados en la
gestión, centrándose en las relaciones con sus directivos. Los investigadores se centran en
explorar y reunir información.

13. Ilusiones.- Estoy impresionado de ver cuantos problemas del desarrollo del software se
deben a la ilusión. Cuántas veces hemos escuchado cosas como estas a distintas personas:
“Ninguno de los miembros del proyecto cree realmente que pueda completarse el
proyecto de acuerdo con el plan que tiene, pero piensan que quizás si trabajan duro, y
nada va mal, y tienen un poco de suerte, serán capaces de concluir con éxito.”. Las
Ilusiones no son solo optimismo. Realmente consisten en cerrar los ojos y esperar a que todo
funcione cuando no se tienen las bases razonables para pensar que será así. Las Ilusiones al
comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo una
planificación coherente y pueden ser la raíz de más problemas en el software que todas las
otras causas combinadas.

Éstos son algunos de los errores clásicos relacionados con los procesos.

Los errores relacionados con el proceso ralentizan a los proyectos por que malgastan el
talento y el esfuerzo del personal.

14. Planificación excesivamente optimista.- Fijar un plan excesivamente optimista

predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la
planificación efectiva y reduciendo las actividades críticas para el desarrollo, como análisis
de requerimientos o el diseño. También supone una excesiva presión para los
desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad.

15. Gestión de riesgos insuficientes.- Si no ejercemos una gestión activa de los riesgos, con
que solo vaya mal una cosa se pasara de tener un proyecto con un desarrollo rápido a uno
con un desarrollo lento. El fallo de no gestionar uno solo de estos riesgos es un error clásico.

16. Fallos de los contratados.- Las empresas a veces contratan la realización de partes de
un proyecto cuando tienen demasiada prisa para hacer el trabajo en casa. Pero los
contratados frecuentemente entregan su trabajo tarde, con una calidad inaceptable o
que falla al no coincidir con la especificación. El problema no está en el abandono del
plan, sino más bien en fallar al no crear un plan alternativo, y caer entonces en el modo de
trabajo de codificar y corregir.

Mtra. Adriana García Vargas

P á g i n a 2|5
 Ingeniería de software

17. Planificación insuficiente.- Si no planificamos para conseguir un desarrollo rápido, no

podemos esperar obtenerlo.

18. Abandono de la planificación bajo presión.- Los equipos de desarrollo hacen planes y
rutinariamente los abandonan cuando se tropiezan con un problema en la planificación. El
problema no está en el abandono del plan, sino más bien en fallar al no crear un plan
alternativo, y caer entonces en el modo de trabajo de codificar y corregir.

19. Pérdida de tiempo en el inicio difuso.- El inicio difuso es el tiempo que trascurre antes de
que comience el proyecto; este tiempo normalmente se pierde en el proceso de aprobar
y hacer el presupuesto.

20. Escatimar en las actividades iniciales.- Los proyectos que se aceleran intentando
acortar las actividades no esenciales, y puesto que el análisis de requerimientos, la
arquitectura y el diseño no producen código directamente, son los candidatos fáciles.

21. Diseño inadecuado.- Un caso especial de escatimar en las actividades iniciales es el

diseño inadecuado. Proyectos acelerados generan un diseño indeterminado, no
asignando suficiente tiempo para él y originando un entorno de alta presión que hace difícil
la posibilidad de considerar alternativas en el diseño.

22. Escatimar en el control de calidad.- En los proyectos que se hacen con prisa se suele
cortar por lo sano, eliminando las revisiones del diseño y del código, eliminando la
planificación de las pruebas y realizando solo pruebas superficiales. Acortar en un día las
actividades de control de calidad al comienzo del proyecto probablemente supondrá de
3 a 10 días de actividades finales. Esta reducción va contra la velocidad de desarrollo.

23. Control insuficiente de la directiva.- Poco control de la directiva para detectar a tiempo
los signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se
abandonan cuando el proyecto comenzó a tener problemas. Antes de encarrilar un
proyecto, en primer lugar debemos ser capaces de decir si va por buen camino.

24. Convergencia prematura o excesivamente frecuente.- Bastante antes de que se haya

programado entregar un producto, hay un impulso para preparar el producto para la
entrega, mejorar el rendimiento del producto, imprimir la documentación final, incorporar
entradas en el sistemas final de ayuda, pulir el programa de instalación, eliminar las
funciones que no van a estar listas a tiempo y demás.

25. Omitir tareas necesarias en la estimación.- Si la gente no guarda cuidadosamente datos

de proyectos anteriores, olvida las tareas menos visibles, pero son tareas que se han de
añadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20% o 30%.

26. Planificar ponerse al día más adelante.- Un tipo de estimación es responder

inapropiadamente al retraso del plan. Si hemos trabajado en un proyecto durante 6 meses,
y hemos empleado tres meses en llegar al hito correspondiente a los dos meses, ¿Qué
hacer? En muchos proyectos simplemente se plantea recupera el retraso más tarde, pero
nunca se hace. Otro tipo de error en la reestimación se debe a cambios en el producto. Si
el producto que estamos construyendo cambia, la cantidad de tiempo necesaria para
construirlo cambiara también.

Mtra. Adriana García Vargas

P á g i n a 3|5
 Ingeniería de software

27. Programación a destajo.- Algunas organizaciones creen que la codificación rápida,

libre, tal como salga, es el camino hacia el desarrollo rápido. Piensan que si los
desarrolladores están lo suficientemente motivados, pueden solventar cualquier obstáculo.

Éstos son algunos de los errores clásicos relacionados con la forma en la que se define el
producto.

28. Exceso de Requerimientos.- Algunos proyectos tienen más requerimientos de los que
necesitan, desde el mismo inicio. La eficiencia se fija como requisito más a menudo de lo
que es necesario, y puede generar una planificación del software innecesariamente larga.

29. Cambio de las prestaciones.- Incluso si hemos evitado con éxito los requerimientos
excesivos, los proyectos sufren como media sobre un 25% de cambios en los requerimientos
a lo largo de su vida. Un cambio de este calibre puede producir un aumento en el plan de
al menos 25%, lo que puede ser fatal para los proyectos de desarrollo rápido.

30. Desarrolladores meticulosos.- Los desarrolladores encuentran fascinante la nueva

tecnología, y a veces están ansiosos por probar nuevas prestaciones de su lenguaje o
entorno, o por crear su propia implementación de una utilidad bonita que han visto en otro
producto, la necesite o no su producto. El esfuerzo requerido para diseñar, implementar,
probar, documentar o mantener estas prestaciones innecesarias alarga el plan.

31. Tiras y aflojes en la negociación.- Cuando un directivo aprueba un retraso en el plan e

un proyecto que progresa más lento de lo esperado, y entonces añade tareas
completamente nuevas después de un cambio en el plan, se produce una situación
curiosa. La razón subyacente de esto es difícil de localizar, puesto que el directivo que
aprueba el retraso en el plan lo hace sabiendo implícitamente que el plan estaba
equivocado. Pero una vez que se corrige, la misma persona realiza acciones explicitas para
volver a equivocarse. Esto solo puede ir en contra del plan.

32. Desarrollo orientado a la investigación.- Seymour Cray, el diseñador de los

supercomputadores Cray, dijo que no intentaba sobrepasar los límites de la ingeniería en
más de dos áreas a la vez, porque el riesgo de fallo es demasiado alto. Si el proyecto fuerza
los límites de la informática por que necesita la creación de nuevos algoritmos o de nuevas
técnicas de computación, no estamos desarrollando software; estamos investigando en
software. Los planes de desarrollo de software son razonablemente predecibles; los planes
en la investigación sobre software ni siquiera son predecibles teóricamente.

Éstos son algunos de los errores clásicos relacionados con el uso correcto o incorrecto de la
tecnología moderna.

33. Síndrome de la panacea.- Cuando un equipo de proyecto se aferra solo a una nueva
técnica, una nueva tecnología o un proceso rígido, y espera resolver con ello sus problemas
de planificación, esta inevitablemente equivocado.

34. Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos.- Las
organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuantas
nuevas herramientas o métodos empleen o lo buenos que sean. Los beneficios de las
nuevas técnicas son parcialmente desplazados por las curvas de aprendizaje que llevan
asociadas, y aprender a utilizar nuevas técnicas para aprovecharlas al máximo lleva su
tiempo. Un caso especial de sobreestimaciones de las mejoras se produce cuando se

Mtra. Adriana García Vargas

P á g i n a 4|5
 Ingeniería de software

reutiliza código de proyectos anteriores. Este tipo de reutilización puede ser una técnica
muy efectiva, pero el tiempo que se gana no es tan grande como se espera.

35. Cambiar de herramientas a mitad del proyecto.- Es un viejo recurso que funciona
raramente. A veces puede tener sentido actualizar incrementalmente dentro de la misma
línea de productos, de la versión 3 a la 3.1 o incluso a la 4. Pero cuando estamos a la mitad
de un proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores
cometidos con una herramienta totalmente nueva, normalmente anulan cualquier posible
beneficio.

35. Falta de control automático del código fuente.- Un fallo en la utilización del control
automático del código fuente expone a los proyectos a riesgos innecesarios. Sin el, si dos
desarrolladores están trabajando en la misma parte del programa, deben coordinar su
trabajo manualmente. Deberían ponerse de acuerdo para poner la última versión de cada
archivo en el directorio maestro y verificarlos con los demás antes de copiarlas en este
directorio. Pero invariablemente alguno sobrescribirá el trabajo del otro. Se desarrolla nuevo
código con interfaces desfasadas, y después se tiene que re-diseñar el código al descubrir
que se ha utilizado una versión equivocada de la interfaz. Como media, los cambios en el
código fuente suelen ser de un 10% al mes y con un control manual del código fuente no
deberían crecer.

Fuente: “Rapid development” Autor: Steve McConnel

Mtra. Adriana García Vargas

P á g i n a 5|5