miércoles, 8 de diciembre de 2010 | By: Wynnie Calero

Sala limpia


A.   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 mostraban promesas significativas, no ha alcanzado una amplia utilización. Henderson sugiere tres posibles razones:

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.

·        * 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
·         .
·        * 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.

La sucesión de tareas de sala limpia para cada incremento se ilustra en la Figura 26.1. 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: 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.



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 «ca.jas 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». 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 sarmático 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 Figura 26.1, 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.

¿Qué hace diferente la sala limpia?

Dyer alude a las diferencias del enfoque de sala limpia cuando define el proceso: La sala limpia representa el primer intento práctico de poner el proceso de desarrollo del software bajo un control estadístico de calidad con una estrategia bien definida para la mejora continua del proceso. Para alcanzar esta meta, se definió un ciclo único de vida de sala limpia, que hacía hincapié en una ingeniería del software basada en las matemáticas para obtener diseños de software correctos y que se basaba en software basado en estadística para la certificación de fiabilidad de ese software. La ingeniería del software de sala limpia difiere de los puntos de vista convencionales y orientados a objetos que se representan porque:
 
  • Hace uso explícito del control estadístico de calidad.
  • Verifica la especificación del diseño empleando una demostración de corrección basada en las matemáticas. 
  • Hace mucho uso de la comprobación estadística de utilización para descubrir errores de especial incidencia.

Evidentemente, el enfoque de sala limpia aplica la mayor parte, si es que no todos, de los principios básicos de ingeniería del software y de los conceptos que se han presentado a lo largo de este libro. Son esenciales unos buenos procedimientos de análisis y diseño si es que se desea producir una elevada calidad. Pero la ingeniería de sala limpia diverge de las prácticas de software convencionales al quitar importancia (hay quien diría eliminar) al papel de las pruebas de unidad y a la depuración y al reducir dramáticamente (o eliminar) la cantidad de comprobaciones que son realizadas por quien desarrolla el software. En el desarrollo convencional del software, los errores se aceptan como cosas que pasan. Dado que se considera que los errores son inevitables, cada módulo del programa debe ser comprobado unitariamente (para descubrir los errores) y depurado después (para eliminar los errores). Cuando se publica finalmente el software, la utilización práctica descubre aun más defectos, y comienza otro ciclo de comprobación y depuración. Este trabajo repetido asociado a las actividades mencionadas resulta costoso y lleva mucho tiempo. Y lo que es peor, puede ser degenerativo; la corrección de errores puede (inadvertidamente) dar lugar a la introducción de otros errores.

En la ingeniería del software de sala limpia, la comprobación unitaria y la depuración se ven sustituidas por una verificación de corrección y por pruebas basadas en la estadística. Estas actividades, junto con el mantenimiento de registros para una continua mejora, hacen que el enfoque de sala limpia sea único.

  1. Especificación funcional

Independientemente del método de análisis seleccionado, los principios de operación siempre serán aplicables. Se modelan los datos, las funciones y el comportamiento. Los modelos resultantes deben de ser descompuestos (refinados) para proporcionar un grado de detalle cada vez más elevado. El objetivo global consiste en pasar de una especificación que captura la esencia de un problema, a una especificación que proporciona una cantidad de detalle sustancial para su implementación.

La ingeniería del software de sala limpia satisface los principios de análisis operacional por cuanto emplea un método denominado especificación de estructura de caja Una “caja” encapsula el sistema (o algún aspecto del sistema) con un cierto grado de detalle. Mediante un proceso de refinamiento progresivo, se van refinando las cajas para formar una jerarquía en la cual cada caja tiene transparencia referencial. Esto es, «el contenido de información de cada especificación de caja basta para definir su refinamiento, sin depender de la implementación de ninguna otra caja». Esto capacita al analista para desglosar jerárquicamente el sistema, pasando de la representación esencial situada en la parte superior, hasta los detalles específicos de la implementación situados en la parte inferior. Se utilizan tres tipos de cajas:

Caja negra: Esta caja especifica el comportamiento del sistema, o de parte de un sistema. El sistema (o parte de él) responde a estímulos específicos (sucesos) mediante la aplicación de un conjunto de reglas de transición que hacen corresponder el estímulo con la respuesta.

Caja de estado: Esta caja encapsula los datos de estados y de servicios (operaciones) de forma análoga a los objetos. En esta vista de especificación, se representan las entradas de la caja de estados (los estímulos) y sus salidas (las respuestas). La caja de estados también representa la «historia de estímulos» de la caja negra, es decir, los datos encapsulados en la caja de estado que deben ser mantenidos entre las transiciones implicadas

Caja limpia: Las funciones de transición que están implicadas en la caja de estado se definen en la caja limpia. Dicho literalmente, la caja limpia contiene el diseño procedimental correspondiente a la caja de estados.


La Figura 26.2 ilustra el enfoque de refinamiento mediante el uso de una especificación de estructura de cajas. Una caja negra (CN,) define las respuestas de todo un conjunto completo de estímulos. CN, se puede refinar en un conjunto de cajas negras, desde CN, , hasta CN, ,,,cada una de las cuales aborda una cierta clase de comportamiento. El refinamiento prosigue hasta que se identifique una clase cohesiva de comportamiento (por ejemplo, CN, , ,). A continuación, se define una caja de estado (CE, , ,) para la caja negra (CN, , ,). En este caso, CE, ,, , contiene todos los datos y servicios necesarios para implementar el comportamiento definido por CN, ! ,. Por último, se refina CE, , , para formar un conjunto de cajas transparentes (CT, , , ") y se especifican los detalles de diseño de procedimientos.

A medida que se va realizando cada uno de estos pasos de refinamiento, se produce también una verificación de la corrección. Se verifican las especificaciones de las cajas de estado para asegurar que todas y cada una de ellas se ajustan al comportamiento definido por la especificación de la caja negra predecesora. De manera similar, se verifican las especificaciones de las cajas transparentes con respecto a la caja de estados predecesora.

Es preciso tener en cuenta que los métodos de especificación basados en métodos formales  se pueden utilizar en lugar del enfoque de especificación de estructura de cajas. El único requisito es que se puede verificar formalmente cada uno de los niveles de especificación.


Una especificación de caja negra describe una abstracción, estímulos y respuestas empleando la notación que se muestra en la Figura 26.3 La función f' se aplica a una secuencia, S*, de entradas (estímulos) y esta función los transforma en una salida (respuesta), R. Para componentes sencillos de software, f; puede ser una función matemática, pero en genera1,f se describe empleando el lenguaje natural (o bien un lenguaje de especificación formal).

Muchos de los conceptos introducidos para sistemas orientados a objetos son aplicables también para la caja negra. Las abstracciones de datos y 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 mostrar las jerarquías de utilización en que las cajas de nivel inferior heredan las propiedades de las cajas de nivel superior dentro de la estructura de árbol.

Especificación de caja de estado

La caja de estado es «una generalización sencilla de una máquina de estado». Recordando la descripción del modelado de comportamiento y de los diagramas de transición de estados, 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 y llega a algún nuevo estado. A medida que se efectúa la transición, puede producirse una acción. La caja de estado utiliza una abstracción de datos para determinar la transición al estado siguiente (respuesta) que se producirá como consecuencia de la transición.







Según se muestra en la Figura 26.4, la caja de estado contiene una caja negra. El estímulo, S, que se introduce en la caja negra, procede de alguna fuente externa y de un conjunto de estados internos del sistema, T. Mills proporciona una descripción matemática de la función,,f, de la caja negra contenida en el seno de la caja de estado:

g:S*xT*+RxT

Donde g es una subfunción que está asociada a un estado específico t. Cuando se consideran en su conjunto, las parejas de estados y subfunciones (t, g) definen la función de caja negra f.

Especificación de sala limpia

La especificación de caja limpia está íntimamente relacionada con el diseño de procedimientos y con la programación estructurada. En esencia, la subfunción g, que se encuentra dentro de la caja de estado, se ve sustituida por las estructuras de programación estructurada que implementa g.

Como ejemplo, considérese la caja limpia que se muestra en la Figura 26.5. La caja negra g, que se muestra en Figura 26.4 se ve sustituida por una sucesión de estructuras que contienen una estructura condicional. Éstas, a su vez, se pueden refinar para formar Lajas transparentes del interior a medida que vaya avanzando el procedimiento de refinamiento progresivo. Es importante tener en cuenta que la especificación de procedimientos descrita en la jerarquía de caja limpia se puede demostrar a efectos de corrección. Este tema se considerará en la sección siguiente.

  1. Refinamiento y verificación del diseño

El enfoque de diseño que se utiliza en la ingeniería del software de sala limpia hace mucho uso de la filosofía de la programación estructurada. Pero, en este caso, la programación estructurada se aplica de forma mucho más rigurosa.






La funciones básicas de procesamiento (que se describían durante los refinamientos anteriores de la especificación) se refinan ahora utilizando una «expansión progresiva de funciones matemáticas en estructuras de conectividad lógica [por ejemplo, si-entonces-sino] y subfunciones, donde la expansión [se] efectúa hasta que todas las funciones identificadas pudieran ser enunciadas directamente en el lenguaje de programación utilizado para la implementación». El enfoque de la programación estructurada se puede utilizar de forma eficiente para refinar la función, pero ¿qué pasa con el diseño de datos'? En este aspecto, entra en juego un cierto número de conceptos fundamentales de diseño. Los datos del programa se encapsulan como un conjunto de abstracciones a las cuales prestan servicio las subfunciones. Los conceptos de encapsulamiento de datos, ocultamiento de información y los tipos de datos se utilizan entonces para crear el diseño de datos.

Refinamiento y verificación del diseño


Cada especificación de caja limpia representa el diseño de un procedimiento (subfunción) necesario para efectuar una transición de caja de estado. Mediante la caja limpia, se utilizan las estructuras de programación estructurada y de refinamiento progresivo según se ilustra en la Figura 26.6. Una función de programa, .f; se refina para dar lugar a una sucesión de subfunciones 8 y h. Éstas a su vez se refinan para formar estructuras condicionales (si-entonces-sino y hacer-mientras). Un refinamiento posterior ilustra la elaboración lógica continuada.





En cada nivel de refinamiento, el equipo de sala limpia  lleva a cabo una verificación formal de corrección. Para lograr esto, se asocia un conjunto de condiciones de corrección genéricas a las estructuras de programación estructurada. Si se expande una función f para dar una sucesión g y h, entonces la condición de corrección para todas las entradas de f es:

  • ¿Es cierto que g seguido por h da lugar a f! Si se refina una función p para llegar a una estructura condicional (si-entonces-sino), la condición de corrección para toda entrada de p es:
  • Siempre que sea cierta la condición (c) es cierto que q realiza p y siempre que (c) sea falsa, es cierto que Y realiza p?
Si se refina una función m en forma de bucle, las condiciones de corrección para todas las entradas de ni son:
  • ¿Está garantizada la finalización?
  • ¿Siempre que (c) sea verdadera es cierto que n seguido por m realiza m, siempre que (c) sea falso, sigue realizándose m si se obvia el bucle?

Cada vez que se refina una caja limpia hasta el siguiente nivel de detalle, se aplican las condiciones de corrección indicadas anteriormente. Es importante tener en cuenta que la utilización de estructuras de programación estructurada restringe el número de comprobaciones de corrección que es preciso efectuar. Se verifica una sola condición en busca de sucesiones; se verifican dos condiciones para los si-entonces-sino; y se verifican tres condiciones para los bucles.

Con objeto de ilustrar alguna verificación de corrección para un diseño de procedimientos, se utiliza un sencillo ejemplo presentado por primera vez por parte de Linger y sus colaboradores. Nuestro objetivo es diseñar y verificar un pequeño programa que calcule la parte entera, y, de una raíz cuadrada de un entero dado, x. El diseño de procedimientos se representa empleando el diagrama de flujo de la Figura 26.7.






Para verificar la corrección de este diseño, es preciso definir las condiciones de entrada y de salida que se indican en la Figura 26.8. La condición de entrada indica que x debe ser mayor o igual a O. La condición de salida requiere que x permanezca intacta y que adopte un valor dentro del intervalo mostrado en la figura. Para demostrar que el diseño es correcto, es necesario demostrar que las condiciones comienzo, bucle, cont, si y salida mostradas en la Figura 26. 8 son ciertas en todos los casos. En algunas ocasiones se denominan subdemostraciones.






  • La condición comienzo exige que [x>0 e y=0]. Basándose en los requisitos del problema, se supone que la condición de entrada es correcta'. Consiguientemente, se satisface la primera parte de la condición comienzo, x 2 O. En el diagrama de flujo, la sentencia que precede inmediatamente a la condición comienzo hace que y = O. Consiguientemente, la segunda parte de la condición comienzo también se satisface. De aquí que comienzo sea verdadero.

  • La condición bucle se puede encontrar de dos maneras:
v  directamente saliendo de comienzo (en este caso, la condición del bucle se satisface directamente)  
v  a través del control de flujo que pasa por la condición cont. Dado que la condición cont es idéntica a la condición bucle, bucle es verdadera independientemente de la rama de flujo que lleve a ella.

  • Se llega a la condición cont únicamente después de haber incrementado en 1 el valor de y. Además, la ruta de flujo de control que lleva a cont solamente se puede invocar si la condición si también es verdadera. Consiguientemente si (Y + 1)2<x, se sigue que y2 <x. La condición cont  se satisface.

  • La condición si se comprueba en la lógica condicional que se muestra. Consiguientemente, la condición si debe de ser verdadera cuando el flujo de control pase por la vía mostrada.


  • La condición salida exige, en primer lugar, que x no haya cambiado. Un examen del diseño indica que x no aparece en ningún lugar a la izquierda de un operador de asignación. No hay ninguna llamada a función que utilice x. Por tanto, queda intacto. Dado que la comprobación de condiciones (y + 1)2 <x tiene que fallar para alcanzar la condición solido, se sigue que (y + 1)2< x. Además, la condición bucle debe seguir siendo verdadera (esto es, y 2  <x). Consiguientemente, que (y + 1)2 > x e y2 <x se pueden combinar para satisfacer la condición de salida.

Además, es preciso asegurar que finalice el bucle. Un examen de la condición del bucle indica que dado que y se va incrementando y que x<0, el bucle finalmente debe terminar.

Los cinco pasos indicados anteriormente son una demostración de la corrección del diseño del algoritmo indicado en la Figura 26.7. Ahora estamos seguros de que el diseño calculará, realmente, la parte entera de una raíz cuadrada. Es posible utilizar un enfoque matemáticamente más riguroso de la Verificación del diseño. Sin embargo, un debate sobre este tema iría más allá del alcance de este libro. Los lectores interesados pueden consultar.


Ventajas de la verificación del diseño

La verificación de corrección rigurosa de cada uno de los refinamientos del diseño de caja limpia posee un cierto número de ventajas evidentes. Linger las describe de la siguiente manera:

  • Se reduce la verificación a un proceso finito. La forma anidada y secuencial, en que se organizan las estructuras de control en una caja limpia, define de manera natural una .jerarquía que revela las condiciones de corrección que es preciso verificar. Un axioma de sustitución nos permite reemplazar las funciones objetivo por sus refinamientos de estructura de control dentro de la jerarquía de subdemostraciones. Por ejemplo, la subdemostracion  para la función final  fl de la Figura 26.9 requiere que la comprobación de las operaciones gl y g2 con la función final f2 produ7ca sobre los datos el mismo efecto f 1. Obsérvese que f2 reemplaza a todos los detalles de su refinamiento dentro de la demostración. Esta sustitución localiza el argumento de demostración en la estructura de control que se está estudiando. De hecho, permite al ingeniero del software realizar demostraciones en cualquier orden.

  • Es posible asociar una importancia excesiva al efecto positivo que posee sobre la calidad de reducción de la verificación a un proceso finito. Aun cuando todos, salvo los programas más triviales, muestran un conjunto, que en esencia es infinito, der utas de ejecución, se pueden verificar en un número finito de pasos. 







  • Permite que los equipos de sala limpia verifiquen todas las líneas de diseño y código. Los diseños pueden efectuar la verificación mediante un análisis y debate en grupo de las bases del teorema de corrección y pueden producir pruebas escritas cuando se necesite una confianza adicional en algún sistema crítico para vidas o misiones.

  • Da lugar a un nivel de defectos próximos a cero. Durante una revisión en equipo, se verifica por turnos la corrección de todas y cada una de las estructuras de control. Cada miembro del equipo debe estar de acuerdo en que cada condición es correcta, por tanto, un error solamente es posible si todos y cada uno de los miembros del equipo verifican incorrectamente una condición. El requisito de acuerdo unánime basada en las verificaciones individuales de resultados da lugar a un software que posee pocos o ningún defecto antes de su primera ejecución.

  • Es escalable. Todo sistema de software, independientemente de su tamaño, posee unos procedimientos de caja transparente del más alto nivel formados por estructuras de secuencia, alternancias e iteraciones. Cada uno de estos invoca típicamente a un gran subsistema que posee miles de líneas de código cada uno de estos subsistemas posee su propio nivel superior de funciones y procedimientos finales. Por tanto, las condiciones de corrección para estas estructuras de control de alto nivel se verifican de la misma forma en que se procede con las estructuras de bajo nivel. Las verificaciones de alto nivel pueden requerir, y merecerá la pena, una mayor cantidad de tiempo, pero no se necesita más teoría.


  • Produce un código mejor para la comprobación unitaria. La comprobación unitaria solamente comprueba los efectos de ejecutar vías de pruebas seleccionadas entre muchas vías posibles. Al basar la verificación en la teoría de funciones, el enfoque de sala limpia puede verificar todos y cada uno de los posibles efectos sobre los datos, porque aun cuando un programa pueda tener múltiples vías de ejecución, solamente posee una función. La verificación es, además, más eficiente que la comprobación unitaria. La mayor de las condiciones de verificación se pueden verificar en unos pocos minutos, pero las comprobaciones unitarias requieren una cantidad notable de tiempo para prepararlas, ejecutarlas y comprobarlas.

Es importante tener en cuenta que la verificación de diseño debe de aplicarse en última instancia al código fuente en sí. En este contexto, suele denominarse verificación de corrección.

  1. Prueba de sala limpia

La táctica y estrategia de la prueba de sala limpia es algo fundamentalmente distinto de los enfoques convencionales de comprobación. Los métodos convencionales derivan de casos de prueba para descubrir errores de diseño y de codificación. El objetivo de los casos de prueba de sala limpia es validar los requisitos del software mediante la demostración de que una muestra estadística de casos prácticos se ha ejecutado con éxito.

Prueba estadística de casos prácticos

El comportamiento visible para el usuario de ese programa está controlado por las entradas y sucesos que suelen ser producidos por el usuario. Pero en casos complejos, el espectro posible de entradas y sucesos (esto es, los casos prácticos) pueden ser extremadamente variables. ¿Cuál es el subconjunto de casos prácticos que verifica adecuadamente el comportamiento del programa? Ésta es la primera cuestión que aborda la prueba estadística de casos prácticos. La prueba estadística de casos «equivale a probar el software en la forma en que los usuarios tienen intención de utilizarlo». Para lograr esto, los
Equipos de prueba de sala limpia (también llamados equipos de certificación) deben determinar la distribución de probabilidad de utilización correspondiente al software. La especificación (caja negra) de cada incremento del software se analiza para definir un conjunto de estímulos (entradas o sucesos) que pueden dar lugar a que el software modifique su comportamiento. Basándose en entrevistas con posibles usuarios, en la creación de escenarios de utilización y en una comprensión general del dominio de la aplicación, se asigna una probabilidad de utilización a cada uno de los estímulos.

Los casos prácticos se generan para cada uno de los estímulos' de acuerdo con la distribución de probabilidad de utilización. Como ejemplo, considérese el sistema de seguridad Hogar Seguro descrito anteriormente en este libro. Se está utilizando la ingeniería del software de sala limpia para desarrollar un incremento del software que gestione la interacción del usuario con el teclado del sistema de seguridad. Para este incremento se pueden identificar cinco estímulos. El análisis indica el porcentaje de probabilidad de cada estímulo. Para hacer que sea más sencilla la selección de casos de prueba, estas probabilidades se hacen corresponder con intervalos numerados entre 1 y 99, lo que se muestra en la tabla siguiente:


Para generar una sucesión de casos de prueba de utilización que se ajuste a la distribución de probabilidades de utilización, se genera una serie de números aleatorios entre 1 y 99. El número aleatorio corresponde al intervalo de distribución de probabilidad anteriormente destacado. Consiguientemente, la sucesión de casos prácticos se define aleatoriamente pero se corresponde con la probabilidad correspondiente de aparición de ese estímulo. Por ejemplo, suponga que se generan las siguientes sucesiones de números aleatorios

13-94-22-24-45-56
81-19-31-69-45-9
38-21-52-84-86-4

Se derivan los siguientes casos prácticos mediante la selección de los estímulos adecuados basados en el intervalo de distribución que se muestra en la tabla anterior:

HD-P-HD-HD-HD-FZ
P-HD-HD-HD-C-HD-H D
HD-HD-FZ-P-P-HD

El equipo de prueba ejecuta los casos prácticos indicados anteriormente (y otros más) y verifica el comportamiento del software frente a la especificación del sistema. La temporización de las pruebas se registra, de modo que sea posible determinar los intervalos temporales. Mediante el uso de intervalos temporales, el equipo de certificación puede calcular
El tiempo-mínimo-entre fallo. Si se lleva a cabo una larga sucesión de pruebas sin fallo, el TMEF es bajo, y se puede suponer que la fiabilidad del software es elevada.


Certificación

Las técnicas de verificación y prueba descritas anteriormente en este capítulo dan lugar a componentes de software (y a incrementos completos) que, se pueden certificar. En el contexto del enfoque de la ingeniería del software de sala limpia, la certificación implica que la fiabilidad (medida por el tiempo mínimo de fallo, TMDF) podrá ser especificada para cada componente.

El posible impacto de los componentes de software certificables va más allá de un sencillo proyecto de sala limpia. Los componentes de software reutilizable se pueden almacenar junto con sus escenarios de utilización, con los estímulo\ del programa y con las correspondientes distribuciones de probabilidad. Cada uno de los componentes dispondrá de una fiabilidad certificada dentro del escenario de utilización y dentro del régimen de comprobación descrito. Esta información es sumamente valiosa para otras personas que tengan intención de utilizar estos componentes.

El enfoque de la certificación implica cinco pasos:

  • Es preciso crear escenarios de utilización.
  • Se especifica un perfil de utilización.
  • Se generan casos de prueba a partir del perfil.
  • Se ejecutan pruebas y los datos de los fallos se registran y se analizan.
  • Se calcula y se certifica la fiabilidad.

Los pasos 1 a 4 se han descrito en secciones anteriores. En esta sección, nos concentramos en la certificación de fiabilidad.

La certificación para la ingeniería del software de sala limpia requiere la creación de tres modelos:

Modelo de muestreo. La comprobación de software ejecuta m casos de prueba aleatoria, y queda certificada si no se produce ningún fallo o si se produce un número de fallos inferior al especificado. El valor de m se deriva matemáticamente para asegurar que se alcance la fiabilidad necesaria.

Modelo de componentes. Es preciso certificar un sistema compuesto por n componentes. El modelo de componentes capacita al analista para determinar la probabilidad de que falle el componente i antes de finalizar el programa.

Modelo de Certificación. Se estima y certifica la fiabilidad global del sistema.

Al final de la prueba estadística de utilización, el equipo de certificación posee la información necesaria para proporcionar un software que tenga un TMEF certificado que se habrá calculado empleando todos estos modelos.





Bibliografía:

Pressman .S. Roger. Ingeniería de Software. Un enfoque practico. Editorial McGraw-Hill V Edición. Pág. 459-469


























0 comentarios:

Publicar un comentario en la entrada