El mes-Hombre mítico Edit

Brooks discute varias causas de fallos de programación. La más duradera es su discusión de la ley de Brooks:Agregar mano de obra a un proyecto de software tardío lo hace más tarde. El mes-hombre es una unidad hipotética de trabajo que representa el trabajo realizado por una persona en un mes; la ley de Brooks dice que la posibilidad de medir el trabajo útil en meses-hombre es un mito, y por lo tanto es la pieza central del libro.

Los proyectos de programación complejos no se pueden dividir perfectamente en tareas discretas en las que se puede trabajar sin comunicación entre los trabajadores y sin establecer un conjunto de interrelaciones complejas entre las tareas y los trabajadores que las realizan.

Por lo tanto, asignar más programadores a un proyecto que se esté retrasando lo hará aún más tarde. Esto se debe a que el tiempo requerido para que los nuevos programadores aprendan sobre el proyecto y el aumento de la sobrecarga de comunicación consumirán una cantidad cada vez mayor del tiempo disponible en el calendario. Cuando n personas tienen que comunicarse entre sí, a medida que n aumenta, su producción disminuye y cuando se vuelve negativa, el proyecto se retrasa aún más con cada persona agregada.

• Fórmula de intercomunicación de grupo: n (n − 1) / 2
• Ejemplo: 50 desarrolladores dan 50 · (50 – 1) / 2 = 1225 canales de comunicación.

Sin viñetaeditar

Brooks añadió » No Silver Bullet — Esencia y Accidentes de Ingeniería de Software «—y más reflexiones sobre ella,»‘No Silver Bullet’ Refired » -a la edición de aniversario del Mítico Mes del Hombre.

Brooks insiste en que no hay una solución mágica «» no hay un solo desarrollo, ni en tecnología ni en técnica de gestión, que por sí solo promete una mejora de un orden de magnitud en una década en productividad, fiabilidad y simplicidad.»

El argumento se basa en la distinción entre complejidad accidental y complejidad esencial, similar a la forma en que la ley de Amdahl se basa en la distinción entre «estrictamente serial» y «paralelizable».

El efecto del segundo sistema Edit

El efecto del segundo sistema propone que, cuando un arquitecto diseña un segundo sistema, es el sistema más peligroso que diseñará, porque tenderá a incorporar todas las adiciones que originalmente no agregó al primer sistema debido a restricciones de tiempo inherentes. Por lo tanto, cuando se embarca en un segundo sistema, un ingeniero debe ser consciente de que es susceptible de sobreingeniarlo.

la tendencia hacia La irreductible número de errorsEdit

El autor hace la observación de que en un sistema adecuadamente complejo hay un cierto número irreductible de errores. Cualquier intento de corregir errores observados tiende a dar lugar a la introducción de otros errores.

Seguimiento del progresoeditar

Brooks escribió » Pregunta: ¿Cómo un gran proyecto de software llega a tener un año de retraso? Respuesta: un día a la vez!»Los deslizamientos incrementales en muchos frentes eventualmente se acumulan para producir un gran retraso general. Es necesario seguir prestando atención a la consecución de pequeños hitos individuales en cada nivel de gestión.

Integridad conceptualeditar

Para hacer un sistema fácil de usar, el sistema debe tener integridad conceptual, que solo se puede lograr separando la arquitectura de la implementación. Un solo arquitecto jefe (o un pequeño número de arquitectos), que actúa en nombre del usuario, decide lo que entra en el sistema y lo que queda fuera. El arquitecto o equipo de arquitectos debe desarrollar una idea de lo que debe hacer el sistema y asegurarse de que el resto del equipo entienda esta visión. Es posible que una idea novedosa de alguien no se incluya si no encaja a la perfección con el diseño general del sistema. De hecho, para garantizar un sistema fácil de usar, un sistema puede proporcionar deliberadamente menos características de las que es capaz de hacer. El punto es que, si un sistema es demasiado complicado de usar, muchas características no se usarán porque nadie tiene tiempo para aprenderlas.

El manualeditar

El arquitecto jefe produce un manual de especificaciones del sistema. Debe describir en detalle las especificaciones externas del sistema, es decir, todo lo que ve el usuario. El manual debe modificarse a medida que los equipos de implementación y los usuarios reciban comentarios.

El sistema piloteditar

Al diseñar un nuevo tipo de sistema, un equipo diseñará un sistema desechable (ya sea que lo desee o no). Este sistema actúa como un» plan piloto » que revela técnicas que posteriormente causarán un rediseño completo del sistema. Este segundo sistema, más inteligente, debería ser el que se entrega al cliente, ya que la entrega del sistema piloto no causaría más que agonía al cliente, y posiblemente arruinaría la reputación del sistema y tal vez incluso la compañía.

Documentos formaleseditar

Cada gerente de proyecto debe crear un pequeño conjunto básico de documentos formales que definan los objetivos del proyecto, cómo se van a lograr, quién los va a lograr, cuándo se van a lograr y cuánto van a costar. Estos documentos también pueden revelar inconsistencias que de otro modo serían difíciles de ver.

Estimación de proyectosEditar

Al estimar los tiempos del proyecto, debe recordarse que los productos de programación (que se pueden vender a clientes que pagan) y los sistemas de programación son tres veces más difíciles de escribir que los programas internos independientes simples. Se debe tener en cuenta cuánto de la semana de trabajo se dedicará realmente a cuestiones técnicas, en lugar de tareas administrativas u otras tareas no técnicas, como reuniones, y especialmente reuniones «de pie» o «de todos».

Comunicacióneditar

Para evitar desastres, todos los equipos que trabajan en un proyecto deben mantenerse en contacto entre sí de tantas maneras como sea posible: correo electrónico, teléfono, reuniones, notas, etc. En lugar de asumir algo, los implementadores deben pedir al arquitecto(es) que aclare su intención sobre una característica que están implementando, antes de proceder con una suposición que muy bien podría ser completamente incorrecta. Los arquitectos son responsables de formular una imagen grupal del proyecto y comunicarla a los demás.

El equipo quirúrgicoeditar

Al igual que un equipo quirúrgico durante la cirugía es dirigido por un cirujano que realiza el trabajo más crítico, mientras dirige al equipo para que ayude con las partes menos críticas, parece razonable tener un «buen» programador que desarrolle los componentes críticos del sistema, mientras que el resto del equipo proporciona lo que se necesita en el momento adecuado. Además, Brooks reflexiona sobre que los programadores «buenos» son generalmente de cinco a diez veces más productivos que los mediocres.

Congelación de código y versiones del sistemaeditar

El software es invisible. Por lo tanto, muchas cosas solo se hacen evidentes una vez que se ha realizado una cierta cantidad de trabajo en un nuevo sistema, lo que permite al usuario experimentarlo. Esta experiencia generará información, que cambiará las necesidades de un usuario o la percepción de las necesidades del usuario. Por lo tanto, el sistema debe cambiarse para cumplir con los requisitos modificados del usuario. Esto solo puede ocurrir hasta cierto punto, de lo contrario, es posible que el sistema nunca se complete. En una fecha determinada, no se deben permitir más cambios en el sistema y el código debe congelarse. Todas las solicitudes de cambios deben retrasarse hasta la próxima versión del sistema.

Herramientas especializadaseditar

En lugar de que cada programador tenga su propio conjunto especial de herramientas, cada equipo debe tener un fabricante de herramientas designado que pueda crear herramientas altamente personalizadas para el trabajo que realiza el equipo, por ejemplo, una herramienta generadora de código que cree código basado en una especificación. Además, un equipo de herramientas comunes, supervisado por el director del proyecto, debería crear herramientas para todo el sistema.

Reducir los costos de desarrollo de software Edit

Hay dos técnicas para reducir los costos de desarrollo de software de las que Brooks escribe:

• Los implementadores pueden ser contratados solo después de que se haya completado la arquitectura del sistema (un paso que puede tomar varios meses, durante el cual los implementadores contratados prematuramente pueden no tener nada que hacer).
• Otra técnica que Brooks menciona no es desarrollar software en absoluto, sino simplemente comprarlo «listo para usar» cuando sea posible.