"Año del Diálogo y Reconciliación Nacional"

Escuela Profesional de Ingeniería

de Sistemas
Curso:
Ingeniería De Software II
Ciclo:
2018-VI

Actividad:

Actividad N°14

Docente:
Ing. Jose A. Santa Cruz Vera

Alumnos:
Aguirre Alvarado Bryan Alessandro
Silva Castro Dilmer Antonio

Sullana 2018
 REQUERIMIENTO DE CALIDAD DE SOFTWARE
Confiabilidad
Factores de Influencia
• En casos en los que el
fracaso del sistema
Varios factores influyen
en la planificación, puede tener
consecuencias
gestión, y selección de
sumamente severas, la
actividades de SQM y
confiabilidad total (en
técnicas, incluyendo:
• El dominio del sistema hardware, el software, y
humanos) son la
en el cual el software
exigencia de calidad
residirá (seguridad
crítica, misión crítica, principal además de la
funcionalidad básica.
negocio crítico)
• Requerimientos del
Sistema y del software. • • La confiabilidad del
software incluye
Los componentes
comerciales (externos) o características tales
como tolerancia al
estándar (internos) que
defecto, fiabilidad,
serán usados por el
seguridad, y usabilidad.
Sistema.
La fiabilidad es también
• Los estándares
un criterio que puede ser
específicos de ingeniería
del software específico definido en términos de
confiabilidad (ISO
aplicables.
9126).
Niveles de integridad Objetivos de la prueba Pruebas de caja negra
del software
• La prueba es un • Se centran en los
• El nivel de integridad proceso de ejecución de requisitos funcionales
se determina en base a un programa con la del software. Permite al
las consecuencias intención de descubrir ingeniero del software
posibles del fracaso del un error. obtener conjuntos de
software y a la • Un buen caso de condiciones de entrada
probabilidad de fracaso. prueba es aquel que tiene que ejerciten
una alta probabilidad de completamente todos los
• Para el software en el mostrar un error no requisitos funcionales de
que la seguridad o la descubierto hasta un programa, es decir
fiabilidad son entonces. consideran la función
importantes, técnicas • Una prueba tiene éxito para la cual fue creado el
como el análisis de si descubre un error no producto (lo que hace).
riesgo para la seguridad detectado hasta
o el análisis de amenazas entonces. “La prueba no • Se llevan a cabo sobre
para la fiabilidad pueden puede asegurar la la interfaz del sistema
ser usadas para ausencia de defectos, reduciendo el número de
desarrollar una actividad sólo puede demostrar casos de prueba
de planificación que se que existen defectos en mediante la elección de
identificaría en donde se el software”. entradas y salidas
encuentren conflictos válidas y no válidas que
potenciales. ejercitan toda la
funcionalidad del
sistema.