Sistemas operativos modernos

las secciones que siguen diremos algo acerca de la adminisü’ación de proyectos de software grandes, sobre todo, proyectos de sistemas operativos grandes. 12.5.1 El mes-hombre mítico En su libro clásico, Fred Brooks, uno de los diseñadores de OS/360 y que más adelante se de­ dicó a la vida académica, aborda la pregunta de por qué es tan difícil construir sistemas opera­ tivos grandes (Brooks, 1975,1995). Cuando la mayoría de los programadores lee su afirmación de que un programador sólo puede producir 1000 líneas de código depurado al año en proyec­ tos grandes, se preguntan si el profesor Brooks está viviendo en el espacio exterior, tal vez en el Planeta Error. Después de todo, casi todos ellos pueden recordar una sesión que se prolon­ gó hasta la madrugada y en la cual produjeron un programa de 1000 líneas. ¿Cómo podría ser ésta la producción anual de una persona con un coeficiente intelectual de más de 50? Lo que Brooks señaló es que los proyectos grandes, con cientos de programadores, son dis­ tintos por completo de los proyectos pequeños, y que no es posible extrapolar los resultados obte­ nidos en proyectos pequeños a la escala de los grandes. En un proyecto grande, se consume una cantidad enorme de tiempo planeando cómo dividir el trabajo en módulos, especificando en for­ ma minuciosa los módulos y sus interfaces, y tratando de imaginar cómo van a interactuar los mó­ dulos, incluso antes de iniciarse la codificación. Luego será preciso codificar y depurar los módulos aislados. Por úlfimo, habrá que integrar los módulos y probar el sistema como un to­ do. El caso normal es que cada módulo funcione a la perfección cuando se prueba solo, pero que el sistema falle de inmediato cuando se arman todas las piezas. Brooks estimó que el tra­ bajo se compone de 1/3 Planificación 1/6 Codificación 1/4 Prueba de módulos 1/4 Prueba del sistema En otras palabras, la escritura del código es la parte fácil. La parte difícil es averiguar qué deben hacer los módulos y lograr que el módulo A se comunique en forma correcta con el módulo B. En un programa pequeño escrito por un solo programador, lo único que queda es la parte fácil. El título del libro de Brooks proviene de su aseveración de que las personas y el tiempo no son intercambiables. No existe una unidad de mes-hombre (o mes-persona). Si 15 personas tar­ dan dos años en llevar a cabo un proyecto, es inconcebible que 360 personas puedan hacerlo en un mes y quizá tampoco será posible que 60 personas lo hagan en seis meses. Tres razones explican este efecto. Primera, el trabajo no puede dividirse completamente en actividades paralelas. Mientras no se haya llevado a cabo la planificación y determinado qué módulos se necesitan y qué interfaces tendrán, no puede comenzar ninguna actividad de codi­ ficación. En un proyecto de dos años, la planificación por sí sola podría ocupar ocho meses. Segunda, para aprovechar en forma plena a un gran número de programadores, el trabajo debe dividirse en un gran número de módulos para que todo mundo tenga algo que hacer. Pues­ to que cabe la posibilidad de que cada módulo interactúe con todos y cada uno de los demás módulos, el número de interacciones módulo-módulo que es necesario considerar crece en fun