MATERIA INGENIERIA DE SOFTWARE

...

[pic 2]

VENTAJAS DE LA VERIFICACIÓN DEL DISEÑO

Se reduce la verificación de un proceso finito, lo que quiere decir de forma anidada o secuencial en dichos procesos de caja limpia, en donde se definen de manera jerárquica las condiciones de corrección y en donde nos permite cambiar las funciones de un objetivo por sus refinamientos de estructuras de control, en donde se requiere la comprobación de las operaciones, en donde la mínima sustitución de argumentos y demostración de una estructura de control que se está estudiando de echo permite a el ingeniero de software realizar evidencias demostraciones o características en cualquier orden sin modificar la calidad de este tema.

Diseño de subdemostraciones: permite que los equipos de sala limpia verifiquen todas las líneas posibles de diseño y código. El diseño puede generar una verificación mediante un análisis y debate en base a la corrección y pueden producir pruebas de forma escrita cuando se necesite una confianza adicional en sistemas críticos y temas de calidad. Esto da lugar a un nivel de defectos próximos a cero, que hacen que unas revisiones en equipo se verifiquen por turnos todas y cada una de las estructuras de control de calidad de cada proceso si se presentan errores solo es posible si los equipos de trabajo verifican con error las condiciones y los requisitos de acuerdo a una primera ejecución.

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, mía mayor cantidad de tiempo, pero no se necesita más teoría.

producción de código menor que la comprobación 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 mi programa pueda tener múltiples vías de ejecución, solamente posee mía función. La verificación es, además, más eficiente que la comprobación unitaria. Las mayores 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.

CONCLUSIONES

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

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

- Aun cuando todos, salvo los programas más triviales, muestran un conjunto, que en esencia es infinito.

BIBLIOGRAFIA

- [CUR86] Currit, P.A., M. Dyer y H.D. Mills, «Certifying the Reliability of Software»,IEÉE Trcms. Software Enginee- ríng, vol. SE-12,n." l,Enerode 1994.

- Especificación, Diseño y Revisión Deck, M.D., «Cleanroom and Object-Oriented Software Engineering: A Unique Synergy», I Y96Software Technology Conference, SaltLake City, UT, 24 de Abril de 1996.

- Deck, M.D., «Using Box Structures to Link Cleanroom and Object-Oriented Software Engineering», Technical Report 94.01h, Cleanroom Software Engineering Inc., Boulder, CO, 1994.

- Dyer, M. «Designing Software for Provable Correctness: the direction for quality software»,Information and Software Technology, \o\. 30, n.y 6, Julio/Agosto de 1988, pp. 331340. ' ’