36 errores clásicos en los proyectos de Software

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
36 errores clásicos en los proyectos de Software por Mind Map: 36 errores clásicos en los proyectos de Software

1. Motivación débil

1.1. 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

2.1. 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.

3.1. Un fallo al tratar con personal problemático también amenaza la velocidad de desarrollo. Un fallo al tomar una decisión cuando se trata con un empleado problemático es una de las quejas mas comunes que tienen los miembros del equipo respecto de sus responsables

4. Hazañas

4.1. Algunos desarrolladores de software ponen un gran énfasis en la realización de hazañas en los proyectos

5. Añadir mas personal a un proyecto retrasado.

5.1. Cuando un proyecto se alarga, añadir mas gente puede quitar mas productividad a los miembros del equipo existente de la que añaden los nuevos miembros.

6. Oficinas repletas y ruidosas

6.1. 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.

7.1. 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

8. Expectativas poco realistas.

8.1. Una de las causas mas comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas

9. Falta de un promotor efectivo del proyecto

9.1. Para soportar muchos de los aspectos del desarrollo rápido es necesario un promotor del proyecto de alto nivel, incluyendo una planificación realista, el control de cambios y la introducción de nuevos métodos de desarrollo.

10. Falta de participación de los implicados.

10.1. Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto.

11. Falta de participación del usuario.

11.1. La inspección de Standish Group descubrió que la razón numero uno de que los proyectos de Sistemas de Información tuviesen éxito es la implicación del usuario.

11.1.1. participacion

12. Política antes que desarrollo

12.1. 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

13.1. Las Ilusiones no son solo optimismo. Realmente consisten en cerrar los ojos y esperara que todo funciones cuando no se tienen las bases razonables para pensar que sera así. Las Ilusiones al comienzo del proyecto llevan a grandes explosiones al final.

14. Planificación excesivamente optimista.

14.1. 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 criticas para el desarrollo, como análisis de requerimientos o el diseño

14.1.1. Planificaion

15. Gestión de riesgos insuficientes.

15.1. 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.

16. Fallos de los CONTRATADOS

16.1. El problema no esta en el abandono del plan, sino mas bien en fallar al no crear un plan alternativo, y caer entonces en el modo de trabajo de codificar y corregir.

17. Abandono de la planificación bajo presión

17.1. Los equipos de Desarrollo Hacen aviones y rutinariamente los abandonan Cuando Se tropiezan Con Un Problema En La Planificación

18. Perdida de tiempo en el inicio difuso.

18.1. 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.

19. Escatimar en las actividades iniciales

19.1. Los Proyectos Que se aceleran Intentando acortar las Actividades sin ESENCIALES, Qué y puesto m de el Análisis de Requerimientos, la Arquitectura y el Diseño no ProduCen CODIGO Directamente, hijo los Candidatos faciles

20. Diseño inadecuado.

20.1. Proyectos acelerados generan indeterminado diseño de la ONU, no asignando Suficiente Tiempo para el y originando la ONU entorno de Alta Presión que hace? Difícil La Posibilidad de considerar Alternativas en el diseño.

21. Escatimar en el control de de Calidad.

21.1. 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.

22. Control insuficiente de la directiva

22.1. 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

23. convergencia prematura o excesivamente Frecuente

23.1. Bastante Antes de Que se Haya Programado: entregar la ONU Producto, heno impulso de las Naciones Unidas para PreparAR El Producto párr La Entrega, Mejorar el Rendimiento del Producto, imprimir la Documentación final, incorporar Entradas en el Sistemas definitiva de ayuda, pulir el Programa de Instalación, ELIMINAR las Funciones Que no van a Estar Listas de Tiempo y demas.

23.1.1. Convergencia

24. Omitir: tareas necesarias en la estimation.

24.1. Si la gente no guarda Cuidadosamente Datos de Proyectos Anteriores, olvida las Tareas Menos visibles, hijo de Pero Tareas Que se de han de: Añadir

25. Planificar Ponerse al Día Más adelante

25.1. Un tipo de estimación es responder inapropiadamente al retraso del plan

26. Programación a destajo

26.1. Algunas Organizaciones Creen que la Codificación Rápida, libre, tal Como salga Es El Camino hacia el Desarrollo Rápido

27. Exceso de Requerimientos.

27.1. Tiene algunos adj Proyectos mas: requerimientos de Los Que necesitan, from El Mismo inicio.

28. Cambio de las prestaciones

28.1. 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.

29. Desarrolladores meticulosos.

29.1. Los desarrolladores encuentran fascinante la nueva tecnologia, y a veces estan 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.

30. Tiras y aflojas en la negociación.

30.1. 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.

31. Desarrollo orientado a la investigación.

31.1. Si el proyecto fuerza los limites 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

32. Síndrome de la panacea.

32.1. 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

33. Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos.

33.1. 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

34. Cambiar de herramientas a mitad del proyecto

34.1. Es un viejo recurso que funciona raramente. A veces puede tener sentido actualizar incrementalmente dentro de la misma linea de productos, de la versión 3 a la 3.1 o incluso a la 4.

35. Falta de control automático del código fuente

35.1. 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.

36. Planificación insuficiente.

36.1. Si no planificamos para conseguir un desarrollo rápido, no podemos esperar obtenerlo.