Citas de "El Mítico Hombre-Mes"

• Prefacio a la Primera Edición

Creo que los grandes proyectos de programación sufren de problemas de gestión de diferente tipo que los pequeños, a causa de la división del trabajo.

• El Pozo de Brea

A lo largo de la década pasada la programación de sistemas grandes ha estado en tal pozo de brea, donde muchas bestias grandes y poderosas han sucumbido violentamente.

A pesar de que la mayoría ha emergido con sistemas que funcionan, pocas han cumplido con los objetivos, calendarios, y presupuestos.

¿Por qué la programación es divertida? ¿Qué satisfacciones pueden esperar sus practicantes como recompensa?

Primero, es la pura satisfacción de hacer cosas. Así como el niño se deleita en su pastel de lodo, así el adulto disfruta construyendo cosas, especialmente cosas de su propio diseño.

Pienso que esta satisfacción debe ser una imagen de la satisfacción de dios al construir cosas, una satisfacción demostrada en la individualidad y originalidad de cada hoja y cada copo de nieve.

Segundo, es el placer de hacer cosas que sean útiles para otras personas.

Tercero, es la fascinación de crear objetos complejos, como rompecabezas, de piezas móviles entrelazadas y observarlos trabajar en ciclos sutiles, desplegando desde el inicio las consecuencias de los principios incorporados.

La computadora programada tiene toda la fascinación de la máquina de pinball o del mecanismo de la rocola, llevada al extremo.

Cuarto, es la satisfacción del continuo aprendizaje, que brota de la naturaleza no repetitiva del trabajo.

De una forma u otra el problema es siempre nuevo, y quien lo resuelve aprende algo: algunas veces algo práctico, otras algo teórico y a veces ambos.

Finalmente, existe la satisfacción de trabajar en un medio tan manipulable.

Sin embargo, no todo es satisfacción y conocer los infortunios intrínsecos nos ayudará para lidiar con ellos cuando surjan.

En primer lugar, se debe actuar perfectamente. El último infortunio, y a veces la gota que colma el vaso, es que el producto en el que se ha trabajado durante tanto tiempo parece estar quedando obsoleto al finalizar (o antes).

• El Mítico Hombre-Mes

Más proyectos de software han fracasado por la escasez de tiempo de calendario que debido a la combinación de otras causas.

Primero, nuestras técnicas de estimación están poco desarrolladas. Segundo, nuestras técnicas de estimación confunden de forma equivo> cada esfuerzo con progreso, Tercero, debido a la incertidumbre de nuestras estimaciones, los gestores de software carecen de la amable tenacidad Cuarto, el calendario de avances está mal supervisado.

Quinto, cuando se detecta un retraso en el calendario, la respuesta normal (y típica) es añadir mano de obra.

Todos los programadores son optimistas. Así pues, la primera falsa suposición que subyace al calendario de la programación de sistemas es que todo saldrá bien, El segundo modo de pensamiento falaz se expresa en la propia unidad de trabajo utilizada en la estimación y en la calendarización: el hombre> mes.

La carga adicional de la comunicación está compuesta de dos partes, la capacitación y la intercomunicación.

Ninguna parte del calendario se ve más afectada por las restricciones secuenciales como la depuración de componentes y la prueba del sistema.

• El Equipo Quirúrgico

En reuniones de la sociedad de computación, con frecuencia escucho a jóvenes gestores de programación afirmar que están a favor de un equipo pequeño e inteligente; de personal de primera clase, en lugar de un proyecto con cientos de programadores, y por ende mediocres.

Nosotros también estamos a favor. Pues este es el problema con el concepto de equipo pequeño e inteligente: es muy lento para sistemas realmente grandes.

Mills ofrece una solución nueva y creativa. 2,3 Él propone que cada segmento de un trabajo grande sea abordado por un equipo, y que cada equipo sea organizado como un equipo quirúrgico en lugar de un equipo de carnicería.

El equipo así definido cumple con los propósitos de varias formas.

Diez personas, siete de ellas profesionales, trabajan en un problema, pero el sistema es el producto de una sola mente – o a lo mucho dos, actuando uno animo.

• Democracia, Aristocracia y Diseño de Sistemas

Yo sostengo que la integridad conceptual es la consideración más importante en el diseño de sistemas.

Es mejor tener un sistema que omita ciertos rasgos anómalos y mejoras, pero que refleje un conjunto de ideas de diseño, que tener uno que contenga muchas ideas buenas pero independientes y sin coordinación.

En El propósito de los sistemas de programación es hacer que la computadora sea fácil de usar.

La facilidad de uso se mejora solo si el tiempo ganado en la especificación funcional excede el tiempo invertido en aprender, recordar y en la búsqueda de manuales.

para un cierto nivel de funcionalidad, el mejor sistema es aquel en el cual se pueden especificar cosas con la mayor simplicidad y sencillez posibles.

La integridad conceptual a su vez obliga a que el diseño proceda de una sola mente, o de un muy pequeño número de mentes en sintonía.

Una forma muy poderosa de lograr la integridad conceptual en proyectos muy grandes consiste en separar el esfuerzo arquitectónico de la implementación.

Las buenas ideas y características que no se integran con los conceptos básicos del sistema es mejor omitirlas.

La integridad conceptual requiere que un sistema refleje una sola filosofía y que la especificación vista por el usuario fluya de unas pocas mentes.

• El efecto del Segundo Sistema

La clave esencial es la exhaustiva, cuidadosa y comprensiva comunicación entre el arquitecto y el constructor.

Sin La tendencia general es sobrediseñar el segundo sistema, utilizando todas las ideas y adornos que cuidadosamente se hicieron a un lado en el primer sistema.

El resultado, como dice Ovidio, es un “gran montón”.

• Pasar la Voz

El manual, o la especificación escrita, es una herramienta necesaria, aunque no suficiente.

No hace falta decir que las reuniones son necesarias. El mejor aliado de un gestor de proyecto es su adversario cotidiano, y es la organización de un probador del producto independiente.

En última instancia, el cliente es el auditor independiente.

• ¿Por Qué Fracasó la Torre de Babel?

El propósito de la organización es reducir la cantidad de comunicación y coordinación necesaria; por lo tanto, la organización es un ataque radical a los problemas de comunicación tratados arriba.

Los medios por los cuales se evita la comunicación son la división del trabajo y la especialización de funciones.

• Predecir la Jugada

La experiencia es un buen maestro, pero los tontos no aprenderán de nadie.

La codificación representa solo alrededor de una sexta parte del problema, y los errores en su estimación o en las proporciones podrían conducir a resultados ridículos.

La productividad de la programación se puede incrementar casi cinco veces cuando se usa un lenguaje de alto nivel adecuado.

• Diez Libras en un Saco de Cinco Libras

Como cualquier costo, el tamaño como tal no es malo, pero el tamaño innecesario sí lo es.

La representación es la esencia de la programación.

• La Hipótesis Documental

"Las organizaciones que diseñan sistemas están obligadas a producir sistemas que son copias de las estructuras de comunicación de tales organizaciones."

Primero, es esencial anotar las decisiones. Solo cuando se escribe surgen los vacíos y sobresalen las contradicciones.

Segundo, los documentos comunicarán las decisiones a los demás. Finalmente, los documentos del gestor le dan una base datos y una lista de control.

El resto es comunicación: escuchar, informar, enseñar, exhortar, conciliar, animar.

El puñado de documentos cruciales son vitales, y satisfarán casi todas sus necesidades.

• Planifique Desechar

En la mayoría de los proyectos, el primer sistema construido apenas es útil.

El primer paso es aceptar el hecho del cambio como forma de vida, en lugar de una excepción inadecuada y molesta.

Algunos cambios en los objetivos son inevitables, y es mejor estar preparados para ellos que suponer que nunca llegarán.

Aceptación del hecho de que a medida que se aprende, se cambia el diseño.

La falla común de los grupos de programación es el muy poco control de gestión, no el exagerado.

En proyectos grandes el gestor debe mantener a dos o a tres de los mejores programadores como caballería técnica que pueda galopar al rescate donde sea que la batalla sea más tupida.

Es fácil fijar escalas salariales correspondientes a cada peldaño. Es mucho más difícil darles el prestigio correspondiente.

Siempre y cuando las aptitudes lo permitan, el personal con experiencia debe mantenerse listo técnica y emocionalmente para gestionar grupos o para disfrutar construyendo programas con sus propias manos.

Los cambios después de la liberación se llaman mantenimiento del programa, problema esencial con el mantenimiento de programas es que corregir un defecto tiene una considerable probabilidad (20> 50 por ciento) de introducir otro.

desconocida. En la práctica tales pruebas de regresión, de hecho, deben aproximarse a este ideal teórico, y eso es muy costoso.

Todas las correcciones tienden a destruir la estructura, a incrementar la entropía y el desorden del sistema.

Además, las máquinas cambian, las configuraciones cambian, y los requisitos del usuario también cambian, por lo que el sistema no es operable eternamente.

Es necesario un flamante rediseño partiendo desde cero.

• Herramientas Afiladas

En primer lugar, el problema esencial es la comunicación, y las herramientas individualizadas dificultan en lugar de facilitar la comunicación.

El ciclo de vida de una herramienta es breve. Debe haber un experto en herramientas por equipo.

Esta persona deber ser experta en todas las herramientas comunes y debe ser capaz de instruir a su cliente> jefe en su uso.

También debe construir herramientas especializadas que su jefe necesita. una concen> tración sostenida reduce el tiempo dedicado a pensar.

Depurar un sistema es como la astronomía, ha sido siempre un trabajo nocturno.

A menos que un programador de aplicaciones observe que un sistema se comporta de forma inconsistente de una ejecución a otra idéntica, está bastante persuadido a buscar errores en su código en lugar de buscarlos en su hardware.

Estoy convencido de que solo la inercia y la pereza impiden la adopción universal de estas herramientas; las dificultades técnicas ya no son excusas válidas. No puedo concebir fácilmente un sistema de programación construido en lenguaje ensamblador.

• El Todo y las Partes

En resumen, la integridad conceptual del producto no solo facilita su uso, también facilita su construcción y lo hace menos propenso a errores.

Para reducir el número de errores en el sistema se necesita una meticulosa definición de la funcionalidad, una cuidadosa especificación y una disciplinada expulsión de adornos funcionales como de técnicas delirantes.

El procedimiento de Wirth es identificar el diseño como una secuencia de pasos de refinamiento.

Es mucho más fácil ver exactamente cuándo y por qué se debe descartar un mal diseño y empezar de nuevo.

Dijkstra arguye que la alternativa, la bifurcación irrestricta vía GO TO, produce estructuras que se prestan a errores lógicos.

Todo el procedimiento fue diseñado para minimizar el tiempo de uso de la computadora, y servir a tantos programadores como fuera posible.

Se puede programar y depurar en un lenguaje de alto nivel.

La parte inesperadamente difícil de la construcción de sistemas de programación es la prueba del sistema.

El uso de componentes limpios, depurados ahorra mucho más tiempo en pruebas del sistema que el gastado en el andamiaje y en las exhaustivas pruebas de componentes.

Uno no conoce todos los efectos esperados de errores conocidos.

Se debe suponer que habrán muchos errores y planificar un procedimiento ordenado para eliminarlos.

• Incubando la Catástrofe

Sin embargo, los desastres generalmente se deben a termitas, no a tornados; y el calendario se ha retrasado imperceptible aunque inexorablemente.

¿Cómo se controla un gran proyecto en un calendario ajustado?

El primer paso es tener un calendario. uno debe ponerse nervioso con el retraso de un día.

Pues tales son los elementos de la catástrofe. Pero no todos los retrasos de un día son igualmente desastrosos.

Pero todo jefe necesita dos tipos de información, las excepciones al plan que requieren acción y un panorama del estado como formación.

Debe disciplinarse para no actuar en los problemas que sus gestores pueden resolver, y nunca actuar en los problemas cuando está revisando explícitamente el estado.

El gestor de componentes debería estar preparado para explicar por qué está retrasado, cuándo estará terminado, qué medidas está tomando y qué ayuda, si es que alguna, necesita del jefe o de grupos colaterales.

Pues el grupo de Planes y Controles es el guardián que visibiliza los retrasos imperceptibles.

• La Otra Cara

Nadie puede poseer lo que no comprende.

La sintaxis organizada rígidamente y las escrupulosas definiciones existen para lograr que las intenciones sean claras a la torpe máquina.

Para los productos de programación, la otra cara hacia el usuario es tan importante como la cara hacia la máquina.

La descripción de cómo se usa un programa se debe complementar con información de cómo se sabe que está funcionando. Esto significa casos de prueba.

El diagrama de flujo es una de las piezas más exageradamente sobrevaloradas de la documentación de un programa.

Muestran la estructura de decisión de una forma bastante elegante cuando el diagrama de flujo cabe en una sola página, pero el resumen fracasa terriblemente cuando tiene múltiples páginas, remendado con salidas numeradas y conectores.

Entonces, las cajas mismas vienen a ser nada más que un ejercicio de dibujo tedioso y devorador de espacio que también podrían ser eliminadas.

Creo que la solución es mezclar los archivos, e incorporar la documentación en el programa fuente. Esto a su vez es un fuerte incentivo hacia el mantenimiento correcto, y nos garantiza de que la documentación siempre estará a disposición del usuario del programa.

Hay varias, algunas han sido reales pero se están volviendo imaginarias con el paso del tiempo.

Puesto que las máquinas están hechas para las personas y no las personas para las máquinas,

• No Existen Balas de Plata: Lo Esencial y lo Accidental

Todo constructo de software involucra tareas esenciales, esto es, la creación de estructuras conceptuales complejas que forman las entidades abstractas de software, y tareas accidentales, es decir, la representación de estas entidades abstractas en lenguajes de programación

De todos los monstruos que pueblan las pesadillas de nuestro folklore, ninguno aterra más que los hombres lobo, pues se transforman inesperadamente de algo familiar en horror. Es por ellos que buscamos balas de plata que mágica> mente los puedan sepultar. Los típicos proyectos de software comparten algunas de estas característica

No existe un solo desarrollo, ni en la tecnología ni en la gestión, que por sí solo prometa al menos una mejora de un orden de magnitud en la productividad, confiabilidad o simplicidad.

Esto mostró a los programadores que el progreso sería realizado paso a paso, con gran esfuerzo, y que se tendría que prestar una atención persistente e incesante al hábito de la pulcritud.

La esencia de una entidad de software es un constructo de conceptos in> terrelacionados: conjuntos de datos, relaciones entre campos de datos, algoritmos e invocaciones de funciones.

Creo que la parte más difícil de la construcción del software es la especificación, el diseño y las pruebas de este constructo conceptual, no el trabajo de representarlo y probar la fidelidad de dicha representación.

las descripciones de una entidad de software que omiten su complejidad muchas veces también omiten su esencia.

Gran parte de la complejidad que debe llegar a gestionar tiene una complejidad arbitraria, forzada sin rima o razón por las numerosas tradiciones y sistemas humanos a los que deben ajustarse sus interfaces.

Todo software exitoso inexorablemente cambia.

¿Qué consigue el lenguaje de alto nivel? Liberar al programa de gran parte de su complejidad accidental.

El tiempo compartido preserva la inmediatez, y por lo tanto nos hace capaces de mantener una visión global de la complejidad.

El efecto principal es la reducción del tiempo de respuesta del sistema.

Cada uno de ellos (tipo de datos abstracto y tipos jerárquicos) elimina una dificultad accidental más del proceso, y permite al diseñador expresar la esencia de su diseño sin tener que expresar grandes cantidades de material sintáctico que no añade nuevo contenido de información.

La dificultad de construir software es decidir qué se quiere expresar, y no cómo expresarlo.

Un sistema experto es un programa que tiene un motor de inferencia generalizada y una base de reglas.

Edward Feigenbaum afirma que el poder de tales sistemas no proviene de los mecanismos de inferencia siempre extravagantes, sino más bien de la base de conocimiento siempre rica que refleja el mundo real de forma más exacta.

Creo que el avance más importante que ofrece esta tecnología consiste en la separación de la complejidad de la aplicación del programa en sí.

La brecha entre la mejor práctica del ingeniero de software y la práctica promedio es muy amplia – quizás más amplia que en otras ramas de la ingeniería.

En esencia, argumenta que en la mayoría de los casos lo que se requiere especificar es el método de solución, no el problema.

La lastimosa forma de elaborar diagramas de flujo hoy en día, a través de múltiples páginas y de cajas de conexiones, ha demostrado ser esencialmente inútil como herramienta de diseño – los programadores dibujan diagramas de flujo después de, no antes de, escribir los programas que los describen.

Cualquiera que haya revuelto un montón de papeles mientras está sentado entre dos pasajeros corpulentos reconocerá la diferencia – solo se pueden ver unas cuantas cosas a la vez.
incluso la verificación perfecta del programa puede solo establecer que un programa cumple con sus especificaciones.

La parte más difícil de la labor de software es llegar a una especificación completa y coherente, y gran parte de la esencia de construir un programa es de hecho la depuración de las especificaciones.

La solución más radical posible para construir software es definitivamente no hacerlo.
desarrollo de un mercado masivo es la tendencia más importante a largo plazo en la ingeniería de software.

Actualmente muchos usuarios manejan día tras día sus propias computadoras en una variedad de aplicaciones sin jamás haber escrito un programa. De hecho, muchos de ellos no saben escribir nuevos programas para sus computadoras, pero sin embargo son expertos en resolver nuevos problemas con ellas.

La parte más difícil de la construcción de los sistemas de software es precisamente decidir qué construir.

No hay otra parte del trabajo conceptual que sea tan dificil como el establecimiento de requisitos técnicos detallados, incluyendo todas las interfaces tanto a los usuarios, como a las computadoras y a otros sistemas de software. O que perjudique tanto el sistema resultante si se hizo mal. Ni que sea más difícil de rectificar posteriormente.

La verdad es que los clientes no saben lo que quieren. Generalmente no saben qué preguntas se deben responder, y casi nunca han pensado en el problema en esos detalles que deben especificarse.

Por lo tanto, uno de los esfuerzos más prometedores de la tecnología actual, y que ataca la esencia, no los accidentes, del problema del software, es el desarrollo de estrategias y herramientas para la obtención rápida de prototipos de sistemas como parte de la especificación iterativa de requisitos.

El propósito del prototipo es hacer realidad la estructura conceptual especificada, de tal manera que el cliente pueda probar su coherencia y su facilidad de uso.

Actualmente gran parte de los procedimientos de adquisición de requisitos de software yacen en la suposición de que se puede especificar un sistema satisfactoriamente por adelantado, obtener ofertas para su construcción, construirlo e instalarlo.
las estructuras conceptuales que construimos hoy en día son bastante complicadas para ser especificadas exactamente por adelantado, y muy complejas para ser construidas sin fallas, entonces debemos tomar un enfoque radicalmente diferente.
que cualquier sistema de software debe desarrollarse a través de un desarrollo incremental.
decir, primero debemos construir un sistema para ser ejecutado, aún cuando no haga nada útil excepto llamar al conjunto apropiado de subprogramas ficticios.

He hallado que los equipos pueden desarrollar entidades mucho más complejas en cuatro meses de las que pueden construir.

Podemos obtener buenos diseños siguiendo buenas prácticas en lugar de malas. Las buenas prácticas de diseño se pueden enseñar.

La construcción del software es un proceso creativo. Una sólida metodología puede facultar y liberar la mente creativa; no puede avivar o inspirar el trabajo rutinario.

Por lo tanto, aunque apoyo firmemente la transferencia de tecnología y los esfuerzos de desarrollo curricular actualmente en curso, creo que el esfuerzo individual más importante que podemos organizar es el desarrollo de formas de crecimiento de grandes diseñadores.

El esfuerzo individual más importante que podemos organizar es el desarrollo de formas de crecimiento de grandes diseñadores.

• ''No Existen Balas de Plata'' Recocido

Toda actividad creativa consta de (1) la formulación de constructos conceptuales, (2) la implementación en un medio real y (3) la interactividad con los usuarios en aplicaciones reales.

La parte de la construcción del software que llamo esencia es la elaboración mental del constructo conceptual; la parte que yo llamo accidente es su proceso de implementación.

los factores moti> vacionales pueden incrementar la productividad. Por otro lado, los factores ambientales y accidentales, no importando cuán positivos sean, no pueden hacerlo;

dificultades esenciales son inherentes a la complejidad conceptual de las funcionalidades del software y es independiente de cuándo y de qué método se use para su diseño y construcción.

En mi experiencia la mayor parte de las complejidades que encontramos en el trabajo de sistemas son síntomas de mal funcionamiento organizacional.

La complejidad de ayer es el orden de mañana.

Desarrollar software en fragmentos de mayor nivel, construido por alguien más o reusado de nuestro propio pasado, evita encarar capas completas de complejidad.

Después de todo, soy un programador de origen, y el optimismo es una enfermedad profesional de nuestro oficio.

es que la estructura del software no está embebida en tres dimensiones, por lo que no existe un mapeo natural simple que vaya del diseño conceptual a un diagrama, ya sea en dos o más dimensiones.

Boehm señala que la productividad cae de nuevo en tanto se persiga una calidad extrema,

La fuerza motriz para usar los principios de la Ingeniería de Software en la producción de software fue el temor a accidentes mayores que pudieran ser causados por tener artistas incontrolables responsables del desarrollo de sistemas cada vez más complejos.

La forma más espectacular de mejorar la productividad de los programadores de sistemas de gestión de información (SGI) es acudir a su tienda local de computadoras y comprar del anaquel lo que hubiesen construido.

Un punto de vista de la programación orientada a objetos es que es una disciplina que impone modularidad e interfaces limpias.
- Enfatiza el encapsulamiento, el hecho de que no se pueda observar, mucho menos diseñar, la estructura interna de las piezas.
- Enfatiza la herencia, con su estructura jerárquica concomitante de clases, con funciones virtuales.
- Enfatiza la sólida abstracción del tipo de datos, con su garantía de que un tipo de datos particular será manipu> lado solo a través de operaciones propias.
- Y sostiene que una manera de abordar las necesidades del software no satisfechas es incrementar el tamaño de la fuerza laboral inteligente mediante la capacitación y la incorporación de nuestros clientes.

Mis colaboradores de oftalmología no se preocupan acerca de las pilas; sí se preocupan por las descripciones de los polinomios de Legendre de la forma de las córneas. Pequeños encapsulamientos producirán pequeños beneficios.

La mejor manera de atacar la esencia de la construcción de software es no construirlo en absoluto.

Asimismo, la promesa de un fácil reuso de clases, con una fácil personalización a través de la herencia, es uno de los atractivos más fuertes de las técnicas orientadas a objetos.

Reusar es algo mucho más fácil de decir que de hacer. Hacerlo requiere por un lado un buen diseño y por otro una buena documentación.

Para mejorar la calidad y la productividad, queremos construir programas componiendo fragmentos de funciones depuradas que están substancialmente más elevadas que las declaraciones en los lenguajes de programación. Por lo tanto, ya sea que hagamos esto a través de bibliotecas de clases o bibliotecas de procedimientos, debemos encarar el hecho de que estamos aumentando radicalmente el tamaño de nuestro vocabulario de programación.

• Las Propuestas de El Mítico Hombre> Mes: ¿Verdaderas o Falsas?

La buena cocina toma tiempo; algunas tareas no pueden apresurarse sin estropear el resultado.

El hombre> mes es un mito falaz y peligroso, porque implica que los hombres y los meses son intercambiables.

Dividir una tarea entre varias personas ocasiona un trabajo extra de comunicación, esto es, entrenamiento e intercomunicación.

La ley de Brooks: Añadir mano de obra a un proyecto de software retrasado lo retrasa aún más.

Añadir gente a un proyecto de software aumenta el esfuerzo total que se necesita de tres formas: por el trabajo y la interrupción del propio reparto, por el entrenamiento del nuevo personal y la intercomunicación añadida.

Un equipo de dos, con un líder, es a menudo el mejor uso que se le puede dar a las mentes. [Observe el plan de dios para el matrimonio.]

"La integridad conceptual es la consideración más importante en el diseño de sistemas."

La disciplina es buena para el arte.

Se necesita, por un lado una definición formal del diseño, por su precisión, y por otro una definición en prosa por su coherencia.

Una implementación, incluyendo una simulación, puede servir como una definición arquitectónica; este uso tiene tremendas desventajas.

“El mejor amigo del gestor de proyecto es su adversario diario, la organización de un probador del producto independiente.”

El proyecto de la Torre de Babel fracasó por la falta de comunicación y su consecuencia, la organización.

Parnas sostiene firmemente de que el objetivo de que todos vean todo es totalmente erróneo; las piezas deberían ser encapsuladas tal que nadie necesite o se le permita ver el interior de cualquier pieza que no sea la suya, solo deberían ver las interfaces.

El propósito de la organización es reducir la cantidad de comunicación y coordinación necesaria.

La organización tradicional tipo árbol refleja el principio de estructura de autoridad de que nadie puede servir a dos amos.

No se puede estimar exactamente el esfuerzo total o el calendario de un proyecto de programación simplemente estimando el tiempo de codificación y multiplicando las demás partes de la tarea por factores.

La productividad de la programación se puede incrementar casi cinco veces cuando se utiliza un lenguaje de alto nivel adecuado.

El tamaño del programa no es malo; el tamaño innecesario sí lo es.

Fomentar una actitud de sistema total y orientado al usuario bien puede ser la función más importante del gestor de programación.

Los programas ligeros, sobrios y rápidos son casi siempre el resultado de avances estratégicos, en lugar de tácticas inteligentes.

La representación es la esencia de la programación.

Entre un montón de papeles, un pequeño número de documentos llega a ser el apoyo crítico alrededor del cual gira toda gestión de proyecto. Son las principales herramientas personales del gestor.”

La principal tarea diaria del gestor de proyecto es la comunicación, no la toma de decisiones; los documentos comunican los planes y las decisiones a todo el equipo.

Para la mayoría de los proyectos, el primer sistema construido es apenas utilizable: es muy lento, o muy grande, o muy difícil de usar, o los tres juntos.

planifique desechar; lo hará de cualquier modo.

Algunos cambios legítimos en los objetivos (y en las estrategias de desarrollo) son inevitables, y es mejor estar preparados para ellos que suponer que nunca llegarán.

Utilizar un lenguaje de alto nivel, operaciones en tiempo de compilación, incorporación de declaraciones por referencia y técnicas de auto> documentación para la reducción de errores inducidos por los cambios.

El mantenimiento del programa es esencialmente diferente al mantenimiento del hardware; principalmente consta de cambios que corrigen defectos de diseño, de adición de funcionalidades incrementales, o de adaptaciones a cambios en el ambiente de uso o la configuración.

Corregir un defecto tiene una probabilidad considerable (20 a 50 por ciento) de introducir otro.

Después de cada reparación, se debe ejecutar el banco entero de casos de pruebas previamente ejecutado en contra de un sistema para asegurar que no ha sido dañado de alguna forma desconocida.

Todas la reparaciones tienden a destruir la estructura, a incrementar la entropía y el desorden de un sistema.

Depurar el sistema es como la astronomía, siempre se ha hecho principalmente de noche.

La herramienta que ahorra la mayor cantidad de trabajo en un proyecto de programación es probablemente un sistema de edición de texto.

El lenguaje de alto nivel mejora no solo la productividad sino también la depuración; menos errores y más fáciles de encontrar.

La depuración es la parte difícil y lenta de la programación de sistemas, y el lento tiempo de respuesta es la ruina de la depuración.

Vyssotsky afirma: “Demasiadas fallas se refieren exactamente a esos aspectos que nunca fueron totalmente especificados.”

La programación estructurada, el diseño de programas, cuyas estructuras de control constan solo de un conjunto específico que gobierna bloques de código (en contra de una variedad de bifurcaciones), es una manera sólida de evitar errores y es la manera correcta de pensar.

Se debería empezar a depurar el sistema solo después de que las piezas parecen funcionar (en contra de atornillarlo todo y probar para que emerjan los errores de la interfaz; y en contra de empezar a depurar el sistema cuando se conocen totalmente los errores de los componentes pero no están corregidos.) [Esto es particularmente cierto para los equipos.]

“¿Cómo es que un proyecto se retrasa un año? … Un día a la vez.”

El retraso diario es más difícil de reconocer, más difícil de evitar y más difícil de recuperar que las calamidades.

El primer paso para controlar un proyecto grande en un calendario ajustado es tener un calendario, construido de hitos y fechas.

Los hitos deben ser eventos concretos, específicos, medibles, definidos con el filo de una navaja.

Si el hito es muy estricto tal que nadie pueda engañarse, rara vez el programador mentirá acerca del avance del hito.

“Si usted no cumple con una fecha, asegúrese de cumplir la siguiente.”

Uno debe tener técnicas de revisión mediante los cuales el personal conozca el estado verdadero. Para este propósito la clave es un calendario de hitos y un documento de finalización.

Para el producto de programación, la otra cara hacia el usuario, la documentación, es absolutamente tan importante como la cara hacia la máquina.

Incluso para los programas más privados, la documentación en prosa es necesaria, porque al usuario> autor le fallará la memoria.

Se debería entregar el programa con unos cuantos casos de prueba, unos para datos de entrada válidos, otros para datos de entrada en el margen de la validez y otras claramente para datos de entrada inválidos.

Pocos programas necesitan un diagrama de flujo de más de una página, si acaso.

Para preservar el mantenimiento de la documentación, es crucial que sea incorporada en el programa fuente, en lugar de preservarla como un documento separado.

Los sistemas de software son tal vez las cosas más intrincadas y complejas (en términos del número de distintos tipos de partes) que la humanidad construye.

pozo de brea de la ingeniería del software continuará siendo pegajoso por mucho tiempo.

• El Mítico Hombre> Mes: 20 Años después

La disciplina del desarrollo del software no ha avanzado de forma normal o apropiada.

La anomalía no es que el software haya tenido un progreso tan lento, sino más bien que la tecnología de las computadoras haya explotado de una manera sin par en la historia de la humanidad.

Hombre-Mes solo trata incidentalmente acerca del software más bien trata principalmente acerca de cómo construimos cosas en equipos.

La integridad conceptual del producto, como la percibe el usuario, es el factor más importante de la facilidad de uso.

Los productos de software son a la vez complejos y ferozmente competitivos respecto al calendario.

¿Cómo se organiza la labor de diseño para conseguir dicha integridad conceptual?

Una de sus tesis es que la gestión de proyectos de programación grandes es cualitativamente diferente a la gestión de pequeños proyectos, debido solo al número de mentes involucradas.

La acción más importante es el encargo a una sola mente como el arquitecto del producto, que es responsable por la integridad conceptual de todos los aspectos perceptibles del producto por el usuario.

El arquitecto da forma y posee el modelo mental público del producto que será utilizado para explicarle al usuario cómo usarlo.

es necesario separar la arquitectura, la definición del producto como el usuario lo percibe, de su implementación.

La integridad conceptual es central a la calidad del producto.

Tener un arquitecto del sistema es el paso más importante hacia la integridad conceptual.

Definir distintos papeles en equipos tan pequeños puede ser un poco radical, pero he observado que funciona bien y contribuye a un diseño exitoso incluso en equipos pequeños.

Paradójicamente, es mucho más difícil diseñar una herramienta de propósito general que diseñar una herramienta de propósito especial, precisamente porque se tiene que asignar pesos a las diferentes necesidades de los diversos usuarios.

La pérdida de la facilidad de uso se acerca con sigilo maliciosamente, a medida que se van añadiendo características en pequeñas dosis, y los manuales se ponen más y más gordos.

Es importante que un equipo de diseño arribe a una sola imagen compartida por todos.

Resumiendo: anotar explícitamente las conjeturas de los atributos del conjunto de usuarios. Es mucho mejor ser una persona explícita aunque equivo> cada que ser vago.

Una de las cuestiones más difíciles que encaran los arquitectos de software es precisamente cómo equilibrar el poder del usuario frente a la facilidad de uso.

Uniformidad fomentando en otros a incorporar directamente nuestro propio código en sus productos, en lugar de intentar hacer que construyan su propio software según nuestras especificaciones.

La principal falacia del modelo en cascada es que supone un proyecto que pasa por el proceso una sola vez, que la arquitectura es excelente y fácil de usar, el diseño de la implementación es sólido, y la realización es corregible a medida que las pruebas avanzan.

La segunda falacia del modelo en cascada es que supone que se construye el sistema completo de una sola vez, se combinan las piezas para una prueba del sistema de punta a punta después de haber hecho todo el diseño de la implementación, la mayor parte del código y gran parte de las pruebas de componentes.

Exhorta al diseñador a anticipar por un lado las extensiones laterales y por otro las versiones sucesivas de un producto, y definir su funcionalidad o diferencias de plataforma así como construir un árbol genealógico de productos relacionados

Harel define útilmente un prototipo como [Una versión de un programa que] refleja solo las decisiones de diseño tomadas en el proceso de preparación del modelo conceptual, y no las decisiones moti> vadas por cuestiones de implementación.

Es posible construir un prototipo que no es en absoluto parte de un producto en desarrollo para su distribución.

El producto del primer hito puede no tener la funcionalidad suficiente que sea de interés para nadie; el producto distribuible está definido como tal por su completitud en suministrar un conjunto útil de funcionalidades, y por su calidad, la creencia de que funciona de forma robusta.

La definicion de Parnas del ocultamiento de información de módulos es el primer paso publicado en ese programa de investigación crucialmente importante, y es el antepasado intelectual de la programación orientada a objetos.

El segundo paso fue una contribución de varios pensadores: la actualización del módulo de Parnas en un tipo de datos abstracto, a partir del cual se podrían derivar muchos objetos.

El tercer paso de la programación orientada a objetos, introduce el poderoso concepto de herencia, por el cual las clases (tipos de datos) toman por omisión atributos específicos de sus antepasados en la jerarquía de clases.

"Añadir más gente a un proyecto retrasado siempre lo hace más costoso, pero no siempre hace que se complete más tarde [las cursivas son de ellos]."

La gente añadida tardíamente a un proyecto de desarrollo deben ser miembros de un equipo dispuestos a colaborar y trabajar dentro del proceso ¡y no intentar alterar o mejorar el proceso mismo!

La calidad de la gente que participa en un proyecto, así como su organización y gestión, son factores mucho más importantes para el éxito que las herramientas que usan o los enfoques técnicos que adoptan.

El modelo COCOMO de Boehm establece que la calidad del equipo, es con mucho, el factor más importante para su éxito, de hecho cuatro veces más fuerte que el siguiente factor más importante.

"Los principales problemas de nuestro trabajo no son tanto de naturaleza tecnológica como sociológica."

"La función del gestor no es hacer que la gente trabaje, sino hacer posible que la gente trabaje."

A pesar de tener una buena documentación, algunos diseños bien avanzados y algunas personas del equipo emisor. Creo que es la ruptura de la fusión del antiguo equipo lo que aborta el producto embrionario y provoca su reinicio.

Una pregunta central que encara la gestión de software es cómo diseñar estructuras y procesos para mejorar, en lugar de inhibir, la creatividad e iniciativa.

Toda acción de la sociedad debe, por su naturaleza, prestar auxilio a los miembros del cuerpo social, más nunca absorberlos y destruirlos

El impulso clave [de los últimos años] fue delegar el poder. ¡Fue como magia! Mejoró la calidad, la productividad y la moral. Tenemos equipos pequeños sin control central. Los equipos son dueños del proceso, pero tienen que tener uno. Tienen muchos procesos diferentes. Son dueños del calendario, pero tienen la presión del mercado. Esta presión hace que busquen herramientas por su cuenta.

El centro gana en autoridad real al delegar poder, y la organización en su conjunto es más feliz y más próspera.

Ahora disfrutamos para cada medio los mismos beneficios que el tiempo compartido trajo a la creación de software – la capacidad de revisar y evaluar instantáneamente el efecto sin perder el tren de pensamiento.

La creatividad también se ve reforzada por las nuevas y flexibles herramientas auxiliares.

La metaprogramación, la construcción de una nueva capa que personaliza la funcionalidad para un subconjunto de usuarios de un paquete.

Después de todo, la ingeniería de software, como la ingeniería química, está involucrada con problemas no lineales de la ampliación a procesos a escala industrial, y al igual que la ingeniería industrial, está permanentemente con> fundida por las complejidades del comportamiento humano.