¿Qué es el diseño de software?
Aunque esta explicación pueda parecer extraña, es el resultado de una cuidadosa consideración. Este artículo solo quiere centrarse en la relación entre programación y programación. Durante casi 10 años, he sentido que toda la industria del software no se ha dado cuenta de las diferencias sutiles entre hacer un diseño de software y lo que es un diseño de software real. Con solo ver esto, creo que podemos aprender algo profundo sobre cómo convertirse en mejores ingenieros de software gracias a la creciente popularidad de C++. Este conocimiento es que la programación no se trata de crear software, sino de diseñar software.
Hace unos años, asistí a un seminario en el que se discutía si el desarrollo de software era una disciplina de ingeniería. Si bien no recuerdo el resultado de la discusión, recuerdo cómo me hizo darme cuenta de que la industria del software hacía algunas comparaciones falsas con la ingeniería de hardware, mientras ignoraba algunas que eran absolutamente ciertas. De hecho, creo que no somos ingenieros de software porque no nos damos cuenta de lo que es el verdadero diseño de software. Ahora estoy aún más convencido de ello.
El objetivo final de cualquier actividad de ingeniería es algún tipo de documentación. Cuando se completa el trabajo de diseño, los archivos de diseño se entregan al equipo de fabricación. El equipo y el equipo de diseño son grupos completamente diferentes y las habilidades son completamente diferentes a las del equipo de diseño. Si el documento de diseño describe correctamente un diseño completo, el equipo de fabricación puede comenzar a construir el producto. De hecho, pueden empezar a construir muchos de los objetos físicos del producto sin ninguna intervención adicional por parte del diseñador. Después de revisar el ciclo de vida del desarrollo de software según mis conocimientos, llegué a la conclusión de que el único documento de software que realmente cumple con los estándares de diseño de ingeniería es la lista de códigos fuente.
Ha habido mucho debate sobre esta idea y se han escrito innumerables artículos a favor y en contra. Este artículo asume que el código fuente final es el diseño de software real y luego analiza más de cerca algunas de las consecuencias de esta suposición. Quizás no pueda demostrar que este punto de vista sea correcto, pero me gustaría argumentar que sí explica algunos hechos observados sobre la industria del software, incluida la popularidad de C++.
Cuando se analiza el código como resultado del diseño de software, un resultado eclipsa por completo a todos los demás. Es muy importante y obvio y, debido a esto, es un punto ciego para la mayoría de las organizaciones de software. El resultado es un software que es barato de construir. No tiene credenciales costosas en absoluto; es barato y casi gratis. Si el código fuente es el diseño del software, entonces la construcción real del software la realizan el compilador y el vinculador. A menudo nos referimos al proceso de compilar y conectar un sistema de software completo como "una compilación". La mayor inversión en equipos de creación de software es muy pequeña: todo lo que se necesita es una computadora, un editor, un compilador y un enlazador. Una vez que tenga un entorno de compilación, la compilación del software real solo toma un momento. Puede llevar mucho tiempo compilar un programa C++ de 50.000 líneas, pero ¿cuánto tiempo llevará construir un sistema de hardware con la misma complejidad de diseño que un programa C++ de 50.000 líneas?
Otra consecuencia de pensar en el código fuente como diseño de software es que los diseños de software son relativamente fáciles de crear, al menos en un sentido mecánico. Por lo general, solo toma unos días escribir (es decir, diseñar) un módulo de software representativo (de 50 a 100 líneas de código) (la depuración completa es otro tema, que se analiza en detalle más adelante). Me encantaría preguntar si alguna otra disciplina puede producir diseños tan complejos como el software en tan poco tiempo, pero primero tenemos que descubrir cómo medir y comparar la complejidad. Sin embargo, está claro que el diseño de software puede llegar a ser muy grande muy rápidamente.
Suponiendo que los diseños de software son relativamente fáciles de crear e inherentemente económicos de construir, no sorprende descubrir que los diseños de software suelen ser muy grandes y complejos. Esto puede parecer obvio, pero a menudo se pasa por alto la importancia del problema. Los proyectos escolares suelen tener miles de líneas de código. Los diseñadores también desechan productos de software con 10.000 líneas de código (diseño). Hace tiempo que dejamos de centrarnos en software simple. Un diseño de software empresarial típico consta de miles de líneas de código. Muchos diseños de software contienen millones de líneas de código. Además, el diseño de software casi siempre está evolucionando. Si bien el diseño actual puede tener solo unos pocos miles de líneas de código, a lo largo de la vida útil del producto es posible que tengas que escribir ese código muchas veces.
Aunque algunos diseños de hardware pueden parecer tan complejos como los diseños de software, tenga en cuenta dos hechos sobre el hardware moderno. En primer lugar, es posible que los resultados complejos de ingeniería de hardware no siempre estén libres de errores. En este punto, no existe ningún criterio en el que creamos como el software.
La mayoría de los microprocesadores se venden con algún tipo de error lógico: puentes colapsan, represas estallan, aviones se estrellan y miles de automóviles y otros productos de consumo son retirados del mercado, todo lo cual aún está fresco en nuestra memoria. Es el resultado de errores de diseño. En segundo lugar, los diseños de hardware complejos tienen una correspondiente fase de construcción compleja y costosa. Por lo tanto, las capacidades necesarias para fabricar dichos sistemas limitan el número de empresas que realmente pueden producir diseños de hardware complejos. Para el software, no existen tales limitaciones. Actualmente, existen cientos de organizaciones de software y miles de sistemas de software muy complejos, y el número y la complejidad aumentan cada día. Esto significa que la industria del software no puede encontrar soluciones a sus propios problemas imitando a los desarrolladores de hardware. Si hay un hilo común, es que la ingeniería de hardware se parecerá cada vez más al desarrollo de software a medida que CAD y CAM ayuden a los diseñadores de hardware a crear diseños cada vez más complejos.
Diseñar software es una actividad de gestión de la complejidad. La complejidad existe en el diseño del software en sí, en la organización del software de la empresa y en la industria del software en su conjunto. El diseño de software y el diseño de sistemas son muy similares. Puede abarcar muchas tecnologías y, a menudo, involucra muchas ramas de disciplinas. Las especificaciones del software no suelen ser fijas y suelen cambiar rápidamente, lo que suele ocurrir durante el proceso de diseño del software. Del mismo modo, los equipos de desarrollo de software tienden a ser inestables y a menudo cambian durante el proceso de diseño. En muchos sentidos, el software se parece más a un sistema social u orgánico complejo que al hardware. Todo esto hace que el diseño de software sea un proceso difícil y propenso a errores. Si bien ninguna de estas son ideas creativas, hoy, casi 30 años después de que comenzara la revolución de la ingeniería de software, el desarrollo de software todavía parece una habilidad no entrenada en comparación con otras industrias de ingeniería.
En general, se acepta que cuando los ingenieros reales completan un diseño, sin importar cuán complejo sea, tienen mucha confianza en que el diseño funcionará. También tienen mucha confianza en que el diseño se puede construir utilizando técnicas probadas. Para ello, los ingenieros de hardware dedican mucho tiempo a validar y mejorar sus diseños. Por ejemplo, considere el diseño de un puente. Antes de construir un diseño de este tipo, los ingenieros realizarán análisis estructurales: construirán modelos por computadora y ejecutarán simulaciones, construirán modelos a escala y los probarán en túneles de viento u otros medios. En resumen, antes de la construcción, el diseñador utilizará todos los métodos imaginables para demostrar que el diseño es correcto. Para el diseño de nuevos aviones de pasajeros, la situación es aún más grave: es necesario construir un prototipo del mismo tamaño que el original y realizar pruebas en vuelo para verificar las distintas expectativas en el diseño.
Para la mayoría de las personas, el software obviamente no es un proyecto tan riguroso como el diseño de hardware. Sin embargo, si miramos el código fuente como un diseño, encontraremos que los ingenieros de software en realidad han verificado y mejorado mucho sus diseños. Los ingenieros de software lo llaman prueba y depuración, no ingeniería. La mayoría de la gente no piensa en las pruebas y la depuración como un "proyecto" real; ciertamente no en la industria del software. La razón de esta visión tiene más que ver con la negativa de la industria del software a ver el código como diseño que con diferencias reales de ingeniería. De hecho, los modelos de prueba, prototipos y placas de prueba de circuitos se han convertido en una parte aceptada de otras disciplinas de ingeniería. La razón por la que los diseñadores de software no utilizan o no utilizan métodos más formales para verificar sus diseños es por la simple ley económica del ciclo de construcción del software.
Primera revelación: simplemente construir un diseño y probarlo es más barato y más fácil que hacer cualquier otra cosa. No nos importa cuántas compilaciones se creen: el costo de estas compilaciones en el tiempo es casi cero y, si descartamos la compilación, los recursos que utiliza se pueden reutilizar por completo. Tenga en cuenta que las pruebas no se trata sólo de lograr que el diseño actual sea correcto, sino que también es parte del proceso de mejorar el diseño. Los ingenieros de hardware de sistemas complejos a menudo construyen modelos (o, al menos, visualizan sus diseños con gráficos por computadora). Esto les da una "sensación" del diseño que no es posible simplemente examinando el diseño. No es posible ni necesario que el software construya tal modelo. Simplemente fabricamos el producto en sí. Incluso si la verificación formal del software pudiera realizarse automáticamente como un compilador, aún pasaríamos por el ciclo de compilación/prueba. De modo que la verificación formal nunca ha tenido mucha importancia práctica para la industria del software.
Esta es la realidad del actual proceso de desarrollo de software. Cada vez más personas y organizaciones crean diseños de software más complejos. Estos diseños se escribirán en algún lenguaje de programación y luego se verificarán y mejorarán mediante un ciclo de compilación/prueba. Este proceso es propenso a errores y no particularmente riguroso. El problema se ve agravado por la renuencia de bastantes desarrolladores de software a creer que así es como funciona el proceso.
Actualmente, la mayoría de los procesos de software intentan separar las diferentes etapas del diseño de software en diferentes categorías. La codificación sólo puede comenzar después de que se congele el diseño de nivel superior. Las pruebas y la depuración son solo para eliminar errores de construcción. Los programadores están en el medio. Son los trabajadores de la construcción de la industria del software. Mucha gente cree que si pudiéramos lograr que los programadores dejaran de "hackear" y construyeran de acuerdo con el diseño que se les dio (y cometieran menos errores en el camino), entonces el desarrollo de software podría madurar hasta convertirse en una verdadera disciplina de ingeniería. Sin embargo, esto no sucederá mientras el proceso ignore los hechos económicos y de ingeniería.
Por ejemplo, ninguna industria moderna puede tolerar una tasa de reelaboración superior al 100% en su proceso de fabricación. Si un trabajador de la construcción no hace su trabajo con regularidad la primera vez, pronto se quedará sin trabajo.
Pero en la industria del software, incluso el fragmento de código más pequeño tiene el potencial de modificarse o reescribirse por completo durante las pruebas y la depuración. En un proceso creativo (como el diseño), reconocemos que dichas mejoras no son parte del proceso de fabricación. Nadie espera que los ingenieros creen un diseño perfecto a la primera. Incluso si lo hace, todavía tiene que pasar por un proceso de mejora para demostrar que es perfecto.
Incluso si no aprendemos nada de los métodos de gestión japoneses, debemos saber que culpar a los trabajadores por errores en el proceso no conduce a mejorar la productividad. No siempre debemos forzar el desarrollo de software a seguir modelos de procesos incorrectos. En cambio, necesitamos mejoras en los procesos que ayuden, no obstaculicen, la producción de mejor software. Esta es la piedra de toque de la ingeniería de software. La ingeniería se trata de cómo implementar el proceso, no de si se necesita un sistema CAD para producir el documento de diseño final.
Una cosa abrumadora sobre el desarrollo de software es que todo es parte del proceso de diseño. La codificación es diseño, las pruebas y la depuración son parte del diseño, y lo que normalmente consideramos diseño sigue siendo parte del diseño. Aunque el software es barato de construir, su diseño es increíblemente caro. El software es muy complejo y tiene muchos aspectos y consideraciones de diseño diferentes. El problema es que todos los diferentes aspectos están interrelacionados (al igual que la ingeniería de hardware). Esperamos que los diseñadores de alto nivel puedan ignorar los detalles del diseño del algoritmo del módulo. Asimismo, esperamos que los programadores no tengan que considerar cuestiones de diseño de alto nivel al diseñar algoritmos dentro de los módulos. Desafortunadamente, los problemas en un nivel de diseño pueden invadir otros niveles. Elegir un algoritmo para un módulo específico puede ser tan importante para el éxito de todo el sistema de software como cualquier cuestión de diseño de nivel superior. No existe una jerarquía de importancia entre los diferentes aspectos del diseño de software. Un error de diseño en el módulo más bajo puede ser tan fatal como un error en el módulo más alto. El diseño del software debe ser completo y correcto en todos los aspectos; de lo contrario, todo el software basado en este diseño será incorrecto.
Para gestionar la complejidad, el software se diseña en capas. Cuando un programador considera el diseño detallado de un módulo, puede haber cientos de otros módulos y miles de detalles que no puede considerar al mismo tiempo. Por ejemplo, en el diseño de software, hay algunos aspectos importantes que no entran completamente en la categoría de estructuras de datos y algoritmos. Idealmente, los programadores no deberían considerar otros aspectos del diseño al diseñar el código.
Sin embargo, el diseño no funciona así y cada vez está más claro por qué. El diseño del software está incompleto hasta que se escribe y prueba. Las pruebas son una parte esencial del proceso de verificación y mejora del diseño. El diseño de una estructura de alto nivel no es un diseño de software completo; es simplemente el marco estructural de un diseño detallado. Nuestra capacidad para verificar rigurosamente diseños de alto nivel es muy limitada. En última instancia, el diseño detallado afecta al diseño de alto nivel al menos tanto como otros factores (o se debería permitir que lo hagan). Mejorar todos los aspectos de un diseño es un proceso que debe ocurrir durante todo el ciclo de diseño. Si algún aspecto de un diseño queda fuera del proceso de mejora, no sorprende que el diseño final sea deficiente o incluso no funcione.
Sería bueno si el diseño de software de alto nivel se convirtiera en un proceso de ingeniería más riguroso, pero la realidad de los sistemas de software no es rigurosa. El software es complejo y depende de muchas otras cosas. Tal vez, algún hardware no funcione como los diseñadores pensaron que lo haría, o una rutina de la biblioteca tiene una limitación que no se explica en la documentación. Todo proyecto de software se topa tarde o temprano con este tipo de problemas. Este tipo de problemas se descubrirán durante las pruebas (si hacemos un buen trabajo), porque no hay forma de detectarlos a tiempo. Cuando se descubren, obligan a realizar cambios en el diseño. Si tenemos suerte, los cambios en el diseño son locales. Los cambios a menudo afectan algunas partes importantes de todo el diseño del software (Ley de Murphy). Cuando la parte afectada del diseño no se puede cambiar por alguna razón, entonces otras partes del diseño deben destruirse para acomodar el efecto. Esto a menudo da como resultado lo que los gerentes consideran "codificación aleatoria", pero esa es la realidad del desarrollo de software.
Por ejemplo, en un proyecto en el que trabajé recientemente, descubrí una dependencia temporal entre la estructura interna del módulo A y otro módulo B. Desafortunadamente, la estructura interna del módulo A estaba oculta detrás de una abstracción. que no permite que las llamadas al módulo B se combinen de ninguna manera en su secuencia correcta de llamadas. Cuando se descubrió el problema, por supuesto se perdió la oportunidad de cambiar el cuerpo abstracto de A. Como era de esperar, lo que sucede es que cada vez se aplican "arreglos" más complejos al diseño interno del Atlético. Cuando no habíamos terminado de instalar la versión 1, había una sensación general de que el diseño iba cuesta abajo. Cada nueva revisión amenaza con destruir algunas de las antiguas. Este es un proyecto formal de desarrollo de software. Finalmente, mis colegas y yo decidimos cambiar el diseño, pero para obtener la aprobación de la gerencia, tuvimos que trabajar horas extras voluntarias y sin paga.
En cualquier proyecto de software a gran escala, estos problemas son inevitables. Aunque la gente ha utilizado varios métodos para prevenir su aparición, se han pasado por alto algunos detalles importantes. Ésta es la diferencia entre tecnología e ingeniería. Si la experiencia puede llevarnos en la dirección correcta, esa es la tecnología. Si la experiencia sólo nos lleva a territorio desconocido, entonces debemos tomar los métodos con los que empezamos y mejorarlos mediante un proceso controlado de mejora, que es la ingeniería.
Echemos un vistazo.
Como parte muy pequeña de esto, todos los programadores saben que escribir la documentación de diseño de software después de la codificación, en lugar de antes, da como resultado una documentación más precisa. La razón es obvia. El diseño final representado por el código es lo único que mejora durante el ciclo de construcción/prueba. Durante este ciclo, la probabilidad de que el diseño inicial permanezca sin cambios es inversamente proporcional al número de módulos y programadores del proyecto. Rápidamente dejará de tener valor.
En ingeniería de software necesitamos un diseño excelente en todos los niveles. Especialmente necesitamos un excelente diseño de alto nivel. Cuanto mejor sea el diseño inicial, más sencillo será el diseño detallado. Los diseñadores deberían utilizar cualquier cosa que les ayude. Diagrama de estructura, diagrama de Butch, tabla de estados, PDL, etc. -Si te ayuda, úsalo. Sin embargo, debemos recordar que estas herramientas y símbolos no son diseños de software. Finalmente, tenemos que crear un diseño de software real y hacerlo en un lenguaje de programación. Por eso, cuando empezamos a diseñar, no debemos tener miedo a codificar. Debemos estar dispuestos a mejorarlos cuando sea necesario.
Hasta el momento, no existe ningún símbolo de diseño que pueda aplicarse tanto al diseño de nivel superior como al diseño detallado. En última instancia, el diseño se expresará como código escrito en un lenguaje de programación. Esto significa que antes de que pueda comenzar el diseño detallado, los símbolos de diseño de nivel superior deben convertirse al lenguaje de programación de destino. Este paso de conversión lleva tiempo e introduce errores. Los programadores tienden a revisar los requisitos y rediseñar el diseño de nivel superior, y luego codificar basándose en su propia realidad en lugar de convertir una notación que puede no corresponderse completamente con el lenguaje de programación elegido. Esto también es parte de la realidad del desarrollo de software.
Quizás sería mejor si el diseñador escribiera él mismo el código inicial en lugar de que otra persona modificara el diseño independiente del lenguaje más adelante. Lo que necesitamos es un símbolo unificado adecuado para todos los niveles de diseño. En otras palabras, necesitamos un lenguaje de programación que también sea adecuado para capturar conceptos de diseño de alto nivel. c++ puede cumplir este requisito. C++ es un lenguaje de programación adecuado para proyectos del mundo real y un lenguaje de diseño de software muy expresivo. C++ nos permite expresar directamente información de alto nivel sobre los componentes de diseño. Esto facilita el diseño y mejora del diseño en el futuro. Debido a que tiene un mecanismo de verificación de tipos más potente, también ayuda a detectar errores en el diseño. Esto da como resultado un diseño más robusto, que en realidad es una mejor ingeniería.
Finalmente, el diseño del software debe expresarse en un lenguaje de programación y luego verificarse y mejorarse a través de un ciclo de construcción/prueba. Cualquier otra idea aparte de esta es completamente inútil. Considere qué herramientas y tecnologías de desarrollo de software son populares. La programación estructurada se consideraba una técnica creativa en ese momento. Pascal lo hizo popular y él mismo se hizo popular. El diseño orientado a objetos es una tecnología popular emergente y C++ es su núcleo. Ahora, considere las cosas que no funcionan. Herramienta de caso, ¿popular? Sí; ¿es universal? No. ¿Qué tal un diagrama estructural? La situación es la misma. Asimismo, existen diagramas de Warner-Alto, diagramas de Butch, diagramas de objetos y todo lo que se te ocurra. Cada uno tiene sus propias fortalezas y sólo una debilidad fundamental: no es realmente un diseño de software. De hecho, la única notación universalmente reconocida para el diseño de software es PDL. ¿Cómo se ve?
Esto muestra que * * * es de suma importancia en la industria del software. En comparación con el conocimiento inconsciente de la tecnología de programación, especialmente la mejora de los lenguajes de programación utilizados en el desarrollo real, es más importante que cualquier otra cosa. la industria del software. También muestra que los programadores se preocupan por el diseño. Cuando aparecen lenguajes de programación más expresivos, los desarrolladores de software los utilizan.
Del mismo modo, considere cómo está cambiando el proceso de desarrollo de software. Érase una vez, utilizamos el proceso de cascada. Ahora estamos hablando de desarrollo en espiral y creación rápida de prototipos. Si bien a menudo se piensa que estas técnicas "eliminan el riesgo" y "acortan el tiempo de entrega del producto", en realidad solo sirven para comenzar a codificar en una etapa más temprana del ciclo de vida del software. Esto es algo bueno. Esto permite que el ciclo de construcción/prueba comience a validar y mejorar el diseño antes. Esto también significa que es probable que los mejores diseñadores de software realicen diseños detallados.
Como se mencionó anteriormente, la ingeniería se trata más de cómo se implementa el proceso que de cómo se ve el producto final. En la industria del software, nos estamos acercando al estándar de los ingenieros, pero se necesitan algunos cambios cognitivos. Los ciclos de programación y construcción/prueba son fundamentales para el proceso de ingeniería del software. Necesitamos gestionarlos de esta manera. La economía del ciclo de construcción/prueba, junto con el hecho de que los sistemas de software pueden representar casi cualquier cosa, hacen que sea completamente imposible encontrar una forma universal de verificar los diseños de software. Podemos mejorar este proceso, pero no podemos romper con él.
Punto final: el objetivo de cualquier proyecto de diseño de ingeniería es algún producto de documentación. Obviamente, los documentos del diseño real son los más importantes, pero no son los únicos documentos que se deben producir. Con el tiempo, alguien utilizará este software. Asimismo, es probable que el sistema requiera modificaciones y mejoras posteriores. Esto significa que la documentación de respaldo es tan importante para los proyectos de software como para los proyectos de hardware. Aunque se ignoran temporalmente los documentos que no están directamente relacionados con el proceso de diseño, como los manuales de usuario y las guías de instalación, todavía quedan dos requisitos importantes que deben resolverse utilizando documentos de diseño auxiliares.
El primer propósito de la documentación auxiliar es capturar información importante del espacio del problema que no se puede utilizar directamente en el diseño. El diseño de software requiere la creación de conceptos de software para modelar conceptos en el espacio del problema. Este proceso requiere que comprendamos los conceptos en el espacio del problema.
A menudo, esta comprensión incluirá información que no se modelará directamente en el espacio del software, pero que aún así ayudará al diseñador a determinar cuáles son los conceptos subyacentes y cuál es la mejor manera de modelarlos. Esta información debe quedar registrada en algún lugar en caso de que desee cambiar el modelo más adelante.
Una segunda necesidad importante de documentación de respaldo es registrar ciertos aspectos del diseño que son difíciles de extraer directamente del diseño mismo. Pueden ser contenidos de alto nivel o contenidos de bajo nivel. Para muchos de estos aspectos, los gráficos son la mejor manera de describirlos. Esto hace que sea difícil incluirlos como comentarios en el código. Esto no quiere decir que se deban utilizar notaciones gráficas de diseño de software en lugar de lenguajes de programación. Esto no es diferente a un documento de diseño gráfico que complementa los temas de hardware con alguna descripción textual.
Nunca olvides que es el código fuente, no la documentación de respaldo, lo que determina cómo se verá el diseño real. Idealmente, se pueden utilizar herramientas de software para posprocesar el código fuente y generar documentación de respaldo. Quizás estemos esperando demasiado de esto. A continuación, los programadores (o redactores técnicos) pueden utilizar herramientas para extraer información específica del código fuente, que luego pueden documentar de otras maneras. No hay duda de que actualizar este tipo de documentación manualmente resulta complicado. Esta es otra razón para respaldar la necesidad de lenguajes de programación más expresivos. Nuevamente, esta es una razón para apoyar mantener esta documentación auxiliar al mínimo y formalizarla lo más tarde posible en el proyecto. De nuevo, podemos utilizar algunas buenas herramientas; en caso contrario, tenemos que recurrir al lápiz, el papel y la pizarra.
Para resumir:
El software real se ejecuta en la computadora. Es una secuencia de 0 y 1 almacenada en algún medio magnético. No es un programa escrito en C++ (ni ningún otro lenguaje de programación).
Un listado de programas es un documento que representa el diseño del software. De hecho, son el compilador y el enlazador los que construyen el diseño del software.
Es increíble lo barato que es construir un diseño de software real, y siempre resulta más barato a medida que las computadoras se vuelven más rápidas.
Diseñar software real es increíblemente costoso debido a la increíble complejidad del software y casi todos los pasos de un proyecto de software son parte del proceso de diseño.
La programación es una actividad de diseño; un buen proceso de diseño de software reconoce esto y no duda en codificar cuando tiene sentido.
La codificación muestra su significado con más frecuencia de lo que pensamos. A menudo, el proceso de expresar un diseño en código revela omisiones y requisitos de diseño adicionales. Cuanto antes suceda esto, mejor será el diseño.
Debido a que el software es tan barato de construir, los métodos formales de verificación de ingeniería son de poca utilidad en el desarrollo de software real. Es más fácil y económico simplemente construir un diseño y probarlo que intentar probarlo.
Las pruebas y la depuración son actividades de diseño; para el software, son equivalentes a los procesos de verificación y mejora del diseño en otras disciplinas de ingeniería. Un buen proceso de diseño de software reconoce esto y no intenta reducir estos pasos.
Existen otras actividades de diseño, llamadas diseño de alto nivel, diseño de módulos, diseño estructural, diseño arquitectónico, etc. Un buen proceso de diseño de software reconoce esto e incluye estos pasos cuidadosamente.
Todas las actividades de diseño son interactivas. Un buen proceso de diseño de software reconoce cuándo los diferentes pasos de diseño revelan su necesidad y permite cambios de diseño, a veces cambios radicales.
Muchos símbolos de diseño de software diferentes pueden resultar útiles: sirven como documentación de respaldo y herramientas para ayudar a simplificar el proceso de diseño. No son diseños de software.
El desarrollo de software sigue siendo un oficio, no una disciplina de ingeniería. Principalmente por falta de rigor en el proceso crítico de verificación y mejora del diseño.
Finalmente, el progreso real en el desarrollo de software depende del progreso de la tecnología de programación, y el progreso de la tecnología de programación significa el progreso de los lenguajes de programación. C++ es una gran mejora. Ganó una popularidad explosiva porque es un lenguaje de programación convencional que respalda directamente un mejor diseño de software.
C++ ha dado un paso en la dirección correcta, pero se necesitan más avances.