No hay bala de plata
Esencia y Accidentes de Ingeniería de Software es un documento ampliamente debatido en la ingeniería del software escrito por Fred Brooks en 1986. Brooks afirma que "no hay desarrollo individual, ya sea técnico o de gestión de tecnología, que por sí mismo exprese promesas, incluso un orden de magnitud, diez veces, de mejora dentro de una década en la productividad, la fiabilidad, en la simplicidad. " También afirma que "no podemos esperar que lleguemos a ver ganancias dos veces cada dos años" en el desarrollo de software, como hay en el desarrollo de hardware.
Se afirma que la mayoría de lo que los ingenieros de software ya no se dedica a lo esencial, por lo que todas las actividades de reducción de accidentes a cero no le dará un orden de magnitud de la mejora. Brooks hace frente a los defensores de las partes esenciales del proceso del software. Mientras se insiste en que no hay una bala de plata ,se cree que una serie de innovaciones atacar complejidad esencial podría dar lugar a (quizás más de diez veces en un período de diez años), mejoras significativas.
La parte mas compleja de construir un software es la especificacion,diseño y prueba del modelo conceptual, más que la labor de representar el modelo y mostrar la representacion
Entonces consideró cuatro propiedades inherentes a la escencia del software
Complejidad. Los problemas clásicos de desarrollar software derivan de esta escencia
Conformidad. En cualquier caso deberá ser el software el que se deba adaptar al entorno y nunca al revés. A veces le toca por haber sido el último en llegar (los procesos existen primero, luego viene su automatización). Conformidad también porque debe cumplir con ciertas interfaces (de usuario, de otras aplicaciones)
Mutabilidad. El software siempre va a estar sujeto a cambios, mucho más que los objetos del mundo real. En gran medida por tratarse de piezas intangibles, fáciles de destruir y reconstruir nuevamente (al menos más fácil que probar hacerlo con casas,autos y otros tipos de construcciones). Pero más aún por la presión del usuario, que en cuanto se sienta cómodo con un software que le sea útil, no va a demorar mucho en imaginar (y pedir) nuevas formas en que ese software lo pueda ayudar
Invisibilidad. El software es invisible e individualizable en el espacio. Poder representar al software como una abstracción geométrica sería fabuloso. Pero en los hechos no es uno sino varios los diagramas que deben ser usados para representar, flujos de control, de datos, secuencias temporales, etc. Estos grafos no son planares ni jerarquicos entre sí. El software se intuye pero no se ve.
Tambien consideramos otras dificultadas accidentales ,dada la forma actual de construir software pero que no son ilogicas.
Lenguajes de alto nivel. Estas abstracciones conceptuales (operaciones, tipos de datos, secuencias, comunicaciones) tratan de aproximarse a la forma intelectual en que el usuario resuelve problemas. Con eso esconden la complejidad accidental del programa compilado, consistente en bits, registros, condiciones, bifurcaciones, canales, discos, interrupciones, etc
Tiempo compartido. La posibilidad de compartir el tiempo de ejecución entre los procesos combate el accidente de los programas batch que se ejecutan en forma lenta y mejora la sensación de tiempo de respuesta general
Entornos de programación unificados. entornos de programación como el de Unix, que con bibliotecas integradas, formatos de archivos unificados, tuberías y filtros combaten el accidente de tener aplicaciones que resuelven en forma individual las problemáticas comunes (reinventando superflua y peligrosamente la rueda). Es interesante ver la evolución que han tenido en estos últimos años plataformas como .NET o JEE, ambas fundadas en API’s de bajo nivel que, combinadas, otorgan una potencia sin precedentes. Brooks ya lo había insinuado antes
Ahora se comienza a intentar forjar la bala de plata, en una forma esperanzadora confiando en que con el tiempo se logrará aproximarla
Programación Orientada a Objetos. Si bien manifiesta tener más esperanzas en este paradigma que en ninguna otra cosa de hoy en día , admite que con la abstracción y la jerarquización sólo ataca el accidente de tener enormes expresiones sintácticas. No obstante la complejidad de los diseños no es accidental si no escencial
Sistemas Expertos. estos sistemas basados en un motor de inferencias y una base de reglas y aserciones, para sugerir interfaces, estrategias detesting, bugs típicos y ayudas de optimización. Aún así, para lograr la base de reglas y aserciones va a hacer falta un experto
Programación "Automática". Técnica de construir generadores de código (el antepasado del concepto de Software Factories).
Programación Visual. En esta tecnología principalmente debido al estado del arte de los monitores de aquellos años.
Verificación de Programas. Consiste en detectar bugs ya desde la etapa de diseño o incluso antes aún, en la cadena hacia la construcción
Entornos y herramientas. Enumerando características deseables tales como editores inteligentes para lenguajes específicos que permitan reducir errores sintácticos, así como otras características
Comprar versus construir. Con un ojo biónico, se enuncia los ahorros en los costos del proyecto si se adquieren paquetes de software ad hoc en lugar de lidiar con las fases de construcción y mantenimiento en forma casera
Refinamientos en los requerimientos y prototipado rápido. habida cuenta de que el usuario va a sentir mayor seguridad de lo que quiere tener si previamente va probando prototipos en forma iterativa y los va refinando incrementalmente. Diez y quince años más tarde respectivamente, procesos de desarrollo como el Proceso Unificado (Unified Process o UP), Extreme Programming (XP)
FUENTES DE INFORMACION
Se afirma que la mayoría de lo que los ingenieros de software ya no se dedica a lo esencial, por lo que todas las actividades de reducción de accidentes a cero no le dará un orden de magnitud de la mejora. Brooks hace frente a los defensores de las partes esenciales del proceso del software. Mientras se insiste en que no hay una bala de plata ,se cree que una serie de innovaciones atacar complejidad esencial podría dar lugar a (quizás más de diez veces en un período de diez años), mejoras significativas.
La parte mas compleja de construir un software es la especificacion,diseño y prueba del modelo conceptual, más que la labor de representar el modelo y mostrar la representacion
Entonces consideró cuatro propiedades inherentes a la escencia del software
Complejidad. Los problemas clásicos de desarrollar software derivan de esta escencia
Casos típicos: dificultades de comunicación entre los miembros, lo que conlleva a productos fallados, costos desbordados y demoras en calendario. También puede darse por dificultades de enumerar los distintos estados de la aplicación, lo que conlleva a falta de confiabilidad.
Dificultades en invocar funcionalidades, que decantan en aplicaciones difíciles de usar. Dificultades en extender la aplicación sin crear efectos colaterales
Conformidad. En cualquier caso deberá ser el software el que se deba adaptar al entorno y nunca al revés. A veces le toca por haber sido el último en llegar (los procesos existen primero, luego viene su automatización). Conformidad también porque debe cumplir con ciertas interfaces (de usuario, de otras aplicaciones)
Mutabilidad. El software siempre va a estar sujeto a cambios, mucho más que los objetos del mundo real. En gran medida por tratarse de piezas intangibles, fáciles de destruir y reconstruir nuevamente (al menos más fácil que probar hacerlo con casas,autos y otros tipos de construcciones). Pero más aún por la presión del usuario, que en cuanto se sienta cómodo con un software que le sea útil, no va a demorar mucho en imaginar (y pedir) nuevas formas en que ese software lo pueda ayudar
Invisibilidad. El software es invisible e individualizable en el espacio. Poder representar al software como una abstracción geométrica sería fabuloso. Pero en los hechos no es uno sino varios los diagramas que deben ser usados para representar, flujos de control, de datos, secuencias temporales, etc. Estos grafos no son planares ni jerarquicos entre sí. El software se intuye pero no se ve.
Tambien consideramos otras dificultadas accidentales ,dada la forma actual de construir software pero que no son ilogicas.
Lenguajes de alto nivel. Estas abstracciones conceptuales (operaciones, tipos de datos, secuencias, comunicaciones) tratan de aproximarse a la forma intelectual en que el usuario resuelve problemas. Con eso esconden la complejidad accidental del programa compilado, consistente en bits, registros, condiciones, bifurcaciones, canales, discos, interrupciones, etc
Tiempo compartido. La posibilidad de compartir el tiempo de ejecución entre los procesos combate el accidente de los programas batch que se ejecutan en forma lenta y mejora la sensación de tiempo de respuesta general
Entornos de programación unificados. entornos de programación como el de Unix, que con bibliotecas integradas, formatos de archivos unificados, tuberías y filtros combaten el accidente de tener aplicaciones que resuelven en forma individual las problemáticas comunes (reinventando superflua y peligrosamente la rueda). Es interesante ver la evolución que han tenido en estos últimos años plataformas como .NET o JEE, ambas fundadas en API’s de bajo nivel que, combinadas, otorgan una potencia sin precedentes. Brooks ya lo había insinuado antes
Ahora se comienza a intentar forjar la bala de plata, en una forma esperanzadora confiando en que con el tiempo se logrará aproximarla
Programación Orientada a Objetos. Si bien manifiesta tener más esperanzas en este paradigma que en ninguna otra cosa de hoy en día , admite que con la abstracción y la jerarquización sólo ataca el accidente de tener enormes expresiones sintácticas. No obstante la complejidad de los diseños no es accidental si no escencial
Sistemas Expertos. estos sistemas basados en un motor de inferencias y una base de reglas y aserciones, para sugerir interfaces, estrategias detesting, bugs típicos y ayudas de optimización. Aún así, para lograr la base de reglas y aserciones va a hacer falta un experto
Programación "Automática". Técnica de construir generadores de código (el antepasado del concepto de Software Factories).
Programación Visual. En esta tecnología principalmente debido al estado del arte de los monitores de aquellos años.
Verificación de Programas. Consiste en detectar bugs ya desde la etapa de diseño o incluso antes aún, en la cadena hacia la construcción
Entornos y herramientas. Enumerando características deseables tales como editores inteligentes para lenguajes específicos que permitan reducir errores sintácticos, así como otras características
Comprar versus construir. Con un ojo biónico, se enuncia los ahorros en los costos del proyecto si se adquieren paquetes de software ad hoc en lugar de lidiar con las fases de construcción y mantenimiento en forma casera
Refinamientos en los requerimientos y prototipado rápido. habida cuenta de que el usuario va a sentir mayor seguridad de lo que quiere tener si previamente va probando prototipos en forma iterativa y los va refinando incrementalmente. Diez y quince años más tarde respectivamente, procesos de desarrollo como el Proceso Unificado (Unified Process o UP), Extreme Programming (XP)
FUENTES DE INFORMACION
Hola celia, podrías subir de nuevo el link del texto en español?
ResponderEliminarte amo cecilia
ResponderEliminar