Metodologa y Tamao

Metodologas se utilizan en proyectos de todos los tamaos. En proyectos

pequeos, metodologas tienden a ser casual e instintiva. En proyectos
grandes, tienden a ser rigurosa y cuidadosamente planificada.
Algunas metodologas pueden ser tan floja que los programadores ni
siquiera son conscientes de que estn usando ellos. Unos programadores
sostienen que las metodologas son demasiado rgidas y dicen que no van a
tocar. Si bien puede ser cierto que un programador no ha seleccionado una
metodologa consciente, cualquier enfoque de la programacin constituye
una metodologa, no importa lo inconsciente o primitiva el enfoque es. El
mero hecho de levantarse e ir a trabajar por la maana es una metodologa
rudimentaria, aunque no muy creativa. El programador que insiste en
metodologas evitando en realidad es slo evitar la eleccin de uno
explcitamente que nadie puede evitar el uso de ellos por completo.
Enfoques formales no siempre son divertidos, y si estn mal aplicados, sus
gastos generales se traga a sus otros ahorros. La mayor complejidad de los
proyectos ms grandes,
sin embargo, requiere una mayor atencin
consciente a la metodologa. La construccin de un rascacielos de requiere
un enfoque diferente a la construccin de una caseta de perro. Diferentes
tamaos de proyectos de software funcionan de la misma manera. En
proyectos grandes, inconscientes opciones son inadecuados para la tarea.
Los planificadores de proyectos exitosos eligen a sus estrategias para
grandes proyectos de manera explcita.
En los entornos sociales, la ms formal del evento, los ms incmodos a sus
ropa tiene que ser (tacones altos, corbatas, etc.). En el desarrollo de
software, los ms formal del proyecto, ms de papel que tiene que generar
para asegurarse de que ha hecho su tarea. Capers Jones seala que un
proyecto de 1.000 288 lneas de cdigo tendr un promedio de alrededor del
7% de su esfuerzo en el papeleo, mientras que una lnea 100 000 de cdigo
de proyecto tendr un promedio de alrededor del 26% de su esfuerzo en el
papeleo (Jones 1998).
Esta documentacin no ha sido creada por el simple placer de la escritura
de documentos. Se crea como resultado directo del fenmeno se ilustra en
la Figura 27-1-los ms de cerebros de las personas que tienen que
coordinar, la documentacin ms formal que necesita para coordinarlos.
No se crea ninguna de esta documentacin para su propio bien. El punto de
escribir un plan de gestin de la configuracin, por ejemplo, es no ejercer
sus msculos escritura. El punto de su escritura es el plan para obligar a
pensar cuidadosamente acerca de gestin de la configuracin y forzar a
que explique su plan de a todos los dems.

La documentacin es un efecto secundario tangible del trabajo real que

hace como a planear y construir un sistema de software. Si se siente como

si estuviera pasando por los movimientos y escribir documentos genricos,

algo est mal.

"Ms" no es mejor, por lo que las metodologas se refiere. En su revisin de

giles frente a las metodologas del plan impulsado, Barry Boehm y Richard
Turner advertir que por lo general va a hacer mejor si se inicia sus mtodos
pequea y la escala para un gran proyecto que si se inicia con un todo
incluido mtodo y recortar hacia abajo para un pequeo proyecto 306
(Boehm y Turner 2004). Algunos expertos hablan de software metodologas
"ligeros" y "peso pesado", pero en la prctica la clave es considerar el
tamao especfico de su proyecto y el tipo y luego encontrar la metodologa
que est "bien-peso."

Recursos adicionales
Boehm, Barry y Richard Turner. Equilibrar la agilidad y disciplina: Una Gua
de los Perplejos, Boston, Mass .: Addison Wesley, 2004. Boehm y Turner
describen cmo el tamao del proyecto afecta a la utilizacin de mtodos
giles y conducidos plan, junto con otros temas giles y del plan impulsado.
Boehm, Barry W. 1981. Software Economa Ingeniera. Englewood Cliffs,
N.J .: Prentice Hall. El libro de Boehm es un extenso tratamiento de los
costes y la productividad , y las ramificaciones de calidad de tamao del
proyecto y otras variables en el proceso de desarrollo de software. Incluye
discusiones sobre el efecto del tamao deconstrucciones y otras
actividades. El captulo 11 es una excelente explicacin de deseconomas
de software de escala. Otra informacin sobre el tamao del proyecto se
extendi a lo largo del libro. Libro 2000 Software Estimacin de costes de
Boehm con Cocomo II contiene mucha ms informacin al da sobre modelo
de estimacin de Cocomo de Boehm, pero el libro anterior proporciona ms
de fondo debates en profundidad que siguen siendo pertinentes.
Jones, Alcaparras, Estimacin de los costos de soporte lgico, Nueva York:
McGraw-Hill, 1998. Este libro est lleno de tablas y grficos del diseccionar
las fuentes de software de productividad de desarrollo. Por el impacto del
tamao del proyecto en concreto, de Jones 1986 Productividad libro de
programacin contiene una excelente discusin de la seccin titulado "El
impacto del programa de Tamao" en el Captulo 3.

Brooks, Frederick P., Jr. El mes laboral mtico: Ensayos sobre Ingeniera de
Software, Aniversario Edicin (2 edicin), Reading, Mass. Addison-Wesley,
1995. Brooks fue el gerente de desarrollo de IBM OS / 360, un gigantesco
proyecto que se llev a 5000 aos-persona. El autor analiza las cuestiones
de gestin relativas a los equipos pequeos y grandes, y presenta un relato
particularmente vvido de los equipos de jefe de programacin en esta
coleccin de ensayos de acoplamiento.

DeGrace, Peter, y Leslie Stahl. Los problemas complejos, soluciones

Righteous: un catlogo de los modernos paradigmas de Ingeniera de
Software. Englewood Cliffs, N.J .: Yourdon Press, 1990. Como indica el ttulo,
este libro catlogos enfoques para el desarrollo de software. Como se ha
sealado en este captulo, el enfoque debe variar a medida que el tamao
del proyecto vara, y DeGrace y Stahl hacer ese punto con claridad. La
seccin titulada "atenuantes y Truncar" en el captulo 5 se examina la
personalizacin de los procesos de desarrollo de software basado en el
tamao del proyecto y la formalidad. El libro incluye descripciones de los
modelos de la NASA y el Departamento de Defensa y un notable nmero de
ejemplos edificantes.
Jones, T. Capers. ". Programa de Calidad y Productividad del programador"
IBM Informe Tcnico TR 02,764 (enero de 1977): 42-78. Tambin disponible
en el Tutorial de Jones: La programacin de productividad:. Cuestiones de
los aos ochenta, 2 ed, Los ngeles: IEEE Computer Society Press, 1986.
Este documento contiene el primer anlisis en profundidad de las razones
grandes proyectos tienen diferentes patrones de gasto que los pequeos. Es
una discusin a fondo de las diferencias entre grandes y pequeos
proyectos, incluidos los requisitos y medidas de garanta de calidad. Tiene
fecha, pero todava interesante.
Puntos clave
A medida que aumenta el tamao del proyecto, la comunicacin debe ser
apoyada. El punto de la mayora de las metodologas es reducir los
problemas de comunicacin, y una metodologa debe vivir o morir por sus
mritos como un facilitador de comunicacin.
Todas las dems cosas son iguales, la productividad ser ms bajo en un
proyecto grande que en una pequea.
Todas las dems cosas son iguales, un gran proyecto tendrn ms errores
por cada lnea de cdigo que uno pequeo.
Las actividades que se dan por sentado en pequeos proyectos deben ser
cuidadosamente planificadas en los ms grandes. La construccin se vuelve
menos predominante a medida que aumenta el tamao del proyecto.
Ampliacin de la escala una metodologa de peso ligero tiende a funcionar
mejor que escalar por una metodologa de gran peso. El enfoque ms eficaz
de todos est utilizando una metodologa "al peso correcto".