2009-03-05 17 views
5

Estoy leyendo Code Complete, así como un par de otros libros de programación en este momento. El tamaño del proyecto afecta a muchos otros parámetros que debe tener en cuenta al planificar, codificar, automatizar pruebas, etc. Me preguntaba qué es lo que las personas en SO generalmente usan en el mundo real para categorizar un proyecto en su "peso" correcto. clase"?¿Cómo mides un proyecto pequeño, grande y muy grande?

¿Se trata de líneas de código? ¿Número de interfaces externas? Páginas necesarias de documentación?

+2

Voy a cerrar esta pregunta como fuera de tema porque no se trata de programación. –

+0

Hombre genial, tuvo un buen OCHO años. –

+0

Es probable que no se borre, solo se cierre; sin embargo, hay un gran impulso para limpiar y posiblemente incluir en la lista negra las etiquetas relacionadas con la administración del proyecto, porque están siendo mal utilizadas (ahora que tenemos [SoftwareEngineering.SE] y [pm. se] hay un impulso para alentar nuevas preguntas sobre este tema que se preguntarán allí). – EJoshuaS

Respuesta

9

Yo diría que es la cantidad de esfuerzo de desarrollo requerido. Tomando un equipo de seis desarrolladores:

  • Pequeño proyecto - hasta 6 meses
  • gran proyecto - 6-18 meses
  • proyecto muy grande - 18+ meses

Todos tendrán una opinión diferente sin embargo.

Editar

estaba pensando acerca de cómo esos valores cambiarían por un "equipo" 1 desarrollador. Creo que sería lo largo de las líneas de:

  • Pequeño proyecto - hasta 1 mes
  • gran proyecto - 1-3 meses
  • proyecto muy grande - más de 3 meses

Este parece sugerir que para un pequeño número de desarrolladores, la regla empírica para el tamaño del proyecto podría ser:

  • Pequeño proyecto: hasta 1 mes por desarrollador
  • gran proyecto - 1-3 meses al desarrollador
  • proyecto muy grande - 3+ meses al desarrollador

Dudo que esto escalas más allá de 6 o más desarrolladores, ya que el número de canales de comunicación empieza a alargarse el tiempo potencial de desarrollo de cada persona. Efectivamente lo que lleva a menos trabajo realizado por mes por desarrollador, más personas tiene en su equipo.

+0

Además, obtiene más sobrecarga para cada persona que agrega al desarrollador/probador del equipo/etc. – BIBD

5

Yo diría Tiempo y Manpower.

1

Normalmente mido el tamaño de un proyecto en el tiempo que llevaría completar, pero otras personas pueden ser diferentes.

0

No comenzaría a saber cómo estimar las líneas de código esperadas en un proyecto. Documentación ... qué es eso;) Entonces para mí, ninguna de esas cosas.

Probablemente contaría las áreas funcionales principales, y vería una idea aproximada del número de pantallas/páginas y también una idea aproximada del número de tablas de la base de datos. La complejidad de la base de datos puede ser un buen indicador en muchos proyectos, creo.

0

La curva de aprendizaje: la cantidad de tiempo que tarda un desarrollador nuevo en familiarizarse con el código antes de que pueda hacer algo útil para contribuir a él.

0

Es un tipo de idea izquierda, pero cuando estoy trabajando en un proyecto que prevén como siendo

1) Una casa = pequeño proyecto

2) Un proyecto supermarkert = tamaño medio

3) Un aeropuerto = gran proyecto

Conoces a las personas que te rodean, lo que tú y ellos están haciendo, y tus posibilidades de éxito en cuál de los tres te encuentras.

1

Podría ser una combinación de cosas:.

  • est puntos de función - tamaño del código
  • puntos de integración - con sistemas externos
  • complejidad de aplicación (aplicaciones web son típicamente menos complejo que sistemas integrados: compare un sitio web con un programa para un cohete)
  • grupos empresariales involucrados - un pequeño cambio que necesita aprobación de 20 unidades de negocios podría ser un gran esfuerzo

Lo anterior determinaría el tamaño del proyecto: el número de personas determinaría la línea de tiempo y agregaría complejidad

Cuestiones relacionadas