Construcción de software

A continuación se presentan algunos de los aspectos clave de la actividad de codificación : ^{[ 2 ]}

Nomenclatura

Elección del nombre para cada identificador. 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. ^{[ 3 ]}

Lógica

Organización en declaraciones y rutinas ^{[ 4 ]}

• Las rutinas con alta cohesión demostraron ser menos propensas a errores que las rutinas con menor cohesión. Un estudio de 450 rutinas reveló que el 50 % de las rutinas con alta cohesión no presentaban fallos, en comparación con solo el 18 % de las rutinas con baja cohesión. Otro estudio de 450 rutinas diferentes halló que las rutinas con las mayores relaciones de acoplamiento a cohesión presentaban 7 veces más errores que aquellas con las menores relaciones de acoplamiento a cohesión, y su corrección resultaba 20 veces más costosa.
• Aunque los estudios mostraron resultados inconclusos respecto a la correlación entre el tamaño de las rutinas y la tasa de errores, un estudio reveló que corregir rutinas con menos de 143 líneas de código resultaba 2,4 veces menos costoso que corregir rutinas más extensas. Otro estudio demostró que el código requería menos modificaciones cuando las rutinas tenían un promedio de entre 100 y 150 líneas. Un tercer estudio halló 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 algunas de las áreas más propensas a errores en un programa. Un estudio demostró que el 39 por ciento de todos los errores se debían a fallos de comunicación entre rutinas.
• Los parámetros no utilizados se correlacionan con una mayor tasa de errores. En un estudio, solo entre el 17 y el 29 por ciento de las rutinas con más de una variable sin referencia no presentaron 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 no debería superar los 7, ya que las investigaciones han demostrado que, por lo general, las personas no pueden recordar más de siete fragmentos de información a la vez.
• Un experimento demostró que los diseños que acceden a los arreglos de forma secuencial, en lugar de aleatoria, dan como resultado menos variables y menos referencias a variables. ^{[ 5 ]}
• Un experimento encontró que los bucles con salida son más comprensibles que otros tipos de bucles. ^{[ 6 ]}
• En cuanto al nivel de anidamiento en bucles y condicionales, los estudios han demostrado que los programadores tienen dificultades para comprender más de tres niveles de anidamiento. ^{[ 6 ] [ 7 ]}
• Se ha demostrado que la complejidad del flujo de control se correlaciona con una baja fiabilidad y errores frecuentes. ^{[ 7 ]}

Modularidad

Estructurar y refactorizar el código en clases , paquetes y otras estructuras. Al considerar la contención , el número máximo de miembros de datos en una clase no debe exceder 7±2. La investigación ha demostrado que este número es la cantidad 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 encontrado que los árboles de herencia profundos están significativamente asociados con mayores tasas de fallas. 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 fallas. ^{[ 8 ]} Un estudio de la NASA mostró 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. ^{[ 8 ] [ 4 ]}

Manejo de errores

Lógica de codificación para gestionar errores y excepciones , tanto planificados como no planificados .

Gestión de recursos

Gestionar el uso de los recursos computacionales mediante mecanismos de exclusión y disciplina en el acceso a recursos reutilizables en serie, incluidos los subprocesos o los bloqueos de bases de datos .

Seguridad

Prevención de fallos de seguridad a nivel de código, como desbordamientos de búfer y de índices de matrices .

Mejoramiento

Optimización evitando la optimización prematura .

Documentación

Tanto integrados en el código como comentarios como documentos externos .

La integración consiste en combinar partes construidas por separado. Entre las consideraciones se incluyen la planificación de la secuencia en la que se integrarán los componentes , la creación de una estructura que dé soporte a las versiones intermedias del software, la determinación del grado de pruebas y el trabajo de calidad que se realizará en los componentes antes de su integración, y la determinación de los puntos del proyecto en los que se probarán las versiones intermedias. ^{[ 1 ]}

Las pruebas pueden reducir el tiempo entre la inserción de lógica defectuosa en el código y su detección. En algunos casos, las pruebas se realizan después de que se ha escrito el código, pero en la programación basada en pruebas , los casos de prueba se crean antes de escribir el código. La construcción incluye al menos dos formas de prueba, a menudo realizadas por el desarrollador que escribió el código: ^{[ 1 ]} pruebas unitarias y pruebas de integración .

La reutilización de software implica más que crear y usar bibliotecas . 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 pueden incluir: ^{[ 1 ]} selección del código reutilizable, evaluación de la reutilización del código o de las pruebas, informes de métricas de reutilización.

Las técnicas para garantizar la calidad durante la construcción del software incluyen: ^{[ 9 ]}

Pruebas

Un estudio encontró que las tasas promedio de detección de defectos de las pruebas unitarias y las pruebas de integración son del 30% y del 35% respectivamente. ^{[ 10 ]}

Inspección de software

Con respecto a la inspección de software , un estudio encontró que la tasa promedio de detección de defectos de las inspecciones formales de código es del 60%. En cuanto 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 usando pruebas que usando 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 15-25 horas a través de pruebas. Microsoft ha encontrado que se necesitan 3 horas para encontrar y corregir un defecto usando inspecciones de código y 12 horas para encontrar y corregir un defecto usando pruebas. En un programa de 700 mil líneas, se informó que las revisiones de código fueron varias veces más rentables que las pruebas. ^{[ 10 ]} Los estudios encontraron que las inspecciones resultan en 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 suelen representar entre el 10 % y el 15 % del presupuesto del proyecto y reducen el costo total del mismo. Los investigadores descubrieron que contar con más de dos o tres revisores en una inspección formal no aumenta el número de defectos detectados, aunque los resultados parecen variar según el tipo de material inspeccionado. ^{[ 11 ]}

Revisión técnica

Con respecto a la revisión técnica , un estudio encontró que las tasas promedio de detección de defectos de las revisiones informales de código y la verificación de escritorio son del 25 % y el 40 % respectivamente. ^{[ 10 ]} Se encontró que los recorridos tenían una tasa de detección de defectos del 20 % al 40 %, pero también se encontró que eran costosos, especialmente cuando aumenta la presión del proyecto. La NASA encontró que la lectura de código detectaba 3,3 defectos por hora de esfuerzo frente a 1,8 defectos por hora para las pruebas. También encontró entre un 20 % y un 60 % más de errores a lo largo de la vida del proyecto que diferentes tipos de pruebas. Un estudio de 13 revisiones sobre reuniones de revisión, encontró que el 90 % de los defectos se encontraron en la preparación para la reunión de revisión, mientras que solo alrededor del 10 % se encontraron durante la reunión. ^{[ 11 ]}

Análisis estático

Con respecto al análisis estático (IEEE1028), los estudios han demostrado que se necesita una combinación de estas técnicas para lograr una alta tasa de detección de defectos. Otros estudios mostraron que diferentes personas tienden a encontrar diferentes defectos. Un estudio encontró que las prácticas de programación extrema de programación en parejas , verificación manual , pruebas unitarias , pruebas de integración y pruebas de regresión pueden lograr una tasa de detección de defectos del 90 %. ^{[ 10 ]} Un experimento con programadores experimentados encontró que, en promedio, pudieron encontrar 5 errores (9 como máximo) de 15 errores mediante pruebas. ^{[ 12 ]}

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 logró reducir los defectos reportados por el cliente en un factor de diez a uno y disminuir su presupuesto de mantenimiento en un 45% en su sistema IMS reparando o reescribiendo solo 31 de las 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 descubrió que unas pocas 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 corregirlos costaba 10 veces más que desarrollar todo el sistema. ^{[ 12 ]}

Para tener en cuenta las deficiencias imprevistas en el diseño del software , se pueden realizar modificaciones de diseño durante la construcción. ^{[ 13 ]}

La minimización de la complejidad de la programación se debe principalmente a la limitada capacidad de las personas para procesar eficazmente información compleja. La complejidad puede reducirse mediante técnicas de calidad centradas en la construcción . ^{[ 16 ]}

Anticipar los cambios ayuda a los desarrolladores a crear software extensible : código que puede mejorarse sin alterar el diseño inherente. ^{[ 16 ]} Investigaciones realizadas durante más de 25 años demuestran que el costo de la reelaboración puede ser de 10 a 100 veces (de 5 a 10 veces para proyectos más pequeños) mayor que el de cumplir correctamente con los requisitos desde el principio. 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 pone de manifiesto la importancia de anticipar los cambios. ^{[ 17 ]}

Construir para la verificación significa construir software de tal manera que los desarrolladores puedan detectar fácilmente los fallos, así como durante las pruebas independientes y las actividades operativas. Algunas técnicas específicas que apoyan la construcción para la verificación incluyen seguir estándares de codificación para facilitar las revisiones de código , realizar pruebas unitarias , organizar el código para facilitar las pruebas automatizadas y restringir el uso de estructuras de lenguaje complejas o difíciles de entender , entre otras. ^{[ 16 ]}

La ocultación de información demostró ser una técnica de diseño útil en programas grandes, ya que facilitó su modificación en un factor de 4. El bajo factor de ramificación es una de las características de diseño que los investigadores consideran beneficiosas. ^{[ 18 ]}

La reutilización de software puede generar importantes beneficios en términos de productividad, calidad y costos. Los principales beneficios se obtienen al reutilizar los activos de software existentes, y esta reutilización se ve respaldada por la creación de software diseñado para su futura reutilización. ^{[ 16 ]}

Las normas, ya sean externas (creadas por organizaciones internacionales) o internas (creadas a nivel corporativo), que afectan directamente a los problemas de construcción incluyen: ^{[ 16 ]}

• Estándares de documentación en cuanto a formato y contenido.
• Estándares de modelado como UML
• Estándares de codificación

La abstracción de datos es una característica del código fuente que representa la información de una forma similar a su significado, ocultando los detalles de implementación. ^{[ 19 ]} La investigación académica demostró que la abstracción de datos hace que los programas sean aproximadamente un 30 % más fáciles de entender que los programas funcionales. ^{[ 8 ]}

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 . ^{[ 20 ] [ 21 ]}

La programación defensiva es la protección de una rutina para evitar que se rompa por entradas no válidas. ^{[ 22 ]} Las aserciones son predicados ejecutables que se colocan en un programa y permiten realizar comprobaciones del programa en tiempo de ejecución. ^{[ 20 ]} El diseño por contrato es un enfoque de desarrollo en el que se incluyen precondiciones y postcondiciones para cada rutina.

El manejo de errores se refiere a la práctica de codificar las condiciones de error que pueden surgir durante la ejecución de un 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 alteran el flujo normal de ejecución del programa. ^{[ 23 ]} La tolerancia a fallos es un conjunto de técnicas que aumentan la fiabilidad del software mediante la detección de errores y la recuperación de los mismos, si es posible, o la contención de sus efectos si la recuperación no es posible. ^{[ 22 ]}

La programación basada en estados consiste en utilizar una máquina de estados finitos para implementar la lógica. ^{[ 22 ]}

La lógica basada en tablas utiliza información formateada como una tabla para dirigir la ejecución. ^{[ 24 ]}

La configuración en tiempo de ejecución es una técnica que vincula los valores de las variables y la configuración del programa mientras este se está ejecutando, generalmente mediante la actualización y lectura de archivos de configuración.

La internacionalización y localización es la actividad de preparar un programa para apoyar múltiples localidades y brindar apoyo a diversas localidades. ^{[ 24 ]}