Cómo evitar crisis de software
La crisis del software impulsó un estudio más profundo del software y sus características y cambió las opiniones anteriores sobre el software. Los programas que se consideran buenos desde el principio suelen ser difíciles de entender para los demás y están llenos de trucos de programación. Hoy en día se cree generalmente que, además de tener funciones correctas y buen rendimiento, un buen programa también debe ser fácil de leer, fácil de usar, fácil de modificar y ampliar.
Los lenguajes de programación han abierto amplias perspectivas para las aplicaciones informáticas, pero el fantasma que persiste en el mundo del software: la "crisis del software" todavía existe. Porque el desarrollo de software no solo está restringido por los métodos y estructuras de diseño del programa, sino también por el ciclo de desarrollo y los costos de desarrollo del software. Más importante aún, la garantía de la calidad del software tiene una gran relación con la corrección del diseño del programa. Si no se puede garantizar la fiabilidad del software desarrollado, se producirán consecuencias graves inimaginables durante el funcionamiento.
Desde mediados de la década de 1960, la tecnología del hardware informático ha progresado día a día, la capacidad de almacenamiento informático, la velocidad y la confiabilidad informáticas han mejorado enormemente y el costo de producción del hardware se ha reducido continuamente. La caída de los precios de las computadoras ha creado buenas condiciones para su aplicación generalizada. En esta situación, la urgente necesidad de software informático también puede adaptarse a ella. Como resultado, han aumentado los requisitos de desarrollo para algunos sistemas de software grandes. Sin embargo, el avance de la tecnología del software ya no puede satisfacer las necesidades del desarrollo de la situación. En el proceso de desarrollo de software a gran escala, han surgido tres problemas principales: alta complejidad, largo ciclo de desarrollo y dificultad para garantizar la corrección. Incapaz de encontrar soluciones a los problemas, lo que resulta en una montaña de problemas y una situación fuera del control de las personas, lo que resulta en la llamada "crisis del software".
El ejemplo más destacado es la serie IBM360 de sistemas operativos para máquinas desarrollados por IBM en Estados Unidos entre 1963 y 1966. Este sistema de software requiere el trabajo de unas 5.000 personas al año. Como máximo, 1.000 personas participaron en el trabajo de desarrollo y escribieron casi 1 millón de líneas de programas fuente. Aunque se invirtieron muchos recursos humanos y materiales, los resultados obtenidos fueron extremadamente pobres. Según las estadísticas, cada nueva versión del sistema operativo es el resultado de corregir 1.000 errores encontrados en la versión anterior. Puedes imaginar lo pobre que es la calidad de este software.
No es de extrañar que F.D. Hierrocks, el responsable del proyecto, dijera emocionado al resumir el proyecto: "Dijo: "... Como una bestia que huye, cayendo al cieno, luchando hasta morir. , cuanto más luchas, más profundo te hundes y, al final, no podrás escapar del desastre de la destrucción. ... El trabajo de programación es como este atolladero..., un grupo de programadores se ven obligados a luchar desesperadamente en el atolladero,..., ¡nadie esperaba que el problema cayera en tal situación! ........."Las lecciones históricas del sistema operativo IBM 360 se han convertido en un caso clásico registrado en los anales de los proyectos de desarrollo de software.
Si el software desarrollado contiene errores, no se puede garantizar la confiabilidad. entonces es probable que cause consecuencias muy graves a todo el sistema durante la operación, lo que puede afectar el funcionamiento normal del sistema, o provocar la parálisis de todo el sistema, o incluso causar accidentes malignos irreparables, como depósitos bancarios. aniquilado, e incluso tuvo un déficit; todos los productos de la fábrica fueron desguazados, lo que provocó la quiebra de la fábrica.
En 1963, uno de los programas informáticos utilizados por Estados Unidos para controlar la sonda a Marte había desaparecido. el número "-" escrito incorrectamente provocó la explosión de la sonda a Marte, provocando pérdidas de cientos de millones de dólares.
Para superar esta crisis, por un lado, se deben realizar una serie de estudios. realizado sobre métodos de programación, corrección de programas y confiabilidad del software. Por otro lado, también necesitamos estudiar los métodos de preparación, prueba, mantenimiento y gestión del software, lo que da como resultado la metodología de programación;
En 1968, E.W. Dykstra propuso por primera vez el argumento de que "las declaraciones GOTO son dañinas", lo que desafió los métodos de programación tradicionales, despertando así una atención generalizada en la discusión sobre los métodos de programación. Muchos científicos informáticos destacados participaron en esta discusión. La metodología de programación se fue produciendo y formando gradualmente en esta discusión extensa y profunda.
¿Qué es la metodología de programación? En resumen, la metodología de programación es una disciplina que explora la naturaleza de los programas, las teorías y los métodos de programación. Contiene contenido rico, como programación estructural, prueba de corrección de programas, transformación de programas, descripción formal y derivación de programas, síntesis de programas, diseño automático de programas, etc. En la metodología de programación, la programación estructurada ocupa una posición muy importante. Se puede decir que la metodología de programación se desarrolla y mejora gradualmente sobre la base de la programación estructurada.
¿Qué es la programación estructurada? En 1974, D.Grice clasificó las diferentes explicaciones de la programación estructurada en 13 tipos, entre las que las más representativas son las siguientes:
La programación estructurada es un método que evita el uso de sentencias GOTO;
p>
La programación estructurada es una programación de arriba hacia abajo;
La programación estructurada es una programación de arriba hacia abajo;
La programación estructurada es una programación de arriba hacia abajo;
La programación estructurada es una programación de arriba hacia abajo;
La programación estructurada es un tipo de programación de arriba hacia abajo;
La programación estructurada es un tipo de programación de arriba hacia abajo;
p>La programación estructurada es un tipo de programación automática de arriba hacia abajo;
La programación estructurada es una programación de arriba hacia abajo.
La programación estructurada es un método para organizar y programar programas de una manera que sea fácil de entender y modificar.
Una de las funciones principales de la estructuración de programas es garantizar la corrección del programa; La prueba es fácil de implementar;
La programación estructurada verifica la exactitud de cada paso en el proceso de diseño, formando así automáticamente un estilo de programación que se explica por sí mismo, se explica por sí mismo y se justifica por sí mismo;
En resumen, la programación estructurada analiza cómo convertir diagramas de flujo complejos a gran escala en una forma estándar que pueda representarse mediante repetición y anidamiento utilizando varias estructuras de control estándar (generalmente secuencia, bifurcación y repetición).
Las definiciones o explicaciones anteriores reflejan los principales temas discutidos en la programación estructurada desde diferentes ángulos. En esencia, la programación estructurada es un principio y método de programación según el cual se puede diseñar un programa que esté bien estructurado, sea fácil de entender, fácil de modificar y fácil de verificar.
Un lenguaje de programación diseñado según los requisitos de la programación estructurada se denomina lenguaje de programación estructurado. Los programas escritos utilizando lenguajes de programación estructurados o según las ideas y principios de la programación estructurada se denominan programas estructurados.
A finales de los años 1960 y principios de los años 1970, se intensificó el debate sobre el uso de la declaración GOTO. Quienes abogan por eliminar las declaraciones GOTO de los lenguajes de programación de alto nivel creen que las declaraciones GOTO son una de las declaraciones más desfavorables para la estructura del programa. Su razón principal es que las declaraciones GOTO hacen que la estructura estática del programa sea inconsistente con la estructura dinámica, lo que hace que la estructura estática del programa sea inconsistente con la estructura dinámica. el programa es difícil de entender. También es difícil comprobar si hay errores. Después de eliminar la declaración GOTO, el proceso de ejecución del programa se puede reflejar directamente desde la estructura del programa. Esto no sólo hace que la estructura del programa sea clara, fácil de entender y de verificación de errores, sino que también ayuda a demostrar la corrección del programa.
La opinión opuesta es que la declaración GOTO es más flexible y puede mejorar la eficiencia del programa en algunos casos. Eliminar por completo la declaración GOTO complicaría demasiado el programa en algunos casos y agregaría cálculos innecesarios.
En 1974, D.E. Knuth hizo una revisión exhaustiva y justa del debate sobre las declaraciones GOTO. Su punto básico es que el uso de declaraciones GOTO sin restricciones, especialmente el uso de declaraciones GOTO de salto hacia atrás, facilitará la tarea. La estructura del programa es difícil de entender. En este caso, se debe evitar la declaración GOTO tanto como sea posible. Pero en otros casos, para mejorar la eficiencia del programa sin destruir la buena estructura del programa, es necesario utilizar algunas declaraciones GOTO con moderación. En sus palabras: "En algunos casos, abogo por la eliminación de la declaración GOTO; en otros casos, abogo por la introducción de la declaración GOTO. Desde entonces, este debate de 10 años ha quedado resuelto".
Más tarde, G. Garcopini y C. Bohm demostraron teóricamente que cualquier programa puede representarse mediante estructuras secuenciales, ramificadas y repetitivas. Esta conclusión muestra que eliminar declaraciones GOTO en lenguajes de programación de alto nivel no afecta las capacidades de programación de los lenguajes de programación de alto nivel y los programas escritos tienen una estructura más clara.
La idea de programación estructurada se refleja en el uso de algunos métodos más efectivos, entre los cuales el método más representativo es el "método paso a paso". El método llamado "paso a paso" significa que al escribir un programa, primero considere la estructura general del programa e ignore temporalmente algunos detalles, y luego proceda paso a paso capa por capa hasta que el lenguaje seleccionado pueda describir completamente cada detalle, es decir, se obtiene el programa requerido. En otras palabras, se trata de organizar las actividades de pensamiento de las personas de acuerdo con el proceso de primero global antes de local, primero completo antes de detalles, primero abstracto y luego concreto, para que la estructura del programa sea clara, fácil de entender, fácil de verificar y fácil de modificar. El "método paso a paso" está relacionado y es diferente del método de diseño modular. En términos generales, el refinamiento paso a paso se refiere principalmente al proceso de diseño de un programa, mientras que el diseño modular se refiere principalmente al proceso de diseño de un programa más grande. sistema.
Además, ante la "crisis del software", la gente investigó la situación real de la producción de software y gradualmente sintió la necesidad de utilizar métodos de ingeniería para dedicarse a la investigación y el mantenimiento de sistemas de software. Por lo tanto, surgieron metodologías de ingeniería de software estrechamente relacionadas con el diseño de programas. Surgieron en 1968. El objetivo principal de la ingeniería de software es el software a gran escala. Los contenidos de la investigación en ingeniería de software incluyen principalmente: garantía de calidad y evaluación de calidad del software. y métodos de mantenimiento, herramientas, documentos; diseño de interfaz de usuario e ingeniería de software. El objetivo final es deshacerse de la producción manual de software y realizar gradualmente la automatización del desarrollo y mantenimiento del software. la crisis del software:
1. Las estimaciones de los costos y cronogramas de desarrollo de software suelen ser muy pequeñas.
Es probable que el costo real sea un orden de magnitud mayor que el estimado. costo, y no es raro que el cronograma real tenga meses o incluso años de retraso con respecto al cronograma esperado, lo que reduce la credibilidad de la organización de desarrollo. Las medidas oportunas tomadas para cumplir con los plazos y ahorrar costos a menudo afectan la calidad de los productos de software, lo que inevitablemente. conduce a la insatisfacción del usuario.
2. Los usuarios no están satisfechos con el sistema de software "completado". Esto no es raro.
Los desarrolladores de software a menudo tienen una comprensión vaga de las necesidades del usuario. E incluso empezar a escribir programas apresuradamente sin siquiera tener una comprensión clara del problema a resolver. La comunicación entre los usuarios suele ser insuficiente y "trabajar a puerta cerrada" conducirá inevitablemente a que el producto final no pueda satisfacer las necesidades reales. de los usuarios.
3. La calidad de los productos de software a menudo no es confiable.
La confiabilidad y la calidad del software a menudo no son confiables. El concepto cuantitativo preciso de garantía de calidad acaba de surgir. Las técnicas de aseguramiento (revisión, revisión y pruebas) no se han aplicado de manera consistente a todo el proceso de desarrollo de software, lo que conducirá a la aparición de problemas de calidad del producto de software.
4. El software a menudo no se puede mantener. p>
Los errores en los programas son difíciles de corregir y es casi imposible adaptar estos programas a nuevos entornos de hardware o agregar nuevas funciones a los programas originales según las necesidades del usuario.
5. no tiene la documentación adecuada.
El software no es sólo un programa, también debe tener un conjunto de documentación que se genera durante el proceso de desarrollo del software y debe estar "actualizado" (exactamente el mismo). como el código).
La falta de documentación traerá inevitablemente muchas dificultades y problemas graves al desarrollo y mantenimiento del software.
6. La proporción del coste del software con respecto al coste total de los sistemas informáticos aumenta año tras año.
Con el avance de la tecnología microelectrónica y el aumento de la automatización de la producción, los costos de hardware están disminuyendo año tras año. Sin embargo, el desarrollo de software requiere mucha mano de obra y los costos de software aumentan año tras año con la inflación y la inflación. expansión continua de la escala y el aumento de la cantidad de software. Una encuesta realizada en 1995 en los Estados Unidos mostró que los costos del software representaban aproximadamente el 90% del costo total de los sistemas informáticos.
La aparición de la crisis del software ha permitido a las personas encontrar las razones internas de la crisis. Se descubre que las razones se pueden resumir en dos aspectos: por un lado, es causada por la complejidad del software. la producción en sí; por otro lado, es causada por la complejidad de la producción de software en sí. Los métodos y tecnologías utilizados en el desarrollo están relacionados.
La ingeniería de software es un concepto propuesto para superar la crisis del software, y sus principios, técnicas y métodos se exploran constantemente en la práctica. En este proceso, la gente estudió y tomó prestados algunos principios y métodos de la ingeniería y formó una nueva disciplina: la ingeniería de software. Sin embargo, desafortunadamente, la crisis del software aún no se ha superado por completo.