Errores clasicos

Errores Clásicos relacionados con el Proceso.

14: Planificación excesivamente optimista. Los retos a los que se enfrenta alguien que desarrolla una aplicación en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicación que necesita un año. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance delproyecto, minando la planificación efectiva, y reduciendo las actividades críticas para el desarrollo, como el 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 insuficiente. Algunos errores no son lo suficientemente habituales como para considerarlosclásicos. Son los llamados "riesgos". Como con los errores clásicos, si no ejercemos una gestión activa de los riesgos, con qué sólo vaya mal una cosa se pasará 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 contratistas. Las compañías a veces contratan la realización de partes de unproyecto 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 las especificaciones (Boehm, 1989). Riesgos como requerimientos inestables o interfaces mal definidas pueden ser enormes cuando un contratado entre en escena. Si las relaciones con los contratados no segestionan cuidadosamente, la utilización de desarrolladores externos pueden retardar el proyecto en vez de acelerarlo.
17: Planificación insuficiente. Si no planificamos para conseguir un desarrollo rápido, no podemos esperar obtenerlo.
18: Abandono de planificación bajo presión. Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en laplanificación (Humphrey, 1989). 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. Ejemplo, un equipo abandona su plan después de fallar en la primera entrega, y esto es lo habitual. A partir de este punto, el trabajo no tiene coordinación ni elegancia.
19: Pérdida de tiempo en el iniciodifuso. El "inicio difuso" es el tiempo que transcurre antes de que comience el proyecto; este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto. No es poco común que un proyecto desperdicie meses o años en un inicio difuso, y entonces se está a las puertas de un plan agresivo. Es mucho más fácil y barato y menos arriesgado suprimir unas pocas semanas o meses del iniciodifuso en vez de comprimir el plan de desarrollo en ese mismo tiempo.
20: Escatimar en las actividades iníciales. Los proyectos 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.
Los resultados de este error, también conocido como "saltar a lacodificación", son todos demasiado predecibles. Los proyectos que normalmente escatiman en sus actividades iniciales tendrán que hacer ese trabajo en otro momento, con un costo de 10 a 100 veces superior a haberlo hecho bien inicialmente (Fagan, 1976; Boehm y Papaccio, 1988). Si no podemos encontrar cinco horas para hacer el trabajo correctamente la primera vez, ¿cómo vamos a encontrar 50 para hacerlocorrectamente más tarde?
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 asignado suficiente tiempo para él y originado un entorno de alta presión que hace difícil la posibilidad de considerar alternativas en el diseño. El énfasis en el diseño está más orientado a la conveniencia...