UNIVERSIDAD NACIONAL ABIERTA Y DISTANCIA UNAD

UNIDAD 2: PASO 3 - DISEÑO Y ELABORACIÓN

ACTIVIDAD INDIVIDUAL

CRISTIAN VALENCIA PEÑA

1077432779

EVALUACIÓN DE SOFTWARE

GRUPO: 301569_25

TUTOR: GIOVANNI CATALÁN

CEAD-QUIBDO

12/10/20
 NORMA ISO/IEC 14598

LA NORMA ISO/IEC 14598 ES UN ESTÁNDAR QUE

PROPORCIONA UN MARCO DE TRABAJO PARA EVALUAR
LA CALIDAD DE TODO TIPO DE PRODUCTO SOFTWARE E
INDICA LOS REQUISITOS PARA LOS MÉTODOS DE
MEDICIÓN Y EL PROCESO DE EVALUACIÓN,
PROPORCIONANDO MÉTRICAS Y REQUISITOS PARA LOS
PROCESOS DE EVALUACIÓN, A TRAVÉS DE 6 ETAPAS.
 ETAPAS QUE CONFORMAN LA NORMA ISO/IEC 14598-5

• DESCRIPCIÓN GENERAL

• PLANIFICACIÓN Y GERENCIAMIENTO

• PROCESO PARA DESARROLLADORES

• PROCESO PARA ADQUIRIENTES

• PROCESO PARA EVALUADORES

• DOCUMENTACIÓN DE MÓDULOS DE EVALUACIÓN

 LA NORMA ISO/IEC 14598-5 CONSTA

• ISO/IEC 14598-1 VISIÓN GENERAL: PROVEE UNA VISIÓN GENERAL DE LAS OTRAS CINCO
PARTES Y EXPLICA LA RELACIÓN ENTRE LA EVALUACIÓN DEL PRODUCTO SOFTWARE Y
EL MODELO DE CALIDAD DEFINIDO EN LA ISO/IEC 9126

• ISO/IEC 14598-2 PLANEAMIENTO Y GESTIÓN: CONTIENE REQUISITOS Y GUÍAS PARA LAS

FUNCIONES DE SOPORTE TALES COMO LA PLANIFICACIÓN Y GESTIÓN DE LA
EVALUACIÓN DEL PRODUCTO DEL SOFTWARE.

• ISO/IEC 14598-3 PROCESO PARA DESENVOLVEDORES: PROVEE LOS REQUISITOS Y GUÍAS

PARA LA EVALUACIÓN DEL PRODUCTO SOFTWARE CUANDO LA EVALUACIÓN ES
LLEVADA A CABO EN PARALELO CON EL DESARROLLO POR PARTE DEL
DESARROLLADOR.
• ISO/IEC 14598-4 PROCESO PARA ADQUIRIENTES: PROVEE LOS REQUISITOS Y GUÍAS PARA
QUE LA EVALUACIÓN DEL PRODUCTO SOFTWARE SEA LLEVADA A CABO EN FUNCIÓN A
LOS COMPRADORES QUE PLANEAN ADQUIRIR O REUTILIZAR UN PRODUCTO DE
SOFTWARE EXISTENTE O PRE-DESARROLLADO.

• ISO/IEC 14598-5 PROCESO PARA AVALADORES: PROVEE LOS REQUISITOS Y GUÍAS PARA LA
EVALUACIÓN DEL PRODUCTO SOFTWARE CUANDO LA EVALUACIÓN ES LLEVADA A CABO
POR EVALUADORES INDEPENDIENTES.

• ISO/IEC 14598-6 DOCUMENTACIÓN DE MÓDULOS: PROVEE LAS GUÍAS PARA LA

DOCUMENTACIÓN DEL MÓDULO DE EVALUACIÓN.
 Alcance de la Norma ISO/IEC 14598-5

El propósito de la evaluación de la calidad del

software es hacer que tanto el desarrollo y el diseño
del software cumplan las expectativas y necesidades
del usuario. Esta norma 14598 define el proceso de
evaluación y provee los requerimientos y las guías
que conducen a evaluaciones de calidad.
 CARACTERÍSTICAS DE LA NORMA ISO/IEC 14598

• REPETIBLE

• REPRODUCIBLE

• IMPARCIAL

• OBJETIVO
 METODOLOGÍAS DE PRUEBAS DE SOFTWARE.

• CAJA NEGRA: PRUEBAS BASADAS EN REQUERIMIENTOS Y FUNCIONALIDADES DEL

SOFTWARE.

• WHITE BOX TESTING: PRUEBAS BASADAS EN EL CONOCIMIENTO DE LA LÓGICA

INTERNA DEL CÓDIGO DE LA APLICACIÓN.

• PRUEBAS DE HUMO: PRUEBA EL SISTEMA CONSTANTEMENTE BUSCANDO FALLAS

POR TODA LA APLICACIÓN.
 TIPOS DE PRUEBAS
PRUEBAS FUNCIONALES
• ENFOCADAS EN LOS REQUISITOS FUNCIONALES.
• LAS PRUEBAS PUEDEN ESTAR BASADAS DIRECTAMENTE EN LOS CASOS DE USO Y
LAS REGLAS DEL NEGOCIO.
PRUEBAS DE REGRESIÓN
• PROBAR NUEVAMENTE EL SISTEMA LUEGO DE REALIZAR CAMBIOS O HACER
ARREGLOS SOBRE BUGS ENCONTRADOS.
• DETERMINAR SI LOS CAMBIOS RECIENTES EN UNA PARTE DE LA APLICACIÓN TIENEN
EFECTO ADVERSO EN OTRAS PARTES.
PRUEBAS DE INTEGRACIÓN
• ESTAS PRUEBAS SUELEN SER REALIZADAS POR EL EQUIPO DE DESARROLLO Y PERMITEN
COMPROBAR QUE LOS COMPONENTES DEL SOFTWARE INTERACTÚAN CORRECTAMENTE,
ENTRE SÍ Y CON OTRAS PARTES DEL SISTEMA.
PRUEBAS DE SISTEMA
• PRUEBA DEL COMPORTAMIENTO GLOBAL DEL PRODUCTO CONSTRUIDO.
• CUBRE TODAS LAS PARTES COMBINADAS DE UN SISTEMA.
• UTILIZA UN ENTORNO DE PRUEBAS QUE SEA LO MÁS SIMILAR POSIBLE AL ENTORNO DE
PRODUCCIÓN.
PRUEBAS UNITARIAS
• PRUEBAS A PEQUEÑA ESCALA.
• PROBAR FUNCIONALIDADES O MÓDULOS PARTICULARES.
• REALIZADAS TÍPICAMENTE POR EL PROGRAMADOR Y NO EL TESTER.
• REQUIERE CONOCIMIENTO DETALLADO DEL CÓDIGO
PRUEBAS DE ACEPTACIÓN
• EL NIVEL DE PRUEBAS DE ACEPTACIÓN.
• NOS REVELARÁ SI CUMPLIMOS CON LAS EXPECTATIVAS DEL CLIENTE.

PRUEBAS DE CARGA
• VERIFICAR EL TIEMPO DE RESPUESTA DEL SISTEMA PARA TRANSACCIONES O CASOS DE USO DE
NEGOCIOS, BAJO DIFERENTES CONDICIONES DE CARGA.
• UTILIZAR CARGAS PESADAS PARA DETERMINAR EN QUE PUNTO EL TIEMPO DE RESPUESTA DEL
SISTEMA SE DEGRADA O FALLA.
PRUEBAS DE STRESS
• VERIFICAR QUE EL SISTEMA FUNCIONA APROPIADAMENTE Y SIN ERRORES, BAJO ESTAS
CONDICIONES DE STRESS:
•MEMORIA BAJA O NO DISPONIBLE EN EL SERVIDOR.
•MÁXIMO NÚMERO DE CLIENTES CONECTADOS O SIMULADOS (ACTUALES O FÍSICAMENTE POSIBLES)
•MÚLTIPLES USUARIOS DESEMPEÑANDO LA MISMA TRANSACCIÓN CON LOS MISMOS DATOS.
•EL PEOR CASO DE VOLUMEN DE TRANSACCIONES (VER PRUEBAS DE DESEMPEÑO).
PRUEBAS DE VOLUMEN
• VERIFICAR QUE LA APLICACIÓN FUNCIONA ADECUADAMENTE BAJO LOS SIGUIENTES
ESCENARIOS DE VOLUMEN:
O MÁXIMO (ACTUAL O FÍSICAMENTE POSIBLE) NÚMERO DE CLIENTES CONECTADOS (O
SIMULADOS), TODOS EJECUTANDO LA MISMA FUNCIÓN (PEOR CASO DE DESEMPEÑO) POR
UN PERÍODO EXTENDIDO.
O MÁXIMO TAMAÑO DE BASE DE DATOS (ACTUAL O ESCALADO) Y MÚLTIPLES CONSULTAS
EJECUTADAS SIMULTÁNEAMENTE
PRUEBAS DE USABILIDAD
• PROBAR QUE LA USABILIDAD DEL SISTEMA SEA AMIGABLE
• SUBJETIVO
• USAR ENTREVISTAS DEL USUARIO, ENCUESTAS Y OTRAS TÉCNICAS.
PRUEBAS DE SEGURIDAD
• PROBAR QUE TAN BIEN EL SISTEMA ESTA PROTEGIDO CONTRA ACCESOS
INTERNOS O EXTERNOS NO AUTORIZADOS
GRAC IA S