ISO 25000

Alumnos:
 Caipo Huacasi Jonathan Raúl
 Calcina Ticlla Luis Fernando
 Machaca Hilasaca Ronald
 Paco Polosi Cesar Edu

Arequipa – Perú
2020
EJERCICIOS

 Para cada una de las Actividades de la ISO 25040 utilice las plantillas para el
desarrollo correspondiente a su Proyecto.

Requisitos de la Evaluación de Calidad

1. Información de Identificación

1.1. Identificación del Evaluador

Responsable Jonathan Raúl Caipo Huacasi

1.2. Identificación del Reporte de Evaluación

ID CR0001
Número de páginas 04

2. Dominio de la aplicación

Dominio Descripción
Esta aplicación se aplica en el área de
Control de negocio
administración del local a alquilar.
Esta aplicación permite que el
producto, en este caso, un local o un
Soporte de negocio
evento artístico, sea promocionado y
tenga una retribución esperada.

3. Propósito de la evaluación

Entregable Necesidades de la evaluación

Verificar que el entregable cubra las
ERS necesidades y aprobaciones de los
stakeholders más importantes.
Verificar que el entregable sea
Diseño de la arquitectura del software soportado por la infraestructura
actual.
Verificar que el entregable cumpla las
Diseño de la base de datos políticas y estándares de diseño de
base de datos.
 Verificar que el entregable cumpla
con la autenticación según políticas
de seguridad de información,
Inyección SQL, Manejo de
excepciones y errores, Validación de
Código fuente del software
datos de entrada, Uso de parámetros,
Estándares de nomenclatura y
arquitectura y Seguridad de
componentes y servicios según
políticas de seguridad de información.
Verificar que el software
Software integrado implementado cubra los requisitos
funcionales y no funcionales.

4. Lista de requerimientos de calidad

Porcentaje
Nivel de referencial del
Simbología Significado
importancia nivel de
importancia
El grado de
importancia de la
característica y
Alto A 70% - 100% subcaracterística
es alto por ende se
realizará las
mediciones.
La característica y
subcaracterística
no es tan relevante
pero puede o no
Medio M 25% - 69%
ser medida
dependiendo del
criterio del
evaluador.
La característica y
subcaracterística
Bajo B 1% - 24%
no tiene relevancia
y no será medida.
Este valor se dará
a la característica
y subcaracterística
que no se pueden
No Aplica NA 0%
medir
dependiendo de
diferentes
factores.
 Funcionalidad Importancia
La capacidad del producto software
para proveer los resultados o efectos
Precisión M
acordados con un grado necesario de
precisión.
La capacidad del producto software
para proteger la información y los
datos de modo que las personas o los
Seguridad sistemas no autorizados no puedan A
leerlos o modificarlos y a las
personas o  sistemas autorizados no
se les denegará el acceso.
Fiabilidad Importancia
La capacidad del producto software
para mantener un nivel especificado
Tolerancia a fallos de funcionamiento en caso de errores A
del software o de incumplimiento de
su interfaz especificada.
Usabilidad Importancia
La capacidad del producto software
para permitir al usuario entender si
el software es aplicable, y cómo
Entendibilidad A
puede ser utilizado para las tareas y
las condiciones particulares de la
aplicación.
La capacidad del producto software
Facilidad de
para permitir al usuario aprender su A
aprendizaje
aplicación.
La capacidad del producto software
Atractividad M
de ser atractivo al usuario.
Eficiencia Importancia
La capacidad del producto software
para utilizar apropiadas cantidades y
Utilización de
tipos de recursos cuando éste B
recursos
funciona bajo las condiciones
establecidas.
Mantenibilidad Importancia
La capacidad del software para
Cambiabilidad permitir que una determinada A
modificación sea implementada.
La capacidad del producto software
para evitar efectos inesperados
Estabilidad M
debido a modificaciones del
software.
Portabilidad Importancia
 La capacidad del producto software
Instalabilidad para ser instalado en un entorno NA
definido.

5. Productos a ser incluidos en la evaluación

Número de iteración del Método de

Entregables a Evaluar
Evaluación de calidad
Iteración 1: finalización de la etapa Especificación de requerimientos del
de análisis. software. (Análisis)
Diseño de la arquitectura del
Iteración 2: finalización de la etapa
software. (Diseño)
de diseño.
Diseño de la base de datos. (Diseño)
Código fuente del software.
Iteración 3: finalización de la etapa
(Implementación)
de implementación.
Software integrado. (Implementación)

6. Control de cambios

Versión Fecha Responsable

v0.0.1 31/05/20 Jonathan Caipo Huacasi
v0.0.2 01/06/20 Luis Calcina Ticlla

7. Aprobaciones

N° de Revisión Fecha Aprobado por

Jonathan Caipo Huacasi
Luis Calcina Ticlla
01 04/06/20
Ronald Machaca Hilasaca
Cesar Paco Polosi

Especificaciones de la Evaluación de Calidad

1. Información de Identificación

1.1. Identificación del Evaluador

Responsable Luis Fernando Calcina Ticlla

1.2. Identificación del Reporte de Evaluación

 ID CE0001
Número de páginas 08

2. Alcance de la evaluación

Se basó en realizar la evaluación de calidad de los siguientes documentos, con la

finalidad de llegar a un objetivo:

Entregable Objetivo de la evaluación

ERS
Diseño de la arquitectura del software debe verificar si la arquitectura
Diseño de la base de datos
Código fuente del software
Software integrado
Verificar que los requisitos
funcionales u no funcionales cubran
las necesidades de los usuarios y
stakeholders.
Verificar que el diseño de la
arquitectura sea soportado por la
arquitectura existente en la empresa;
es decir, esta evaluación de calidad
diseñada es acorde a la arquitectura
de la empresa, tanto en hardware,
software, redes y conectividad y
estándares de diseño.
Verificar que el diseño de base de
datos cumpla estándares de la
empresa
Verificar que el código fuente del
producto software cumple los
estándares de la empresa, así como
los estándares de desarrollo seguro,
mejores prácticas de desarrollo y las
políticas de seguridad de información.
Verificar que el software terminado
cumple los requisitos funcionales y
no funcionales definidos para el
producto final.

3. Referencia cruzada entre la información necesaria para realizar la evaluación

y los componentes del producto referenciados en su descripción

Productos a evaluar Información necesaria

Especificación de requisitos del Requisitos funcionales y no funcionales

software.
Diseño de la arquitectura del software
Diseño de la base de datos
Código fuente del software
Software integrado
de los interesados.
Evidencia de la conformidad de los
requisitos funcionales y no funcionales
del sistema.
Diagrama de la arquitectura del
software.
Descripción de los elementos de la
arquitectura del software.
Diagrama Entidad Relación con el
modelo de la base de datos.
Diccionario de datos del modelo.
Código fuente del producto software.
Requisitos funcionales y no funcionales
del sistema.
Software integrado y publicado.

4. Especificación de las métricas de calidad y sus criterios de decisión

Funcionalidad
Nombre Métrica Propósito Fórmula
X=A/T

¿Cuán frecuente A = Número de casos

no son encontrados por los
aceptables las usuarios con una
diferencias entre diferencia respecto a los
Precisión Precisión esperada los resultados resultados
reales y los razonablemente
resultados esperados más allá de lo
razonablemente aceptable.
esperados?
T = Tiempo de
operación.
Seguridad Auditoria de acceso ¿Cuán completa X = A / B
es la pista de
auditoria A = Número de
referida al “Acceso de Usuarios al
acceso del Sistema y Datos”
usuario al registrado en la base de
sistema y a los datos de historia de
datos? accesos.

B = Número de
“Acceso de Usuarios al
Sistema y Datos”
hechos durante la
 evaluación.
Fiabilidad
Nombre Métrica Propósito Fórmula
¿Con qué X = 1 - A / B
frecuencia el
producto A = Número de caídas.
Tolerancia a Prevención de
software causa
fallos caídas
caídas en el B = Número de fallas.
ambiente de
producción?
Usabilidad
Nombre Métrica Propósito Fórmula
X=A/B
¿Qué proporción
de funciones (o
A = Número de
de tipos de
funciones (o tipos de
función) pueden
Funciones funciones) identificadas
Entendibilidad ser identificadas
evidentes por el usuario.
por el usuario
basado en
B = Número total de
condiciones de
funciones actuales (o
inicio?
tipos de funciones).
X=A/B
¿Qué proporción
A = Número de
de funciones del
funciones de la interfaz
producto el
Función de cuyo propósito se
Entendibilidad usuario es capaz
comprensión describe correctamente.
de entender
correctamente?
B = Número de
funciones disponible de
interfaz.
¿Cuánto tiempo T = Tiempo promedio,
toma el usuario tomado para aprender a
Facilidad de Facilidad de
para aprender a utilizar una función
aprendizaje aprender la función
usar una correctamente.
función?
Cuestionario para
determinar la interfaz
¿Cuán atractiva
Interacción atractiva para el usuario
Atractividad es la interfaz del
atractiva después de la
usuario?
experiencia de uso.

Eficiencia
Nombre Métrica Propósito Fórmula
Utilización de Límites de carga ¿Cuál es el X = Amax / Rmax
recursos E/S límite absoluto
de utilización Amax = MAX (Ai),
 E/S al cumplir (desde i = 1 hasta N).
una función?
Rmax = Máximo
número de mensajes
E/S requeridos.

MAX (Ai) = Número

máximo de mensajes
E/S desde la primera
hasta la evaluación i-
ésima.

N = Número de
evaluaciones.
Mantenibilidad
Nombre Métrica Propósito Fórmula
Tiempo promedio:

Tprom = Sum (Tm) / N

Tm = Tsal – Tent

Tsal = Tiempo en el
¿Puede cual las causas de falla
fácilmente el fueron removidas con el
Tiempo de responsable de cambio del software (o
Cambiabilidad implementación del mantenimiento el estado es reportado al
cambio cambiar el usuario).
software para
resolver la falla? Tent = Tiempo en el
cual las causas de falla
son encontradas.

N = Número de fallas
registradas y
removidas.

Estabilidad Ratio de éxitos de Puede el usuario X = Na / Ta

cambios operar el sistema
software sin Y = ((Na / Ta) / (Nb /
fallas después Tb))
del
mantenimiento? Na = Número de casos
en los cuales el usuario
encuentra fallas durante
la operación después
que el software fue
cambiado.
 Nb =Número de casos
en los que el usuario
encuentra fallas durante
la operación antes de
que el software sea
cambiado.

Ta = Tiempo de
operación durante el
periodo de observación
especificado después
que el software sea
cambiado.

Tb = Tiempo de
operación durante el
periodo de observación
especificado antes que
el software sea
cambiado.

Portabilidad
Nombre Métrica Propósito Fórmula
X=A/B
¿Puede el
A = Número de casos
usuario o
en los cuales un usuario
responsable de
exitosamente cambió la
mantenimiento
Facilidad de instalación a su
Instalabilidad instalar
instalación conveniencia.
fácilmente
B = Número total de
software en el
casos en el que un
entorno de
usuario intentó cambiar
operación?
la instalación a su
conveniencia.
E R Característica P E R Sub-Característica P E R Métrica
0.64 0.62 Funcionalidad 20 0,62 0,52 Aplicabilidad 0%
%
Precisión 40% 0.6 0.50 Precisió
5
Interoperabilidad 0%
Seguridad 60% 0.6 0.55 Auditor
0
Conformidad de 0%
funcionalidad
Fiabilidad 10 0.60 0.62 Madurez 0%
%
Tolerancia a Fallos 100% 0.6 0.62 Prevenc
0
Recuperabilidad 0%
Conformidad de fiabilidad 0%
Usabilidad 30 0.65 0.60 Entendibilidad 33.3% 0.5 0.55 Funcion
% 7

Función
compren
Facilidad de aprendizaje 33.3% 0.7 0.65 Facilida
0 aprende
Operabilidad 0%
Atractividad 33.3% 0.7 0.60 Interacc
0
Conformidad de usabilidad 0%
Eficiencia 20 0.65 0.70 Comportamiento en el 0%
% tiempo
Utilización de recursos 100% 0.6 0.70 Límites
5
Conformidad de eficiencia 0%
Facilidad de 10 0.70 0.60 Analizabilidad 0%
Mantenimiento %
Cambiabilidad 50% 0.7 0.55 Tiempo
0 impleme
cambio
Estabilidad 50% 0.7 0.65 Ratio
0 ca
Examinabilidad 0%
Conformidad de la 0%
mantenibilidad
Portabilidad 10 0.65 0.70 Adaptabilidad 0%
% Instabilidad 100% 0.6 0.70 Fac
5 ins
Coexistencia 0%
Reemplazabilidad 0%
Conformidad de 0%
portabilidad
5. Control de cambios

Versión Fecha Responsable

v0.0.1 31/05/20 Luis Calcina Ticlla
v0.0.2 01/06/20 Jonathan Caipo Huacasi

6. Aprobaciones

N° de Revisión Fecha Aprobado por

Jonathan Caipo Huacasi
Luis Calcina Ticlla
01 04/06/20
Ronald Machaca Hilasaca
Cesar Paco Polosi

Diseño de la Evaluación de Calidad

1. Información de Identificación

1.1. Identificación del Evaluador

Responsable Jonathan Raúl Caipo Huacasi

1.2. Identificación del Reporte de Evaluación

ID CC0001
Número de páginas 03

2. Personas y Responsabilidades

Responsables
Machaca Hilasaca Ronald Fabiany
Cesar Polosi Paco Edu
Caipo Huacasi Jonathan Raúl
Calcina Ticlla Luis Fernando
Responsabilidades
Interpretar mediciones y ejecutarlas
Controlar y monitorear
Revisión de los entregables y
consolidarlos
Revisión del producto

3. Restricciones

ID Restricciones Descripción
Se debe de cumplir a
lo largo del proyecto
Lanzamiento
R1 la estimación del
del
 producto tiempo de
finalización de
proyecto de calidad.
Se debe de cumplir
a lo largo del
Actualizaciones
R2 proyecto sobre que
posteriores
actualizaciones se
realizaran para
mejora del producto.
No se dispondrá de
costos elevados para
R3 Costos elevados las actualizaciones e
implementación del
proyecto.

4. Riesgos

Riesg
os
Proyec Aplicación Móvil
to SCOLEE
N° de Categoría Nombre del riesgo Puntaje Parte
riesgo del del responsable
riesgo riesgo
1 Externo Desinterés de los Stakeholders por 2 Ronald
participar en la evaluación de
calidad
2 Externo Falta de conectividad 1 Usuario
3 Externo Instalación en dispositivos de bajo 1 Usuario
rango
4 Técnico Incompatibilidad con nuevas 2 Jonathan
versiones
de Android
5 Técnico Problemas con el registro de 3 Jonathan
compras
6 Técnico No se cumple con los requisitos 2 Ronald
esperados
7 Técnico Bloqueo de publicidad 3 Ronald
8 Técnico Colores inadecuados 2 Paco
9 Técnico Fallas de conectividad con el 2 Paco
servidor
10 Gestión del Inconformidad con el plan 2 Luis
proyecto establecido
11 Gestión del Documentación imprecisa 2 Luis
proyecto
12 Externo Falta de publicidad 3 Empresa
5. Plan de trabajo

6. Control de cambios

Versión Fecha Responsable

v0.0.1 31/05/20 Jonathan Caipo Huacasi
v0.0.2 01/06/20 Luis Calcina Ticlla

7. Aprobaciones

N° de Revisión Fecha Aprobado por

Jonathan Caipo Huacasi
Luis Calcina Ticlla
01 04/06/20
Ronald Machaca Hilasaca
Cesar Paco Polosi