¿Qué es una solución milagrosa?

Introducción

(Escribí este artículo hace un año porque no podía entender el progreso y la innovación de la tecnología de software. Durante muchos años, algunas personas en China siempre han estado interesadas en Al afirmar que no existe una solución milagrosa en el mundo, todos piensan que han visto y comprendido la tecnología del software (¿realmente han entendido "El mito del hombre y la luna"?), y les gusta burlarse de los demás. A los ojos de estas personas, "no existe una solución milagrosa" y "la ingeniería de software es inútil". Dado que no existe una solución milagrosa, la ingeniería de software no puede resolver el llamado "problema fundamental". entonces la brecha entre nosotros y el software estadounidense y europeo no es tan grande. Casi puedo seguir viviendo la vida de A Q con tranquilidad. Según mi investigación, el profesor Bu no proporcionó una definición precisa y científica de "bala de plata". ". Hay al menos tres explicaciones diferentes de lo que es una "bala de plata". También es difícil definir qué es una tecnología "única": muchas cosas en el mundo se pueden descomponer. En mi opinión, ciertamente existen balas de plata. Hay 6 mil millones de personas en el mundo, y ¿cuántas personas pueden escalar el Monte Everest? Aferrarse al concepto de "no existe una solución milagrosa" y quedarse quieto es un signo de incompetencia por parte de algunos expertos en software chinos ( por supuesto, están rezagados) - 2006.6.30)

No Silver Bullet, la declaración más famosa en la comunidad mundial de ingeniería de software, proviene del Dr. Frederick Brooks, profesor y ganador del Premio Turing en 1999 en los Estados Unidos. States, un pionero, autoridad y veterano en la comunidad mundial de ingeniería de software. ¿Cómo podría estar equivocado? De hecho, en los últimos dos años, con la introducción, traducción y publicación de la versión china y la versión fotocopia de "El mito del hombre y la luna" en China, así como el consiguiente impulso y clamor, ahora la moda importada producto "no hay una solución milagrosa" casi se ha convertido. Algunas personas en la industria de TI dicen palabras que vuelan por todo el cielo todos los días: "Esto no es una solución milagrosa, eso no es una solución milagrosa", "OOAD no es una solución milagrosa" , UML no es una solución milagrosa, los casos de uso no son una solución milagrosa, RUP no es una solución milagrosa, MDA no es una solución milagrosa y la ingeniería de software no es una solución milagrosa..." La lista sigue y sigue. A los ojos de la gente, la teoría de la bala de plata (NSB) de Bruce es como una panacea o un ungüento multiuso que puede llevar consigo. Sólo puede usarlo si puede encontrar un lugar para aplicarle una dosis.

¿Es realmente así? ¿Qué es exactamente la bala de plata de Brinell? ¿Por qué se dice que la bala de plata de Brinell no tiene importancia práctica? Vea el desglose a continuación.

Motivación

En una charla reciente, le pregunté a un amigo de la industria sobre su opinión sobre la situación actual y el desarrollo futuro de la ingeniería de software nacional. Es un activista en esta área. Esperaba escucharlo expresar sus ambiciones, pero inesperadamente sacudió la cabeza. Le pregunté qué pasaba y dijo que "la ingeniería de software se ha arruinado en China", así que ahora no. No me atrevo a publicitar mis actividades afuera y no me atrevo a tener nada que ver con la ingeniería de software. ¡Lo que dijo superó completamente mis expectativas y realmente me sorprendió! Sí, la teoría de la inutilidad y el vacío en la ingeniería de software tiene una larga historia en China. Pero para aquellos de nosotros que tratamos con software todos los días, la ingeniería de software es como una rutina diaria, un trabajo y un estilo de vida completamente diario. Es realmente difícil imaginar cómo sería el desarrollo de software sin la ingeniería de software.

Después de un período de observación, poco a poco descubrí una realidad tan dura que no esperaba que todavía hubiera tanta gente en China (al menos como se refleja en algunos de los sitios web, medios y medios más profesionales). foros) que están tan confundidos. La gente siempre ha dudado de la importancia y la necesidad de la ingeniería de software, y su comprensión de "qué es exactamente la ingeniería de software" también es arbitraria y variada. He pensado una y otra vez en todas las razones detrás de este fenómeno.

Desafortunadamente, parece que después de leer "El mito del Hombre-Luna" (quizás sin leerlo detenidamente), muchas personas piensan que Brooks tiene una visión pesimista, y luego deducen de su teoría que no existe una solución milagrosa que " La ingeniería de software no es una solución milagrosa". "Bullet", que cree que la ingeniería de software es básicamente un mito inútil, y promueve la ingeniería de software como un grupo de geeks técnicos que buscan una solución milagrosa elusiva e inexistente. En los últimos 30 años, La ingeniería de software no ha logrado ningún logro... ¡Pero creo que están fundamentalmente equivocados y contradicen completamente la intención original de "El mito del hombre y la luna"!

Después de investigar e investigar seriamente, descubrí un hecho que me sorprendió: el NSB de Bretón no está equivocado, y la mayoría de los que seguimos el lema "No existe una solución milagrosa" estamos muy equivocados. ¡Realmente no entendemos al profesor Bu!

La bala de plata de Bruchner no es una panacea

Antes que nada hay que dejar claro que la bala de plata no es sinónimo de panacea, es decir, no podemos. Ponga casualmente "bala de plata" en una oración. La palabra "bala" se usa como una "panacea".

Demostración: Utilice la prueba por contradicción.

Suponiendo que "la solución milagrosa" es igual a "panacea", entonces "OOAD no es la solución milagrosa, UML no es la solución milagrosa, los casos de uso no son la solución milagrosa, RUP no es la solución milagrosa, MDA No es una solución milagrosa, como tampoco lo es la ingeniería de software. "La solución milagrosa" es, por supuesto, correcta, porque no existe ninguna panacea en el mundo.

Pero pensándolo bien, la proposición "No existe ninguna panacea en el mundo" debería ser un axioma y no necesita ser demostrada nuevamente. ¿Podría ser que el profesor Bu escribió dos artículos importantes con nueve años de diferencia? ¿Gastar tanta energía sólo para demostrar que "no existe una panacea en la ingeniería de software"? ¿No es ridículo? Obviamente aquí hay una contradicción, por lo que no se puede establecer la hipótesis anterior, lo que indica que la bala de plata Brinell tiene otro significado.

Supongo que la mayoría de las personas que dicen "no existe una solución mágica" no entienden realmente el significado de la solución mágica, ni comprenden el espíritu de Lao Bu. Es posible que hayan cometido errores: la primera posibilidad es que estén diciendo tonterías y la segunda posibilidad es que sin darse cuenta ignoren y excluyan aquellas tecnologías y métodos verdaderamente valiosos. Para dar un ejemplo del mal uso de NSB (confundiendo soluciones milagrosas y panaceas): "Durante muchos años, la comunidad técnica ha estado buscando persistentemente una 'solución milagrosa' para resolver todos los problemas en el proceso de desarrollo. Estos esfuerzos son sin duda respetables, pero Los resultados son decepcionantes: a pesar de que no existe una solución milagrosa, la ingeniería de software, que comenzó a aparecer a finales de los años 60, alguna vez fue considerada como una panacea para todas las enfermedades. El autor obviamente no entiende qué es una solución milagrosa, por lo que este párrafo se ha convertido en una tontería aburrida, formando una ilusión y una premisa errónea para su argumento posterior de que "hay una crisis en la ingeniería de software".

Entonces, ¿qué es una solución milagrosa?

¿Qué es exactamente una "bala de plata"? Investiguemos un poco sobre la famosa profecía de Bush. En cuanto a la cuestión de si existe una solución milagrosa, si debemos ser serios, probablemente no sea un enfoque científico abandonar el texto original y simplemente gritar "no existe una solución milagrosa". Mi traducción es:

“Ningún avance, ya sea en ingeniería o tecnología de gestión, puede prometer de forma independiente mejoras en la productividad, confiabilidad o simplicidad del software dentro de una década en términos de rendimiento, incluso si se trata de un pedido. de mejora de magnitud”,

Por cierto, calcule la tasa de crecimiento anual promedio requerida por la tecnología milagrosa:

Según la definición, hay (1 + x)^10. = 10, entonces x ≈ 0,26

Se puede ver que la solución milagrosa Brinell en realidad requiere que nuestra productividad en el desarrollo de software mantenga una tasa de crecimiento promedio de aproximadamente el 26 % cada año (o aumente 10 veces en 10 años). . Cuando discutimos si existe una solución milagrosa, por supuesto no podemos abandonar este criterio básico.

El aburrimiento de la Brinell Silver Bullet

De hecho, la búsqueda de la Brinell Silver Bullet no tiene ningún significado práctico para el desarrollo de software real. ¿Por qué? Existen al menos las siguientes tres razones:

1) Para un producto de software o proyecto de ingeniería específico, ¿qué sentido tiene mejorar ciegamente la productividad independientemente de los demás? La mejora unilateral de la productividad (o la confiabilidad, la simplicidad) no es nuestro verdadero propósito. Las empresas sólo pueden perseguir una alta productividad, una alta confiabilidad y una alta simplicidad cuando garantizan la calidad, satisfacen verdaderamente las necesidades de los clientes y obtienen ganancias significativas. Entonces, si una tecnología o herramienta no es una solución milagrosa y no garantiza una mejora 10 veces mayor, eso no significa que debamos despreciarla, rechazarla o abandonarla.

2) ¿Por qué es necesario estipular que sólo se puede utilizar una única tecnología? Para un producto de software o proyecto de ingeniería específico, siempre que todavía existan deficiencias en nuestra organización, siempre que se espere que el efecto de mejora sea mejor que antes, utilizaremos diversas tecnologías de ingeniería y métodos de gestión que puedan garantizar el éxito general y lograr Debemos intentarlo con valentía y decisión y utilizarlo de forma integral y flexible. Además, es muy difícil definir el progreso de una sola tecnología. Tendemos a exigir un crecimiento general integral, y buscar una solución milagrosa única no tiene valor práctico.

3) ¿Por qué se requiere aumentar 10 veces en 10 años? Al evaluar una tecnología, normalmente consideramos si puede ser de ayuda práctica para los proyectos y productos de este año. Los científicos jefes de las principales empresas de software del mundo generalmente consideran tecnologías estratégicas durante un máximo de 3 a 5 años y hablan alrededor de 10 veces al día. El año no tiene importancia práctica en ingeniería. Además, aunque una determinada tecnología de ingeniería y un método de gestión son eficaces, si la mejora que aporta al proyecto no llega al 26%, por ejemplo, es sólo del 20% o el 10%, ¿no es malo y debería abandonarse o ignorarse? ?

Se puede ver que Lao Bu utilizó algunos trucos al llegar a la conclusión del NSB, con la esperanza de que no fracase durante al menos 10 años. Sin embargo, ¿qué impacto y significado tiene NSB en nuestro trabajo real? Al menos no podemos dar por sentado "si algo es una solución milagrosa" como criterio para guiar nuestra práctica, selección y adopción de una determinada tecnología o herramienta.

Entonces, ¿por qué el Sr. Bu propuso NSB? No debería ser infundado. Según mi comprensión y análisis, la razón puede ser la siguiente: en 1986, como profesor académico, no estaba satisfecho con la excesiva propaganda falsa realizada por los desarrolladores de herramientas CASE en ese momento, por lo que utilizó NSB para revelar sus herramientas. limitaciones: no puede resolver los problemas fundamentales de la ingeniería de software y, al mismo tiempo, nos muestra un camino claro ("No existe un camino real, pero sí un camino". [1]), en su opinión, las balas de plata en realidad Se refieren a tecnologías que pueden resolver problemas fundamentales en el futuro. La bala de plata de Brinell fue originalmente solo una broma utilizada para ridiculizar la promoción excesiva de algunos desarrolladores extranjeros de herramientas CASE, pero terminó siendo utilizada por un grupo de entusiastas aburridos en nuestro país para atacar la ingeniería de software sin pensar.

Descubriendo la verdad: existe una solución mágica

Como tecnología clave revolucionaria, las soluciones mágicas existen ampliamente en todos los ámbitos de la vida. Para estar seguro, Lao Bu solo miró hacia adelante 10 años al NSB de ingeniería de software. Pero eso no sucedió en ese momento, lo que no significa que no sucederá en el futuro. ¿Es cierto que la solución milagrosa para la ingeniería de software nunca existirá?

¿Es realmente difícil de alcanzar el 26% de crecimiento anual requerido por la Brinell Silver Bullet? Creo que para muchas organizaciones de TI nacionales, mejorar la eficiencia o la calidad de un proyecto en un 30% no es una tarea difícil, porque todavía hay muchas partes ineficientes o incluso incorrectas en nuestro trabajo. No creo que nuestro nivel de ingeniería de software esté a la par de los países desarrollados avanzados del mundo, ya sea en términos de gestión o tecnología, y no hay espacio para ni siquiera un 30% más de crecimiento.

De hecho, Lao Bu tenía una bala de plata en mente, o esperaba con ansias su aparición. Dedicó mucho espacio a analizar la posibilidad de la existencia de una bala de plata. Específicamente, significa prestar atención al análisis empresarial, al análisis de la demanda y al diseño de software. Cuanto más cerca esté de comprender la esencia del problema y de resolverlo, mejor. Advirtió a la comunidad de TI que distinga entre tecnologías que resuelven problemas fundamentales y problemas secundarios, y que preste más atención y promueva vigorosamente la investigación y el desarrollo de las primeras. Creo que esta es su verdadera intención. Desafortunadamente, por diversas razones, muchas personas en China olvidaron inexplicablemente la segunda mitad de la oración, o fingieron no verla, o incluso utilizaron NSB para negar falsamente la ingeniería de software.

Según su análisis, era poco probable que algunas de las tecnologías, herramientas y métodos de ese momento, como los lenguajes de programación de alto nivel, la tecnología de tiempo compartido y los entornos de programación unificados, fueran soluciones mágicas diez veces mayores. porque solo resolvieron problemas menores, pero algunos son soluciones mágicas posibles, potenciales y en desarrollo. Nos ha dado muchos consejos, como la reutilización del software, el refinamiento de requisitos y la creación rápida de prototipos, desarrollo incremental y diseño excelente, y cree que algunos de ellos. estas tecnologías bastante prometedoras.

Si examinamos detenidamente el camino de desarrollo de la ingeniería de software extranjera en los últimos 20 años, podemos encontrar que ya han aparecido o están a punto de aparecer soluciones mágicas o casi mágicas (¿tiene sentido buscar soluciones 100% mágicas?). e incluso han existido desde hace algún tiempo. Por ejemplo, la reutilización de software es una prueba milagrosa: Motorola logró una mejora de productividad de 10:1 al lograr una reutilización del 85 % en un proyecto de compilador [4]. Un sistema de gestión de mantenimiento y planificación de inventario en General Motors logró una mejora general de la productividad de 14:1[3] debido a la sustitución del antiguo sistema PL/1 por el desarrollo Smalltalk 80. Se puede ver que la tecnología orientada a objetos es de hecho una solución mágica, o al menos la receta central de la solución mágica.

Algunas personas piensan que debido a que el "problema fundamental" de la ingeniería de software mencionado por Lao Bu nunca podrá resolverse fundamentalmente, no puede haber una solución milagrosa. En realidad, esta es una lógica equivocada. "Si se puede resolver" y "la eficiencia de la solución" son dos cosas diferentes. ¿Es el “problema fundamental” que el profesor Bu llama algo similar a un problema NP-completo? Por supuesto que no. El NSB del profesor Bu trata sobre la eficiencia y eficacia de las soluciones. La ingeniería de software es diferente de la investigación científica teórica. Es una práctica empresarial real y una aplicación científica. Los problemas que debe resolver la ingeniería de software generalmente deben tener solución (garantizados por el análisis de viabilidad del proyecto); de lo contrario, no puede llamarse ingeniería. Pensemos en tantos proyectos de software ultradifíciles, en los cientos de millones de teléfonos móviles que circulan por el mundo (China ha sido durante mucho tiempo el mayor mercado de comunicaciones móviles del mundo), en los 777 y 380 volando en el cielo y en el Shenzhou 5 que Enorgulleció a los chinos y sorprendió al mundo (nuestros héroes espaciales tienen balas de plata en sus manos), así como el Espíritu que aterrizó en Marte. No todos estos son logrados por personas que utilizan la ingeniería de software y la ingeniería de sistemas para resolver hábilmente varios problemas extremadamente complejos. "Problemas fundamentales" ¿Logro brillante? Amigos, la práctica es el único criterio para probar la verdad. Dejen de apegarse a los libros y observen bien el mundo que nos rodea con nuestra sabiduría. Es muy difícil demostrar si existe una tecnología n*10 y/o una solución milagrosa de gestión en la ingeniería de software mediante cálculos científicos puros y derivaciones teóricas, incluso el profesor Bu no puede hacer nada al respecto. Al final, todo sólo puede determinarse mediante hechos y las cifras hablan por sí solas.

Para ser honesto, probablemente no estemos calificados para hablar sobre soluciones mágicas con los líderes de la industria mundial del software. En todos los aspectos de la ingeniería de software, que se ha convertido en una enorme disciplina en los últimos 30 años, en el campo del software civil, ¿cuántas cosas originales se nos han ocurrido y cuántas hemos podido lograr que hayan ganado aplausos? de los círculos académicos e industriales del mundo? Hasta ahora, parece que China no tiene su propio maestro en tecnología de objetos. Y ahora parece que, al entrar en el siglo XXI, todavía tenemos que seguir realizando el difícil trabajo esclarecedor de la ingeniería de software a mayor escala. Por lo tanto, ¡no se deje engañar por la teoría engañosa de que no existe una solución milagrosa! Si ignoramos la 3721 y tratamos todas las "nuevas" tecnologías y "nuevos" métodos con los que no estamos familiarizados y que no dominamos como falsas bombas y fracasos, y tiramos al bebé con el agua del baño, ¿no estaríamos asumiendo un gran riesgo? ? La proliferación de NSB en China sólo hará que nos quedemos aún más atrás.

Redefiniendo la bala de plata: una granada

Hemos demostrado lo aburrido de NSB y la existencia real de la bala de plata de Buchner, y simplemente proponer que no existe una bala de plata puede no ser cierto de la intención original del profesor Bu. Por lo tanto, ahora tenemos la razón y la necesidad de revisar la definición de solución milagrosa y presentar nuestra propia teoría de la solución milagrosa:

1) La tecnología clave central de cualquier ingeniería de software es la solución milagrosa. Quien domine la tecnología central del desarrollo de software dominará la solución milagrosa del alto rendimiento.

2) Cualquier progreso, ya sea tecnología de ingeniería o tecnología de gestión, siempre que pueda lograr una mejora del 30% en la productividad, confiabilidad o simplicidad del software, entonces es una solución milagrosa.

3) Cualquier medida importante que asegure el éxito de un proyecto de software es también una solución milagrosa, independientemente de la tasa de mejora que aporte, y mucho menos del 1%.

4) La solución mágica de la ingeniería de software existe ampliamente y es dominada principalmente por algunos líderes de la industria. La solución milagrosa de otra persona no es necesariamente la suya. Al mismo tiempo, obtener una solución milagrosa también requiere mucho esfuerzo y costo.

5) Dado que la ingeniería de software es esencialmente un proceso de lograr constantemente un equilibrio dinámico de varios factores, la solución milagrosa de la ingeniería de software debe ser una granada (submunición), que se basa en la teoría ternaria de mejora de la calidad ( arquitectura), procesos, gestión organizacional) se pueden utilizar para lograr la máxima efectividad.

Para continuar con el punto 3, la ingeniería de software en sí misma es, en cierto sentido, una solución milagrosa.

El llamado NSB es solo una introducción a un libro de fama mundial, una medicina sobria que puede inspirarte a pensar profundamente y observar la realidad con seriedad. Es muy absurdo intentar utilizar NSB para subvertir el software. ingeniería. Por el contrario, debemos centrarnos en completar cada proyecto que tenemos por delante en la realidad de que ya es un lujo tener todos los proyectos completados exitosamente a tiempo y con una calidad del 100%, incluso si puede mejorar la calidad o la eficiencia de un proyecto. ¡El proyecto en un 10%, un 5% también se considera un éxito! Para conseguirlos no queda otro camino, la ingeniería de software es la garantía más importante.

Brooks bajó del altar

"El mito del mes del hombre" es una obra muy rara y valiosa en la historia del software mundial, pero no es una colección formal de artículos académicos, pero solo una colección de Contiene notas diversas del profesor Brooks sobre varios pensamientos profundos y puntos de vista perspicaces sobre el desarrollo temprano y mediano de la ingeniería de software. Por supuesto, es inevitable que también haya algunas contradicciones semánticas y lógicas. problemas.

Nos gustaría decir algo más sobre la planificación de marketing de algunas editoriales de TI, los llamados medios más profesionales y todo tipo de pistoleros y cómplices: ¿Cómo puede haber tantas Biblias y cómplices en ¿El mundo? ¿Un clásico de lectura obligada? Hasta donde yo sé, parece haber sólo dos versiones oficiales publicadas de la Biblia en el mundo desde la Creación: el Nuevo Testamento y el Antiguo Testamento. Por supuesto, a algunos occidentales les gusta usar la palabra Biblia al nombrar libros técnicos, pero ¿deberíamos copiarla y especular juntos sobre la "Biblia"? Según tengo entendido, la Biblia debe tenerse en nuestras manos y leerse con devoción cada semana. ¿Hay santos o Biblias en el mundo del software? Será mejor que no creemos artificialmente nuevos mitos para evitar que se rían de nosotros en el futuro.

¡Han pasado 17 años desde que Lao Bu propuso por primera vez el NSB! Curiosamente, UP (Proceso unificado), Caso de uso (Caso de uso), UML (Lenguaje de modelado unificado), OOAD (Análisis y diseño orientado a objetos), MDA (Arquitectura basada en modelos), CBD (Desarrollo de software basado en componentes), Diseño Patrones, arquitectura, marco, modelo de análisis, reutilización, ingeniería de dominio, ingeniería comercial ... etc., etc., casi todos los grandes esfuerzos y avances importantes realizados en la ingeniería de software en los últimos 17 años tienen como objetivo resolver el "problema fundamental". " planteado por el señor dirección. Pensando en esto, uno no puede evitar sentir admiración y sorpresa ante la visión de su padre. Desafortunadamente, pocas personas en la industria parecen ver esto. Sólo hay una voz llena de impetuosidad, superficialidad e incluso errores sin soluciones milagrosas. El Sr. Bu fue previsor y señaló la dirección de la industria a su manera. Todos han avanzado y avanzan hacia este camino. Ésta es su grandeza, y aquí es donde radica el verdadero significado y valor de NSB.

De hecho, deberíamos escuchar el mantra de Lao Bu y prestar una atención más seria y entusiasta a las tecnologías avanzadas internacionales contemporáneas, como el modelado de negocios, la ingeniería de dominio, el análisis de requisitos de software y el diseño de arquitectura, la reutilización de software y la ingeniería de componentes, y los proyectos de software. gestión, etc. La gestión de la ingeniería de software y los campos de la tecnología son posibles soluciones mágicas que pueden aportar beneficios prácticos a nuestro presente y futuro.

Mi sugerencia

Descubrí que hay al menos dos declaraciones clásicas famosas sobre la ingeniería de software en la historia del software (una es el modelo en cascada del desarrollo de software, la otra es que hay No hay una teoría mágica), sin darse cuenta, ayudó mucho a los estadounidenses, ayudándolos a establecer y mantener su liderazgo mundial a largo plazo en la industria del software. Los expertos en software estadounidenses verdaderamente inteligentes, basándose en sus verdaderos juicios internos, no obedecieron estos llamados juicios clásicos. Por lo tanto, aunque experimentaron varios altibajos, lograron resultados impresionantes que atrajeron la atención mundial.

Por supuesto que no podemos culpar al Sr. Royce y al Sr. Bu. Tienen buenas intenciones y están hablando del asunto. Solo podemos culparnos a nosotros mismos, quienes nos dijeron que no fuéramos buenos en las primarias. ¿Los estudiantes de escuela en serio? ¿No han aprendido a pensar de forma independiente y comprender verdaderamente el espíritu, pero están dispuestos a aceptar todas las experiencias y prescripciones brindadas por famosos expertos extranjeros, maestros famosos e instituciones famosas?

Si a través de una evaluación cuidadosa predices que existen técnicas de desarrollo o métodos de gestión que pueden hacer que tu proyecto o producto sea exitoso en el corto y/o largo plazo, entonces intenta con valentía analizar racionalmente. No te desanimes incluso si fallas ocasionalmente. Estas cosas no son difíciles de hacer, porque definitivamente no eres la primera persona en el mundo en hacer esto, así que no digas sin pensar que esto no existe y que es inútil.

Asegúrate de prestar atención a las balas de plata, de cobre o de hierro que pasan y aprovecha cada oportunidad de mejora, ¡el milagro está a tus pies!

Referencias

[1 ] Brooks F. P. , Jr., "The Myth of the Man and the Moon" (versión fotocopia), China Electric Power Press, primera edición, marzo de 2003.

[2] Brooks F. P., Jr., traducido por Wang Ying, "The Myth of the Man and the Moon", Tsinghua University Press, 1.ª edición, noviembre de 2002.

[3] Graham I., traducido por Yuan Zhaoshan y otros, "Principles and Practice of Object-Oriented Methods", Machinery Industry Press, primera edición en marzo de 2003.

[4] Jacobson I., et al, Reutilización de software: arquitectura, proceso y organización para el éxito empresarial (fotocopia de "Reutilización de software"), sucursal de Beijing de World Book Publishing Company, marzo de 1998, n.º 1 versión.

Posdata

De hecho, este artículo lleva más de un año gestándose. En la primera mitad, demostré la ineficacia de la Bala de Plata de Brinell. En versiones posteriores, aclararé los presagios y propondré formalmente la "Teoría de la Bala de Plata de Zhang". Otros contenidos también incluirán: ¿Qué es un tipo de bala de plata? ¿Bala de plata B? ¿Son irresolubles los problemas fundamentales de la ingeniería de software? Cox, Harel, Brooks, cuál tiene razón y cuál no, así como un análisis párrafo por párrafo del texto original de Lao Bu, etc. Si se completa, se espera que alcance entre 50.000 y 60.000 palabras. Sin embargo, el significado básico de la versión actual ya está disponible y ha logrado buenos resultados. ¡Gracias a los internautas por su entusiasta apoyo y aliento!

La última solución mágica descubierta: una aplicación temprana en General Motors (GM): un sistema de gestión de mantenimiento y planificación de inventario para piezas de mantenimiento y reparación de automóviles. El antiguo sistema constaba de 265.000 líneas de código PL/1, que requería 12,5 años-hombre y 13,6 millones de memoria para ejecutarse. El sistema de reemplazo se desarrolló utilizando Smalltalk 80. El tiempo total invertido fue de menos de 1 año-hombre y. el sistema solo tenía 22.000 líneas. El código y la memoria solo requieren 1,1 millones. El rendimiento de ambos sistemas es aproximadamente el mismo, ¡pero la relación de productividad general entre los dos es de 14:1! p45, escrito por Ian Graham, traducido por Yuan Zhaoshan y otros, "Object-Oriented Methods: Principios y práctica, tercera edición de Pearson en 2001", Mechanical Industry Press, primera edición en marzo de 2003. Según sentencia preliminar, este hecho debió ocurrir entre 1980 y 1995.