Sistemas operativos modernos

Puesto Deberes Programador en jefe Realiza el diseño arquitectónico y escribe el código Copiloto Ayuda al programador en jefe y comenta sus sugerencias Administrador Maneja el personal, presupuesto, espacio, equipo, informes, etcétera Editor Edita la documentación, que debe redactar el programador en jefe Secretarios Tanto el administrador como el editor necesitan un secretarlo Arcíiivador de programas Mantiene los archivos de código y documentación Instrumentista Proporciona las herramientas que necesita el programador en jefe Probador Prueba el código del programador en jefe Abogado de lenguajes Miembro ocasional que asesora al programador en jefe en cuanto al lenguaje Figura 12-9. Propuesta de Mills para integrar un equipo de programador en jefe de 10 personas. pero persiste la necesidad de que una sola mente controle el diseño. Además, esa mente debe­ rá poder dedicar 100 % de su tiempo a diseñar y programar, de ahí la necesidad del personal de apoyo, aunque con la ayuda de la computadora el persona) que se necesita ahora es más redu­ cido. No obstante, la esencia de la idea sigue siendo válida. Cualquier proyecto grande debe organizarse en una jerarquía. En el nivel más bajo están muchos equipos pequeños, cada uno encabezado por un programador en jefe. En el siguiente nivel, un gerente debe coordinar grupos de equipos. La experiencia muestra que cada persona dirigida requiere 10 % del tiempo del gerente, por lo que se requiere un gerente de tiempo com­ pleto por cada grupo de 10 equipos. Estos gerentes necesitan a su vez otros gerentes, y así has­ ta la parte más alta del árbol. Brooks observó que las malas noticias tienen dificultad para subir por el árbol. Jerry Salt­ zer, del MIT, llamó a este efecto diodo de malas noticias. Ningún programador en jefe o ge­ rente quiere decirle a su jefe que el proyecto lleva un atraso de cuatro meses y que va a ser imposible cumplir con la fecha límite, porque existe una tradición milenaria de cortarle la ca­ beza al portador de malas noticias. Por íllo, la alta gerencia generalmente no está enterada del estado real del proyecto. Cuando se hace obvio que no podrá cumplirse con la fecha límite, la alta gerencia responde añadiendo personal, y en ese momento entra en acción la ley de Brooks. En la práctica, las compañías grandes, que han tenido larga experiencia en la producción de software y saben qué sucede si se produce a tontas y a locas, al menos tratan de hacerlo en forma correcta. En cambio, las pequeñas compañías nuevas, ansiosas por salir al mercado, no siempre se toman el fiempo para crear su software con cuidado. Esta prisa, por lo regular, pro­ duce resultados nada óptimos. Ni Brooks ni Mills previeron el crecimiento del movimiento de fuente abierta. Aunque ha lo­ grado algunos éxitos, todavía no se ha comprobado que sea un modelo viable para producir gran­ des cantidades de software de calidad una vez que pase la novedad. Recordemos que, en sus albores, la radio estuvo dominada por operadores aficionados, pero éstos pronto cedieron su lugar a la radio comercial y más adelante a la televisión comercial. Lo notable es que los pro­ yectos de software de fuente abierta que más éxito han tenido han ufilizado el modelo de