Estándares PRUSOFT


Materia
Pruebas de software

Tema
Estándares para pruebas de software











INDICE

IEEE 830……………………………………………….. 3
IEEE 1362……………………………………………… 5
IEEE 1063………………………………………………. 6
IEEE 1012………………………………………………. 7
IEEE 1219……………………………………………... 9
IEEE 829…………………………………………..…… 10










IEEE 830
Este estándar nos muestra las consideraciones para producirbuenas especificaciones para un producto software. Al momento de producir un ERS (especificación de requisitos de software) se deben considerar las siguientes clausulas:
a) la Naturaleza del ERS
b) el Ambiente del ERS
c) las Características de un buen ERS
d) la preparación de los Joins del ERS
e) la evolución de ERS
f) Prototipos
g) Generando el diseño en el ERS
h) Generando los requisitosdel proyecto en el ERS
El ERS son especificaciones para un producto de software en particular, programa, o juego de programas que realizan ciertas funciones en un ambiente específico. El ERS puede escribirse por uno o más representantes del proveedor, uno o más representantes del cliente, o por ambos.
Un buen ERS debe cumplir con las siguientes características:
a) Correcto:
Un ERS es correctosi, y sólo si, cada requisito declarado se encuentra en el software. No hay ninguna herramienta o procedimiento que aseguran la exactitud.
b) Inequívoco:
Un ERS es inequívoco si, y sólo si, cada requisito declarado tiene sólo una interpretación. Como un mínimo, se requiere que cada característica de la última versión del producto se describa usando un único término.

c) Completo:
Un SRS estácompleto si, y sólo si, incluye los elementos siguientes:
a) Los requisitos están relacionados a la funcionalidad, el desarrollo, las restricciones del diseño, los atributos y las interfaces externas.
b) La definición de las respuestas del software a todos los posibles datos de la entrada del sistema y a toda clase de situaciones.
c) Tener todas las etiquetas llenas y referencias a todas lasfiguras, tablas, diagramas en el ERS y definición de todas las condiciones y unidades de medida.
d) Consistente:
La consistencia se refiere a la consistencia interior. Si un ERS no está de acuerdo con algún documento del superior-nivel, como una especificación de requisitos de sistema, entonces no es correcto.
e) Delinear que tiene importancia y/o estabilidad:
Un ERS debe delinear laimportancia y/o estabilidad si cada requisito en él tiene un identificador para indicar la importancia o estabilidad de ese requisito en particular.
f) Comprobable:
Un ERS es comprobable si, y sólo si, cada requisito declarado es comprobable.
g) Modificable:
Un ERS es modificable si, y sólo si, su estructura y estilo son tales que puede hacerse cualquier cambio a los requisitos fácilmente,completamente y de forma consistente mientras conserva la estructura y estilo.
h) Identificable:
Un ERS es identificable si el origen de cada uno de sus requisitos está claro y si facilita las referencias de cada requisito en el desarrollo futuro o documentación del mismo.


IEEE 1362
El propósito de este estándar es ofrecer un formato y contenidos para la confección de las descripciones de sistema enlos desarrollos y modificaciones de sistemas intensivos de software.
El estándar no especifica técnicas exactas, sino que proporciona las líneas generales que deben respetarse. No es por tanto un modelo final, sino una guía de referencia sobre la que cada organización debe desarrollar sus propias prácticas y procedimientos para preparar y actualizar su documentación con las descripciones de lossistemas.
Las partes esenciales de un ConOps (descripción del sistema) son:
Punto 3: descripción del sistema existente.
Punto 4: justificación del desarrollo o de la modificación.
Punto 5: Descripción del sistema propuesto.
Los proyectos de tamaño pequeño requieren descripciones de sistema menos formales, pero no por su reducido tamaño debe ignorarse.
Si el proyecto de software forma parte...