Ensayo de la lectura "No Silver Bullets"

Universidad Tecnológica de León Ingeniería en Redes Inteligentes y Ciberseguridad

Asignatura: Tecnologías para Manejo Masivo de Datos

Profesor: Roberto Cardiel Rodríguez

Título del trabajo: Ensayo: Lectura “No silver bullets”.

Alumna: Fátima Abigail Porras Noriega

Matrícula: 18002125

Grupo: IRIC701

León, Guanajuato. Viernes, 20 de noviembre de 2020

No Silver Bullet: Essence and Accidents of Software Engineering

by Frederick P. Brooks, Jr En el artículo de ingería del software, el autor argumenta principalmente que “No hay un simple desarrollo en tecnología o técnica de gestión, que por sí solo prometa incluso una mejora en la productividad, fiabilidad, simplicidad, en un orden de magnitud dentro de una década”, es por ello que el autor hace la analogía de las balas de plata, al comparar la búsqueda de balas de plata para matar un hombre lobo, con la gestión o diseño de un proyecto de software, en donde él explica que no se pueden encontrar balas de plata que puedan eliminar lo duro que es el desarrollar software.

Para poder observar el progreso que se espera en la tecnología del software, él divide las dificultades en dos: 1. Dificultades esenciales, las cuales son inherentes a la naturaleza del software; 2. Dificultades accidentales, las cuales se encuentran de hoy en dia pero que no son inherentes al software. Brooks las divide de esta manera ya que piensa que la parte más dura de construir software es la especificación, el diseño y la prueba del concepto construido y no tanto el trabajo de representarlo y comprobar la fidelidad de la representación, ya que lo difícil en realidad sería poder encontrar el proceso de solución al problema mas no el implementar dicho proceso, dando por hecho que esto es cierto, el software sería siempre algo duro de desarrollar, no habría ninguna bala de plata.

Brooks menciona cuatro propiedades inherentes a la esencia irreductible de los modernos sistemas de software: complejidad, conformidad, variabilidad e invisibilidad.

La complejidad. Él menciona esta propiedad como esencial, no accidental, ya que cree que desarrollar software es mas complejo incluso que cualquier otra construcción humana debió que no hay dos partes iguales. Su complejidad se da también de manera que se necesita estar incrementando la cantidad de elementos diferentes, además, de la complejidad del software surge por ejemplo el desarrollo de productos defectuosos, sobrecostes y retrasos, la dificultad de comprender y usar el programa, la falta de fiabilidad, la dificultad de ver el programa de manera escalable, ya que habría efectos laterales y por último, la creación de agujeros en la seguridad imprevistos. De la complejidad no sólo se derivan problemas técnicos, sino también problemas de gestión.

La conformidad. Esta propiedad se refiere al hecho de adaptación o ajuste a lo más reciente que se tiene, por ejemplo las interfaces, ya que no se puede simplemente rediseñar el software para adaptarlo a los que se desea.

La variabilidad. Se refiere a los constantes cambios que se somete el software y la manera en la que es afectado a diferencia de otras cosas debido a que el software se adapta a su función y la función es la parte que más siente la presión para cambiar. Todo el software que triunfa cambia, ya sea porque se le quiera dar más usos desarrollando nuevas aplicaciones basadas en la ya hecha, o bien, más allá de la vida del hardware para el que haya sido diseñado porque es adaptable a nuevas oportunidades. Brooks menciona: “El software vive dentro de un entorno cultural de aplicaciones, usuarios, leyes y hardware.

Todo este entorno cambia continuamente, y esos cambios inexorablemente fuerzan a que se produzcan cambios en el software”.

La invisibilidad. “El software es invisible e invisualizable”, menciona Brooks en el artículo, ya a que el software no es algo espacial o algo que tenga representaciones geométricas o diagramas y esto debido a que al querer crear un diagrama de la estructura de software, se puede descubrir que no se constituye sólo por uno sino por varios que apuntan a distintas direcciones cada uno. Esto no sólo hace difícil el pensamiento del diseño, sino hace que difícil la comunicación del diseño.

En otra sección del articulo menciona que los avances del pasado solucionaron dificultades accidentales, no esenciales, basándose en los tres pasos del desarrollo de la tecnología del software que según él han sido más fructíferos: 1. Los lenguajes de alto nivel. Se menciona que el uso de los lenguajes de alto nivel ha ayudado a que se tenga una mejora tanto en productividad como en fiabilidad y simplicidad, debido a que libera a un programa de mucha de su dificultad accidental, abarcando todas las construcciones que un programador imagina en un programa abstracto, creando así una herramienta nueva que incrementa en vez de reducir el trabajo intelectual del usuario.

2. El tiempo compartido. Se menciona que el tiempo compartido ha conseguido una mejora en la productividad tanto de los programadores, como en la calidad del producto, debido a que permite la inmediatez evitando así el olvido de pequeños detalles a implementar en el programa al momento de dejar de programar y compilar para ejecutar.

3. Los entornos de desarrollo unificados. Mejoraron la productividad gracias a que atacan las dificultades accidentales que se producen al usar programas individuales de forma conjunta ¿de qué manera? Proporcionando librerías, filtros, ficheros, etc.

La siguiente sección del articulo habla sobre las esperanzas de descubrir la plata (siguiendo con la analogía de las balas), que consiste en todos aquellos desarrollos técnicos que podrían ser potenciales balas de plata.

1. Ada y otros avances de lenguajes de alto nivel. Brooks comenta que Ada abarca características para animar a utilizar diseño moderno y modularidad. Además, también habla de que la gran contribución de Ada ha sido el cambio ocasionado en los programadores adoptando técnicas modernas de diseño de software. Sin embargo, Ada no ha demostrado ser la bala de plata que pueda acabar con lo duro que es el producir software, ya que sólo es un lenguaje más de alto nivel.

2. Programación orientada a objetos. Brooks menciona que en esta técnica es en la cual se tienen mayormente puestas las esperanzas de que sea la bala de plata más que en cualquier otra técnica debido a que POO permite al programador escribir y entender código de una manera más natural para los humanos, basándose en simular o representar eventos o acciones propios del mundo real, pero esto implica conocer bien los conceptos utilizados dentro de un sistema orientado a objetos y además permite el modelado integrado de propiedades estáticas y dinámicas del ámbito. La POO es importante ya que con el paso del tiempo los programadores han sufrido varios problemas que resultan ser muy comunes cuando se desarrolla un software verdaderamente robusto y eficaz. Este hecho de nuevo ha abierto nuevos patrones de diseño, que podría verse como la integración de pensamientos que otros programadores nos han brindado, consolidando soluciones a problemas que pueden aparecer en el entorno del software, así pues, los programadores atrapan las mejores ideas consolidando buenas prácticas de software, aumentando su nivel de eficacia y precisión para resolver problemas.

3. Inteligencia Artificial. Brooks menciona que, a diferencia de la mayoría, él no cree que la AI pueda ser el avance revolucionario para la productividad del software y su calidad, ya que, basándose en la definición que dice que “la inteligencia artificial es el uso de ordenadores para solucionar problemas que sólo podrían solucionarse por un humano”, él considera que lo verdaderamente difícil al escribir software es decidir lo que uno quiere decir, no decirlo, es decir, que un sistema basado en inteligencia

artificial no podría pensar la solución, solo llevarla a cabo. En cambio, él cree en los sistemas expertos, los cuales, son sistemas pueden por ejemplo, sugerir las reglas para la interfaz, aconsejar sobre estrategias de test, recodar las frecuencias de tipos de bugs, y mostrar claves para la optimización.

4. Programación “automática”. Argumenta que en la mayoría de los casos las especificaciones que deben tenerse no son las del problema sino las del método para su solución, la generación de un programa que resuelva u problema a partir de las especificaciones, suena verdaderamente difícil ya que no aplica en todos los ámbitos, es decir, no se puede generalizar al mundo con esta técnica.

5. Programación gráfica. Brooks está convencido de que esta técnica nunca será fructífera debido a que el flujograma es una pobre abstracción de la estructura del software y que además, el software es muy difícil de visualizar (en la propiedad de invisibilidad).

6. Verificación del programa. La verificación de un programa es esencial para comprobar que el mismo cumple con todas sus especificaciones de manera correcta y con esto ayudar a una mejor implementación. Una herramienta muy útil para el manejo adecuado de las especificaciones son los patrones de diseño los cuales ayudan en la delegación de responsabilidades, encapsulamiento, entre otros conceptos importantes. Sin embargo, Brooks no cree que pueda mejorar tanto la productividad como la fiabilidad al probar la corrección de los diseños y además porque la verificación del programa no implica programas a prueba de errores.

7. Entornos y herramientas. Estas herramientas prometen librar al desarrollador de los errores sintácticos y los errores semánticos simples. Brooks considera que la única ganancia que tendría esta técnica sería el uso de sistemas de BD integrados.

8. Estaciones de trabajo. Brooks considera que tener estaciones de trabajo más potentes será bueno pero no en virtud de productividad al desarrollar softwares, sino en virtud de mejora de composición y edición de programas y documentos.

La última sección del articulo habla sobre los ataques prometedores sobre la esencia conceptual, la cual habla sobre los diferentes ataques tecnológicos en el proceso del software que están limitados por la productividad, los cuales son: 1. Comprar vs construir. “La solución más radical para construir software es no hacerlo”. Este ataque radica en que actualmente la gente prefiere comprar software

ya desarrollado a crear uno propio ya que consideran que es más barato (hablando intelectualmente) comprarlo que hacerlo.

2. Refinamiento de equipos y prototipado rápido. “La parte mas dura de hacer software es, precisamente, decidir qué hacer”. Ninguna otra de las partes es tan difícil como establecer los requisitos detallados, es por ellos que una gran promesa es esta, el desarrollo de aproximación y herramientas para el prototipado rápido de sistemas.

3. Grandes diseñadores. “La cuestión central sobre como mejora el arte del software se centra, como siempre, en la gente”. Esta es la técnica a la que se lo podría ver mas futuro debido a que las buenas prácticas de diseño pueden aprenderse, además, los diseños excelentes preceden se diseñadores excelentes, por lo que, aunque es muy bueno invertir en mejorar la tecnología, también debería invertirse en desarrollar nuevas formas de que surjan grandes programadores. Y estos se pueden desarrollar identificando a los mejores tan pronto como sea posible, asignando un mentor responsable del desarrollo de su carrera, ideando y manteniendo un plan de aprendizaje estricto y cuidadosamente seleccionado y finalmente dando oportunidades para que los diseñadores en desarrollo interactúen y se estimulen con otros.