Ingeniería del software de sala limpia

Sala limpia es un método de ingeniería de software propuesto en los años 80 por Harlan Mills, es una técnica que puede dar lugar a un software de calidad extremadamente alta. Es un resultado de la combinación del modelo convencional de ingeniería de software, métodos formales, demostraciones de corrección y estadística de especificaciones para el aseguramiento de calidad (SQA).

Emplea la especificación de estructura de cajas para el modelado de análisis y diseño, haciendo hincapié en la verificación de la corrección, más que en la comprobación, como mecanismo fundamental para encontrar y eliminar errores. Se aplica una comprobación estadística de uso para desarrollar la información relativa a la tasa de fallos necesaria para certificar la fiabilidad del producto software. La filosofía de sala limpia es un enfoque riguroso de la ingeniería del software. Se trata de un modelo de proceso del software que hace hincapié en la verificación matemática de la corrección, y en la certificación de la fiabilidad del software. El resultado final es una tasa de fallo extremadamente baja, que sería difícil o imposible de conseguir  empleando métodos menos formales.

Importancia del método de sala limpia.

Los errores conllevan doble trabajo. Trabajar el doble lleva más tiempo y es más caro. ¿No sería maravilloso poder reducir dramáticamente la cantidad de errores (fallos informáticos) que se cometen en el diseño y construcción del software? Esto es lo que promete la ingeniería del software de sala limpia.

Cuando el software falla en el mundo real, suelen abundar los peligros a largo plazo así como los peligros inmediatos. Los peligros pueden estar relacionados con la seguridad humana, con pérdidas económicas o con el funcionamiento efectivo de una infraestructura social y de negocios. La ingeniería del software de sala limpia es un modelo de proceso que elimina los defectos antes de que puedan dar lugar a riesgos graves.

En la aplicación de este método de sala limpia se realizan las siguientes tareas:
Planificación de Incrementos. Permite calidad temprana y continua interacción con el usuario. Facilita mejoras de proceso mientras el desarrollo progresa. El acercamiento incremental evita los riesgos inherentes integración tardía en el ciclo de desarrollo.

 Recolección de requisitos. El propósito del proceso del análisis de requisitos es :

• Definir requisitos para el producto de software, incluyendo función, uso, ambiente, y funcionamiento. 
• Obtener un acuerdo con el cliente en los requisitos como la base para la función y especificación del uso.

 Especificación de la estructura de cajas. Tres tipos especiales de funciones matemáticas son importantes en el desarrollo a Sala limpia, debido a su correspondencia y correlación en el proceso de descomposición y verificación. Estas funciones son conocidas como la caja negra, la caja de estado y caja limpia. En la estructura de las cajas se pueden aplicar una variedad de estrategias de descomposición, además se puede incluir funcionabilidad y orientación a objeto.

 Diseño Formal. Mediante el uso del enfoque de estructura de cajas, el diseño de sala limpia es una extensión natural y sin discontinuidades de la especificación. Dan los objetivos, los participantes, los criterios de entrada, las tareas, la verificación, las medidas y los criterios comunes de la salida en los procesos, así como elementos de proceso común.

Verificación de Corrección. El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de verificación de corrección aplicadas primero al diseño y después al código. El propósito del proceso de la verificación de la corrección, es verificar la corrección del incremento del software usando técnicas matemáticas.

Generación de Código, inspección y verificación. Las especificaciones de estructura de caja que se representan mediante un lenguaje especializado se traducen la lengua de programación más adecuada. 

Planificación de la comprobación estadística, Comprobación estadística de utilización y Certificación. El propósito del proceso estadístico de prueba y de certificación es demostrar la aptitud del software para el uso en un experimento estadístico formal. La "aptitud para el uso" se define con respecto a los modelos de uso y a las metas de la certificación empleados en el proceso de prueba. Las metas de certificación, primero establecidas en el plan de medida y refinadas en el plan de prueba de incremento, se pueden expresar en términos tales como índice de confiabilidad del software.

Cajas utilizadas en el modelo.

Caja negra

 Es una abstracción que describe la forma en que un sistema responde a unos estímulos. Las abstracciones de datos, las operaciones que manipulan estas abstracciones, se ven encapsuladas por la caja negra. Al igual que una jerarquía de clases, la especificación de caja negra puede mostrara las jerarquías de utilización en que las cajas de nivel inferior heredan las propiedades de las cajas de nivel inferior dentro de la estructura de árbol.

Caja de estado

Es una generalización sencilla de una máquina de estado. Un estado es algún modo observable de comportamiento del sistema. A medida que se produce el procesamiento, el sistema va respondiendo a sucesos (estímulos) efectuando una transición que parte del estado actual y llega a algún nuevo estado. A medida que se efectúa la transición, puede producirse una acción.

Utiliza una abstracción de datos para determinar la transición al estado siguiente, y la acción (respuesta) que se producirá como consecuencia de la transición.

La caja de estado contiene una caja negra.

Caja transparente
Está íntimamente relacionada con el diseño de procedimientos y con la programación estructurada. Es importante tener en cuenta que la especificación de procedimientos descrita en la jerarquía de caja transparente se puede demostrar a efectos de corrección. 

Refinamiento de la estructura de cajas

No ha alcanzado la mayor simpatía quizás por tres razones:

• La creencia de que es muy teórica y radical para aplicarla en un proyecto de software real.
• No promueve una revisión unitaria (modular o por clases) sino un control estadístico de calidad.
• Requiere revisiones muy rigurosas en cada etapa del ciclo, y la industria del software no ha alcanzado tal madurez.