Listado de los errores clásicos en el desarrollo

de softwarei

Son las prácticas de desarrollo poco efectivas que han sido

realizadas tantas veces por tanta gente y con malos resultados
tan predecibles que han sido denominados “Errores clásicos”

Cuadro resumen de los errores clásicos

Personas Proceso Producto Tecnología

14.- 28.-Exceso de 33.-Síndrome de

1.-Motivación
Planificaciones requisitos. la panacea.
indeterminada
excesivamente 34.-Exceso en la
2.-Personal poco 29.-Cambio en los
optimistas. estimación de
capacitado requisitos.
los ahorros de
15.- Nula o poca 30.-Exceso de
3.-Falta de los nuevos
gestión de funcionalidade
actuación con métodos y
riesgos s.
los elementos herramientas.
problemáticos 16.- Fallos de los 31.-Tiras y aflojas 35.-Cambio de
subcontratistas en la herramientas a
4.-Heroismo.
17.-Planificación negociación. mitad del
5.-Añadir más
insuficiente. 32.- Desarrollo proyecto.
personal a los
18.-Abandono de orientado a la 36.-Falta de
proyectos
la planificación. investigación. control
retrasados
19.-Perder el automático de
6.-Oficinas código fuente.
repletas y tiempo en los
ruidosas. trámites
iniciales.
7.-Fricciones
entre los 20.-“Saltar a
clientes y los codificar”
desarrolladores 21.-Diseño
8.-Expectativas inadecuado.
poco realistas. 22.-Eliminar las
9.-Falta de un actividades de
promotor control de
efectivo del calidad.
proyecto. 23.-Poco
10.-Falta de seguimiento del
participación proyecto
de los 24.-Forzar la
implicados. convergencia
11.-Falta de de todas las
participación actividades .
del usuario. 25.-Omitir tareas
12.-Política sobre importantes al

Ingeniería del software de gestión II Curso 2000/2001

T3 Gestión de Riesgos.Anexo 30/03/2011
Isg 2 T3-A 00-01 1-0.doc Pág3.A-1
Eduardo Basterrechea Molina
Ebaste@eitig.com
 el contenido. hacer la
13.-Buenos estimación
deseos: 26.-Mantener una
planificación
cuando ya se
han producido
retrasos.
27.-Programación
a destajo

Desarrollo de los errores clásicos

Referentes a las Personas:

1.-Motivación indeterminada: Boehm “La motivación es el mayor

factor sobre la productividad y la calidad del desarrollo de
software” Errores: Arengas, trabajo extra, irse de
vacaciones, remuneraciones irrisorias por terminar en plazo.
2.-Personal poco capacitado: Después de la motivación, las
capacidades de los individuos o su relación como equipo
son los siguientes factores en importancia en la
productividad. Errores: Contratar lo más barato
3.-Falta de actuación con los elementos problemáticos
4.-Heroismo: NO interesan actuaciones heroicas sino el
desarrollo continuo, pausado y sin sobresaltos.
5.-Añadir más personal a los proyectos retrasados
6.-Oficinas repletas y ruidosas. Los trabajadores que están en
oficinas silenciosas tienden a funcionar mejor que los que
ocupan cubículos en salas ruidosas y repletas.
7.-Fricciones entre los clientes y los desarrolladores
8.-Expectativas poco realistas. Standish group. Las expectativas
realistas son uno de los cinco factores necesarios para
asegurar el éxito de los desarrollos de software internos
9.-Falta de un promotor efectivo del proyecto. Ayuda a realizar
una planificación realista, control de cambios y la
introducción de nuevos métodos de desarrollo

Ingeniería del software de gestión II Curso 2000/2001

T3 Gestión de Riesgos.Anexo 30/03/2011
Isg 2 T3-A 00-01 1-0.doc Pág3.A-2
Eduardo Basterrechea Molina
Ebaste@eitig.com
10.-Falta de participación de los implicados. Promotores,
ejecutivos, responsables del equipo, miembros del equipo,
personal de ventas, usuarios finales, clientes, marketing…
11.-Falta de participación del usuario. Según el Standish group,
la razón fundamental de que los proyectos de sistemas de
información tengan éxito es la implicación del usuario.
12.-Política sobre el contenido. Los grupos de desarrolladores
tienen diferente personalidad igual que las personas.
Podemos encontrar: Políticos: Se concentran en las
relaciones con los responsables. Investigadores: su principal
preocupación es investigar, buscar y recopilar más
información. Los aislacionistas buscan marcar su zona y
aislarse del exterior. Los equipos en los que predominan los
políticos funcionan bien al principio pero luego pierden el
interés de la dirección.
13.-Buenos deseos: (pág 43 inglés) No es optimismo, es cerrar
los ojos y esperar que algo funcione, sin tener bases
razonables para pensarlo.

Referentes al proceso de desarrollo

14.-Planificaciones excesivamente optimistas: Además reduce

en gran medida la autoestima y la productividad de los
desarrolladores
15.- Nula o poca gestión de riesgos
16.- Fallos de los subcontratistas (retrasos, baja calidad o no
respondiendo a los requisitos)
17.-Planificación insuficiente
18.-Abandono de la planificación por un exceso de presión. Se
hacen planes pero se abandonan al aparecer las dificultades
19.-Perder el tiempo en los trámites iniciales. Es el tiempo
empleado en obtener la aprobación de la dirección y los
fondos. Es más fácil no perder ese tiempo que recuperarlo
al programar.
20.-“Saltar a codificar” Eliminar las actividades iniciales
“improductivas” Ante la pregunta ¿enséñame la
documentación de diseño? la respuesta. No ha habido
tiempo de diseñar. Eliminamos el diseño, el análisis y los
requisitos.
21.-Diseño inadecuado. No se tiene el tiempo ni la tranquilidad
suficiente para llevarlo a cabo.
Ingeniería del software de gestión II Curso 2000/2001
T3 Gestión de Riesgos.Anexo 30/03/2011
Isg 2 T3-A 00-01 1-0.doc Pág3.A-3
Eduardo Basterrechea Molina
Ebaste@eitig.com
22.-Eliminar las actividades de control de calidad. (Un ahorro de
un día en calidad puede costar entre 3 y 10 días al final del
proyecto)
23.-Poco seguimiento del proyecto
24.-Forzar la convergencia de todas las actividades –módulos-
del producto. Si intentamos que todo encaje antes de
tiempo tendremos trabajo extra.
25.-Omitir tareas importantes al hacer la estimación
26.-Mantener una planificación cuando ya se han producido
retrasos. Hay que actualizar la planificación cuando vamos
teniendo más datos del producto. (Cambios en los
requisitos)
27.-Programación a destajo (Code-like-hell) Piensan que si los
programadores están suficientemente motivados salvarán
cualquier obstáculo

Referentes al producto:

28.-Exceso de requisitos: Se piden al sistema características

complejas que el usuario no necesita y se da excesiva
importancia al rendimiento.
29.-Cambio en los requisitos. El proyecto medio experimenta un
25% de cambio en los requisitos durante su desarrollo, lo
que origina un 25% de incremento en el tiempo de
desarrollo.
30.-Exceso de funcionalidades. Los desarrolladores, fascinados
por la tecnología u otros productos, añaden funcionalidades
no solicitadas por el cliente
31.-Tiras y aflojas en la negociación. La dirección asume el
retraso en el proyecto pero a la vez añade nuevas
funcionalidades
32.- Desarrollo orientado a la investigación. Seymour Cray, el
diseñador de los ordenadores Cray, dice que nunca trata de
superar los límites de la ingeniería en más de dos áreas
simultáneamente, porque el riesgo de fallar es demasiado
alto. La investigación no es predecible.

Referentes a la Tecnología

33.-Síndrome de la panacea. Se confía demasiado en las nuevas

tecnologías antes de ser probadas.
Ingeniería del software de gestión II Curso 2000/2001
T3 Gestión de Riesgos.Anexo 30/03/2011
Isg 2 T3-A 00-01 1-0.doc Pág3.A-4
Eduardo Basterrechea Molina
Ebaste@eitig.com
34.-Exceso en la estimación de los ahorros de los nuevos
métodos y herramientas. Raramente se producen grandes
mejoras instantáneas en productividad. Los beneficios de
las nuevas prácticas se ven reducidas por las curvas de
aprendizaje asociadas con ellas.
35.-Cambio de herramientas a mitad del proyecto.
36.-Falta de control automático de código fuente.

Ingeniería del software de gestión II Curso 2000/2001

T3 Gestión de Riesgos.Anexo 30/03/2011
Isg 2 T3-A 00-01 1-0.doc Pág3.A-5
Eduardo Basterrechea Molina
Ebaste@eitig.com
i
Obtenido de Rapid Development. Steve McConnell. Microsoft Press 1996. Existe
versión en castellano McGrawHill. Desarrollo y gestión de proyectos informáticos.