Beruflich Dokumente
Kultur Dokumente
CONTENIDO
1INGENIERA DE SOFTWARE DE SALA LIMPIA .................................................... 3 1.11.21.32Concepto .................................................................................................................. 3 Importancia .............................................................................................................. 4 Diferencia respecto al desarrollo convencional del software. ................................. 4
EL ENFOQUE DE SALA LIMPIA ............................................................................... 5 2.1 Tareas del Enfoque de Sala Limpia .............................................................................. 6 Planificacin de Incrementos ......................................................................................... 6 Recoleccin de Requisitos .............................................................................................. 6 Especificacin de la Estructura de Cajas ........................................................................ 6 Diseo Formal ................................................................................................................ 6 Verificacin de Correccin ............................................................................................. 6 Generacin de Cdigo, inspeccin y verificacin .......................................................... 6 Planificacin de la Comprobacin Estadstica ............................................................... 7 Comprobacin estadstica de utilizacin ........................................................................ 7 Certificacin ................................................................................................................... 7
3- ESPECIFICACIN FUNCIONAL ................................................................................... 7 3.13.23.33.43.54.14.25.15.25.3Objetivo ................................................................................................................... 7 Estructura de Cajas .................................................................................................. 7 Especificacin de Caja Negra .................................................................................. 8 Especificacin de Caja de Estado ........................................................................... 9 Especificacin de Caja Transparente ...................................................................... 9 Finalidad ................................................................................................................ 10 Ventajas de la Verificacin del Diseo .................................................................. 14 Finalidad ................................................................................................................ 15 Comprobacin de Estadstica de Casos Prcticos .................................................. 16 Certificacin ........................................................................................................... 18
4- REFINAMIENTO Y VERIFICACIN DEL DISEO .................................................. 10 Ejemplo de una verificacin del diseo:....................................................................... 12 5- COMPROBACIN DE SALA LIMPIA ......................................................................... 15
Ejemplo de comprobacin estadstica de casos prcticos: ........................................... 16 ANEXOS .............................................................................................................................. 19 Anexo 1. Mapa Mental Ingeniera de Sala Limpia ........................................................... 19 BIBLIOGRAFA .................................................................................................................. 20 2
Su filosofa consiste en evitar la dependencia de costosos procesos de eliminacin de defectos, mediante la escritura de incrementos de cdigo desde un primer momento, y mediante la verificacin de su correccin antes de las pruebas. Su modelo de proceso incluye la certificacin estadstica de calidad de los incrementos de cdigo, a medida que estos se van aadiendo en el sistema.
Al igual que las tcnicas de mtodos formales, el proceso de sala limpia hace hincapi en el rigor en la especificacin y en el diseo, y en la verificacin formal de cada uno de los elementos del modelo de diseo resultante mediante el uso de pruebas de correccin basadas en fundamentos matemticos. Al extender el enfoque adoptado en los mtodos formales, el enfoque de sala limpia hace hincapi tambin en tcnicas de control estadstico de calidad, incluyendo las comprobaciones basadas en el uso anticipado del software por parte de los clientes.
Debido al alto nivel de exigencia que este mtodo requiere, debe ser realizado por un ingeniero de software formado para sta especializacin
1.2-
Importancia
Los errores conllevan doble trab ajo. Trabajar el doble lleva ms tiempo y es
ms caro. No sera maravilloso poder reducir dramticamente la cantidad de errores (fallos informticos) que se cometen en el diseo y construccin del software? Esto es lo que promete la ingeniera 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 prdidas econmicas o con el funcionamiento efectivo de una infraestructura social y de negocios. La ingeniera del software de sala limpia es un modelo de proceso que elimina los defectos antes de que puedan dar lugar a riesgos graves.
1.3-
pasan. Dado que se considera que los errores son inevitables, cada mdulo del programa debe ser comprobado unitariamente (para descubrir los errores) y depurado despus (para eliminar los errores). Cuando se publica finalmente el software, la utilizacin prctica descubre aun ms defectos, y comienza otro ciclo de comprobacin y depuracin. Este trabajo repetido asociado a las actividades mencionadas resulta costoso y lleva mucho tiempo. Y lo que es peor, puede ser degenerativo; la correccin de errores puede (inadvertidamente) dar lugar a la introduccin de otros errores.
Difiere tambin de los puntos de vista convencionales y orientados a objetos en cuanto a: 1. Hace uso explcito del control estadstico de calidad 2. Verifica la especificacin del diseo empleando una demostracin de correccin basada en las matemticas. 3. Hace mucho uso de la comprobacin estadstica de utilizacin para descubrir errores de especial incidencia.
El enfoque de sala limpia aplica la mayor parte de los principios bsicos de ingeniera del software. Prcticas convencionales: quita importancia al papel de la comprobacin y depuracin de unitarios y al reducir mucho las comprobaciones que son realizadas por quien desarrolla el software. En sala limpia, la comprobacin unitaria y la depuracin se ven sustituidas por una verificacin de correccin y por una comprobacin basada estadsticamente.
cdigo y de cajas, y la correccin sintctica del cdigo. Se efecta una verificacin de correccin para el cdigo fuente. Planificacin de la Comprobacin Estadstica La utilizacin estimada del software se analiza y se planifica y se disea un conjunto de casos de prueba que ejerciten la distribucin de probabilidad de esa utilizacin. Especificacin, verificacin y generacin de cdigo en paralelo. Comprobacin estadstica de utilizacin Resulta necesario disear un conjunto finito de casos de prueba. Las tcnicas estadsticas de utilizacin ejecutan una coleccin de pruebas derivadas de una muestra estadstica de todas las posibles ejecuciones del programa por parte de todos los usuarios de una cierta poblacin blanca. Certificacin Despus de la verificacin, inspeccin y la comprobacin se certifica el incremento como preparado para su integracin.
3- ESPECIFICACIN FUNCIONAL
3.1- Objetivo
Independientemente del modelo de anlisis seleccionado. Se modelan los datos, la funcin y el comportamiento. Los modelos resultantes deben ser desglosados para proporcionar un grado de detalle cada vez ms elevado. El objetivo global consiste en pasar de una especificacin que captura la esencia de un problema a una especificacin que proporciona una cantidad de detalle sustancial para su implementacin.
formar una jerarqua en la cual cada caja tiene transferencia referencial: el contenido de informacin de cada especificacin de caja basta para definir su refinamiento, sin depender de la implementacin de ninguna otra caja (Ver Ilustracin 1). Esto capacita al analista para desglosar jerrquicamente el sistema.
Se utilizan tres tipos de cajas: Caja Negra Caja de Estado Caja Transparente
10
En cada nivel de refinamiento, el equipo de sala limpia lleva a cabo una verificacin formal de correccin. Para lograr esto, se asocia un conjunto de condiciones genricas de correccin a las estructuras de programacin estructurada. Si se expande una funcin f para dar sucesin a g y h entonces la condicin de correccin para todas las entradas de f es: Es cierto que g seguido por h da lugar a f? Si se refina una funcin p para llegar a una estructura condicional (si-entoncessino), la condicin de correccin para toda entrada de p es: Siempre que sea cierta la condicin (c) es cierto que q realiza p y siempre que (c) sea falsa, es cierto que y realiza p? Si se refina una funcin m en forma de bucle, las condiciones de correcci{on para todas las entradas de m son: Est garantizada la finalizacin? Siempre que (c) sea verdadera es cierto que n seguido por m, siempre que (c) sea falso sigue realizndose m si se obvia el bucle?
11
Cada vez que se refina una caja limpia hasta el siguiente nivel de detalle, se aplican las condiciones de correccin indicadas anteriormente. Ejemplo de una verificacin del diseo: Nuestro objetivo es disear y verificar un pequeo programa que calcule la parte entera, y, de una raz cuadrada de un entero dado, x, El diseo de procedimientos se representa empleando el diagrama de flujo de la Ilustracin 6.
Para verificar la correccin de este diseo, es preciso definir las condiciones de entrada y de salida que se indican en la Ilustracin 7. La condicin de entrada indica que x debe ser mayor o igual a 0. La condicin de salida requiere que x permanezca intacta y que adopte un valor dentro del intervalo mostrado en la figura. Para demostrar que el diseo es correcto, es necesario demostrar que las condiciones comienzo, bucle, cont, si y salida mostrada en la Ilustracin 7 son ciertas en todos los casos. En algunas ocasiones se denominan sub-demostraciones.
12
1. La condicin comienzo exige que [x>=0 y y=0]. Basndose en los requisitos del problema, se supone que la condicin de entrada es correcta.
Consiguientemente, se satisface la primera parte de la condicin comienzo, x >=0. Consiguientemente la segunda parte de la condicin comienzo tambin se satisface. De aqu que comienzo sea verdadero. 2. La condicin bucle se puede encontrar de dos maneras: a) directamente saliendo de comienzo (en este caso, la condicin del bucle se satisface directamente) o bien b) a travs del control de flujo que pasa la condicin cont. Dado que la condicin cont es idntica a la condicin bucle es verdadera
independientemente de la rama de flujo que lleve a ella. 3. Se llega a la condicin cont nicamente despus de haber incrementado en 1 el valor de y. Adems, la ruta de flujo de control que lleva a cont solamente se puede invocar si la condicin si tambin es verdadera. Consiguientemente si (y+1)2<= x, se sigue que y2<=x. La condicin cont se satisface. 4. La condicin si se comprueba en la lgica condicional que se muestra. Consiguientemente la condicin si debe ser verdadera cuando el flujo de control pase por la va mostrada. 5. La condicin salida exige, en primer lugar, que x no aparece en ningn lugar a la izquierda de un operador de asignacin. No hay ninguna llamada a funcin que utilice x. Por lo tanto, queda intacto. Dado que la comprobacin de
13
condiciones (y+1)
verdadera (esto es y2>=x). Consiguientemente, que (y+1) pueden combinar para satisfacer la condicin salida.
>x e y2<=x se
Adems, es preciso asegurar que finalice el bucle. Un examen de la condicin del bucle indica que dado que y se va incrementando y que x>=0, el bucle finalmente debe terminar.
Los cinco pasos anteriormente descritos son una demostracin de la correccin del diseo del algoritmo indicado en la Ilustracin 6. Ahora se puede estar seguro de que el diseo calcular realmente, la parte entera de una raz cuadrada.
requisito de acuerdo unnime basado en las verificaciones individuales de resultados da lugar a un software que posee pocos o ningn defecto antes de su primera ejecucin. Es escalable. Todo sistema de software, independientemente de su tamao, posee unos procedimientos de caja transparente del ms alto nivel formados por estructuras de secuencia, alternancias e iteraciones. Cada uno de estos invoca tpicamente a un gran subsistema que posee miles de lneas de cdigo. Por lo tanto, las condiciones de correccin para estas estructuras de control de alto nivel se verifican de la misma forma en que se procede con las estructuras de bajo nivel. Produce un cdigo mejor que la comprobacin unitaria. La comprobacin unitaria solamente comprueba los efectos de ejecutar vas de pruebas seleccionadas entre muchas vas posibles. Al basar la verificacin en la teora de funciones, el enfoque de sala limpia puede verificar todos y cada uno de los posibles efectos sobre los datos, porque an cuando un programa pueda tener mltiples vas de ejecucin, solamente posee una funcin. La verificacin tambin es ms eficiente que la comprobacin unitaria. La mayora de las condiciones de verificacin se pueden verificar en unos pocos minutos, pero las comprobaciones unitarias requieren una cantidad notable de tiempo para prepararlas, ejecutarlas y comprobarlas.
16
estmulo. Para facilitar la seleccin de los casos de prueba, estas probabilidades se hacen corresponder con intervalos numerados entre 1 y 99 (Ver Tabla 1).
Tabla 1 Ejemplo Porcentaje de Probabilidad de una determinada funcionalidad del uso de un Software
Estmulos de Programa Consultar (C) Incluir Registro (IR) Habilitar / Deshabilitar (HD) Eliminar (E)
Probabilidad 50 % 30 % 15 % 5%
Para generar una sucesin de casos de prueba de utilizacin que se ajuste a la distribucin de probabilidades de utilizacin, se genera una serie de nmeros aleatorios entre 1 y 99. El nmero aleatorio corresponde al intervalo de distribucin de probabilidad anteriormente destacado. Consiguientemente, la sucesin de casos prcticos se define aleatoriamente pero se corresponde con la probabilidad correspondiente de aparicin de ese estmulo. Por ejemplo, supongamos que se generan las siguientes sucesiones de nmeros aleatorios: 13-94-22-24-45-56 81-19-31-69-45-9 38-21-52-84-86-4 Se derivan los siguientes casos prcticos mediante la seleccin de los estmulos adecuados basados en el intervalo de distribucin que se muestra en la tabla anterior: C-HD-C-C-C-IR HD-C-C-IR-C-C C-C-IR-HD-C El equipo de prueba ejecuta los casos prcticos indicados anteriormente (y otros ms) y verifica el comportamiento del software frente a la especificacin del sistema. La temporizacin de las pruebas se registra, de modo que sea posible determinar los intervalos temporales, el equipo de certificacin puede calcular el tiempo mnimo entre fallos. Si se lleva a cabo una larga sucesin de pruebas sin fallo, se puede suponer que la fiabilidad del software es elevada.
17
5.3- Certificacin
Las tcnicas de verificacin y pruebas descritas anteriormente, dan lugar a componentes de software y a incrementos completos que se pueden certificar. En el contexto del enfoque de la ingeniera del software de sala limpia, la certificacin implica que la fiabilidad (medida por el tiempo mnimo entre fallos) podr ser especificada para cada componente. El enfoque de certificacin implica cinco pasos:
1) es preciso crear escenarios de utilizacin 2) se especifica un perfil de utilizacin 3) se generan casos de prueba a partir del perfil 4) se ejecutan pruebas y los datos de los fallos se registran y se analizan 5) se calcula y se certifica la fiabilidad.
La Certificacin para la ingeniera de software de sala limpia requiere la creacin de tres modelos: Modelo de muestreo: la comprobacin de software ejecuta m casos de prueba aleatorios y queda certificada si no se produce ningn fallo o si se produce un nmero de fallos inferior al especificado. El valor de m se deriva matemticamente 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 certificacin: se estima y certifica la fiabilidad global del sistema.
18
ANEXOS
Anexo 1. Mapa Mental Ingeniera de Sala Limpia
19
BIBLIOGRAFA
Ingeniera del Software, Un Enfoque Prctico. Quinta Edicin. Roger S. Pressman. Editorial McGraw Hill.
20