El Mitico Hombre Mes

El Mítico Hombre-Mes
(Redirigido desde The Mythical Man-Month)

El Mítico Hombre-Mes: Ensayos de ingeniería de Software (en inglés The Mythical Man-Month : Essays on Software Engineering) es un libro de administración de proyectos de Software de Fred Brooks, cuyo tema central está en que "agregando recursos humanos a un proyecto retrasado lo hace demorarse aún más". Esta idea es conocida como la"Ley de Brooks".
El trabajo fue publicado en 1975, y republicado como una versión aniversario en 1995 (ISBN 0-201-83595-9) junto al ensayo "Sin balas de plata" y comentarios por el autor.
Las observaciones de Brooks están basadas en sus experiencias en IBM mientras administraba el desarrollo de OS/360. Para acelerar el desarrollo, se trató infructuosamente de agregar más trabajadores al proyectoque ya estaba retrasado. También apostó que escribir un compilador en ALGOL requería "6 meses de mano de obra" adicional. La tendencia de quienes administran de repetir estos errores llevaron a Brook a la conclusión de "la biblia de la ingeniería de software" porque "todos la leen pero nadie la practica".
Contenido
  [ocultar] 
1 El Mito del Hombre-Mes
2 El efecto Segundo-Sistema
3 Seguimiento deprogresos
4 Integridad Conceptual
5 El Manual
6 El Piloto
7 Documentos Formales
8 Enlaces externos
[editar]El Mito del Hombre-Mes
Asignar más programadores a un proyecto atrasado sólo lo atrasará más, debido al tiempo requerido por los nuevos programadores para aprender acerca del proyecto, como al aumento en la sobrecarga de comunicaciones. Cuando N personas tienen que comunicarse entre ellos(sin jerarquías), al aumentar N, la cantidad de comunicación M disminuye y puede incluso resultar negativa, p.ej., el trabajo total pendiente al final del día es mayor que el trabajo total que había pendiente al principio del día, como cuando se crean muchos nuevos errores.
Fórmula de la intercomunicación grupal: n(n − 1) / 2
Ejemplo: 50 programadores generan 50 · (50 – 1) / 2 = 1225 canales decomunicación.
[editar]El efecto Segundo-Sistema
El segundo sistema que un arquitecto diseña es el más peligroso de todos los que nunca hará, dado que tenderá a incorporar todos los agregados que él mismo generó pero no pudo agregar (debido a inherentes restricciones de tiempo) a su primer sistema. Por tanto, cuando se embarca en un segundo sistema, un ingeniero debería tener presente su naturaltendencia a sobrecargarlo.
[editar]Seguimiento de progresos
Pregunta: ¿Cómo es posible que un gran proyecto de software se atrase un año entero? Respuesta: ¡De a un día a la vez! Pequeñas demoras incrementales en variados frentes eventualmente se acumulan para producir un enorme retraso. Permanente atención al alcance de pequeñas metas individuales se requiere en todos los niveles del proyecto.[editar]Integridad Conceptual
Para hacer que un sistema sea utilizable (amigable), debe tener integridad conceptual, lo que solo es posible separando la arquitectura de la implementación. Un único arquitecto jefe (o un pequeño número de arquitectos), actuando en representación del usuario, decide qué debe ir en el sistema y qué debe permanecer fuera. Una "super" idea de alguien no debe ser incluída si nocalza armoniosamente con el diseño general del sistema. De hecho, para asegurarse un sistema amigable, se debe brindar deliberadamente menos características de las que es capaz de tener. El punto es que si un sistema es demasido complejo de usar, entonces muchas de sus características no se utilizarán solo porque nadie tendrá el tiempo de aprender a usarlas.
[editar]El Manual
Lo que el diseñador enjefe produce son especificaciones escritas para el sistema en forma de manual. Debería describir las especificaciones externas del sistema en detalle, p.ej., todo lo que el usuario ve. El manual debería ser alterado a medida que se recibe retroalimentación de los usuarios y del equipo de desarrollo.
[editar]El Piloto
Al diseñar un nuevo tipo de sistema, un equipo hará un sistema descartable...