Construcción de software

La construcción de software es una disciplina de ingeniería de software . Es la creación detallada de software funcional y significativo mediante una combinación de codificación, verificación , pruebas unitarias , pruebas de integración y depuración . Está vinculada a todas las demás disciplinas de ingeniería de software, especialmente al diseño y las pruebas de software . ^[1]

La necesidad de reducir la complejidad se debe principalmente a la capacidad limitada de la mayoría de las personas para almacenar estructuras e información complejas en sus memorias de trabajo. La reducción de la complejidad se logra haciendo hincapié en la creación de código que sea simple y legible en lugar de inteligente. La minimización de la complejidad se logra mediante el uso de estándares y numerosas técnicas específicas de codificación. También se apoya en técnicas de calidad centradas en la construcción. ^[2]

Anticipar los cambios ayuda a los ingenieros de software a crear software extensible, lo que significa que pueden mejorar un producto de software sin alterar la estructura subyacente. ^[2] Las investigaciones realizadas durante 25 años demostraron que el costo de la reelaboración puede ser de 10 a 100 veces (5 a 10 veces para proyectos más pequeños) más caro que lograr que los requisitos sean correctos la primera vez. Dado que el 25% de los requisitos cambian durante el desarrollo de un proyecto promedio, la necesidad de reducir el costo de la reelaboración ilustra la necesidad de anticipar el cambio. ^[3]

Construir para verificación significa crear software de tal manera que los ingenieros de software que escriben el software puedan detectar fácilmente los fallos , así como durante las pruebas independientes y las actividades operativas. Las técnicas específicas que respaldan la construcción para verificación incluyen seguir estándares de codificación para respaldar las revisiones de código , las pruebas unitarias , la organización del código para respaldar las pruebas automatizadas y el uso restringido de estructuras de lenguaje complejas o difíciles de entender , entre otras. ^[2]

La reutilización sistemática puede permitir mejoras significativas en la productividad, la calidad y los costos del software. La reutilización tiene dos facetas estrechamente relacionadas: ^[2]

• Construcción para reutilización: crear activos de software reutilizables.
• Construcción con reutilización: Reutilizar activos de software en la construcción de una nueva solución.

Las normas, ya sean externas (creadas por organizaciones internacionales) o internas (creadas a nivel corporativo), que afectan directamente las cuestiones de construcción incluyen: ^[2]

• Métodos de comunicación: como estándares para formatos y contenidos de documentos.
• Lenguajes de programación
• Normas de codificación
• Plataformas
• Herramientas: Como estándares diagramáticos para notaciones como UML .

Se han creado numerosos modelos para desarrollar software , algunos de los cuales enfatizan la construcción más que otros. Algunos modelos son más lineales desde el punto de vista de la construcción, como los modelos de ciclo de vida en cascada y de entrega por etapas. Estos modelos tratan la construcción como una actividad que ocurre solo después de que se haya completado un trabajo significativo de prerrequisitos, incluido el trabajo detallado de requisitos , el trabajo de diseño extenso y la planificación detallada . Otros modelos son más iterativos , como el prototipado evolutivo , la programación extrema y Scrum . Estos enfoques tienden a tratar la construcción como una actividad que ocurre simultáneamente con otras actividades de desarrollo de software , incluidos los requisitos , el diseño y la planificación , o se superpone a ellas. ^[1]

La elección del método de construcción es un aspecto clave de la actividad de planificación de la construcción. La elección del método de construcción afecta el grado en que se realizan los requisitos previos de construcción (por ejemplo, análisis de requisitos , diseño de software , etc.), el orden en que se realizan y el grado en que se espera que se completen antes de que comience el trabajo de construcción. La planificación de la construcción también define el orden en que se crean e integran los componentes , los procesos de gestión de la calidad del software , la asignación de tareas a ingenieros de software específicos y las otras tareas, según el método elegido . ^[1]

Se pueden medir numerosas actividades y artefactos de construcción, incluidos el código desarrollado, el código modificado, el código reutilizado, el código destruido, la complejidad del código, las estadísticas de inspección del código, las tasas de reparación y detección de fallas, el esfuerzo y la programación. Estas mediciones pueden ser útiles para administrar la construcción, garantizar la calidad durante la construcción, mejorar el proceso de construcción, así como por otras razones. ^[1]

La construcción de software está impulsada por muchas consideraciones prácticas:

Para tener en cuenta las lagunas imprevistas en el diseño del software , durante la construcción del software se deben realizar algunas modificaciones de diseño en una escala más pequeña o más grande para completar los detalles del diseño del software . ^[4]

Los investigadores han descubierto que una de las características de diseño que resulta beneficiosa es el bajo abanico de distribución . El ocultamiento de información resultó ser una técnica de diseño útil en programas grandes que los hacía más fáciles de modificar por un factor de 4. ^[5]

Los lenguajes de construcción incluyen todas las formas de comunicación mediante las cuales un ser humano puede especificar una solución ejecutable a un problema en una computadora. Entre ellos se encuentran los lenguajes de configuración, los lenguajes de herramientas y los lenguajes de programación : ^[6]

• Los lenguajes de configuración son lenguajes en los que los ingenieros de software eligen entre un conjunto limitado de opciones predefinidas para crear instalaciones de software nuevas o personalizadas.
• Los lenguajes de kits de herramientas se utilizan para crear aplicaciones a partir de kits de herramientas y son más complejos que los lenguajes de configuración.
• Los lenguajes de script son tipos de lenguajes de programación de aplicaciones que admiten scripts que a menudo se interpretan en lugar de compilarse.
• Los lenguajes de programación son el tipo más flexible de lenguajes de construcción que utilizan tres tipos generales de notación:
  • Notaciones lingüísticas que se distinguen en particular por el uso de cadenas de texto similares a palabras para representar construcciones de software complejas y la combinación de dichas cadenas similares a palabras en patrones que tienen una sintaxis similar a una oración.
  • Notaciones formales que se basan menos en significados intuitivos y cotidianos de palabras y cadenas de texto y más en definiciones respaldadas por definiciones precisas, inequívocas y formales (o matemáticas).
  • Notaciones visuales que se basan mucho menos en las notaciones orientadas al texto de la construcción lingüística y formal y, en cambio, se basan en la interpretación visual directa y la colocación de entidades visuales que representan el software subyacente.

Los programadores que trabajan en un lenguaje que han utilizado durante tres años o más son aproximadamente un 30 por ciento más productivos que los programadores con experiencia equivalente que son nuevos en un lenguaje. Los lenguajes de alto nivel como C++, Java, Smalltalk y Visual Basic ofrecen entre 5 y 15 veces más productividad, confiabilidad, simplicidad y comprensión que los lenguajes de bajo nivel como el ensamblador y C. Se ha demostrado que un código equivalente necesita menos líneas para implementarse en lenguajes de alto nivel que en lenguajes de nivel inferior. ^[7]

Las siguientes consideraciones se aplican a la actividad de codificación de construcción de software: ^[8]

• Técnicas para crear código fuente comprensible , incluyendo la denominación y el diseño del código fuente. Un estudio demostró que el esfuerzo necesario para depurar un programa se minimiza cuando los nombres de las variables tienen entre 10 y 16 caracteres. ^[9]
• Uso de clases , tipos enumerados , variables , constantes con nombre y otras entidades similares:
  • Un estudio realizado por la NASA demostró que colocar el código en clases bien factorizadas puede duplicar la reutilización del código en comparación con el código desarrollado utilizando diseño funcional. ^{[10] [11]}
  • Un experimento demostró que los diseños que acceden a matrices de forma secuencial, en lugar de aleatoria, dan como resultado menos variables y menos referencias de variables. ^[12]
• Uso de estructuras de control:
  • Un experimento descubrió que los bucles con salida son más comprensibles que otros tipos de bucles. ^[13]
  • Respecto al nivel de anidación en bucles y condicionales, los estudios han demostrado que los programadores tienen dificultades para comprender más de tres niveles de anidación. ^{[13] [14]}
  • Se ha demostrado que la complejidad del flujo de control se correlaciona con una baja confiabilidad y errores frecuentes. ^[14]
• Manejo de condiciones de error, tanto errores planificados como excepciones (entrada de datos erróneos, por ejemplo)
• Prevención de violaciones de seguridad a nivel de código ( desbordamientos de búfer o desbordamientos de índice de matriz , por ejemplo)
• Uso de recursos mediante el uso de mecanismos de exclusión y disciplina en el acceso a recursos reutilizables en serie (incluidos subprocesos o bloqueos de bases de datos )
• Organización del código fuente (en instrucciones y rutinas ): ^[11]
  • Las rutinas con un alto grado de cohesión resultaron ser menos propensas a errores que las rutinas con un grado de cohesión menor. Un estudio de 450 rutinas determinó que el 50 por ciento de las rutinas con un alto grado de cohesión no presentaban errores, en comparación con solo el 18 por ciento de las rutinas con un grado de cohesión menor. Otro estudio de otras 450 rutinas determinó que las rutinas con los índices de acoplamiento a cohesión más altos presentaban siete veces más errores que las que presentaban los índices de acoplamiento a cohesión más bajos y su reparación era veinte veces más costosa.
  • Aunque los estudios no han mostrado resultados concluyentes en cuanto a la correlación entre el tamaño de las rutinas y la tasa de errores en ellas, un estudio descubrió que las rutinas con menos de 143 líneas de código eran 2,4 veces más baratas de corregir que las rutinas más grandes. Otro estudio demostró que el código necesitaba ser modificado menos cuando las rutinas tenían un promedio de 100 a 150 líneas de código. Otro estudio descubrió que la complejidad estructural y la cantidad de datos en una rutina estaban correlacionadas con los errores independientemente de su tamaño.
  • Las interfaces entre rutinas son unas de las áreas de un programa más propensas a errores. Un estudio demostró que el 39 por ciento de todos los errores se debían a errores de comunicación entre rutinas.
  • Los parámetros no utilizados se correlacionan con una mayor tasa de error. En un estudio, solo entre el 17 y el 29 por ciento de las rutinas con más de una variable no referenciada no tenían errores, en comparación con el 46 por ciento en las rutinas sin variables no utilizadas.
  • El número de parámetros de una rutina debe ser 7 como máximo, ya que las investigaciones han demostrado que las personas generalmente no pueden realizar un seguimiento de más de siete fragmentos de información a la vez.
• Organización del código fuente (en clases , paquetes u otras estructuras). Al considerar la contención , el número máximo de miembros de datos en una clase no debe exceder 7 ± 2. Las investigaciones han demostrado que este número es el número de elementos discretos que una persona puede recordar mientras realiza otras tareas. Al considerar la herencia , el número de niveles en el árbol de herencia debe ser limitado. Se ha descubierto que los árboles de herencia profundos están significativamente asociados con mayores tasas de errores. Al considerar el número de rutinas en una clase, debe mantenerse lo más pequeño posible. Un estudio sobre programas C++ ha encontrado una asociación entre el número de rutinas y el número de errores. ^[10]
• Documentación del código
• Ajuste de código

El propósito de las pruebas de construcción es reducir la brecha entre el momento en que se insertan fallas en el código y el momento en que se detectan esas fallas. En algunos casos, las pruebas de construcción se realizan después de que se haya escrito el código. En la programación de prueba primero , los casos de prueba se crean antes de que se escriba el código. La construcción implica dos formas de prueba, que a menudo las realiza el ingeniero de software que escribió el código : ^[1]

• Pruebas unitarias
• Pruebas de integración

Implementar la reutilización de software implica más que crear y utilizar bibliotecas de activos. Requiere formalizar la práctica de la reutilización mediante la integración de procesos y actividades de reutilización en el ciclo de vida del software . Las tareas relacionadas con la reutilización en la construcción de software durante la codificación y las pruebas son: ^[1]

• La selección de las unidades reutilizables, bases de datos , procedimientos de prueba o datos de prueba .
• La evaluación de la reutilización del código o prueba.
• La notificación de información de reutilización sobre código nuevo, procedimientos de prueba o datos de prueba .

Las principales técnicas utilizadas para garantizar la calidad del código a medida que se construye incluyen: ^[15]

• Pruebas unitarias y pruebas de integración . Un estudio determinó que las tasas promedio de detección de defectos de las pruebas unitarias y las pruebas de integración son del 30 % y el 35 %, respectivamente. ^[16]
• Desarrollo de pruebas primero
• Uso de aserciones y programación defensiva
• Depuración
• Inspecciones . Un estudio encontró que la tasa promedio de detección de defectos de las inspecciones de código formales es del 60%. Con respecto al costo de encontrar defectos, un estudio encontró que la lectura de código detectó un 80% más de fallas por hora que las pruebas. Otro estudio mostró que cuesta seis veces más detectar defectos de diseño mediante pruebas que mediante inspecciones. Un estudio de IBM mostró que solo se necesitaban 3,5 horas para encontrar un defecto a través de inspecciones de código frente a las 15-25 horas mediante pruebas. Microsoft ha descubierto que se necesitan 3 horas para encontrar y corregir un defecto mediante inspecciones de código y 12 horas para encontrar y corregir un defecto mediante pruebas. En un programa de 700 mil líneas, se informó que las revisiones de código eran varias veces más rentables que las pruebas. ^[16] Los estudios encontraron que las inspecciones dan como resultado un 20% - 30% menos de defectos por cada 1000 líneas de código que las prácticas de revisión menos formales y que aumentan la productividad en aproximadamente un 20%. Las inspecciones formales generalmente ocuparán entre el 10% y el 15% del presupuesto del proyecto y reducirán el costo general del proyecto. Los investigadores descubrieron que tener más de 2 o 3 revisores en una inspección formal no aumenta la cantidad de defectos encontrados, aunque los resultados parecen variar según el tipo de material que se inspecciona. ^[17]
• Revisiones técnicas . Un estudio descubrió que las tasas promedio de detección de defectos de las revisiones de código informales y las comprobaciones de escritorio son del 25% y el 40% respectivamente. ^{[16] Se descubrió que} las revisiones de código tienen una tasa de detección de defectos del 20% al 40%, pero también se descubrió que son costosas, especialmente cuando aumentan las presiones del proyecto. La NASA descubrió que la lectura de código detecta 3,3 defectos por hora de esfuerzo frente a los 1,8 defectos por hora de las pruebas. También encuentra entre un 20% y un 60% más de errores a lo largo de la vida del proyecto que otros tipos de pruebas. Un estudio de 13 revisiones sobre reuniones de revisión descubrió que el 90% de los defectos se encontraron en preparación para la reunión de revisión, mientras que solo alrededor del 10% se encontraron durante la reunión. ^[17]
• Análisis estático (IEEE1028)

Los estudios han demostrado que es necesario utilizar una combinación de estas técnicas para lograr una alta tasa de detección de defectos. Otros estudios demostraron que diferentes personas tienden a encontrar diferentes defectos. Un estudio descubrió que las prácticas de programación extremas de programación en pares , verificación de escritorio , pruebas unitarias , pruebas de integración y pruebas de regresión pueden lograr una tasa de detección de defectos del 90%. ^[16] Un experimento que involucró a programadores experimentados descubrió que, en promedio, pudieron encontrar 5 errores (9 en el mejor de los casos) de 15 errores mediante pruebas. ^[18]

El 80% de los errores tienden a concentrarse en el 20% de las clases y rutinas del proyecto. El 50% de los errores se encuentran en el 5% de las clases del proyecto. IBM pudo reducir los defectos reportados por los clientes en un factor de diez a uno y reducir su presupuesto de mantenimiento en un 45% en su sistema IMS reparando o reescribiendo solo 31 de 425 clases. Alrededor del 20% de las rutinas de un proyecto contribuyen al 80% de los costos de desarrollo. Un estudio clásico de IBM encontró que algunas rutinas propensas a errores de OS/360 eran las entidades más costosas. Tenían alrededor de 50 defectos por cada 1000 líneas de código y arreglarlos cuesta 10 veces lo que se necesitó para desarrollar todo el sistema. ^[18]

Una actividad clave durante la construcción es la integración de rutinas , clases , componentes y subsistemas construidos por separado. Además, puede ser necesario integrar un sistema de software en particular con otros sistemas de software o hardware. Las preocupaciones relacionadas con la integración de la construcción incluyen la planificación de la secuencia en la que se integrarán los componentes , la creación de un andamiaje para respaldar las versiones provisionales del software , la determinación del grado de prueba y el trabajo de calidad realizado en los componentes antes de que se integren y la determinación de los puntos del proyecto en los que se prueban las versiones provisionales del software . ^[1]

Los lenguajes orientados a objetos admiten una serie de mecanismos de tiempo de ejecución que aumentan la flexibilidad y adaptabilidad de los programas, como la abstracción de datos , la encapsulación , la modularidad , la herencia , el polimorfismo y la reflexión . ^{[19] [20]}

La abstracción de datos es el proceso mediante el cual los datos y los programas se definen con una representación similar en forma a su significado, mientras se ocultan los detalles de implementación. ^[21] La investigación académica mostró que la abstracción de datos hace que los programas sean aproximadamente un 30% más fáciles de entender que los programas funcionales. ^[10]

Las afirmaciones son predicados ejecutables que se colocan en un programa y que permiten realizar comprobaciones en tiempo de ejecución del programa. ^[19] El diseño por contrato es un enfoque de desarrollo en el que se incluyen condiciones previas y posteriores para cada rutina. La programación defensiva es la protección de una rutina para que no se interrumpa debido a entradas no válidas. ^[22]

El manejo de errores se refiere a la práctica de programación de anticipar y codificar las condiciones de error que pueden surgir cuando se ejecuta el programa. El manejo de excepciones es una construcción del lenguaje de programación o un mecanismo de hardware diseñado para manejar la ocurrencia de excepciones, condiciones especiales que cambian el flujo normal de ejecución del programa. ^[23] La tolerancia a fallas es una colección de técnicas que aumentan la confiabilidad del software al detectar errores y luego recuperarse de ellos si es posible o contener sus efectos si la recuperación no es posible. ^[22]

La programación basada en estados es una tecnología de programación que utiliza máquinas de estados finitos para describir los comportamientos del programa. ^[22] Un método basado en tablas es un esquema que utiliza tablas para buscar información en lugar de utilizar instrucciones lógicas (como if y case). ^[24]

La configuración en tiempo de ejecución es una técnica que vincula los valores de las variables y las configuraciones del programa cuando éste se está ejecutando, generalmente mediante la actualización y lectura de archivos de configuración en un modo justo a tiempo. La internacionalización es la actividad técnica de preparar un programa, generalmente un software interactivo, para que admita múltiples configuraciones regionales. La actividad correspondiente, la localización , es la actividad de modificar un programa para que admita un idioma local específico. ^[24]

• Ingeniería de software
• Desarrollo de software

• Guía del conjunto de conocimientos de ingeniería de software - Versión 2004 Por IEEE Computer Society
• Guía del conjunto de conocimientos de ingeniería de software, versión 3.0, IEEE Computer Society, 2014