EVALUACIÓN DE LA CALIDAD DEL

SISTEMA DE PLANEAMIENTO DE
ASIGNATURA – FIIS - UNAS
PRODUCTO DEL TRABAJO: INFORME 1

Elaborado por: Jean Fernando Unzueta Diego

Marzo 2021
 INDICE
INTRODUCCION ................................................................................................................... 3
I. OBJETIVOS ................................................................................................................... 4
1.1 Objetivo General .................................................................................................... 4
II. METODOLOGÍA ............................................................................................................. 4
2.1 Generalidades ........................................................................................................ 4
2.2 Herramientas ......................................................................................................... 4
2.3 Técnicas ................................................................................................................ 4
III. PROCEDIMIENTO ....................................................................................................... 4
3.1 ESTABLECER LOS REQUISITOS DE LA EVALUACIÓN ...................................................... 4
3.1.1 Establecer el propósito de la evaluación ............................................................. 4
3.2 OBTENER LOS REQUISITOS DE CALIDAD DEL PRODUCTO ............................................. 5
3.2.1 Registro de Interesados en el producto de Software ............................................ 5
3.2.2 Modelo de Calidad a Utilizar ............................................................................. 5
3.3 IDENTIFICAR LAS PARTES DEL PRODUCTO QUE SE DEBEN EVALUAR.............................. 6
3.4 DEFINIR EL RIGOR DE LA EVALUACIÓN ...................................................................... 7
V. DISEÑAR LA EVALUACIÓN .............................................................................................12
5.1 PLANIFICAR LAS ACTIVIDADES DE LA EVALUACIÓN ....................................................12
VI. RESULTADOS ............................................................................................................13
VII. CONCLUSION............................................................................................................17
VIII. RECOMENDACIÓN.....................................................................................................17

CUADROS

Tabla 1: Registro de interesados ............................................................................................ 5

Tabla 2: Descripción de los Requisitos según las Sub Características ........................................... 6
Tabla 3: Resumen general de la cantidad de tipo de evaluación ................................................. 7
Tabla 4: Niveles de Evaluación ............................................................................................... 7
Tabla 5: Cronograma de Actividades ......................................................................................12
 INTRODUCCION
La evolución de los procesos informáticos genera una dependencia para la toma de
decisiones, por esta razón los productos software deben satisfacer elementales criterios de
calidad. En la actualidad el auge de los sistemas web y móvil va incrementándose a grandes
rasgos, lo que ha posicionado a los usuarios finales como evaluadores idóneos para medir la
calidad percibida de un producto software determinado (Covella, 2005).
Para definir la calidad se debe tener clara la diferencia entre calidad del proceso de desarrollo
y calidad del producto. Aunque estén ligadas subyacentemente, siendo la calidad del
producto el resultado de la calidad del proceso. El proceso desencadena parámetros sencillos
para normalizar y controlar, sin embargo, la calidad del producto, independientemente del
proceso aplicado, puede diferir si se ve afectada por factores externos (Estayno et al., 2009).
Por lo tanto, se puede definir a la calidad como un conjunto de características subjetivas
medibles, que dependen de la perspectiva de requerimientos de los usuarios del producto
(Patiño y Reina, 2018).
En consonancia con lo expuesto, el presente trabajo de investigación tiene como objetivo
evaluar la calidad en uso, de las características: Efectividad, Eficiencia y Satisfacción, mediante
la determinación de las métricas que describen: Efectividad de la tarea, Frecuencia de error,
Tiempo de la tarea, Eficiencia de la tarea, Productividad económica, Nivel de satisfacción, Uso
discrecional de las funciones y Porcentaje de quejas de los usuarios, especificadas en la norma
ISO/IEC 25022.
Está organizado de la siguiente manera: el capítulo 1 presenta el objetivo general y los
específicos, el capítulo 2 presenta la metodología donde detalla las generalidades del análisis
del sistema, la herramienta a emplear y la técnica que se empleará; el capítulo 3 detalla el
procedimiento a realizar, para ello se tuvo por concerniente seguir la guía de la ISO/IEC 25040 ;
el capítulo 4 discute el diseño y ejecución de la revisión sistemática como eje central de esta
tesis, y finalmente el capítulo 7 presenta las conclusiones, interpretaciones y trabajos futuros
que se desprenden de este estudio.
I. OBJETIVOS
1.1 Objetivo General

Determinar el nivel de calidad interna del Sistema de Planeamiento de Asignatura,

mediante un análisis estático de código fuente, haciendo uso de las características y
sub características de la ISO/IEC 25000, con el software SonarQube.

II. METODOLOGÍA
2.1 Generalidades

• El Sistema que se va a evaluar está desarrollado en el lenguaje de programación C#.

• El sistema será evaluado con las sub características que detalla en la ISO/IEC
25010.

2.2 Herramientas

• SonarQube 8.6.1; es una herramienta que sirve para evaluar el código fuente y que a
su vez utiliza diversas herramientas de análisis estático.

2.3 Técnicas

• Análisis Estático de software; es un tipo de análisis de software que se realiza sin

ejecutar el programa.

III. PROCEDIMIENTO
3.1 ESTABLECER LOS REQUISITOS DE LA EVALUACIÓN
3.1.1 Establecer el propósito de la evaluación
El proyecto “Sistema de planeamiento de asignatura (SPA)” será evaluada para
poder asegurar la calidad del software y a su vez cumpla con las especificaciones
de las ISO 25010 y la 25040.
3.2 OBTENER LOS REQUISITOS DE CALIDAD DEL PRODUCTO
3.2.1 Registro de Interesados en el producto de Software
Tabla 1: Registro de interesados

NOMBRE ROL
Marco Arturo, Canales Aguirre Decano de la FIIS
Pedro Crisologo, Trujillo Natividad Jefe de Departamento Académico FIIS
William Rogelio, Marchand Niño Director de Escuela FIIS
- Ronald Eduardo, Ibarra Zapata
- Cristian, García Villegas
- Edwin Jesús, Vega Ventocilla
- Jorge Luis, Pozo Malpartida
- Brian Cesar, Pando Soto
- Hubel, Bonifacio Solis Docentes de la FIIS
- Rannoverng, Yanac Montesino
- Noel, Juipa Campo
- William George, Paucar Palomino
- Gardyn, Olivera Ruiz
- Eudolio Gregorio, Vásquez Pinedo
Fuente: Elaboración propia

3.2.2 Modelo de Calidad a Utilizar

El modelo que se empleará en el desarrollo del proyecto es a través del

ISO/IEC 25010.

Ilustración 1: Calidad del Producto

Fuente: ISO/IEC 25010

 3.3 IDENTIFICAR LAS PARTES DEL PRODUCTO QUE SE DEBEN EVALUAR
Tabla 2: Descripción de los Requisitos según las Sub Características

CARACTERISTICA SUBCARACTERISTICA EVALUACIÓN

Comportamiento
A
Temporal

EFICIENCIA DE Utilización de
A
DESEMPEÑO Recursos

Capacidad A

Aprendizaje B

Protección contra
USABILIDAD A
errores de usuarios

Estética B

Disponibilidad
A

FIABILIDAD Tolerancia a fallos A

Integridad A

SEGURIDAD Confidencialidad A

Capacidad de ser
A
Modificado
MANTENIBILIDAD
Capacidad de ser
A
Probado

PORTABILIDAD Adaptabilidad B

Fuente: Elaboración propia

Donde:

A = Buena
B = Regular
C = Mala
Cuadro Resumen

En este cuadro se muestra los resultados generales de la clasificación de los requisitos

de calidad conforme al grado de satisfacción que le fue otorgado.

Tabla 3: Resumen general de la cantidad de tipo de evaluación

GRADO DE SATISFACCIÓN CANTIDAD

BUENO 10
REGULAR 3
MALO 0
Fuente: Elaboración propia

3.4 DEFINIR EL RIGOR DE LA EVALUACIÓN

Se determinaron 3 niveles posibles para la evaluación para cada característica
y/o sub característica del modelo de calidad.

Tabla 4: Niveles de Evaluación

GRADO DE
DESCRIPCIÓN IMPORTANCIA (%)
SATISFACCIÓN
Cumple con todas las
características en todos BUENO 51 % - 100 %
los componentes
Cumple con algunas
características en REGULAR 11 % - 49 %
algunos componentes
No cumple con las
características en MALO 0 % - 10 %
ningún componente
Fuente: Elaboración propia
 IV. Metricas
SUB TIPO DE PROPÓSITO DE LA TIPO DE
CARACTERISTICA METRICA FÓRMULA VALOR DESEADO
CARACTERISTICA CALIDAD MÉTRICA MEDIDA
X=B-A
A: Tiempo de envío de la Deseado: x=3 seg. X = Tiempo
¿Cuál es el tiempo
Tiempo de Respuesta INTERNA petición. Pero caso: x>3 seg. A = Tiempo
estimado de respuesta?
B: Tiempo de recepción B = Tiempo
de la respuesta.
X=B–A
COMPORTAMIENTO ¿Cuál es el tiempo A: Tiempo cuando se X = Tiempo
Deseado: x=10 min
TEMPORAL Tiempo de Espera INTERNA estimado de envío de la inicia un trabajo. A = Tiempo
Pero caso: x>10 min
petición? B: Tiempo en completar B = Tiempo
un trabajo.
X = A/T
¿Cuántas tareas se A: Número de tareas Deseado: x>= 10/15 X = Tareas
EFICIENCIA DE Rendimiento INTERNA podrá realizar en un completadas min. A = # entero
DESEMPEÑO tiempo determinado? T: Intervalo de tiempo. Peor caso: 0/15 min. T = Tiempo
Dónde: T > 0
¿Cuánto espacio de X = A/B
UTILIZACION DE Utilización de la Deseado: 0%
EXTERNA memoria RAM puede A: Cantidad de memoria X = Mb
RECURSOS Memoria Peor caso: >=10%
consumir el sistema? usado para una tarea
X = A/T
X =
¿Cuál es la capacidad A: Número máximo de
Capacidad
Número de peticiones máxima de peticiones peticiones online Deseado: >= 10/3min
INTERNA A =
online (Máx.) realizadas por los procesada Peor caso: 0/3min
#peticiones
CAPACIDAD usuarios? T: Tiempo de Operación
T = Tiempo
Dónde: T > 0
X = A/T X =
Número de accesos ¿Cuál es la capacidad Deseado: >=10/3min
INTERNA A: Número máximo de Capacidad
Simultáneos (Máx.) máxima de accesos Peor caso: 0/3min
accesos simultáneos A = #accesos
 hechos por usuarios a la T: Tiempo de Operación T = Tiempo
vez? Dónde: T > 0

¿Qué cantidad de X=A/ B

funciones están A= Número de funciones
Efectividad de la
descritas descritas correctamente 0 <= X <= 1 X= Contable
documentación del
APRENDIZAJE EN USO correctamente en la B= Número total de Deseado: El más A= Contable
usuario o ayuda del
documentación del funciones cercano a 1 B= Contable
sistema
usuario o usuario en implementadas
línea? Dónde: B > 0
X=A/ B
A= Número de ítems de
entrada que son válidos 0 <= X <= 1 X= Contable
Verificación de ¿Qué cantidad de ítems
EN USO B= Número de ítems Deseado: El más A= Contable
entradas válidas de entrada son válidos?
que necesitan ser cercano a 1 B= Contable
validados
Dónde: B>0
X=A/ B
USABILIDAD PROTECCION
A= Número de
CONTRA ERRORES
operaciones iniciales
DE USUARIOS
incorrectas
¿Cuántas funciones
B= Número de funciones 0 <= X <= 1 X= Contable
Prevención del uso tienen la capacidad de
EN USO implementadas para Deseado: El más A= Contable
incorrecto evitar operaciones
evitar fallos de cercano a 1 B= Contable
incorrectas?
funcionamiento
provocados por un uso
incorrecto
Dónde: B>0
¿Qué cantidad de los X = A / B
Personalización de la elementos de la interfaz A= Número de 0 <= X <= 1 X= Contable
ESTÉTICA apariencia de la EN USO de usuario pueden ser elementos de interfaz Deseado: El más A= Contable
interfaz del usuario personalizados en que pueden ser cercano a 1 B= Contable
apariencia? personalizados
 B= Número total de
elementos de interfaz
Dónde: B>0
X=A/ B
A= Tiempo de servicio
del sistema que se
¿Cuál es el tiempo de proporciona
0 <= X <= 1 X= Tiempo
Tiempo de Servicio servicio del sistema que actualmente
EXTERNA Deseado: Cuánto mas A= Tiempo
proporciona B= Tiempo de servicio
se acerque al 1 B= Tiempo
realmente? del sistema regulado en
DISPONIBILIDAD el cronograma
operacional
Dónde: B>0
¿Cuál es el tiempo X=A/ T
X= Contable/
promedio que el A= Número de fallos Deseado: El más
Tiempo medio de Tiempo
EXTERNA sistema está inactivo B= Tiempo total de cercano a 0/T es lo
FIABILIDAD inactividad A= Tiempo
después de ocurrir un inactividad mejor
B= Contable
fallo? Dónde: T>0
X=A/ B
A= Número de
ocurrencia de fallas
evitadas contra los casos
¿Cuántas fallas iniciales X= Contable/
de pruebas de fallas 0 <= X <= 1
TOLERANCIA A estuvieron bajo control Contable
Prevención de fallos EXTERNA iniciales Deseado: Cuánto mas
FALLOS para evitar fallas serias A= Tiempo
B= Número de casos de se acerque al 1
y críticas? B= Contable
prueba de fallas iniciales
ejecutados durante las
pruebas
Dónde: B>0
¿Qué tan controlable 0 <= X <= 1 X= Contable/
Capacidad de control INTERNA/
SEGURIDAD CONFIDENCIALIDAD son los accesos al X = A / B Deseado: Cuánto mas Contable
de acceso EXTERNA
sistema? se acerque al 1 A= Contable
 A= Número de B= Contable
diferentes tipos de
operaciones ilegales
B= Número de tipos de
operaciones ilegales en
la especificación
Dónde: B>0
X=A/ T
¿Con qué facilidad el A= Número de
X=Contable /
desarrollador puede modificaciones
CAPACIDAD DE SER Complejidad de Deseado: El más Tiempo
EXTERNA modificar el software B= Tiempo de trabajo
MODIFICADO modificación lejano a 0/T A= Contable
para resolver que le toma al
B= Tiempo
problemas? desarrollador modificar
Dónde: T>0
X=A/ B
MANTENIBILIDAD A= Número de casos en
los cuales el
¿Con qué facilidad se
mantenedor puede X=Contable /
puede llevar a cabo las 0 <= X <= 1
CAPACIDAD DE SER Capacidad de reinicio pausar y restaurar las Contable
EXTERNA pruebas nuevamente Deseado: Cuánto más
PROBADO de pruebas pruebas A= Contable
después del se acerque al 1
B= Número de casos de B= Contable
mantenimiento?
prueba en la ejecución
de pruebas
Dónde: B>0
X=A/ B
A= Número de funciones
operativas que no se
¿Es el sistema lo X=Contable /
hayan completado con 0 <= X <= 1
Adaptabilidad en suficientemente capaz Contable
PORTABILIDAD ADAPTABILIDAD EXTERNA el entorno hardware Deseado: Cuánto más
entorno de hardware de adaptarse al entorno A= Contable
B= Número total de se acerque al 1
hardware? B= Contable
funciones que han sido
probadas
Dónde: B>0
V. DISEÑAR LA EVALUACIÓN
5.1 PLANIFICAR LAS ACTIVIDADES DE LA EVALUACIÓN
Tabla 5: Cronograma de Actividades

Diseño de instrumentos 8 de marzo 2021

Aplicación de instrumentos 10 de marzo 2021
Procesamiento de datos 12 de marzo 2021
Análisis de resultados 13 de marzo 2021
Socialización de resultados 15 de marzo 2021
Elaboración del informe final 20 de marzo 2021
Socialización del informe final 22 de marzo 2021
Fuente: Elaboración propia
VI. RESULTADOS
ANALIZANDO CON SONARQUBE

6.1 Perfil de calidad integrado

C# CSS

JavaScript HTML
 4.2 Analizando los bugs de código e identificando la métrica y sub
característica a la que afecta directamente.
Cuadro
NÚMERO DE SUB
LENGUAJE CODIGO DE ERROR MÉTRICA SEVERIDAD
OCURRENCIAS CARACTERÍSTICA

csharpsquid:S4487 1 Complejidad de Capacidad de ser Crítico

C# modificación Modificado

csharpsquid:S4144 1 Complejidad de Capacidad de ser Mayor

C#
modificación Modificado
- Capacidad de
reinicio de - Capacidad de
pruebas. ser Modificado
csharpsquid:S2933 3 Mayor
C# - Capacidad de
- Complejidad de ser probado
modificación
Complejidad de Capacidad de ser
csharpsquid:S125 7 Mayor
C# modificación Modificado
Prevención de Tolerancia a
csharpsquid:S3925 2 Mayor
C# fallos fallos
Complejidad de Capacidad de ser
C# csharpsquid:S1118 1 Mayor
modificación Modificado
Accesibilidad Accesibilidad
Web:TableHeaderHasIdOrScopeCheck 25 Mayor
HTML física técnica
Tiempo de Comportamiento
HTML Web:S5254 1 Mayor
respuesta temporal
Personalización
de la apariencia
Web:S5255 2 Estética Mayor
HTML de la interfaz del
usuario

Fuente: Elaboración propia

 Ilustración 2: Porcentaje total de ocurrencias

Fuente: SonarQube
En la Ilustración 2 se puede apreciar los resultados que nos brinda la herramienta SonarQube,
obteniendo un porcentaje de 0.2% de código duplicado, 46 bugs, 1 Security Hotspots y 132
Code Smells, cuya duración para poder solucionar estos conflictos en el código fuente es de 7
horas con 59 minutos.

Ilustración 3: Porcentaje total de ocurrencias

Porcentaje total de ocurrencias de errores

2; 5%
1; 3%
7; 18%

csharpsquid:S125
2; 5%
csharpsquid:S3925
1; 3%
csharpsquid:S1118

Web:TableH eaderHasIdOrScopeCheck

25; 66% Web:S5254

Web:S5255

Fuente: Elaboración propia

 Ilustración 4: Número de Ocurrencias por Código

NÚMERO DE OCURRENCIAS
30

20
NÚMERO DE
10 OCURRENCIAS
0

Fuente: Elaboración propia

En la ilustración 4 se observa el número de veces que se repite un código de Bug,

dándonos a conocer que dicho bug pertenece a una parte de codificación realizado en
el lenguaje HTML.
VII. CONCLUSION

✓ De los resultados obtenidos en el análisis estático respecto a la herramienta

SonarQube se obtuvo un total de 43 bugs en el código fuente.

✓ Del análisis que se obtuvo se verificó 8 repeticiones y 1 crítico.
✓ Referente al Codigo sucio (Code Smell) es fácil de solucionar y no afectaría gravemente
el desempeño del sistema.

VIII. RECOMENDACIÓN
• Se recomienda comentar el código en cada método desarrollado.
• Implementar herencia para los archivos con código repetido.