Administracion de Proyectos

2
ADMINISTRACIOND E PROYECTOS Los Programadores son optimistas perpetuos. Casi todos piensan que la forma de escribir un programa es correr la teclado y comenzar a escribir . Poco tiempo después el programa depurado por completo estará listo En el caso de programas muy grandes, la cosa no funciona asi. En las secciones que siguen diremos algo acerca de la administración de proyectos de software grandes, sobre todo proyectos de sistemas operativos grandes. 12.5.1. El mes hombre mitico En su libro clásico Fredd Brooks, uno de los diseñadores de os \ 360y que mas adelante se dedico a su vida academica, aborda la pregunta de porque es tan difícil construir sistemas operativos grandes (Brooks, 1975 , 1995). Cuando la mayoría de los programadores lee su afirmación de que un programador solo peude producir 1000 lineas de código depurado al año en proyectos grandes , se pregunta si el profesor Brooks esta viviendo en el espacio exterior, tal vez en el planeta Error. Despues de todo , casi todos ellos pueden recordar una sesión que se prolongo hasta la madrugada y en la cual produjeron un programa de 1000 lineas . ¿Como podría ser esta la producción anual de una persona con un coeficiente intelectual de mas de 50? Lo que Brook señalo es que los proyectos grandes, con cientos de prohgramadores , son distintnos por completo de los proyectos pequeños , y que no esposible extrapolar los resultados obtenidos en proyecto spequeños , y que no es posible extrapolar los resultados obtendios en proyectos pequeños a la escala de los grandes. En un proyecto grande se consume una cantidad enorme de tiempo planenando como dividir el trabajo en modulos, especificando en forma minuciosa los modulos y sus interfaces , y tratando de imaginar como van interactuar los modulos aislados . Por ultimo, habrá que integrar los modulos y probar el sistema como un todo. El caso normal es que cada modulo funcione a la perfeccion cuando se prueba solo, peor que el

description

Administracion de Proyectos

Transcript of Administracion de Proyectos

ADMINISTRACIOND E PROYECTOSLos Programadores son optimistas perpetuos. Casi todos piensan que la forma de escribir un programa es correr la teclado y comenzar a escribir . Poco tiempo despus el programa depurado por completo estar listo En el caso de programas muy grandes, la cosa no funciona asi. En las secciones que siguen diremos algo acerca de la administracin de proyectos de software grandes, sobre todo proyectos de sistemas operativos grandes.12.5.1. El mes hombre miticoEn su libro clsico Fredd Brooks, uno de los diseadores de os \ 360y que mas adelante se dedico a su vida academica, aborda la pregunta de porque es tan difcil construir sistemas operativos grandes (Brooks, 1975 , 1995). Cuando la mayora de los programadores lee su afirmacin de que un programador solo peude producir 1000 lineas de cdigo depurado al ao en proyectos grandes , se pregunta si el profesor Brooks esta viviendo en el espacio exterior, tal vez en el planeta Error. Despues de todo , casi todos ellos pueden recordar una sesin que se prolongo hasta la madrugada y en la cual produjeron un programa de 1000 lineas .Como podra ser esta la produccin anual de una persona con un coeficiente intelectual de mas de 50?Lo que Brook sealo es que los proyectos grandes, con cientos de prohgramadores , son distintnospor completo de los proyectos pequeos , y que no esposible extrapolar los resultados obtenidos en proyecto spequeos , y que no es posible extrapolar los resultados obtendios en proyectos pequeos a la escala de los grandes. En un proyecto grande se consume una cantidad enorme de tiempo planenando como dividir el trabajo en modulos, especificando en forma minuciosa los modulos y sus interfaces , y tratando de imaginar como van interactuar los modulos aislados . Por ultimo, habr que integrar los modulos y probar el sistema como un todo. El caso normal es que cada modulo funcione a la perfeccion cuando se prueba solo, peor que el sistema falle de inmediato se arman todas las piezas . Brooks estimo que el trabajo se comoponde de1\3 de planificacin1\6 codificacion1\4 prueba de modulos1\4 pruebas del sistemaEn otras palabras, la escritura del cdigo es la parte fcil. La parte difcil es averiguar que deben hacer los modulos y lograr que el modulo A se comunique en forma correcta con el modulo B. En un programa pequeo escrito por un solo programador, lo nico que queda es la parte fcil.El titulo del libro de Brooks proviene de que su aseveracin de las personas y el tiempo no son intercambiables . No existe una unidade de mes hombre (o mes persona) . Si 15 personas tardan dos aos en llevar acabo un pryecto , es inconcesible de que 360 personas puedan hacerlo en un mes y quiz tampoco ser posible que 60 personas lo hagan en 6 meses.Tres razones explican este efecto. Primera el trabajo no puede dividirse completamente en actividades paralelas. Mientras no se haya llevado a cabo la planificacin y determinado que modulos se necesitan y que interfaces tendrn, no puede comenzar ninguna actividad de codificacin. En un proyecto de dos aos , la planificacin por si sola podr ocupar ocho meses.Segunda, para aprovechar en forma plena a un gran numero de programadores, el trabajo debe dividirse en un gran numeor de modulos para que todo mundo tenga alo que hacer. Puesto que cabe la posibilidad de que cada odulointeractue con todos y cada uno de los dems modulos, el numero de interacciones modulo modulo que es necesario considerar crece en funcin del cuadro