El software: naturaleza y calidad

Capítulo 2

El software: naturaleza y calidad.

El objetivo de cada actividad de ingeniería es construir algo, un artefacto o un producto; de modo que el ingeniero civil construye un puente, el ingeniero aeroespacial un avión, el ingeniero electrónico un circuito. El producto de ingeniería de software es un sistema de software: no es tan tangible como los otros, pero sin embargo es un artefacto capaz de responder a una función de uso específica.

La característica que quizás más distingue al software de otros productos es el hecho de que es "dúctil": es decir, es posible modificar el producto en lugar de modificar el proyecto muy fácilmente y esto lo hace sustancialmente diferente de otros productos, como automóviles u hornos.

Esta peculiaridad del software es a menudo mal utilizada. Aunque es posible modificar un puente o un avión para satisfacer nuevas necesidades (por ejemplo, ajustar el puente al flujo de tráfico en aumento o permitir que un avión transporte más mercancías) este cambio nunca se realiza a la ligera, y ciertamente no se intenta sin reelaborar primero el proyecto y verificar el impacto del cambio en profundidad. En contraste, a los ingenieros de software a menudo se les exige hacer cambios sustanciales. La ductilidad del software lleva a pensar que hacer cambios es trivial, pero en la práctica no lo es. Es fácil cambiar el código a través de un editor de texto, pero no es fácil asegurarse de que el software cumpla con las necesidades para las que se requirió un cambio. Por lo tanto, es bueno que el software se trate a la par con otros productos de ingeniería: un cambio en el software debe verse como un cambio en el proyecto en lugar de en el código. Una propiedad como la ductilidad se puede explotar ventajosamente, pero debe hacerse con disciplina.

Otra característica del software es que su creación es intensiva en humanos, es decir, requiere una gran intensidad de trabajo; En esencia, requiere una "ingeniería" en lugar de una actividad de "fabricación". En la mayoría de las otras disciplinas, el proceso de fabricación determina el costo final del producto; Además, el proceso de producción debe gestionarse de manera precisa, de modo que no se introduzcan defectos no deseados en el producto. Las mismas consideraciones se aplican a los productos de hardware, mientras que, para el software, la fabricación se reduce a un proceso de duplicación trivial. El proceso de producción del software consiste esencialmente en el diseño y la implementación, no en la fabricación. Este proceso debe cumplir con los criterios apropiados que aseguran la producción de software de alta calidad. Es deseable que un producto cumpla ciertas necesidades y cumpla con los estándares de aceptación que prescriben las cualidades que debe poseer. Por ejemplo, la funcionalidad de un puente es facilitar la conexión de un lugar a otro; Una de las cualidades esperadas es que esto no se colapsa en presencia de vientos muy fuertes o cuando es atravesado por una fila de camiones.

En las disciplinas de la ingeniería tradicional, el ingeniero tiene herramientas para describir las cualidades del producto de una manera distinta del diseño del producto en sí. En ingeniería de software, esta distinción no es tan clara: las cualidades de un producto de software a menudo se mezclan en especificaciones, junto con las cualidades intrínsecas del proyecto.

En este capítulo examinaremos las cualidades relevantes de los productos de software y los procesos de producción de software. Estas cualidades se convertirán en nuestros objetivos a perseguir en la práctica de la ingeniería de software. En el siguiente capítulo presentaremos los principios de ingeniería de software aplicables para lograr estos objetivos. También es importante verificar y medir la presencia de la calidad: estos temas se presentan en la Sección 2.4 y se analizan en el Capítulo 6.

2.1 Clasificación de las cualidades del software.

Hay muchas cualidades deseables para el software; Algunos se aplican tanto al producto como al proceso utilizado para su desarrollo.

El usuario requiere que el producto de software sea confiable, eficiente y fácil de usar. El fabricante de software desea que sea verificable, mantenible, portátil y extensible.

El gerente de un proyecto de software desea que el proceso de desarrollo sea productivo, predecible y fácil de controlar. En esta sección analizaremos dos clasificaciones diferentes de cualidades relacionadas con el software: cualidades internas y cualidades externas, por un lado, y calidad del producto y calidad del proceso, por el otro.

2.1.1 Cualidades internas y externas

Podemos dividir la calidad del software en dos categorías: interna y externa. Las cualidades externas son visibles para los usuarios del sistema, mientras que las cualidades internas afectan a los desarrolladores.

En general, los usuarios de software solo están interesados ​​en cualidades externas, pero son cualidades internas, que en gran medida tienen que ver con la estructura del software, para ayudar a los desarrolladores a lograr cualidades externas. Por ejemplo, la calidad interna de verificabilidad es necesaria para obtener la calidad externa de confiabilidad. En muchos casos, sin embargo, las cualidades están estrechamente relacionadas entre sí y la distinción entre cualidades internas y externas no está tan marcada.

2.1.2 Calidad del proceso y calidad del producto.

Se utiliza un proceso para hacer un producto de software. Es posible atribuir ciertas cualidades a un proceso, incluso si las cualidades del proceso a menudo se correlacionan con las del producto. Por ejemplo, la confiabilidad de un producto aumenta si el proceso relacionado requiere una planificación cuidadosa de los datos de prueba antes de que se lleve a cabo una actividad de diseño y desarrollo del sistema. Al abordar la calidad del software, es bueno tratar de distinguir entre la calidad del proceso y la calidad del producto.

El término producto generalmente se refiere a lo que finalmente se entrega al cliente. Aunque esta es una definición aceptable desde el punto de vista del cliente, no es correcta para el desarrollador, ya que el desarrollador produce una serie de productos intermedios durante el proceso de desarrollo. El producto que realmente es visible para el cliente es el código ejecutable y los manuales de usuario, pero el desarrollador produce una gran cantidad de otros artefactos, como documentos de especificación y especificación del proyecto, datos de prueba, etc. Utilizaremos el término artefacto para denotar estos productos intermedios y para distinguirlos del producto final entregado al cliente. Estos productos intermedios a menudo están sujetos a los mismos requisitos de calidad que el producto final. Como hay muchos productos intermedios, es posible que diferentes subconjuntos de estos puedan ponerse a disposición de diferentes clientes.

Por ejemplo, un fabricante de computadoras podría vender a una empresa de fabricación de sistemas de control de procesos el código objeto que debe instalarse en el hardware especializado de una aplicación integrada; esto podría luego distribuir el código objeto y los manuales del usuario a los revendedores de software. Finalmente, podría vender el proyecto y el código fuente a los productores de software, quienes podrían modificarlos para construir otros productos.

La gestión de la configuración es la parte del proceso de producción del software que aborda el problema de mantener y controlar las relaciones entre los diferentes productos intermedios de las distintas versiones de un producto.

Las herramientas de gestión de la configuración admiten el mantenimiento de las familias de productos y sus componentes y ayudan a controlar y gestionar los cambios en los productos intermedios. Discutiremos la actividad de gestión de la configuración en el Capítulo 7.

2.2 Principales cualidades del software.

En esta sección presentamos las cualidades más importantes de los productos y procesos de software; En su caso, analizamos una calidad con referencia a las clasificaciones que hemos descrito en el párrafo anterior.

2.2.1 Corrección, fiabilidad y robustez.

Los términos corrección, confiabilidad y robustez están estrechamente relacionados y juntos caracterizan una calidad de software según la cual la aplicación realiza la funcionalidad esperada. Veamos ahora estos tres términos en detalle, analizando sus relaciones mutuas.

2.2.1.1 corrección

Un programa debe cumplir con la especificación de sus requisitos funcionales (requisitos de especificación); sin embargo, existen otros requisitos, los de rendimiento y escalabilidad, que no se refieren a las funcionalidades del sistema; estos se denominan requisitos no funcionales (requisitos no funcionales). Un programa es funcionalmente correcto si se comporta de acuerdo con lo establecido por las especificaciones funcionales. A menudo, el término "correcto" se usa en lugar de "funcionalmente correcto", y de manera similar, en este contexto se usa el término "especificaciones" en lugar de "especificaciones de requisitos funcionales". Seguiremos esta convención cuando el contexto sea claro.

La definición de corrección supone que las especificaciones del sistema están disponibles y que es posible determinar sin ambigüedad si un programa cumple con las especificaciones. Estas especificaciones rara vez están disponibles para la mayoría de los sistemas de software existentes. Si existe una especificación, normalmente se escribe en lenguaje no formal usando lenguaje natural; por lo tanto es probable que contenga ambigüedad. Sin embargo, la definición de corrección es útil porque captura un objetivo deseable de los sistemas de software.

...