La utilización
integrada del modelado de ingeniería del software convencional,
métodos formales, verificación de programas (demostraciones de corrección)
y estadística SQA se han combinado en una técnica que puede dar lugar a un
software de calidad extremadamente alta. La ingeniería del software de sala
limpia es un enfoque que hace hincapié en la necesidad de incluir la corrección
en el software a medida que éste se desarrolla. En lugar del ciclo clásico de
análisis, diseño, pruebas y depuración, el enfoque de sala limpia sugiere un
punto de vista distinto :
La filosofía que subyace tras la ingeniería del software de sala limpia
consiste en evitar la dependencia de costosos procesos de eliminación de
defectos, mediante la escritura de incrementos de código desde un primer
momento, y mediante la verificación de su corrección antes de las
pruebas. Su modelo de proceso incluye la certificación estadística de
calidad de los incrementos de código, a medida que estos se van añadiendo
con el sistema.
En muchos aspectos, el enfoque de
sala limpia eleva la ingeniería del software a otro nivel. Al igual que las
técnicas de métodos formales que se presentaban en el Capítulo 25, el proceso
de sala limpia hace hincapié en el rigor en la especificación y en el diseño, y
en la verificación formal de cada uno de los elementos del modelo de diseño
Resultante mediante el uso de pruebas de corrección basadas en fundamentos
matemáticos. Al extender el enfoque adoptado en los métodos formales, el
enfoque de sala limpia hace hincapié también en técnicas de control estadístico
de calidad, incluyendo las comprobaciones basadas en el uso anticipado del
software por parte de los clientes.
EL ENFOQUE DE SALA LIMPIA.
La filosofía de la «sala limpian en
las técnicas de fabricación de hardware es en realidad algo bastante sencillo:
se trata de una forma rentable y
eficiente, en términos de tiempo, de establecer un enfoque de fabricación que
impida la introducción de defectos de producción. En lugar de fabricar un
producto y dedicarse después a eliminar defectos, el enfoque de sala limpia
demanda la disciplina necesaria para eliminar errores en las especificaciones y
en el diseño, fabricando entonces el producto de forma «limpia».
La filosofía de sala limpia fue
propuesta por primera vez para la ingeniería del software por parte de Mills y
sus colegas durante los años 80. Aun cuando las primeras experiencias
acerca de este enfoque disciplinado para los trabajos relacionados con el
software mostraba promesas significativas , no ha alcanzado una amplia
utilización. Henderson sugiere tres posibles razones:
1- La creencia en que la
metodología de sala limpia es excesivamente teórica, excesivamente matemática y
excesivamente radical para utilizarla en el desarrollo de software real.
2- No propugna una comprobación
unitaria por parte de los desarrolladores, sino que la sustituye por una
verificación de la corrección y por un control estadístico de la calidad -estos
conceptos que representan una desviación fundamental con respecto a la forma en
que se desarrolla la mayor parte del software en la actualidad-.
3- La madurez de la industria de
desarrollo del software. El uso de procesos de sala limpia requiere una
aplicación rigurosa de procesos definidos en todas las fases del ciclo de vida.
Dado que la mayor parte de la industria funciona todavía en el nivel ad hoc
(según se ha definido por parte del Software Engineering Institute Capability
Maturity Model), la industria no ha estado preparada para aplicar estas
técnicas.
Aun cuando existen ciertos indicios
de verdad en todas las indicaciones expresadas anteriormente, los posibles
beneficios de la ingeniería del software de sala limpia compensan más que
sobradamente la inversión requerida para superar la resistencia cultural que se
encuentra en el núcleo de estas objeciones.
La estrategia de sala limpia:
El enfoque de sala limpia hace uso
de una versión especializada del modelo incremental de software. Se desarrolla
un «cauce de incrementos de software» por parte de equipos de ingeniería
del software pequeños e independientes. A medida que se va certificando cada incremento, se integra en el todo.
Consiguientemente, la funcionalidad del sistema va creciendo con el tiempo.
Los requisitos globales del sistema
o producto se van desarrollando empleando los métodos de ingeniería de
sistemas. Una vez que se ha asignado una funcionalidad al elemento de software
del sistema, el tubo de la sala limpia comienza sus incrementos. Se producen
las tareas siguientes:
Planificación de incrementos. Se desarrolla un plan de proyecto que
adopta la estrategia incremental. Se van estableciendo las funcionalidades de
cada uno de los incrementos, su tamaño estimado y un plan de desarrollo de sala
limpia. Es preciso tener especial cuidado para asegurar que los incrementos
certificados se vayan integrando de forma temporalmente oportuna.
Recolección de requisitos. Mediante el uso de técnicas similares a las presentadas en el Capítulo
1 1, se desarrolla una descripción más detallada de requisitos del nivel del
usuario (para cada incremento).
Especificación de la estructura de
cajas. Se utiliza un método de especificación que hace uso de estructuras de
caja para describir la especificación funcional.
Ajustado a los principios de
análisis operacional, la estructura de caja «aísla y separa la definición
creativa del comportamiento, de los datos, y de los procedimientos para cada
nivel de refinamiento».
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.
Aun cuando es posible efectuar una distinción clara entre estas dos
actividades, las especificaciones (que se denominan «cajas negras>>)s e
refinan iterativamente (dentro de cada incremento) para transformarse en diseños
análogos a la arquitectura y a los procedimientos (que se denominan «cajas de
estado» y «cajas trasparentes», respectivamente).
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. La verificación comienza con la estructura de cajas del más alto
nivel (la especificación) y avanza hacia el detalle de diseño y el código. El
primer nivel de verificación de corrección se lleva a cabo aplicando un
conjunto de cuestiones de corrección» [LIN88]. Si este conjunto de preguntas no
demuestra que la especificación es correcta, se utilizan métodos más formales
(matemáticos) de verificación.
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 al lenguaje
de programación adecuado. Se utilizan entonces técnicas estándar de recorrido o
de inspección para asegurar el cumplimiento semántico de las estructuras de
código y de cajas, y la corrección sintáctica de código. A continuación, se
efectúa una verificación de corrección para el código fuente.
Planificación de la comprobación estadística. La utilización estimada del software se analiza, se planifica y se
diseña un conjunto de casos de prueba que ejerciten la «distribución de
probabilidad» de esa utilización. Según se muestra en la, esta actividad de
sala limpia se realiza en paralelo con la especificación, la verificación y la
generación de código.
Comprobación estadística de
utilización. Recordando que es imposible una comprobación
exhaustiva del software de computadora, siempre resulta necesario diseñar un
conjunto finito de casos de prueba. Las técnicas estadísticas de utilización ejecutan
una colección de pruebas derivadas de una muestra estadística (la distribución
de probabilidad indicada anteriormente) de todas las posibles ejecuciones del
programa por parte de todos los usuarios de una cierta población objetivo.
Certificación. Una vez que se ha finalizado la verificación, la
inspección y la comprobación de utilización (y después de corregir todos los
errores) se certifica el incremento como preparado para su integración.
Al igual que otros modelos de proceso del software descritos en otras partes de
este libro, el proceso de sala limpia hace especial hincapié en la necesidad de
conducir unos modelos de análisis y de diseño de muy alta calidad. Según se
verá posteriormente en este capítulo, la notación de estructura de cajas no es
más que otra forma para que el ingeniero del software pueda representar los
requisitos y el diseño. La distinción real del enfoque de sala limpia consiste
en que se aplica la verificación formal a los modelos de ingeniería.
