errores clásicos en el desarrollo de software

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

1.-Motivación indeterminada 2.-Personal poco capacitado 3.-Falta de actuación con los elementos problemáticos 4.-Heroismo. 5.-Añadir más personal a los proyectos retrasados 6.-Oficinas repletas y ruidosas. 7.-Fricciones entre los clientes y los desarrolladores 8.-Expectativas poco realistas. 9.-Falta de un promotor efectivo del proyecto. 10.-Falta de participación de los implicados. 11.-Falta de participación del usuario. 12.-Política sobre

14.Planificaciones excesivamente optimistas. 15.- Nula o poca gestión de riesgos 16.- Fallos de los subcontratistas 17.-Planificación insuficiente. 18.-Abandono de la planificación. 19.-Perder el tiempo en los trámites iniciales. 20.-“Saltar a codificar” 21.-Diseño inadecuado. 22.-Eliminar las actividades de control de calidad. 23.-Poco seguimiento del proyecto 24.-Forzar la convergencia de todas las actividades . 25.-Omitir tareas importantes al

28.-Exceso de requisitos. 29.-Cambio en los requisitos. 30.-Exceso de funcionalidade s. 31.-Tiras y aflojas en la negociación. 32.- Desarrollo orientado a la investigación.

33.-Síndrome de la panacea. 34.-Exceso en la estimación de los ahorros de los nuevos métodos y herramientas. 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 T3 Gestión de Riesgos.Anexo Isg 2 T3-A 00-01 1-0.doc

Curso 2000/2001 30/03/2011 Pág3.A-1 Eduardo Basterrechea Molina [email protected]

el contenido. 13.-Buenos deseos:

hacer la estimación 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 T3 Gestión de Riesgos.Anexo Isg 2 T3-A 00-01 1-0.doc

Curso 2000/2001 30/03/2011 Pág3.A-2 Eduardo Basterrechea Molina [email protected]

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 T3 Gestión de Riesgos.Anexo Isg 2 T3-A 00-01 1-0.doc

Curso 2000/2001 30/03/2011 Pág3.A-3 Eduardo Basterrechea Molina [email protected]

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ódulosdel 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 T3 Gestión de Riesgos.Anexo Isg 2 T3-A 00-01 1-0.doc

Curso 2000/2001 30/03/2011 Pág3.A-4 Eduardo Basterrechea Molina [email protected]

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 T3 Gestión de Riesgos.Anexo Isg 2 T3-A 00-01 1-0.doc

Curso 2000/2001 30/03/2011 Pág3.A-5 Eduardo Basterrechea Molina [email protected]

Obtenido de Rapid Development. Steve McConnell. Microsoft Press 1996. Existe versión en castellano McGrawHill. Desarrollo y gestión de proyectos informáticos. i