TL-Donayre J-Ext

FACULTAD DE CIENCIAS EMPRESARIALES
CARRERA PROFESIONAL DE INGENIERIA DE

SISTEMAS EMPRESARIALES
“IMPLEMENTACIÓN DE LA NORMA TÉCNICA PERUANA 9126-3

2005 PARA MEJORAR LA CALIDAD DEL SOFTWARE S.O.S
TESIS DE LA EMPRESA OCEAN SRL, 2021”
Tesis para optar el título profesional de:

INGENIERO DE SISTEMAS EMPRESARIALES
Presentado por:
Julio Francisco Donayre Martínez (0000-0001-6531-5255)
Asesor:
Hugo Eladio Chumpitaz Caycho (0000-0001-6768-381X)
Lima – Perú
2022
2
INFORME DE REVISIÓN DE ORIGINALIDAD
Título del documento evaluado. Implementación de la Norma Técnica Peruana 9126-

3 2005 para mejorar la calidad del software S.O.S Tesis de la empresa Ocean SRL 2021
Autores. Julio Francisco Donayre Martínez.
Mecanismo de revisión de originalidad. Evaluación con Turnitin (ID 1943887939).
Resultado de la evaluación. 9%
Revisado por. Magaly Kelly Guerrero Huaracallo.
Comentarios sobre la revisión. Filtros usados: excluir fuentes de menos de 12

palabras.
3
DEDICATORIA
Gracias a Dios, por haberme dado la vida, acompañado a lo largo

de mi carrera, por ser la luz en mi camino y por darme la
sabiduría y fortaleza para alcanzar mis objetivos.
A mis Padres, Reyna y Máximo por haberme forjado como

persona, mucho de mis logros se los debo a ustedes. A mi
mamita Betty, por el amor incondicional a lo largo de mi vida
personal y profesional, seres a quienes adoro desde lo más
profundo de mi corazón, por ser los artífices en la culminación
de mis estudios superiores con sus consejos y el impulso
constante para salir adelante.
A mi esposa, Katya porque siempre eres mi fuerza y

complemento en cada proyecto, tú has sido una pieza
fundamental porque me acompañas en todos los momentos
buenos y malos, pero siempre estuviste motivándome y
ayudándome hasta donde tus alcances lo permiten, te amo
mucho amor.
A mis hermanos, Wilfredo y John mis mejores amigos y

compañeros de vida quienes han vivido de cerca los distintos
procesos de mi vida. Gracias por el respaldo y cariño que siempre
me han brindado, impulsándome a salir adelante, además de
saber que mis logros también son los suyos.
A mis Hijos, Julio por ser ese gran amigo, confidente y mi bastón
en este camino de vida y Valentino que con su inocencia fue
parte importante en este proyecto, solo quiero que sepan que
no importa cuantas pruebas se me presenten en el camino o
cuan largo sea, al final uno tiene que seguir luchando para
alcanzar sus sueños. Los quiero mucho.
4
AGRADECIMIENTOS
A la Universidad Científica del Sur, que me dio la

bienvenida y me abrió sus puertas de su seno científico
para poder estudiar mi carrera, así como a los
diferentes docentes que me brindaron sus
conocimientos a lo largo de mi carrera profesional.
Agradezco a mi asesor de Tesis Dr. Hugo Eladio

Chumpitaz Caycho, por compartir sus conocimientos y
guiarme en el proceso de la presente tesis y a mi buen
amigo Rodrigo Manrique Tejada, a quien agradezco
por ser parte de este hermoso proyecto y mi gusto por
la investigación.
El camino fue largo con muchas pruebas, pero he

logrado concluir con éxito un proyecto que en un
principio podría parecer una tarea titánica e
interminable.
Mi más sincero agradecimiento y felicitaciones por todo

el conocimiento, paciencia y trabajo fuerte en equipo
realizado, para lograr producir todo lo que aquí se
presenta.
5
ÍNDICE GENERAL
Dedicatoria ....................................................................................................................... 3
Agradecimientos ............................................................................................................... 4
Índice general ................................................................................................................... 5
Índice de figuras ............................................................................................................... 8
Índice de tablas ................................................................................................................. 9
Índice de anexos ............................................................................................................. 11
Resumen ......................................................................................................................... 12
Abstract .......................................................................................................................... 13
Introducción ................................................................................................................... 14
CAPITULO I: PLANTEAMIENTO DEL PROBLEMA ............................................................. 15
1.1. Descripción de la realidad problemática............................................................ 15
1.2. Formulación del problema ................................................................................. 18
1.2.1. Problema general...................................................................................... 18
1.2.2. Problemas específicos .............................................................................. 18
1.3. Justificación de la investigación ......................................................................... 19
1.4. Limitaciones de la investigación ......................................................................... 21
1.5. Viabilidad de la investigación .................................................................................. 22
CAPITULO II: MARCO TEORICO ....................................................................................... 24

6
2.1. Antecedentes de la investigación ............................................................................ 24
2.1.1. Internacionales ..................................................................................... 24
2.1.2. Nacionales ............................................................................................. 26
2.2. Bases teóricas .......................................................................................................... 31
2.3. Objetivos de la investigación ................................................................................... 43
2.3.1. Objetivo general ....................................................................................... 43
2.3.2. Objetivos específicos ................................................................................ 43
2.4. Formulación de hipótesis ........................................................................................ 44
2.4.1. Hipótesis general ...................................................................................... 44
2.4.2. Hipótesis especificas ................................................................................. 45
CAPITULO III: DISEÑO METODOLÓGICO ......................................................................... 46
3.1. Diseño de la investigación ....................................................................................... 46
3.2. Tipo de investigación ............................................................................................... 46
3.3. Enfoque.................................................................................................................... 46
3.4. Población ................................................................................................................. 46
3.5. Muestra ................................................................................................................... 47
3.6. Operacionalización de variables .............................................................................. 48
3.7. Técnicas para la recolección de datos ..................................................................... 49
3.8. Técnica para el procesamiento y análisis de datos ................................................. 49
3.9. Aspectos éticos ........................................................................................................ 50

7
CAPITULO IV: RESULTADOS ............................................................................................ 51
4.1 Resultados Fuente Secundaria ................................................................................. 51
4.2 Resultados Fuente Primaria...................................................................................... 79
4.3 Comprobación de Hipótesis ................................................................................... 111
CAPITULO V: DISCUSION, CONCLUSIONES Y RECOMENDACIONES ............................. 121
5.1. Discusión ................................................................................................................ 121
5.2. Conclusiones .......................................................................................................... 126
5.3. Recomendaciones.................................................................................................. 128
Referencias bibliográficas ............................................................................................. 130
Bibliografía .................................................................................................................... 130
Abreviaturas ................................................................................................................. 135
Anexos .......................................................................................................................... 136
Anexo 1: Matriz de consistencia ................................................................................... 137
Anexo 2: Matriz de operacionalización ........................................................................ 138
Anexo 3: Encuesta/instrumento de evaluación ........................................................... 139
Anexo 4: Constancia emitida por la institución donde se realizó la investigación ...... 140
8
ÍNDICE DE FIGURAS
Figura 1. Relación entre tipos de métricas ..................................................................... 37
Figura 2. Proceso general MOF y ROF ............................................................................ 82
Figura 3. Organigrama Funcional OCEAN SRL ................................................................ 83
Figura 4. Formato de Proyecto ....................................................................................... 86
Figura 5. Desarrollo Software S.O.S. Tesis ...................................................................... 87
Figura 6. Acceso al S.O.S. Tesis ....................................................................................... 91
Figura 7. Diseño y distribución S.O.S. Tesis .................................................................... 91
Figura 8. Comunicación S.O.S. Tesis ............................................................................... 92
Figura 9. Despliegue y Decisión usuario S.O.S. Tesis ...................................................... 92
Figura 10. Error en Forma de Estilo de Referencia S.O.S. Tesis...................................... 94
Figura 11. Error en Desarrollo de Instrumentos S.O.S. Tesis ......................................... 94
Figura 12. Métrica de Precisión Cálculo Muestra S.O.S. Tesis ....................................... 95
Figura 13. Aporte de Mejora de la Calidad S.O.S. Tesis.................................................. 96
Figura 14. Percepción de NTP en Calidad de S.O.S. Tesis ............................................. 107
Figura 15. Percepción de S.O.S. Tesis con NTP ............................................................. 111

9
ÍNDICE DE TABLAS
Tabla 1. Criterios de calidad en modelos conceptuales ................................................. 32
Tabla 2. Características dependientes según ISO/IEC 25012 ......................................... 33
Tabla 3. Características inherentes según ISO/IEC 25012 .............................................. 34
Tabla 4. Características compartidas según ISO/IEC 25012 ........................................... 34
Tabla 5. Correspondencia entre las características ISO 9126 e ISO/IEC 25012 ............. 36
Tabla 6. Calidad de Software .......................................................................................... 40
Tabla 7. NTP 9126-3 2005 Métricas de Funcionabilidad ................................................ 52
Tabla 8. NTP 9126-3 2005 Métricas de Fiabilidad .......................................................... 57
Tabla 9. NTP 9126-3 2005 Métricas de Usabilidad......................................................... 60
Tabla 10. NTP 9126-3 2005 Métricas de Eficiencia ........................................................ 65
Tabla 11. NTP 9126-3 2005 Métricas de Mantenimiento .............................................. 69
Tabla 12. NTP 9126-3 2005 Métricas de Portabilidad .................................................... 71
Tabla 13. Distribución de Métricas NTP9 126-3 2005 .................................................... 77
Tabla 14. Resultados de Funcionabilidad Antes y Después de la NTP ........................... 98
Tabla 15. Resultados de Fiabilidad Antes y Después de la NTP ..................................... 99
Tabla 16. Resultados de Usabilidad Antes y Después de la NTP .................................. 100
Tabla 17. Resultados de Eficiencia Antes y Después de la NTP .................................... 101
Tabla 18. Resultados de Mantenimiento Antes y Después de la NTP.......................... 102
Tabla 19. Resultados de Portabilidad Antes y Después de la NTP ............................... 103
Tabla 20. Percepción de Métricas NTP aplicada a S.O.S. Tesis .................................... 104
Tabla 21. Percepción de usuarios antes de NTP........................................................... 108
Tabla 22. Diferencia en Métricas de Funcionabilidad .................................................. 121
Tabla 23. Diferencia en Métricas de Fiabilidad ............................................................ 122

10
Tabla 24. Diferencia en Métricas de Usabilidad ........................................................... 123
Tabla 25. Diferencia en Métricas de Eficiencia............................................................. 124
Tabla 26. Diferencia en Métricas de Mantenimiento .................................................. 125
Tabla 27. Diferencia en Métricas de Portabilidad ........................................................ 126

11
ÍNDICE DE ANEXOS
Anexos .......................................................................................................................... 136
Anexo 1: Matriz de consistencia ................................................................................... 137
Anexo 2: Matriz de operacionalización ........................................................................ 138
Anexo 3: Encuesta/instrumento de evaluación ........................................................... 139
Anexo 4: Constancia emitida por la institución donde se realizó la investigación ...... 140
12
RESUMEN
El trabajo de investigación, consideró como objetivo el analizar de qué manera la
implementación de la Norma Técnica Peruana 9126-3 2005 incide en la calidad del
software S.O.S. Tesis de la empresa OCean SRL, 2021, para ello se ejecutó un diseño
experimental, de tipo puro, con un enfoque cuantitativo, aplicando técnicas de
entrevistas y encuestas, con instrumentos de entrevista semiestructurada a 5
trabajadores de la empresa y un cuestionario de percepción a 100 usuarios del software.
Se analizó la NTP 9126-3 2005, dada por el Instituto Nacional de la Calidad (INCAL), de
la que se obtuvo las características y criterios que se evaluaron y que permitieron
comprobar mejoras en las métricas de funcionabilidad, confiabilidad, usabilidad,
eficiencia, mantenimiento y portabilidad, por lo que se concluye que se da una
diferencia de las 71 métricas, de las cuales 42 mejoran, lo que es un 60% del producto
final, además que si hay diferencia significativa, pues de 14 métricas, se aprecia un
cambio en sus indicadores en 13 de las mismas y la NTP si incide en la confiabilidad del
software, pues 9 de 9 métricas cambiaron, en la usabilidad 8 de 18, en el mantenimiento
7 de las 7, en la eficiencia 1 de 11 y en la portabilidad 4 de 12. Por lo que la
implementación de la NTP es favorable en la calidad del software.
Palabras Claves: Norma Técnica Peruana 9126-3 2005, calidad, software, S.O.S Tesis
13
ABSTRACT
The research work considered as an objective to analyze how the implementation of the
Peruvian Technical Standard 9126-3 2005 affects the quality of the software S.O.S.
Thesis of the company OCean SRL, 2021, for this an experimental design was executed,
of pure type, with a quantitative approach, applying techniques of interviews and
surveys, with semi-structured interview instruments to 5 workers of the company and a
questionnaire to 100 users of the software. The NTP 9126-3 2005, given by the National
Institute of Quality (INCAL), from which the characteristics and criteria that were
evaluated and that allowed to verify improvements in the metrics of functionality,
reliability, usability, efficiency, maintenance and portability were obtained, so it is
concluded that there is a difference of the 71 metrics, of which 42 improve, which is
60% of the final product, in addition to that if there is a significant difference, because
of 14 metrics, a change in its indicators is appreciated in 13 of them and the NTP if it
affects the reliability of the software, because 9 of 9 metrics changed, in usability 8 of
18, in maintenance 7 of the 7, in efficiency 1 of 11 and in portability 4 of 12. So the
implementation of the NTP is favorable in the quality of the software.
Keywords: Peruvian Technical Standard 9126-3 2005, quality, software, S.O.S Thesis
14
INTRODUCCIÓN
El desarrollo de las actividades de las personas, considera en estos tiempos, el uso de
software, con los cuales se puedan optimizar los tiempos y hacerlos más eficientes y
eficaces, sin embargo, existen todo tipo de calidades en estos, por lo que se establece,
en el Instituto Nacional de Calidad (INACAL) una Norma Técnica Peruana (NTP), que
permita dar métricas a las características internas que debe de cumplir los softwares,
pues se tiene relacionado que si desde la fabricación se tiene buenas métricas en su
desarrollo, entonces, los usuarios pueden tener un mejor nivel de satisfacción sobre el
software. La empresa OCean SRL, fundada en el 2003, diseñó y propuso, en su unidad
de Tecnologías de información, diferentes productos, uno de ellos es el denominado OC
Tesis, que desde el año 2006 se presenta como una alternativa para que las personas,
que así lo deseen, puedan tener un aprendizaje y/o uso en el desarrollo de las tesis
universitarias. En la actualidad, el software es denominado S.O.S. Tesis y al haberlo
desarrollado sin la intervención de ninguna NTP, es que se plantea el hecho de analizar
de qué manera la implementación de la Norma Técnica Peruana 9126-3 2005 puede
incidir en la calidad del software, para que, de los resultados, la gerencia determine el
uso de las NTP en sus demás softwares.
El trabajo se ha planteado en cinco capítulos, en el primero se aprecia el planteamiento
del problema, en la cual se presentan las preguntas guía del trabajo desarrollado, para
luego, en el capítulo segundo, se puede ver todo el marco teórico, sustento de lo que se
ejecutó, mientras que, en el capítulo tercero, se plasma todo el diseño metodológico, y
así llegar a los resultados en el capítulo cuarto, siendo por último el capítulo de
discusión, conclusiones y recomendaciones.

15
CAPITULO I: PLANTEAMIENTO DEL PROBLEMA
1.1. Descripción de la realidad problemática
En el Mundo, dentro de la industria del software, hablar de calidad del software, es
comentar la preocupación por fabricarlos con mejores estándares, para obtener de ellos
la mayor satisfacción de todos los usuarios, pues los parámetros con los que deben de
cumplir son los mínimamente requeridos por el mercado, como la Funcionalidad,
Usabilidad, Fiabilidad, Rendimiento y Compatibilidad. El problema al inicio de la
industria, fue como identificar los criterios para calificar que el software es de calidad,
considerando que esta calificación pasaría de lo cualitativo a lo cuantitativo, por eso que
los primeros factores cualitativos que se dieron, se aprecian en los factores de calidad
de McCall (Ramos, 2019), así como los que llega a proponer Hewlett Packard (FURPS:
Funcionality, Usability, Reliability, Perfomance, Supportability – Funcionalidad,
Usabilidad, Fiabilidad, Rendimiento, Compatibilidad). Luego de varias propuestas es que
se presenta el de la International Standard Organization (ISO) con lo cual se plantea los
principales en la familia de normas ISO 9000, como son la ISO 9001 y la ISO 9003-2, el
modelo de niveles de madurez CMM (Capability Maturity Model), es otra de las
presencias de estandarización, también se ve el aseguramiento de planes de calidad del
IEEE 730: 1984 y la norma ISO/IEC 9126 (Abud, 2004).
En el Perú, también se presentan fábricas de software, que comienzan a establecer sus
calidades en base a lo señalado por las organizaciones internacionales, hasta que llega
el año 2005, donde el Instituto nacional de la Calidad (INCAL), emite la NTP ISO/IEC-TR
9126-3: 2005 Software Engineering. Product quality. Part 3: Internal Metrics (Ingeniería
de Software. Calidad del producto. Parte 3: Métricas Internas. 1ra. Edición 13/05/2008)
(Instituto Nacional de Calidad, 2005) con lo cual se define, para Perú las métricas que se
16
debe de tener en cuenta en el desarrollo de software, las mismas que pueden ser
medibles. Dentro de esta norma, aprobada por Resolución de INDECOPI, (R. 18-2005-
CRT-INDECOPI) el 2005, marzo 20, le da un clasificador de 62 – Actividades de la
tecnología de información y del servicio informático y un subclasificador 6201 –
Programación Informática, Ingeniería de Software, Sistemas de Información y Gestión
de Proyectos del Instituto Nacional de la Calidad (INACAL, 2021).
El 20% de las organizaciones privadas, desarrollan en una de sus modalidades, la
producción de software, con el fin de aportar al desarrollo territorial (Manrique y
Manrique, 2020). Se publica la NTP ISO/IEC-TR 9126-3:2005 INGENIERIA DE SOFTWARE.
Calidad del producto. Parte 3: Métricas internas, para que la producción de software,
considere el uso de métricas para alcanzar una mejor calidad en sus entregables. Dentro
de estas organizaciones privadas, se puede encontrar una que produce un software que
se relaciona con el desarrollo de Tesis de universidad. La ley 30220, Ley Universitaria,
indica que una de las alternativas para optar un grado, es por la sustentación de una
tesis, como lo señala el Ministerio de Educación del Perú (MINEDU, 2014), la misma que
permite el desarrollo de nuevos conocimientos o la explicación a hechos, que desde un
punto puedan alcanzar diferentes grados de madurez con relación a proyectos; esos
grados son denominados TRL (Technology Readiness Levels) o Nivel de Madurez
Tecnológica (Consejo Nacional de Ciencia, Tecnología e Innovación Tecnológica) , que
van desde los TRL 1, que considera una investigación tipo básica con un producto
entregable como es una publicación de artículo en revista indexada, hasta el nivel 9, que
es la masificación de lo que se innovó y su aceptación en el mercado.
Para el Sistema Integrado de Información de Comercio Exterior (SIICEX, 2009), en
América Latina, las inversiones en Tecnologías de Información y Comunicaciones (TIC),

17
tienen concentraciones en un 51.4% para Hardware, un 31.7% para servicios y un 16.8%
para software. Se puede ver que, en esta industria, se registraban 300 empresas
formales con unos 30,000 programadores de sistemas y 6,000 puestos de trabajo
directo, altamente tecnificado, lo que hacía un promedio de 20 personas x empresa, así
también, señala el documento que se dan 9,000 puestos de trabajo indirecto. Se señala
que, en el Perú, solo el 1% de las empresas cuentan con International Standard
Organization (ISO), por lo que los niveles de calidad, exportables, pueden estar aun con
una gran brecha. Pero a pesar de ello, las empresas de software que ya exportan son
cada vez mayores y gracias a las certificaciones que obtienen. Si se considera que las
certificaciones ISO ayudan a que las empresas puedan expandirse, en mercados
exteriores, se puede ver, por el resultado del 1%, que no todos lo visualizan de esa
forma. Pero tener una ISO, no solo, permitiría ampliar el mercado externo, sino que
también puede lograr un mejor posicionamiento en el mercado nacional.
La empresa OCean SRL, constituida desde el año 2003, tiene una línea de producción
relacionada a TIC, con un software denominado S.O.S. Tesis. Los usuarios pueden tener
acceso y uso gratuito de este software, por medio de internet, en una plataforma web.
Esta plataforma, que tiene menos de tres (3) años, nunca tuvo la aplicación de métricas
de calidad, en el desarrollo de software, a pesar de sus cambios anuales que se
presentan en sus versiones de mejora constante. Implementar una Norma Técnica
Peruana (NTP), brindada por la INCAL, puede ser tan favorable como una conducta
permanente en los diferentes servicios que brindan con el desarrollo de software de la
empresa, ese es el objetivo que se plantea en el presente trabajo, con el fin de asegurar
la continuidad de su posicionamiento y posible expansión de mercado. Cuando se habla
de calidad y de mejora, se puede tener diversas interpretaciones, sin embargo, el uso

18
de la Norma Técnica Peruana (NTP) 9126-3, permitiría que se planteen y replanteen todo
lo relacionado, no solo al proceso propio de la producción, como es la ingeniería del
software, sino también en tener las métricas desde el usuario final. El proceso de
implementación se ejecutará en la empresa, con lo cual se recopilará información que
pueda ser empleada en los demás procesos de ingeniería de software y en empresas
similares, aportando con ello, al desarrollo de producto peruano con calidad, basada en
las Normas Técnicas Peruanas, diseñadas y accesibles a un costo establecido por el
Instituto Nacional de Calidad , en beneficio del desarrollo territorial.
1.2. Formulación del problema
Para una mejor comprensión del presente trabajo de investigación, se consideró los
siguientes problemas:
1.2.1. Problema general
¿De qué manera la implementación de la Norma Técnica Peruana 9126-3 2005,
incide en la calidad del software S.O.S Tesis de la empresa OCean SRL, 2021?
1.2.2. Problemas específicos
Para el caso de los problemas específicos se consideran los siguientes:
• ¿De qué manera la implementación de la Norma Técnica Peruana 9126-3 2005,
incide en la funcionalidad del software S.O.S. Tesis de la empresa OCean SRL,
2021?
incide en la confiabilidad del software S.O.S. Tesis de la empresa OCean SRL,
2021?
19
incide en la usabilidad del software S.O.S. Tesis de la empresa OCean SRL, 2021?
incide en la capacidad de mantenimiento del software S.O.S. Tesis de la empresa
OCean SRL, 2021?
incide en la eficiencia del software S.O.S. Tesis de la empresa OCean SRL, 2021?
incide en la portabilidad del software S.O.S. Tesis de la empresa OCean SRL,
2021?
1.3. Justificación de la investigación
El desarrollo del trabajo de investigación consideró su justificación en los siguientes
puntos:
Justificación Académica
La teoría del conocimiento siempre será el aporte que se dará en todo trabajo de
investigación, pues las conclusiones a las que se llegan pueden ser empleadas como
parte de los estados del arte de otros trabajos futuros, ya sea por continuidad o
referente. Entonces, a nivel teórico, brindará mayor aporte a la teoría del conocimiento
y estados del arte dentro de la línea de investigación, como es calidad en la ingeniería
del software. Los resultados de proceso de investigación indicaran que problemas se
presentaron para implementar la NTP en la unidad de estudio, como se solucionó y que
medidas la NTP podría cambiar, debido a la posible existencia de barreras que no

20
puedan ser superadas o que tengan una métrica muy baja a la que se esperaba
(Manrique y Manrique, 2020).
Justificación Social
Se considera el desarrollo del presente trabajo de investigación con el fin de aportar a
las personas que tienen proyectos en I+D+i en beneficio del Perú, por lo que facilitar su
gestión es siempre importante, pues la tesis que hacen, en pregrado o posgrado, son en
beneficio de la sociedad, por eso es que si se tiene un software que ayuda hacer la tesis,
con una calidad de producto mayor, las personas tendrán más confianza en su uso y este
permitirá que obtengan mayores satisfacciones por los resultados que tienen, es decir,
sus tesis ejecutadas en un software que ha superado la métrica de la calidad, permite
que se tenga un producto más para disminuir la brecha, entre egresados y graduados
(Manrique, 2020).
Justificación Técnica
Con el pasar de los tiempos, el uso de las TIC en las actividades de las personas, se tiene
presente, más aún con la Pandemia, entonces, la justificación técnica para el desarrollo
del software es que se brindará un software con una calidad que cumpla las métricas de
la NTP, para que se pueda integrar en la producción de todos sus softwares, ya que la
empresa cuenta con más de 18 años en el mercado y recién se implementará una NTP
(Chávez, 2014).
Justificación Económica
21
Implementar la NTP en el software S.O.S. Tesis, permitirá analizar y solucionar los
problemas que hoy el software tiene, es decir, será un prototipo, ya que este software
se da en forma gratuita; y de ser exitoso, los resultados recopilados de los usuarios, es
decir, que antes era malo y ahora es mejor, motivará a que se implemente en el resto
de desarrollo de los otros softwares que tiene la empresa. Si actualmente, se viene
dando en crecimiento promedio del 8% del mercado anual en la empresa, sin NTP, se
espera que del crecimiento del 10% que se da en la industria del sector, por lo menos el
2% sea para la empresa, lo que significaría mayores ingresos económicos, gracias a la
satisfacción de los usuarios de los softwares. (Manrique y Revollar, 2012).
1.4. Limitaciones de la investigación
La investigación se limita a la unidad de estudio que es la empresa OCean SRL y a su
ejecución que se dará en el período 2020-2021. No se tiene limitación alguna sobre
complicaciones que se puedan presentar, pues se cuenta con el apoyo de la gerencia
general de la empresa, para la implementación de la NTP. Un limitante material, fue el
acceso a la base de datos de los clientes, pues la Gerencia Administrativa, señaló que
por Ley de Protección de Datos Personales, Ley N° 29733, se recopila los datos de los
usuarios única y exclusivamente para darles el acceso a la plataforma, respetando con
ello el Artículo 6 de la ley, que señala como principio de finalidad, que todos los datos
personales: se requiere buscar datos específicos en fuentes confiables. El uso de la
información de carácter personal no se difunde sin la autorización del autor, excluyendo
los casos de interés público (Diario El Peruano, 2013).

22
Bajo ese estricto cumplimiento es que la información requerida de los usuarios, se
aceptó que la empresa sería quien, a través de sus canales con los clientes, proporcione
la recolección de información, por medio de los instrumentos presentados.
1.5. Viabilidad de la investigación
La investigación se limita a la unidad de estudio que es la empresa OCean SRL y a su
ejecución que se dará en el período 2020-2021. No se tiene limitación alguna sobre
complicaciones que se puedan presentar, pues se cuenta con el apoyo de la gerencia
general de la empresa, para la implementación de la NTP.
Viabilidad Técnica
Los recursos tales como, equipos informáticos con el adecuado procesamiento, software
y otros recursos tecnológicos, son accesibles en la región donde se plantea realizar la
investigación.
23
Viabilidad Económica
Siendo los recursos económicos limitados para la investigación se desarrolló un cuadro
de costos y presupuesto para que se asigne de forma exacta a cada parte y proceso antes
y durante la investigación, garantizando la viabilidad económica.
Viabilidad Temporal
La investigación está prevista para ser realizada en seis (6) meses, tiempo adecuado para
realizar la investigación bibliográfica, realización de pruebas, aplicación de la
metodología propuesta y finalmente la redacción de resultados.

24
CAPITULO II: MARCO TEORICO
Dentro del presente capítulo, se establece todo el sustento del desarrollo del trabajo de
investigación.
2.1. Antecedentes de la investigación
2.1.1. Internacionales
Figueroa (2019) en su investigación denominada: La aplicación de modelo basado
en normas ISO/IEC 25000 para asegurar la calidad de plataformas E-Learning,
plantea como objetivo desarrollar una guía para la implementación de calidad en las
plataformas E-Learning. La metodología empleada fue una revisión bibliográfica,
dentro de lo que se refiere a una revisión sistemática, de las normas de calidad y de
los procesos E-Learning, de acuerdo con los instructores del centro de
entrenamiento de Tecnologías de la Información – CETI de Ecuador y el análisis de
las diferentes divisiones de la familia de normas ISO/IEC 25000. Esta revisión,
permite ser la base para que planteen un modelo propio, con el cual la calidad de
las plataformas E-learning, sea mejorada y así lograr indicadores de usabilidad
mayor, en la educación. Concluye que el uso de las TIC siempre beneficiará la
actividad del ser humano, en cualquiera de sus adaptabilidades.
También se puede señalar que Fabián (2015), en su trabajo titulado: Construcción
de un framework que facilite la implementación de VSE, según la norma ISO/IEC
29110, planteó como objetivo la construcción de un framework, logrando como
resultados obtenidos en su investigación, el hecho de tener como técnica la NDT
facilita que, respecto a tiempo y número de dispositivos de usabilidad, formulados
por las USEP’s se puede construir de forma óptima estos factores. Al realizar el
25
análisis con la ISO/IEC 9126-2 a través de la técnica de desarrollo NDT y la
incorporación de normas USEP’s de modo que se pueda cuantificar la calidad
externa de la facilidad de uso del prototipo funcional con la finalidad de detectar
anticipadamente en el desarrollo de software las necesidades del cliente y cumplir
con las expectativas. Mediante la incorporación de procesos y su adecuada
identificación se alcanzará el progreso de la entidad en cuestión. Y para ello se debe
seguir un procedimiento para concretar las metas alcanzadas sin la correcta
aplicación de este proceso se puede incurrir en riesgos que dificulten alcanzar los
estándares requeridos para conseguir la eficiencia en el proceso. Es por ello que el
trabajo, planteó una estructura que de viabilidad y adecuación al proceso VSEs,
conforme a lo establecido en la norma ISO/IEC TR 29110-5-1-2. Es por ello que al
implementar al framework el objetivo clave es otorgar viabilidad mediante un
seguimiento y evaluación de modo que instituciones más pequeñas puedan
adaptarlo. El trabajo de investigación, empleó como metodología experimental, los
cambios en el framework propuesto, empleando herramientas como: Meycor
CobiT, CMMI-Quest y IME Toolkit.
Por último, como señala Beltrán (2019), en su trabajo denominado: Aplicación de la
metodología SCRUM usando herramientas OpenSource facilitando el aseguramiento
de calidad de acuerdo con la Norma ISO/IEC9126, planteó las siguientes preguntas
¿Impacta el uso de metodologías ágiles, herramientas libres y buenas prácticas en
la reducción de los costos y tiempos para el aseguramiento en calidad de acuerdo
con la Norma ISO/IEC 9126? ¿Por qué utilizar múltiples herramientas libres,
metodologías ágiles, buenas prácticas, estándares de referencia y técnicas permiten
lograr una calidad en software a bajo costo? Las preguntas anteriores permitieron
26
durante la investigación aplicar una serie de herramientas para la gestión y creación
de funcionalidades complejas de forma sencilla disminuyendo los tiempos y
reduciendo los costos de producción. Orientadas a una arquitectura (MVC) y
metodología ágil sólida con el fin de obtener una evaluación en diferentes factores
y cualidades relacionados a la calidad pertenecientes a la norma ISO/IEC9126. El
método aplicado fue el análisis sistemático de literatura, y permite la
implementación de metodología SCRUM con una serie de herramientas Open
Source para facilitar el aseguramiento en calidad de acuerdo con la Norma ISO/IEC
9126, por lo que llega a concluir que aplicar SCRUM y otras opensource en WEB
Resposive asegura la calidad de las métricas de mantenibilidad, seguridad y
usabilidad. Además, la Web que empleó “Marca Personal” si cumplió los
requerimientos y expectativas esperadas. Considera en sus conclusiones que las
Buenas Prácticas y herramientas ágiles, intervienen en la relación costo-tiempo,
resaltando también que la Arquitectura MVC, da fortalezas para la seguridad y
mantenibilidad de la aplicación desarrollada.
2.1.2. Nacionales
Arangüena (2018), en su trabajo titulado: Sistema Web SWGPI en la gestión de
proyectos de investigación evaluado con la ISO/IEC 9126, planteó como objetivo
determinar la influencia del Sistema Web SWGPI al ser en la gestión de proyectos
de investigación de la Vicepresidencia de Investigación (VIPIN), de la Universidad
Nacional José María Arguedas (UNAJMA), para este trabajo la metodología constó
de un diseño pre-experimental con pre y post-prueba. Es así que con la finalidad de

27
gestionar los procedimientos de la investigación se desarrolló el sistema SWGPI, que
se fundamenta en la gestión de procesos (CMS) DRUPAL, para el caso de estudio se
empleó una muestra compuesta por 27 investigaciones regidos por la VIPIN (2017-
ii) a las cuales se les aplicó observaciones y cuestionarios todo esto adaptado a las
normas software ISO/IEC 9126. Se concluye que la implementación de este sistema
es eficiente a través de los módulos de ingreso y mantenimiento.
Asimismo, según los autores Fernández y Ramírez (2018), en su trabajo de
investigación titulado: Evaluación de modelo de calidad en uso para sitios web
institucionales utilizando la norma ISO/IEC 9126, determinó como finalidad el
análisis de la usabilidad mediante la ISO/IEC 9126 de la plataforma web de la
Universidad Señor de Sipán. Para la usabilidad es necesaria una pauta establecida.
La metodología que empleó fue una investigación descriptiva-cuantitativa, ceñido
al diseño no-experimental, además se utilizó un diseño mixto de modo que se aplicó
entrevistas y cuestionarios. La norma ISO/IEC 9126 sirvió de fundamento teórico
además se analizó el diseño metodológico WebQEM (Web Quality Evaluation
Methodology) analizando el instrumento SW-AQUA. Se obtuvo que la
productividad, efectividad y satisfacción son los factores de mayor valor, en
consecuencia, el modelo ISO 9126 fue el más adecuado para cumplir los estándares
de calidad. Finalmente, la investigación revela la insuficiencia en cuanto a
satisfacción y accesibilidad; por ello la plataforma web debe realizarse considerando
las exigencias de los clientes.
Moreno (2020), en su trabajo de investigación titulado: Modelo de gestión de
calidad basada en los estándares NTP 12207 e ISO 9126, para los procesos de
desarrollo de software: caso RENIEC, planteó como objetivo la creación de un

28
modelo de gestión de calidad que esté sustentado en la NTP 12207, ISO 9001 e ISO
9126, con el cual se puede tener los procesos de desarrollo de software en la
Subgerencia de Ingeniería de Software de la RENIEC. La metodología lo lleva a hacer
un análisis de siete (7) proyectos de un total de catorce (14), que fueron
desarrollados por la Subgerencia, empleando dos (2) instrumentos, encuestas, pre
y post implementación, tomando en cuenta un análisis documental previo. Detecta
defectos en los siete (7) proyectos, por lo que, al implementar el modelo, estos se
reducen significativamente (Pvalue = 0.0000). Al comprobar que la preprueba, tenía
un promedio de defectos por proyecto de ciento cincuenta y seis (156), estos se
reducen a dieciséis (16) defectos por proyecto con la implementación del sistema;
concluyéndose que existe una significativa diferencia en los promedios de defectos
en las correspondientes etapas de prueba. Además, indica que la innovación es
constante y debe de permitir el desarrollo de sus diferentes versiones.
En el mismo año, Pinedo (2020) el trabajo de investigación denominado: El Sistema
de Información Gerencial y su influencia en los procesos administrativos de una
universidad pública año 2018, planteó como objetivo general el hecho de
determinar la forma en que el Sistema de Información Gerencial podría mejorar los
procesos administrativos que se dan en la Universidad pública de Ucayali. Se emplea
encuesta dirigidas a ciento sesenta y cinco (165) docentes y se desarrolla un análisis
documental. Considera que las características del Sistema de Información Gerencial
tuvieron una gran calificación en los ciento sesenta y cinco (165) docentes que
intervinieron para emplearlo y brindar su percepción, por lo cual aceptó su hipótesis
nula, que demuestra una mejora de los procesos administrativos gracias al sistema
implementado, pues le dio un P-value de 0.0000, en un Rho. Finalmente se

29
determina que la información gerencial obtiene una optimización en cuanto a
procesos acorde a lo estipulado por la institución.
Otros trabajos considerados en el ámbito nacional fueron el de Román (2018), en su
trabajo denominado: Sistema de Información de gestión de escalafón para la
modernización del recurso humano en las Instituciones Públicas Andahuaylas 2017,
planteó como objetivo identificar la influencia del empleo de Sistemas de
Información en la escala utilizada en Recursos Humanos en entidades públicas de
Andahuaylas. Tiene como diseño, una propuesta experimental, para una población
de sesenta y cinco (65) instituciones públicas de Andahuaylas, de las que considera
una muestra a conveniencia de dos (2): La UGEL y la Municipalidad Provincial ambas
ubicadas en Andahuaylas. Logró identificar que la información que mantienen las
organizaciones es muy importante, tanto para la toma de decisiones como para
presentación de esta a las personas que lo requieran. La implementación del
Sistema de Gestión para el escalafón de las entidades públicas del distrito
Andahuaylas (UGEL) demostraron que los tiempos y costos se reducen, así como
también se aprecia una calificación satisfactoria por los usuarios. Por ello que se
concluye que, si el Estado se moderniza, empleando para ello múltiples elementos
como: las nuevas tecnologías, legislaciones de simplificación administrativa, gestión
por resultados, reingeniería de procesos, entre otros no menos importantes. Con la
implementación del sistema se logra optimizar el escalafón de ambas instituciones
públicas.
30
Dos años antes Seclén (2016), en su trabajo titulado: factores que afectan la
implementación del sistema de gestión de seguridad de la información en las
entidades públicas peruanas de acuerdo con la NTP-ISO/IEC 27001, planteó como
objetivo el análisis de la problemática que tienen para la implementar SGSI en
entidades públicas. El diseño cualitativo, afirma el autor, indica que la población
objetivo son las entidades públicas descentralizados que se encuentran adscritos en
la PCM. Los resultados del sistema de gestión se sustentan en la capacidad de los
sistemas informáticos, pues todo sistema de gestión contempla datos y el tamaño
de estos, así como su calidad, son las que dan los reportes para la toma de
decisiones, esto lo presentó en el VIII Congreso Internacional de Computación y
Telecomunicaciones COMTEL 2016. Las conclusiones presentan ocho (8) categorías
que afectan la implementación de un Sistema: uno (1) Estratégico (la política del
Estado), tres (3) en Operaciones (Apoyo a alta Dirección, Gestión de Seguridad,
organización del SGSI y normativa establecida y tres (3) Técnicas (Norma Técnica
Peruana, Presupuesto y Especialización de profesionales).
Considerar a los autores Ortiz y Huamán (2017), en su trabajo de investigación
titulado: Evaluación de metodologías de desarrollo Web bajo el paradigma de
desarrollo dirigido por modelos (MDD) con la integración de directrices para la
captura de requisitos de usabilidad medido por la ISO/IEC 912 para lograr la
satisfacción del cliente, contemplan que en la coyuntura social los softwares son más
elaborados y de mayor importancia en el día a día, en el reporte Chaos (2015)
enfatiza que un 29% de una muestra de 50,000 proyectos es el índice de éxito en los
proyectos, dicho éxito depende de identificar adecuadamente con los

31
requerimientos del usuario de modo que le permita adaptarse con facilidad en
consecuencia que sea de un uso fácil. La investigación, de diseño experimental, está
en función de metodologías Web UWE (de desarrollo) y NDT para identificación de
nuevas necesidades respecto a la usabilidad entorno a un software adaptado a las
normas ISO/IEC: 9126, 9241 y ISO 25000, en función a otras investigaciones se
desarrolló un diseño metodológico que enfatiza las necesidades que se tiene al
desarrollar un software Web, de las cuales se escogió NDT y UWE al incorporar la
metodología escogida se realiza la codificación. Un factor sobre calidad que jugó un
rol fundamental es la usabilidad analizada bajo el marco de la norma ISO/IEC 9126-
2. También Bejarano (2017) es trabajo denominado Propuesta de arquitectura de
software para el desarrollo de aplicativos móviles en el sector financiero usando el
enfoque de diseño arquitectual del SEI/CMU, mostró el desarrollo de una estructura
de pautas para la elaboración de un aplicativo móvil orientado al área financiera
utilizando la técnica °Attribute-Driven Design. De forma que se promueva un medio
seguro a través de la técnica ADD que consta de tres fases: el diseño, la
documentación y la evaluación permitiendo la usabilidad para el desarrollo del
aplicativo.
2.2. Bases teóricas
La propia calidad, establece el uso de Normas, que en el caso de Perú se toma en cuenta
la Norma Técnica Peruana (NTP) 9126-3 2005, que se sustenta en la ISO, por ello es
importante identificar que la mejora de la calidad del software, por medio de esta
norma, se puede lograr. Para ello es necesaria la comprensión de las métricas a emplear
en lo que se presentan las siguientes tablas, pues la calidad, como variable de

32
investigación, alcanza los términos en conceptualizaciones que se han desarrollado
alrededor de las ISO.
Tabla 1. Criterios de calidad en modelos conceptuales
Criterio Descripción
Está enfocado a las consideraciones visuales para la lectura

y presentación del modelo conceptual (ausencia de cruces
LEGIBILIDAD
entre las relaciones, superposiciones, tipografía clara, entre
otros).
El modelo debe incluir totalmente lo que se quiere diseñar,

que es aquello que se encuentra plasmado en los
COMPLETITUD requerimientos del sistema por desarrollar. En términos
generales, cada requerimiento debe ser representado en el
modelo. Y el modelo no debe incluir requerimientos
supuestos.
Se puede evaluar desde dos perspectivas:

• La sintáctica, cuando las distintas partes de un
modelo están construidas con respecto al lenguaje
CORRECCIÓN
utilizado.
• Y La semántica, cada elemento del problema se
representa haciendo uso de las estructuras
adecuadas.
Un modelo conceptual se considera mínimo si no tiene

MINIMALIDAD información redundante o duplicada, y, por consiguiente, si
se elimina un elemento del esquema se perderá
información.
El modelo representa la realidad, de manera que con sus

EXPRESIVIDAD elementos esta puede ser comprendida fácilmente. La
expresividad intenta medir la capacidad de comunicación
del modelo a nivel semántico.
En el modelo pueden ser representados todos los requisitos,

AUTOEXPLICACIÓN por consiguiente, la lógica del negocio con respecto a los
datos puede ser accedida y entendida por el modelo
conceptual.
EXTENSIBILIDAD Se refiere a la capacidad de un esquema para poder tolerar

cambios en los requisitos y adaptarse a nuevas necesidades
33
de los usuarios de la base de datos, es decir, el esquema
fácilmente se descompone en partes (módulos, vistas).
Fuente: Varas y Pradenas (2000)
Como se puede ver en la Tabla 1. Criterios de calidad en modelos conceptuales, se
propone analizar siete criterios que permitan alcanzar la calidad que se requiere en un
producto, esto aporta para una conceptualización sobre lo que debe de cumplir para
que el cliente – usuario, tenga un mejor producto en su ejecución. En base a ello es que
se presentan también, en la siguiente tabla, las características que se dan según la
ISO/IEC 25012.
Tabla 2. Características dependientes según ISO/IEC 25012
Disponibilidad El grado en el cual el dato tiene atributos que le permiten

(Availability) ser recuperados por usuarios autorizados o por aplicaciones
en un contexto específico de uso.
El grado en el cual el dato tiene los atributos que le permiten

Portabilidad
ser instalado, substituido o movido de un sistema a otro
(Portability)
conservando la calidad existente en un contexto específico
de uso.
El grado en el cual el dato puede mantener y conservar un

Recuperabilidad
nivel especificado de operaciones y calidad, aún en caso de
(Recoverability)
falla.
Fuente: García (2009)
Como se puede ver en la Tabla 2. Características dependientes según ISO/IEC 25012,
las dimensiones que dependen son la de disponibilidad, portabilidad y recuperabilidad,
es decir, la calidad del software, tendrá que permitir que esa dependencia se cumpla.
34
Además de esta dependencia, se toma en cuenta las que son propias a la ISO/IEX 25012,
que se muestran en la siguiente tabla:
Tabla 3. Características inherentes según ISO/IEC 25012
El grado en el cual el dato tiene atributos que representan

Exactitud correctamente el valor del atributo intencionado de un
(Accuracy) concepto o evento en un contexto específico de empleo.
El grado en el cual el dato del sujeto asociado con una

Completitud
entidad tiene valores para todos los atributos esperados e
(Completeness)
instancias de entidad relacionadas en un contexto específico
de uso.
Consistencia El grado en el cual el dato tiene los atributos que son libres
(Consistency) de contradicción y son coherentes con otros datos en un
contexto específico de uso.
El grado en el cual el dato tiene atributos que son
Credibilidad
considerados verdaderos y creíbles por usuarios en un
(Credibility)
contexto específico de uso.
Actualidad
El grado en el cual el dato tiene atributos que son del
(Currentness)
periodo correcto en un contexto específico de uso.
Fuente: (García, 2009)
Como se puede ver en la Tabla 3. Características inherentes según ISO/IEC 25012, estas
dimensiones permiten al cliente-usuario la tranquilidad y/o seguridad que la data que
contiene el software permite tomar las decisiones, según los resultados que puedan
tener. En este desglose de la ISO/IEC 25012, se aprecia también aquellas características,
que son compartidas:
Tabla 4. Características compartidas según ISO/IEC 25012

35
El grado en el cual el dato puede ser accesado en un

Accesibilidad contexto específico de uso, en particular por la gente que
(Accessibility) necesita el soporte de tecnología o una configuración
especial debido a alguna inhabilidad (incapacidad).
El grado en el cual el dato tiene atributos que se adhieren a

normas, convenciones o regularizaciones vigentes y reglas
Conformidad
similares relacionadas con la calidad de datos en un contexto
(Compliance)
específico de uso.
Confidencialidad El grado en el cual el dato tiene los atributos que aseguran

(Confidentiality) que solo es accesible e interpretable por usuarios
autorizados en un contexto específico de uso.
El grado en el cual el dato tiene los atributos que pueden ser

Eficiencia procesados, y proporciona los niveles esperados de
(efficiency) funcionamiento (desempeño) usando las cantidades y los
tipos de recursos apropiados en un contexto específico de
uso.
Precisión El grado en el cual el dato tiene atributos que son exactos o

(Precision) que proporcionan la discriminación en un contexto
específico de uso.
Trazabilidad El grado en el cual el dato tiene atributos que proporcionan

(Traceability) un rastro de auditoría de acceso a los datos y de cualquier
cambio hecho a los datos en un contexto específico de uso.
El grado en el cual el dato tiene atributos que le permiten

Entendibilidad
ser leído e interpretado por usuarios, y es expresado en
(Understandability)
lenguajes apropiados, símbolos y unidades en un contexto
específico de uso.
Fuente: (Software Engineering, 2003)
Como se puede ver en la Tabla 4. Características compartidas según ISO/IEC 25012, siete
dimensiones que se plasman en la calidad del software, estas tienen grados que se
pueden calificar como los más altos en una puntuación de 5 y los más bajo de 1.
36
De este desglose de dimensiones, es que se tiene la siguiente tabla, que agrupa las seis
características finales de la ISO 9126 e ISO/IEC 25012.
Tabla 5. Correspondencia entre las características ISO 9126 e ISO/IEC 25012
ISO 9126 ISO/IEC 25012

Características Subcaracterísticas Características
Consistencia
Actualidad
Idoneidad
Completitud
Funcionalidad Precisión
Exactitud Exactitud
Interoperabilidad
Seguridad Seguridad
Disponibilidad
Madurez
Fiabilidad
Tolerancia a fallos
Recuperabilidad
Facilidad de recuperación
Facilidad de comprensión Entendibilidad
Facilidad de aprendizaje
Usabilidad
Accesibilidad
Operatividad
Manejabilidad
Tiempo de uso
Eficiencia Eficiencia
Recursos utilizados
Facilidad de análisis
Facilidad de cambio Facilidad de cambio
Mantenibilidad
Estabilidad
Facilidad de prueba
Facilidad de instalación
Portabilidad Facilidad de ajuste Portabilidad
Facilidad de adaptación al cambio
Fuente: (Rafique et al. 2012)
Como se puede ver en la Tabla 5. Correspondencia entre las características ISO 9126 e
ISO/IEC 25012, la gran diferencia entre el antes - 9126 y el después - 25012, considera
la base que se tomará en cuenta para el trabajo, ya que esta es la que se ha adaptado a
la NTP que se empleará.

37
NTP-ISO/IEC-TR 9126-3:
La Norma Técnica Peruana ISO/IEC-TR 9126-3: 2005 INGENIERÍA DE SOFTWARE: Calidad
del Producto. Parte 3, define cuales son las métricas internas que permiten la medición
cuantitativa de la calidad del software. Esta norma ofrece métricas que permiten evaluar
los atributos de seis (6) características de calidad, definida en la NTP-ISO/IEC 9126-1.
Dichas métricas son relacionadas de la siguiente manera:
Figura 1. Relación entre tipos de métricas
Estas métricas, consideran una calificación de Likert. Rensis Likert presenta una escala
para que se califique en los cuestionarios los reactivos, ítems o preguntas que se
presentan con el fin de medir reacciones, actitudes y comportamientos de la persona.
Para el caso de las métricas, aplicadas a los clientes-usuarios, se dará en una calificación
de 5, como máximo puntaje de excelencia para la métrica y de 1, como el mínimo. Las
métricas serán para (Abud, 2013):
Métricas de Funcionalidad: En este apartado se agrupa algunos factores que facilitan la
evaluación de un producto de software que den viabilidad a la cobertura de las

38
necesidades del usuario. Con esta calificación tiene el valor de la métrica que permite
conocer las características de funcionamiento que tiene el software en:
Métricas de Aplicabilidad: se relaciona a las ventajas y limitaciones del software.
Métricas de Precisión: relacionado a los errores que puede presentarse (cero).
Interoperabilidad: como es que se da la combinación de información en cada espacio
del software.
Métricas de Seguridad: relacionada a la vulnerabilidad del software.
Métricas de Conformidad de funcionabilidad: se relaciona a lo que espera el cliente-
usuario.
Métricas de Fiabilidad: Se congregan las cualidades concernientes a la suficiencia del
software respecto al índice de concretización en un periodo determinado. Para tal caso
se identificaron dimensiones de:
Métricas de Madurez: las versiones que van mejorando y corrigiendo los posibles
errores.
Métricas de tolerancia a fallos: relacionada hasta donde puede presentarse un error sin
que perjudique la totalidad del resultado.
Métricas de recuperabilidad: relacionada a la acción ante la presencia de un error.
Métricas de conformidad de fiabilidad: se relaciona a la seguridad de los resultados que
espera el cliente-usuario.
Métricas de Usabilidad: Contempla agregados de factores que dan viabilidad a la
evaluación de la dificultad que percibirá el cliente al hacer uso del sistema. Por otro lado,
la comprensibilidad hace alusión a la dificultad percibida al momento de identificar la
estructura lógica y conceptos referentes a la aplicación del software. Además, la rapidez
de adaptarse a la usabilidad del software también debe considerarse la operatividad:

39
Métricas de entendibilidad: se relaciona a intuitividad del software.
Métricas de facilidad de aprendizaje: relacionado a cómo es que se aprende y aplica
todas las funciones que tiene.
Métricas de atractividad: relacionadas a la percepción que tienen sobre cómo les
motiva usarlo.
Métricas de conformidad de usabilidad: se relaciona al uso que el cliente-usuario dará.
Métricas de Eficiencia: Permite evaluar la relación que existe entre grado de
funcionamiento del software y cantidad de recursos empleados:
Métricas de comportamiento en el tiempo: se relacionan a los tiempos que se
requieren para procesar la información.
Métricas de utilización de recursos: relacionado a las características de hardware
(externas).
Métricas de conformidad de eficiencia: se relaciona a lo necesita tener el software para
que el cliente-usuario lo emplee.
Métricas de Facilidad de Mantenimiento: Son características que facilitan la evaluación
del esfuerzo requerido para generar los cambios en el software, así partan de alguna
contingencia u optimización de la funcionalidad:
Métricas de analizabilidad: relacionadas a los reportes que brinda sobre la forma en
que funciona el software.
Métricas de cambiabilidad: se relaciona a la capacidad adaptativa que puede tener el
software.
Métricas de estabilidad: se relaciona al comportamiento del software en el tiempo.

40
Métricas de testeabilidad: se relaciona con la forma en que se evalúa el software para
su mantenimiento.
Métricas de conformidad de facilidad de mantenimiento: se relaciona a como se
sostiene el software durante el uso de cliente-usuario.
Métricas de Portabilidad: Es la acción de transferir de un ambiente a otro el software,
en entornos determinados de hardware:
Métricas de adaptabilidad: se relaciona con todo lo que es medios para su uso.
Métricas de instalación: relacionado con la forma en que se dan los ejecutables
Métricas de coexistencia: se relaciona con la forma en que emplea algunos recursos
(librerías y ejecutables) preexistentes.
Métricas de reemplazabilidad: relacionado a como se sustituyen y solucionan
problemas durante la ejecución y/o traslado del software.
Métricas de conformidad de portabilidad: se relaciona a la adaptabilidad del software
para que el cliente-usuario lo emplee.
El desarrollo de estas se puede apreciar en el documento de la NTP, que es parte del
anexo y tiene el instrumento, sugerido por la INACAL, donde se califica de 5 a 1, siendo
el máximo de calificación de calidad que se puede dar y el mínimo.
Dentro de esta se puede tomar las siguientes preguntas:
Tabla 6. Calidad de Software
Características Pregunta Central
¿Permiten una satisfacción de necesidades las funciones y

Funcionalidad
propiedades explicitas e implícitas; es decir, el qué hace…
41
Características Pregunta Central
¿El nivel de rendimiento, bajo ciertas condiciones y por cierto

Confiabilidad
tiempo, son sostenibles o infectadas?
Usabilidad ¿Es fácil de usar y aprender el software?
Eficiencia ¿los recursos que emplea el software son rápidos y minimalistas?
Mantenibilidad ¿La modificación y/o verificación del software no es complicada?
Portabilidad ¿pasarlo o transferirlo de un ambiente a otro no es complicado?
Fuente: Arrioja et al. (2013)
Además de las dimensiones en la calidad del software, es que se considera posibles usos
en la implementación de la NTP en la empresa OCean SRL, como es el caso de la mejora
continua de DEMING, quien establece el siguiente punto:
PHVA adaptado:
Edward Deming presenta el ciclo PHVA (Planificar, Hacer, Verificar y Actuar), el mismo
que se identifica como ciclo de DEMING. Se emplea en los procesos que ejecuta una
organización o en los proyectos a ejecutar, si se logra adaptar los resultados favorecen
la ejecución, puesta en marcha o implementación. Para el caso del sistema de gestión
en el presente trabajo se considera emplear este ciclo, pero adaptarlo, de tal forma que
permita la conjugación de este con el software a desarrollar (García et al., 2003).
Los pasos son PHVA:
(1) Planificar: establece el diseño de lo que se quiere, como se hará y que se requiere
para su ejecución.
(2) Hacer: establece la ejecución de la planificación.

42
(3) Verificar: establece si lo que se quiere se logra.
(4) Actuar: establece cambios que se deben hacer para la continuidad de mejora.
Se hace imperativo también identificar dentro de estas bases conceptuales los
siguientes términos, que se encuentran relacionados con la mejora y la calidad, estos
son:
Software:
Considerando lo escrito por la Real Academia de la Lengua Española (RAE), es entendido
por la totalidad de programas, instrucciones y reglas informáticas que permitan la
realización de trabajos en algún ordenador. El Estado Peruano norma mediante la ley
28612, usar, adquirir y adecuar software en la administración pública, en su artículo N°
2, indica que las evaluaciones técnicas (software y hardware) son normadas por el
Sistema Nacional de Informática. Los softwares se definen como:
Software Libre: permite su uso y garantiza:
El uso sin obstáculos para alguna finalidad a través de un programa.
Respeta la libertad de los usuarios.
Los usuarios pueden copiar, modificar, estudiar, distribuir los códigos fuentes y mejorar
el software.
Software Propietario: software de código fuente cerrado, no permite modificaciones
por parte del usuario.

43
Antes de concluir con el presente punto es necesario señalar que en la cadena de
búsqueda, NORMA TÉCNICA PERUANA 9126-3 2005, colocada en repositorios de
SUNEDU (RENATI)1 se presentan solo dos resultados, para el caso del repositorio de
CONCYTEC (ALICIA)2 con la misma cadena se da como resultado cero, al igual que la
REFERENCIA3. Si bien es cierto es una NTP, casi nula en investigación, es necesario,
señalar que como ISO si se presentaron los resultados obtenidos.
2.3. Objetivos de la investigación
2.3.1. Objetivo general
Analizar de qué manera la implementación de la Norma Técnica Peruana 9126-3
2005 incide en la calidad del software S.O.S. Tesis de la empresa OCean SRL, 2021.
2.3.2. Objetivos específicos
Para el caso de los objetivos específicos se tiene los siguientes:
• Analizar de qué manera la implementación de la Norma Técnica Peruana
9126-3 2005, incide en la funcionalidad del software S.O.S. Tesis de la
empresa OCean SRL, 2021.
9126-3 2005, incide en la confiabilidad del software S.O.S. Tesis de la
1 https://renati.sunedu.gob.pe/simple-search?query=NORMA+T%C3%89CNICA+PERUANA+9126-3+2005+
2 https://alicia.concytec.gob.pe/vufind/Search/Results?lookfor=NORMA+T%C3%89CNICA+PERUANA+9126-3+2005&type=AllFields
3 https://www.lareferencia.info/vufind/Search/Results?lookfor=NORMA+T%C3%89CNICA+PERUANA+9126-3+2005&type=AllFields
44
9126-3 2005, incide la usabilidad del software S.O.S. Tesis de la empresa
OCean SRL, 2021.
9126-3 2005, incide en la capacidad de mantenimiento del software S.O.S.
de la empresa OCean SRL, 2021.
9126-3 2005, incide en la eficiencia del software S.O.S. Tesis de la empresa
OCean SRL, 2021.
9126-3 2005, incide en la portabilidad del software S.O.S. Tesis de la
empresa OCean SRL, 2021?
2.4. Formulación de hipótesis
2.4.1. Hipótesis general
La implementación de la Norma Técnica Peruana 9126-3 2005, incide
significativamente en la calidad del software S.O.S. Tesis de la empresa OCean SRL,
2021.
45
2.4.2. Hipótesis especificas
Para el caso de los problemas específicos se consideran las siguientes hipótesis:
• La implementación de la Norma Técnica Peruana 9126-3 2005, incide
significativamente en la funcionalidad del software S.O.S. Tesis de la
significativamente en la confiabilidad del software S.O.S. Tesis de la
significativamente en la usabilidad del software S.O.S. Tesis de la
significativamente en la eficiencia del software S.O.S. Tesis de la empresa
OCean SRL, 2021.
significativamente en la capacidad de mantenimiento del software
S.O.S. Tesis de la empresa OCean SRL, 2021.
significativamente en portabilidad del software S.O.S. Tesis de la

46
CAPITULO III: DISEÑO METODOLÓGICO
3.1. Diseño de la investigación
Para el diseño de la investigación se considera que es experimental (Hernández, 2014).
Se ha tomado tres aspectos importantes (i) la empresa tiene un producto, S.O.S. Tesis,
que desarrolló sin intervención de métricas de calidad de la NTP (ii) la empresa
implementa un diagnóstico con la intervención de métricas de calidad de la NTP (iii) la
empresa modifica los resultados obtenidos por las métricas de calidad de la NTP. Esto
es lo que permite demostrar que el uso de las NTP, mejora los indicadores de calidad.
Entonces, es un diseño experimental.
3.2. Tipo de investigación
Será experimental puro. (Hernández, 2014). Al afectarse directamente una de las
variables, como resultados de los sometimientos a las métricas y determinar luego de
ello la nueva situación, es que se determina que es puro.
3.3. Enfoque
Para el estudio se contempla que es cuantitativo, pues los instrumentos serán
cuantitativos de acuerdo con el autor (Hernández, 2014).
3.4. Población
El software es producido por la empresa OCean SRL, siendo un total de usuarios de 100,
en el momento de la intervención, es decir, son los que hacen sus planes de tesis usando
S.O.S. Tesis, como plataforma web. Dentro de la empresa hay 03 personas que se
encargan de la programación, base de datos, interfaz y comunicación electrónica, es

47
decir, personal de la unidad de TI y dos personas de staff, lo que hace un total de 05
personas que ven directamente con el S.O.S. Tesis. Ambos han sido considerados como
sujetos del objeto de estudio.
3.5. Muestra
Se considera que será una muestra censal (Manrique, 2018). Cuando una población es
finita y se toma como referencia, la totalidad de la misma, se condiciona el termino
censal, ya que en el momento de la aplicación, la propia recolección de información
puede tener instrumentos que estén incompletos, por lo que el investigador deberá de
asumir una de las dos (2) posiciones: volver a aplicar el instrumento, donde el impacto,
por el conocimiento del mismo ya no sería “sin reposición” o analizar el impacto en los
resultados de la cantidad de instrumentos que serían descartados, por ello es que se
denomina censal.
48
3.6. Operacionalización de variables

VARIABLES DEFINICION CONCEPTUAL DEFINICION DIMENSION INDICADOR ITEM ESCALA INSTRUMENT
OPERACIONAL O
Variable Características aceptadas por el usuario del Conocer e implementar Diagnóstico MOF – ROF – MAPRO Anexo 6: PHVA Nominal Ficha
Depen- software. Permite a la empresa que desarrolla la NTP en los procesos modificado Documental –
diente: software, conocer la calidad de sus productos y a las de producción de la Entrevista
SOFTWARE empresas que compran software, decidirse por una empresa OCEAN SRL, Planificación Requerimiento Humano, Material y Anexo 3: Ficha Nominal Ficha
S.O.S. solución u otra en función de sus necesidades tomando como caso Económico Documental Documental
(International Standard Organization-ISO 2014) resultante su producto
S.O.S. Tesis
Ejecución Desarrollo, Pruebas de Stress, Nominal
Servidor y Terminales
Evaluación Reportes e Informes Nominal
Variable Reglas y principios para considerar en un producto Analizar la percepción

Indepen- denominado software. Es un documento que de la calidad del Calidad del Funcionalidad 1, 2, 3, 4 Ordinal Encuesta
diente: establecen las especificaciones de calidad de los software de los usuarios Software basada en el
productos, procesos y servicios. Define las métricas de la plataforma S.O.S. Confiabilidad 5, 6 y 7 Ordinal estándar
Norma internas para la medición cuantitativa de la calidad Tesis luego de la Usabilidad 10 y 11 Ordinal ISO/IEC 9126
Técnica interna del software en términos de características implementación de la Eficiencia 8y9 Ordinal
Peruana y subcaracterísticas definidas en la NTP-ISO/IEC NTP 9126-3 Capacidad de Mantenimiento 12 y 13 Ordinal
9126-3 9126-1 y se pretende que sea utilizado junto con la Portabilidad 14, 15 y 16 Ordinal
NTP-ISO/IEC 9126-1. Esta NTP contiene: I. Una
explicación de la forma de aplicación de las métricas
de calidad del software; II. Un conjunto básico de
métricas para cada subcaracterística; III. Un
ejemplo de la forma en que se aplican las métricas
durante el ciclo de vida del producto software
(Instituto Nacional de la Calidad - INACAL 2005
49
3.7. Técnicas para la recolección de datos
La recolección de información estableció como técnicas las entrevistas y la encuesta, por
lo que los instrumentos fueron la entrevista semiestructurada y los cuestionarios: a) La
Norma Técnica Peruana – NTP y b) cuestionario de percepción de los usuarios finales.
La Norma Técnica Peruana y las entrevistas se aplicaron al personal de la empresa (05
en total) y el cuestionario de percepción del software a los 100 usuarios finales. (el
cuestionario consta de 1 sola pregunta ¿cuál es su percepción de cómo funciona los
menús y submenús del SOS Tesis, califique con 1 para la mínima calificación y 5 para la
máxima calificación?), este cuestionario se aplicó antes y después.
Nota: El detalle de la información del cuestionario de percepción de los 100 usuarios
fueron trabajados por la Empresa OCEAN SRL, los resultados obtenidos (promedio)
fueron entregados al tesista para que continue su tesis.
3.8. Técnica para el procesamiento y análisis de datos
Una vez recolectada la información, se hizo uso de las medidas de tendencia central
(MTC), para el análisis estadístico, en las hojas de cálculo de MS Excel, aplicada a los
cuestionarios, tanto de percepción de los usuarios finales, como de los resultados antes
y después de aplicar las métricas de calidad. Además, para el caso de las entrevistas, se
usó el MS Word, con lo cual se agrupó los resultados de los cinco trabajadores de OCean
SRL. Para la comprobación de las hipótesis, se ha tomó los resultados previos, antes de
la implementación de cambios a las métricas de calidad y luego de las mismas. Siendo
estos valores cuantitativos, es que se procedió a hacer la diferencia entre antes y
después para cada métrica, en la que la diferencia, permitía determinar que estadístico
se usaría para saber si la diferencia de ambos es significativa o no, por lo que se usó en
50
la primera, para ver el supuesto de normalidad, Kolmogorov-Smirnov y Shapiro, en los
casos que superaban las 50 métricas, como el de la hipótesis general, se usó
Kolmogorov-Smirnov y el resto Shapiro-Wilk. Una vez determinado los supuestos de
normalidad o no, es que se selecciona la prueba de Wilconxon, con la cual se aprecia si
los cambios en la métrica fueron significativos o no. El planteamiento de las hipótesis
nula y alterna, se aceptó o rechazó, basado en los resultados que se tuvieron, tomando
en cuenta el P-value y el valor de 0.05 de significancia, en cada una de las muestras. Para
el procesamiento, primero se obtuvo los resultados en la hoja de cálculo y se trasladó al
SPSS donde se procedió a trabajar con los estadísticos ya indicados.
3.9. Aspectos éticos
Se cumplió con todos los procesos axiológicos plasmados en el reglamento de grados y
títulos, así como también, al no existir manipulación de seres vivos, en forma directa e
indirecta, es que no hubo necesidad de un protocolo ético, sin embargo, si se cumplió
con entregar el acta de consentimiento informado, a las personas que participaron en
la investigación y, por último, se esperó la comunicación favorable de la universidad en
relación a los aspectos éticos dados en el presente trabajo.

51
CAPITULO IV: RESULTADOS
El software S.O.S. Tesis, mantiene como nicho de mercado, aquellas personas que
desean desarrollar una tesis, ya sea a nivel de pregrado o posgrado, por lo que se puede
trasladar a un público local, regional, nacional e internacional. En el presente capítulo,
se plasmó los resultados que se obtuvieron, siendo este de dos fuentes, fuente
secundaria y fuente primaria.
4.1 Resultados Fuente Secundaria
El trabajo de investigación, que se propuso e implementó, se basó en la NTP 9126-3
2005, dada por el Instituto Nacional de la Calidad (INCAL), de esta se obtuvo las
características y criterios que se evaluaron y se obtuvo la tabla siguiente:

52
Tabla 7. NTP 9126-3 2005 Métricas de Funcionabilidad
Métricas internas de aplicabilidad

Tipo de Referencia
Nombre de Propósito de la Medición, fórmula y cálculo Interpretación del Entradas para Audiencia
Método de aplicación escala de Tipo de medida PCVS ISO/IEC
métrica métrica de los elementos de datos valor medido la medición objetivo
métrica 12207
Contar el número de
funciones implementadas en
las que se detectó problemas Especificación
X = 1-A/B
para realizar las tareas de
A = Número de funciones en X=
¿Cuán adecuadas son especificadas y comparar con 0 <= X <= 1 requerimientos. 6.5 Validación
Adecuación las que se detectó problemas Cantidad/Cantidad Evaluador
las funciones las funciones implementadas. Lo más cercano a 1 Absoluta Diseño 6.6 Revisión
funcional durante la evaluación A = Cantidad Desarrollador
revisadas? Se puede medir lo siguiente: es lo mejor. Código fuente conjunta
B = Número de funciones B = Cantidad
- todas o parte de las Reporte de
revisadas
especificaciones de diseño. revisión
- módulos/partes completadas
de productos software
X = 1-A/B Especificación
A = Número de funciones de
funciones faltantes detectadas X=
Integridad de ¿Cuán completa es la faltantes detectadas en la 0 <= X <= 1 requerimientos. 6.5 Validación
en la evaluación y comparar Cantidad/Cantidad Evaluador
implementación Implementación evaluación Lo más cercano a 1 Absoluta Diseño 6.6 Revisión
con el número de funciones A = Cantidad Desarrollador
funcional funcional? B = Número de funciones es lo mejor. Código fuente conjunta
descritas en la especificación B = Cantidad
descritas en la especificación Reporte de
de Requerimientos
de requerimientos revisión
X = 1-A/B
Contar el número de Especificación
A = Número de funciones
funciones faltantes o de
faltantes o implementadas X=
Cobertura de la ¿Cuán correcta es la implementadas 0 <= X <= 1 requerimientos. 6.5 Validación
incorrectamente que se Cantidad/Cantidad Evaluador
implementación Implementación incorrectamente y comparar Lo más cercano a 1 Absoluta Diseño 6.6 Revisión
detectaron A = Cantidad Desarrollador
funcional funcional? con el número de funciones es lo mejor. Código fuente conjunta
B = Número de funciones B = Cantidad
descritas en la especificación Reporte de
descritas en la especificación
de requerimientos revisión
de requerimientos
Contar el número de 6.5 Validación
funciones cambiadas X = 1-A/B 6.3
¿Cuán estable es la (añadidas, modificadas, o A = Número de funciones Especificación Aseguramiento
Estabilidad X= Desarrollador
Especificación eliminadas) durante la fase de cambiadas durante la fase del 0 <= X <= 1 de de la calidad
(volatilidad) de la Cantidad/Cantidad Responsable
funcional durante el desarrollo del ciclo de vida y ciclo de vida de desarrollo Lo más cercano a 1 Absoluta requerimientos. 5.3 Pruebas de
especificación A = Cantidad de
ciclo de vida de comparar con el número de B = Número de funciones es lo mejor. Reporte de calificación
funcional B = Cantidad mantenimiento
desarrollo? funciones descritas en la descritas en la especificación revisión 6.8 Resolución
especificación de de requerimientos de problemas
requerimientos 5.4 Operación
53
Métricas internas de precisión

Tipo de Referencia
métrica 12207
X = A/B
A = Número de funciones en
Contar el número de Especificación
las que se ha implementado
¿Cuán funciones que han de
requerimientos de exactitud X=
completamente se implementado los 0 <= X <= 1 requerimientos. 6.5 Validación
Exactitud de específicos, confirmados en la Cantidad/Cantidad Evaluador
implementaron los requerimientos de exactitud y Lo más cercano a 1 Absoluta Diseño 6.6 Revisión
cálculos evaluación. A = Cantidad Desarrollador
requerimientos de comparar con el número de es lo mejor. Código fuente conjunta
B = Número de funciones para B = Cantidad
exactitud? funciones con requerimientos Reporte de
las cuales se necesita
de exactitud especificados. revisión
implementar requerimientos
de exactitud específicos.
Contar el número de ítems de X = A/B
Especificación
¿Cuán datos que cumplen con los A = Número de ítems de datos
de
completamente se requerimientos de niveles de implementados con niveles de X=
0 <= X <= 1 requerimientos. 6.5 Validación
implementaron los precisión específicos y precisión específicos, Cantidad/Cantidad Evaluador
Precisión Lo más cercano a 1 Absoluta Diseño 6.6 Revisión
niveles específicos de comparar con el número total confirmados en la evaluación. A = Cantidad Desarrollador
es lo mejor. Código fuente conjunta
precisión en los ítems de ítems de datos con B = Número de ítems de datos B = Cantidad
Reporte de
de datos? requerimientos de niveles de que requieren niveles de
revisión
precisión especificados precisión especificados.
54
Métricas internas de interoperabilidad

Tipo de Referencia
métrica 12207
X = A/B
Contar el número de formatos
A = Número de formatos de
de datos de interfaces que se Especificación
datos de las interfaces que se
han implementado de
Intercambiabilidad ¿Cuán correctamente han implementado X=
correctamente según las 0 <= X <= 1 requerimientos 6.5 Validación
de datos (basado se implementaron los correctamente según las Cantidad/Cantidad Desarrollador
especificaciones, y comparar Lo más cercano a 1 Absoluta Diseño 6.6 Revisión
en formatos de formatos de datos de especificaciones. A = Cantidad Evaluador
con el número de formatos de es lo mejor. Código fuente conjunta
datos) interfaces? B = Número de formatos de B = Cantidad
datos que deben ser Reporte de
datos que deben ser
intercambiados según las revisión
intercambiados según las
especificaciones.
especificaciones.
X = A/B
A = Número de protocolos de
protocolos de interfaz que se Especificación
interfaz que implementan un
implementaron de
¿Cuán correctamente formato consistente según las X=
correctamente según las 0 <= X <= 1 requerimientos. 6.4 Verificación
Consistencia de las se implementaron los especificaciones confirmadas Cantidad/Cantidad Desarrollador
especificaciones y comparar Lo más cercano a 1 Absoluta Diseño 6.6 Revisión
interfaces protocolos de en la revisión. A = Cantidad Evaluador
con el número de protocolos es lo mejor. Código fuente conjunta
interfaz? B = Número de protocolos de B = Cantidad
de interfaz que deben Reporte de
interfaz que deben
implementarse según las revisión
implementarse según las
especificaciones.
especificaciones.
55
Métricas internas de seguridad

Tipo de Referencia
métrica 12207
Contar el número de tipos de X = A/B
Especificación
acceso que se han registrado A = Número de tipos de
de
correctamente según las acceso que han ingresado 0 <= X <= 1 X=
requerimientos. 6.5 Validación
Auditoría de ¿Cuán auditables son especificaciones y comparar según las especificaciones. Mientras más Cantidad/Cantidad Evaluador
Absoluta Diseño 6.6 Revisión
accesos los accesos? con el número de tipos de B = Número de tipos de cercano a 1, más A = Cantidad Desarrollador
Código fuente conjunta
acceso requeridos para acceso requeridos para auditable. B = Cantidad
Reporte de
ingresar según las ingresar según las
revisión
especificaciones. especificaciones.
X = A/B
A = Número de
requerimientos de control de Especificación
requerimientos de control de
accesos implementados de
accesos implementados 0 <= X <= 1 X=
¿Cuán controlables correctamente según las requerimientos. 6.5 Validación
correctamente según las Mientras más Cantidad/Cantidad Evaluador
Control de acceso son los accesos al especificaciones y comparar Absoluta Diseño 6.6 Revisión
especificaciones. cercano a 1, más A = Cantidad Desarrollador
sistema? con el número de Código fuente conjunta
B = Número de controlable. B = Cantidad
requerimientos de control de Reporte de
requerimientos de control de
accesos en las revisión
accesos en las
especificaciones.
especificaciones.
X = A/B
A = Número de instancias de
instancias de prevención de
prevención de corrupción de
corrupción de datos Especificación
datos implementadas según lo
implementadas según lo de
¿Cuán completa es la especificado, confirmadas en X = Cantidad/
Prevención de especificado y comparar con 0 <= X <= 1 requerimientos. 6.5 Validación
implementación de la revisión. Cantidad
corrupción de el número de instancias de Lo más cercano a 1 Absoluta Diseño 6.6 Revisión Desarrollador
prevención de B = Número de instancias de A = Cantidad
datos operaciones/accesos es lo mejor. Código fuente conjunta
corrupción de datos? operaciones/accesos B = Cantidad
especificadas en los Reporte de
especificadas en los
requerimientos según su revisión
requerimientos según su
capacidad para
capacidad para
corromper/destruir datos.
corromper/destruir datos.
Contar el número de X = A/B
Especificación
instancias para A = Número de instancias de
de
¿Cuán completa es la encriptar/desencriptar de encriptación/decriptación de X = Cantidad/
0 <= X <= 1 requerimientos
Encriptación de implementación de ítems de datos ítems de datos Cantidad
Lo más cercano a 1 Absoluta Diseño 6.5 Validación Desarrollador
datos encriptación de implementadas según lo implementadas según lo A = Cantidad
es lo mejor. Código fuente
datos? especificado y comparar con especificado, B = Cantidad
Reporte de
el número de instancias de confirmadas en la revisión.
revisión
ítems de datos que requieren B = Número de instancias de
56
facilidades para ítems de datos que requieren

encriptar/desencriptar datos facilidades de
según las especificaciones. encriptación/decriptación de
datos según las
especificaciones.
Métricas internas de conformidad de funcionalidad

Tipo de Referencia
métrica 12207
X = A/B Especificación
A = Número de ítems de conformidad
Contar el número de ítems
correctamente de normas, o
¿Cuán conforme está que requieren conformidad y
implementados confirmados X = Cantidad/ convenciones o
la funcionalidad del que lo han logrado, y 0 <= X <= 1 6.5 Validación
Conformidad de en la revisión relacionados Cantidad regulaciones Evaluador
producto con las comparar con el número de Lo más cercano a 1 Absoluta 6.6 Revisión
funcionalidad con la conformidad de A = Cantidad relacionadas Desarrollador
regulaciones, normas ítems que requieren es lo mejor. conjunta
funcionalidad. B = Cantidad Diseño
y convenciones? conformidad según las
B = Número total de ítems de Código fuente
especificaciones.
funcionalidad que requieren Reporte de
conformidad. revisión
X = A/B
Contar el número de A = Número de interfaces Especificación
¿Cuán conformes
interfaces que logran la correctamente de
están las interfaces X = Cantidad/
Conformidad con conformidad requerida y implementadas según lo 0 <= X <= 1 requerimientos 6.5 Validación
entre sistemas con Cantidad Evaluador
normas para comparar con el número de especificado, confirmadas en Lo más cercano a 1 Absoluta Diseño 6.6 Revisión
las regulaciones, A = Cantidad Desarrollador
intersistemas interfaces que requieren la revisión. es lo mejor. Código fuente conjunta
normas y B = Cantidad
conformidad según las B = Número total de Reporte de
convenciones?
especificaciones. interfaces que requieren revisión
conformidad.
Fuente: INACAL
57
Tabla 8. NTP 9126-3 2005 Métricas de Fiabilidad
Métricas internas de madurez

Tipo de
Nombre de Propósito de la Medición, fórmula y cálculo Interpretación del Entradas para Referencia PCVS Audiencia
Método de aplicación escala de Tipo de medida
métrica métrica de los elementos de datos valor medido la medición ISO/IEC 12207 objetivo
métrica
0 <= X
El valor A
X = A/B Un valor alto de X
proviene del
A = Número Absoluta de fallas implica
Contar el número de fallas reporte de
detectadas en la revisión. buena calidad de X=
¿Cuántas fallas fueron detectadas en la revisión y revisión 6.5 Validación
Detección de B = Número de fallas producto, mientras Cantidad/Cantidad Evaluador
detectadas en el comparar con el número de Absoluta El valor B 6.6 Revisión
fallas estimadas que se espera se que si A=0 no A = Cantidad Desarrollador
producto revisado? fallas estimadas que se espera proviene de conjunta
detecte en la revisión (usando necesariamente B = Cantidad
se detecte en esta fase. la base de
datos históricos o un modelo implica que el
datos de la
de referencia). producto revisado
organización
esté libre de fallas.
0 <= X El valor A
X=A
Contar el número de fallas Un valor alto de X proviene del 6.5 Validación
¿Cuántas fallas fueron A = Número de fallas X = Cantidad Evaluador
corregidas durante el implica que Ratio reporte de 6.6 Revisión
corregidas? corregidas en A = Cantidad Desarrollador
diseño/codificación. quedan menos remoción de conjunta
diseño/codificación.
fallas fallas
Eliminación de
Contar el número de fallas
fallas Y = A/B
removidas durante el 0 <= Y <= 1
A = Número de fallas El valor B
diseño/codificación y Mientras más Y=
¿Cuál es la proporción corregidas en proviene del
comparar con el número de cercano a 1, mejor Absoluta Cantidad/Cantidad
de fallas removidas? diseño/codificación. reporte de
fallas detectadas en la (más fallas B = Cantidad
B = Número de fallas revisión
revisión durante el removidas).
detectadas en la revisión
diseño/codificación.
X = A/B El valor A
Contar el número de casos de 6.3
A = Número de casos de proviene del
¿Cuántos de los casos prueba planeados y comparar X= Aseguramiento Desarrollador
prueba diseñados que están 0 <= X plan de
Suficiencia de de prueba requeridos con el número de casos de Cantidad/Cantidad de calidad Responsable
en el plan de pruebas y Cuando X es mayor Absoluta pruebas
pruebas están cubiertos por el prueba requeridos para A = Cantidad 6.8 Resolución de
confirmados en la revisión es lo mejor. El valor B
plan de pruebas? obtener una adecuada B = Cantidad de problemas mantenimiento
B = Número de casos de proviene de los
cobertura de pruebas. 6.4 Verificación
prueba requeridos requerimientos
58
Métricas internas de tolerancia a fallos

Tipo de
métrica
X = A/B
A = Números total de
patrones de fallas que
El valor A
consideran prevención en
proviene del
diseño/código.
reporte de 6.4 Verificación
B = Número de patrones de Desarrollador
¿Cuántos patrones de Contar el número de patrones 0 <= X X= revisión 6.5 Validación
fallas que deben considerarse. Evaluador
Prevención de fallas se pusieron bajo de fallas evitadas y comparar Cuando X es Cantidad/Cantidad El valor B 6.6 Revisión
COMENTARIO 1: Ejemplo de Absoluta Responsable
fallos control para evitar con el número de patrones de mayor, mejor A = Cantidad proviene del conjunta
patrones de fallas es el de
fallas serias y críticas? fallas a ser considerados. evitación de fallas B = Cantidad documento de 6.8 Resolución
bloqueo por datos fuera de mantenimiento
especificación de problemas
rango.
de
COMENTARIO 2: La técnica de
requerimientos
análisis del árbol de fallas se
puede usar para detectar
patrones de fallas.
X = A/B
implementadas para evitar
patrones de operación
incorrecta.
Contar el número de B = Número de patrones de
El valor A
funciones implementadas operación incorrecta que
proviene del
para evitar fallas críticas y deben considerarse.
0 <= X reporte de 6.4 Verificación
¿Cuántas funciones se serias causadas por operación COMENTARIOS: Desarrollador
Cuando X es X= revisión 6.5 Validación
Prevención de han implementado incorrecta y comparar con el Patrones de operación Evaluador
mayor, mejor es la Cantidad/Cantidad El valor B 6.6 Revisión
operación con capacidad de número de patrones de incorrecta. Absoluta Responsable
prevención de A = Cantidad proviene del conjunta
incorrecta prevención de operación incorrecta que Tipos de datos incorrectos, de
operación B = Cantidad documento de 6.8 Resolución
operación incorrecta? deben considerarse. como parámetros. mantenimiento
incorrecta especificación de problemas
COMENTARIO: Las fallas del Secuencia de datos de
de
sistema incluyen también entrada incorrecta.
requerimientos
datos dañados Secuencia de operación
incorrecta. COMENTARIOS: La
técnica de análisis del árbol de
fallas se puede usar para
detectar patrones de
operación incorrecta
59
Métricas internas de recuperabilidad

Tipo de
métrica
requerimientos de
restauración implementados y El valor A
X = A/B
comparar con el número de proviene del
A = Número de
requerimientos de reporte de
¿Cuán capaz es el requerimientos de
restauración en las 0 <= X <= 1 X= revisión Desarrollador
sistema de restaurarse restauración implementados 6.4 Verificación
Capacidad de especificaciones Cuando X es Cantidad/Cantidad El valor B Responsable
a sí mismo después de confirmados en la revisión. Absoluta 6.6 Revisión
restauración Ejemplos de requerimientos mayor, mejor A = Cantidad proviene de los de
un evento anormal o a B = Número de conjunta
de restauración: punto de restaurabilidad B = Cantidad requerimientos mantenimiento
solicitud? requerimientos de
comprobación de base de o del
restauración en las
datos, punto de documento de
especificaciones.
comprobación de transacción, diseño
función rehacer, función
deshacer.
Contar el número de X = A/B El valor A
requerimientos de A = Número de proviene del
restauración implementados requerimientos de reporte de
que cumplen con los tiempos restauración implementados 0 <= X <= 1 X= revisión Desarrollador
Efectividad de la ¿Cuán efectiva es la 6.4 Verificación
de restauración (mediante que cumplen con los tiempos Cuando X es Cantidad/Cantidad El valor B Responsable
capacidad de capacidad de Absoluta 6.6 Revisión
cálculos o simulaciones) y de restauración esperados. mayor, mejor A = Cantidad proviene de los de
restauración restauración? conjunta
comparar con el número de B = Número de efectividad B = Cantidad requerimientos mantenimiento
requerimientos de requerimientos de o del
restauración con tiempos restauración con tiempos documento de
esperados especificados esperados especificados. diseño
60
Métricas internas de conformidad de fiabilidad

Tipo de
métrica
Especificación
es de
X = A/B
Contar el número de ítems conformidad y
A = Número de ítems
¿Cuán conforme es la que requieren conformidad normas,
correctamente X=
fiabilidad del producto de fiabilidad y que la 0 <= X <= 1 convenciones y 6.4 Verificación
Conformidad de implementados relacionados Cantidad/Cantidad Evaluador
en aplicación a las alcanzaron, y comparar con el Lo más cercano a 1 Absoluta regulaciones 6.6 Revisión
fiabilidad con la conformidad de A = Cantidad Desarrollador
regulaciones, normas número de ítems que es lo mejor. relacionadas. conjunta
fiabilidad, en la evaluación. B = Cantidad
y convenciones? requieren conformidad según Diseño
B = Número total de ítems de
las especificaciones. Código fuente
conformidad de fiabilidad.
Reporte de
revisión
Fuente: INACAL
Tabla 9. NTP 9126-3 2005 Métricas de Usabilidad
Métricas internas de entendibilidad

Tipo de Referencia
métrica 12207
X=A/B
¿Qué proporción de A = Número de funciones ( o Especificación
funciones (o tipos de tipos de funciones) descritas X de
funciones que son 0 <=X<= 1 6.4 Verificación
Claridad de la funciones) son en la descripción del =Cantidad/Cantidad requerimientos. Evaluador
adecuadamente descritas y Lo más cercano a 1 Absoluta 6.6 Revisión
descripción descritas en la producto. A = Cantidad Diseño Desarrollador
comparar con el número total es lo mejor conjunta
descripción del B =Número Total de B = Cantidad Reporte de
de funciones en el producto.
producto? Funciones (o tipos de revisión
funciones).
X=A/B
¿Qué proporción de Contar el número de Especificación
las funciones que funciones que tengan la X de
demostradas y confirmadas 0 <=X<= 1 6.4 Verificación
Capacidad de requieren capacidad de demostración y =Cantidad/Cantidad requerimientos. Evaluador
en la revisión. Lo más cercano a 1 Absoluta 6.6 Revisión
demostración demostración tienen comparar con el número total A = Cantidad Diseño Desarrollador
B = Número total de funciones es lo mejor conjunta
la capacidad de de funciones que requieran B = Cantidad Reporte de
que requieren la capacidad de
demostración? una demostración revisión
demostración
61
Métricas Internas de entendibilidad

Tipo de Referencia
métrica 12207
X=A/B Especificación
¿Qué proporción de Contar el número de
A = Número de funciones ( o X de
las funciones del funciones que son evidentes 0 <=X<= 1 6.4 Verificación
Funciones tipos de funciones) evidentes =Cantidad/Cantidad requerimientos. Evaluador
producto son para el usuario y comparar Lo más cercano a 1 Absoluta 6.6 Revisión
evidentes para el usuario. A = Cantidad Diseño Desarrollador
evidentes para el con el número total de es lo mejor conjunta
B = número total de funciones B = Cantidad Reporte de
usuario? funciones.
(o tipos de funciones). revisión
X=A/B
¿Qué proporción de A = Número de funciones Especificación
funciones presentes en las
las funciones del presentes en las interfaces de X de
interfaces donde el propósito 0 <=X<= 1 6.4 Verificación
Función de producto será el los usuarios cuyo propósito es =Cantidad/Cantidad requerimientos. Evaluador
es entendible y comparar con Lo más cerca a 1 es Absoluta 6.6 Revisión
comprensión usuario capaz de entendido por el usuario. A = Cantidad Diseño Desarrollador
el número de funciones lo mejor. conjunta
entender en forma B = Número total de funciones B = Cantidad Reporte de
presentes en la interfaz de los
correcta? presentes en las interfaces del revisión
usuarios.
usuario
Métricas Internas de facilidad de aprendizaje

Tipo de Referencia
métrica 12207
¿Qué proporción de Contar el número de Especificación
Integridad de la X=A/B
las funciones son funciones implementadas con de
documentación A = Número de funciones 0 <=X<= 1 6.4 Verificación
descritas en la facilidades de ayuda y/o requerimientos. Evaluador
del usuario y/o descritas Lo más cercano a 1 Absoluta 6.6 Revisión
documentación para el documentación y comparar Diseño Desarrollador
facilidad de B = Número total de funciones es lo mejor conjunta
usuario y/o facilidades con el número total de Reporte de
ayuda proveídas
de ayuda? funciones del producto revisión
62
Métricas Internas de operabilidad

Tipo de Referencia
métrica 12207
Contar el número de X=A/B Especificación
¿Qué proporción de
elementos de entrada que son A = Número de elementos de de
Revisión de la los elementos de 0 <= X <= 1 6.4 Verificación
validados y comparar con el entrada que son validados. X= requerimientos. Desarrollador
validez de la entrada proveen Lo más cercano a 1, Absoluta 6.6 Revisión
número total de elementos de B = Número de elementos de Cantidad/Cantidad Diseño Evaluador
entrada mecanismos para es lo mejor. conjunta
entrada que podrían ser entrada que podrían ser Reporte de
validación de datos?
validados. validados. revisión
X=A/B
funciones implementadas que Especificación
A = Número de funciones 0 <= X <= 1
Capacidad de ¿Qué proporción de pueden ser canceladas por el de
implementadas que pueden Lo más cercano a 1, 6.4 Verificación
cancelar las funciones pueden usuario antes de haber sido X= requerimientos. Desarrollador
ser canceladas por el usuario. indica una mejor Absoluta 6.6 Revisión
operación de ser canceladas antes completado con su tarea y Cantidad/Cantidad Diseño Evaluador
B = Número de funciones que capacidad de conjunta
usuario de ser completadas? comparar con el número de Reporte de
requieren la capacidad de cancelación.
funciones que requieren la revisión
cancelación.
capacidad de ser canceladas.

Tipo de Referencia
métrica 12207
Contar el número de X=A/B 0 <= X <= 1 Especificación
Capacidad de funciones implementadas que A = Número de funciones Lo más cercano a 1, de
¿Qué proporción de 6.4 Verificación
deshacer pueden ser deshechas luego implementadas que pueden indica una mejor X= requerimientos. Desarrollador
las funciones pueden Absoluta 6.6 Revisión
operación de que ya completaron su tarea y ser deshechos por los capacidad para Cantidad/Cantidad Diseño Evaluador
ser deshechas? conjunta
usuario comparar con el número total usuarios. deshacer Reporte de
de funciones B = Número de funciones funciones. revisión
X=A/B
funciones implementadas que Especificación
A = Número de funciones que
¿Qué proporción de pueden ser personalizadas de
pueden ser personalizadas 0 <= X <= 1 6.4 Verificación
las funciones pueden por el usuario durante su X= requerimientos. Desarrollador
Personalización durante la operación. Lo más cercano a 1 Absoluta 6.6 Revisión
ser personalizad a operación y comparar con el Cantidad/Cantidad Diseño Evaluador
B = Número de funciones que es lo mejor. conjunta
durante la operación? número de funciones que Reporte de
requieren la capacidad de ser
requieren la capacidad de ser revisión
personalizadas
personalizadas.
63
0 <= X <= 1
¿Qué proporción de Contar el número de Lo más cercano a 1, Especificación
las funciones pueden funciones implementadas que X=A/B indica una mejor de
6.4 Verificación
Accesibilidad ser personalizada para pueden ser personalizadas A = Número de funciones que capacidad para X= requerimientos. Desarrollador
Absoluta 6.6 Revisión
física el acceso de usuarios por usuarios con discapacidad pueden ser personalizadas. atender a las Cantidad/Cantidad Diseño Evaluador
conjunta
con discapacidad física y comparar con el B = Número de funciones. personas con Reporte de
física? número total de funciones incapacidades revisión
físicas
Contar el número de X=A/B
Especificación
¿Qué proporción de funciones implementadas, A = Número de funciones que
Capacidad para X= de
las funciones tienen la cuyo estado puede ser tienen la capacidad de 0 <= X <= 1 6.4 Verificación
monitorear el Cantidad/Cantidad requerimientos. Desarrollador
capacidad para monitoreado y comparar con monitorear su estado. Lo más cercano a 1 Absoluta 6.6 Revisión
desarrollo de las A = Cantidad Diseño Evaluador
monitorear el estado el número de funciones que B = Número de funciones que es lo mejor conjunta
operaciones B = Cantidad Reporte de
de las operaciones? requieren la capacidad de requieren la capacidad de
revisión
monitoreo. monitorear su estado.
Contar el número de las X=1–A/B
¿Qué proporción de Especificación
instancias de las operaciones A = Número de instancias de
las operaciones se X= de
que tengan un las operaciones que tengan un 0 <= X <= 1 6.4 Verificación
Consistencia comportan de forma Cantidad/Cantidad requerimientos. Desarrollador
comportamiento comportamiento Lo más cercano a 1 Absoluta 6.6 Revisión
operacional similar a las A = Cantidad Diseño Evaluador
inconsistente y comparar con inconsistente. es lo mejor conjunta
operaciones de otras B = Cantidad Reporte de
el número total de B = Número total de
partes del sistema? revisión
operaciones. operaciones.
A = Número de mensajes X= de
¿Qué proporción de mensajes implementados con 0 <= X <= 1 6.4 Verificación
Claridad de implementados con Cantidad/Cantidad requerimientos. Desarrollador
los mensajes son auto- explicaciones claras y Lo más cercano a 1 Absoluta 6.6 Revisión
mensajes explicaciones claras. A = Cantidad Diseño Evaluador
explicativos? comparar con el número total es lo mejor conjunta
B = Número de mensajes B = Cantidad Reporte de
de mensajes.
implementados revisión
¿Qué proporción de A = Número de elementos de X= de
elementos de la interfaz que 0 <= X <= 1 6.4 Verificación
Claridad de la los elementos de la interfaz que son auto Cantidad/Cantidad requerimientos. Desarrollador
sean auto explicativos y Lo más cercano a 1 Absoluta 6.6 Revisión
interfaz interfaz son auto- explicativos. A = Cantidad Diseño Evaluador
comparar con el número total es lo mejor. conjunta
explicativos? B = Número total de B = Cantidad Reporte de
de elementos de interfaz.
elementos de interfaz. revisión
X=A/B
funciones que hayan sido Especificación
Capacidad para ¿Qué proporción de implementadas con un X= de
implementadas con manejo 0 <= X <= 1 6.4 Verificación
recuperarse de las funciones pueden manejo de errores y comparar Cantidad/Cantidad requerimientos. Desarrollador
de una tolerancia al error. Lo más cercano a 1 Absoluta 6.6 Revisión
un error tolerar un error del con el total del número de A = Cantidad Diseño Evaluador
B = Número total de funciones es lo mejor. conjunta
operacional usuario? funciones que requieren la B = Cantidad Reporte de
que requieren la capacidad de
capacidad de tolerancia de revisión
manejo de errores.
errores.
64
Métricas internas de atractividad

Tipo de Referencia
métrica 12207
Interrogar al usuario para
conocer su opinión sobre la
apariencia de la interfaz,
tomando en cuenta atributos,
tales como colores o diseños
gráficos. Especificación
COMENTARIO(S): Algunos de
X = Cantidad 6.4 Verificación
Interacción ¿Qué tan atractiva es Aplicar cuestionario a los elementos que contribuyen a Clasificación de la requerimientos. Desarrollador
Ordinal (Cantidad es un 6.6 Revisión
atractiva la interfaz del usuario? usuarios mejorar la apariencia de la evaluación Diseño Evaluador
puntaje) conjunta
interfaz son: Elementos Reporte de
alineados, grupos, uso de revisión
colores, Tamaño de los
elementos, Uso de espacios
en blanco, bordes,
separadores, animaciones e
interfaces 3D
¿Qué proporción de X=A/B Especificación
los elementos de A = Número de tipos de X= de
Personalización 0 <= X <= 1 6.4 Verificación
interfaz del usuario elementos de la interfaz que Cantidad/Cantidad requerimientos. Desarrollador
de la apariencia Inspección (por un experto) Lo más cercano a 1, Absoluta 6.6 Revisión
puede ser pueden ser personalizados A = Cantidad Diseño Evaluador
de la interfaz es lo mejor. conjunta
personalizada en B = Número total de tipos de B = Cantidad Reporte de
cuanto a apariencia? elementos de la interfaz revisión
Métricas de conformidad de usabilidad

Tipo de Referencia
métrica 12207
Especificaciones
X=A/B
Contar el número de de conformidad
A = Número de elementos
¿En qué medida la elementos que requieran y normas,
implementados de forma
conformidad del conformidad y que hayan X convenciones o
correcta y que estén 0<= X <=1 6.4 Verificación
Conformidad de producto debe aplicar cumplido dicha conformidad y =Cantidad/Cantidad regulaciones Evaluador
relacionados con la Lo más cercano a 1 Absoluta 6.6 Revisión
usabilidad regulaciones, normas comparar con el número de A =Cantidad relacionadas. Desarrollador
conformidad aprobada en la es lo mejor conjunta
y convenciones de elementos que requieren B =Cantidad Diseño
evaluación.
usabilidad? conformidad en la Código fuente
B = Número total de ítems
especificación Reporte de
que requieren conformidad.
revisión
Fuente: INACAL
65
Tabla 10. NTP 9126-3 2005 Métricas de Eficiencia
Métricas internas del comportamiento en el tiempo

Tipo de Referencia
métrica 12207
Evaluar la eficiencia del
sistema operativo y las
llamadas de las aplicaciones.
Estimar el tiempo de
respuesta basándose en lo
anterior.
Sistema
Lo siguiente puede ser
operativo
¿Cuál es el tiempo medido:
conocido. 6.4 Verificación
Tiempo de estimado para - Todo o parte de la X = tiempo (calculado o Lo menor es lo Desarrollador
Ratio X = Tiempo Tiempo 6.6 Revisión
respuesta completar una tarea especificación del diseño simulado) mejor Evaluador
estimado en conjunta
especifica? - Probar toda la ruta de la
llamadas al
transacción
sistema
- Pruebas completas de los
módulos o partes del
producto software
- El producto software
completo durante la fase de
prueba
Evaluar la eficiencia de la Sistema
¿Cuál es el número manipulación de recursos del operativo
estimado de tareas sistema. conocido. 6.4 Verificación
Tiempo de X = Número de tareas por Lo mayor es lo Desarrollador
que pueden ser Establecer un factor basado Ratio X =Cantidad Tiempo 6.6 Revisión
rendimiento unidad de tiempo mejor. Evaluador
realizadas durante una en las llamadas de las estimado en conjunta
unidad de tiempo? aplicaciones para el manejo llamadas al
de recursos. sistema
66
Evaluar la eficiencia del

sistema operativo y las
llamadas de las aplicaciones.
Estimar el tiempo de
respuesta para completar un
grupo de tareas relacionadas
basándose en lo anterior. Sistema
¿Cuál es el tiempo
Lo siguiente podrá ser operativo
estimado para
medido: conocido. 6.4 Verificación
Tiempo de completar un grupo de X = tiempo (calculado o Lo menor es lo Desarrollador
- Todo o parte de la Ratio X = Tiempo Tiempo 6.6 Revisión
retorno tareas relacionadas simulado) mejor Evaluador
especificación del diseño estimado en conjunta
como un trabajo en
- Probar toda la ruta de la llamadas al
lote?
transacción sistema
- Pruebas completas de los
módulos o partes del
producto software
- El producto software
completo durante la fase de
prueba
Métricas interna de utilización de los recursos

Tipo de Referencia
métrica 12207
¿Cuál es la utilización
Estimar la utilización de
estimada de entradas
Utilización de entradas y salidas X = Número de Buffers Lo menor es lo
y salidas para Ratio X = Tamaño Código fuente 6.4 Verificación Desarrollador
entradas y salidas requeridas para la (calculados o simulados). mejor
completar una tarea
aplicación.
específica?.
¿Cuál es la densidad
X=A/B
de los mensajes Contar el número de errores o
A = Número de mensajes de
relacionados a la advertencias relacionadas a
error relacionados con fallas X=
Densidad de los utilización de entradas las fallas en las entradas y
de entrada y salida. Lo mayor es lo Cantidad/Cantidad
mensajes de y salidas que se salidas y comparar con el Absoluta Código fuente 6.4 Verificación Desarrollador
B = Número de líneas de mejor A = Cantidad
entrada y salida encuentran en las número estimado de líneas de
código directamente B = Cantidad
líneas de código código responsables de
relacionadas a llamadas al
responsables de llamadas al sistema
sistema.
llamadas al sistema?.
67
¿Cuál es el tamaño
estimado de memoria Estimar el
Utilización de que ocupará el Estimar el requerimiento de X = Tamaño en bytes Lo menor es lo tamaño de
Ratio X = Tamaño 6.4 Verificación Desarrollador
memoria producto para memoria (calculado o estimado). mejor utilización de
completar una tarea memoria
específica?.
¿Cuál es la densidad X=A/B
Contar el número de errores o
de los mensajes A = Número de mensajes de
advertencias relacionadas a
Densidad de relacionados a la error relacionados a fallas de X=
las fallas en la utilización de la
mensajes en la utilización de la memoria. Lo mayor es lo Cantidad/Cantidad
memoria y comparar con el Ratio Código fuente 6.4 Verificación Desarrollador
utilización de memoria en las líneas B = Número de líneas de mejor A = Cantidad
número estimado de líneas de
memoria de código que son código directamente B = Cantidad
código responsables de
responsables de relacionadas a llamadas al
llamadas al sistema
llamadas al sistema? sistema
Sistema
¿Cuál es la cantidad operativo
Estimar la utilización de los
estimada de la conocido.
Utilización de la recursos de transmisión X = bits / tiempo (calculado o Lo menor es lo
utilización de la Ratio X = Tiempo Tiempo 6.4 Verificación Desarrollador
transmisión estimando el volumen de estimado) mejor
transmisión de estimado en
transmisión.
recursos? llamadas al
sistema
Métricas Internas de conformidad de eficiencia

Tipo de Referencia
métrica 12207
Especificación
de conformidad
¿En qué medida Contar el número de X =A / B
y normas,
cumple la eficiencia elementos que requieren A = Número de elementos
convenciones o
del producto con conformidad y que han sido implementados relacionados 0<= X <=1 6.4 Verificación
Conformidad de X= regulaciones Evaluador
respecto a cumplidos y comparar con el a la conformidad de Lo más cerca de 1, Absoluta 6.6 Revisión
eficiencia Cantidad/Cantidad relacionadas. Desarrollador
regulaciones, normas número de elementos que eficiencia. es lo mejor. conjunta
Diseño
y convenciones requieren conformidad en la B = Número total de ítems de
Código Fuente
aplicables? especificación. conformidad
Reporte de
revisión
68
Métricas internas de analizabilidad

Tipo de Referencia
métrica 12207
0 <= X <= 1
Lo más cerca a 1,
significa que se
X=A/B El valor de A
tiene mayor
A = Número de datos viene del
Contar el número de ítems cantidad de datos
registrados de acuerdo a las reporte de
registrados en el registro de para registrar el X=
¿Qué tan completo es especificaciones, confirmados revisión. 6.4 Verificación
Registro de actividades según lo estado del sistema. Cantidad/Cantidad Mantenimiento
el registro del estado en la revisión. Absoluta El valor de B 6.6 Revisión
actividades especificado y comparar con COMENTARIO: Es A = Cantidad Usuario
del sistema? B = Número de datos que viene del conjunta
el número de elementos que necesario convertir B = Cantidad
deberían ser registrados de requerimiento
requieren ser registrados. este valor al
acuerdo a las de
intervalo <0,1> si
especificaciones. especificaciones
se hace un
resumen de las
características
0 <= X <= 1
Lo más cerca a 1,
funciones de diagnóstico
provee una mejor El valor de A
implementadas como se han
X=A/B implementación de viene del
especificado y comparar con
A = Número de funciones de las funciones de reporte de
¿Qué tan completa es el número de funciones de X=
Preparación de diagnóstico especificadas diagnóstico revisión. 6.4 Verificación
la provisión de diagnóstico requeridas en la Cantidad/Cantidad Mantenimiento
funciones de implementadas, y COMENTARIO: Es Absoluta El valor de B 6.6 Revisión
funciones de especificación A = Cantidad Usuario
diagnóstico confirmadas en la revisión. necesario convertir viene del conjunta
diagnóstico? COMENTARIO: Esta métrica B = Cantidad
B = Número de funciones de este valor al requerimiento
también es usada para medir
diagnóstico requeridas. intervalo <0,1> si de
la capacidad de análisis de
se hace un especificaciones
fallas y la capacidad de
resumen de las
análisis de causas.
características
Fuente: INACAL
69
Tabla 11. NTP 9126-3 2005 Métricas de Mantenimiento
Métricas internas de cambiabilidad

Tipo de Referencia
métrica 12207
0 <= X <= 1
X=A/B
Lo más cercano a
¿Son los cambios a las A = Número de cambios en
1, indica un mayor Sistema de
especificaciones y funciones y / o módulos que
registro. Cuando el X= control de
módulos de programa tienen comentarios, 6.4 Verificación Desarrollador
Registro de Registrar el ratio del módulo control de cambio Cantidad/Cantidad configuración.
registrados confirmado en la revisión. Absoluta 6.6 Revisión Mantenimiento
Cambios de cambio de información. indica 0, significa A = Cantidad Registro de
adecuadamente en el B = Número total de conjunta Evaluador
un pobre control B = Cantidad versiones.
código y haciendo uso funciones y / o módulos
de cambios o Especificaciones
de comentarios? alterados desde la primera
pequeños cambios,
versión del código.
alta estabilidad
Métricas internas de estabilidad

Tipo de Referencia
métrica 12207
X = 1-A / B A = Proviene
Contar el número de impactos
¿Cuál es la frecuencia A = Número de impactos X= del reporte de
adversos detectados después 0 <= X <= 1 6.4 Verificación Desarrollador
Impacto de de los impactos adversos detectados después Cantidad/Cantidad revisión
de la modificación y comparar Lo más cerca de 1 Absoluta 6.6 Revisión Mantenimiento.
cambios adversos después de de la modificación A = Cantidad B = Proviene del
con el número de es lo mejor conjunta Evaluador
la modificación? B = Número de B = Cantidad reporte de
modificaciones realizadas.
modificaciones hechas revisión
Contar el número de variables
afectadas en una modificación
y comparar con el número
total de variables en el X = A/B A = Proviene
0 <= X <= 1
¿Qué tan grande es el producto. A = Número de variables de X= del reporte de
Lo más cerca de 0, 6.4 Verificación Desarrollador
Impacto de la impacto de la COMENTARIO: Variable datos afectadas por la Cantidad/Cantidad revisión
menor es el Absoluta 6.6 Revisión Mantenimiento.
modificación modificación en el impactada es: modificación, confirmado en A = Cantidad B = Proviene del
impacto de la conjunta Evaluador
producto software? a) Toda variable en la la revisión B = Cantidad reporte de
modificación
instrucción que fue cambiada. B = Número total de variables revisión
b) Variable que está en la
misma instrucción que las
variables indicadas en a).
70
Métricas de testeabilidad
Tipo de Referencia
métrica 12207
Contar el número de X=A/B
A viene del
funciones de pruebas A = Número de funciones de
documento de
Completitud de incorporadas según lo pruebas incorporadas según X=
¿Qué tan completa es 0 <= X <= 1 revisión. 6.4 Verificación Desarrollador
las funciones de especificado y comparar con lo especificado, confirmadas Cantidad/Cantidad
la capacidad de Lo más cercano a 1 Absoluta B viene del 6.6 Revisión Mantenimiento
prueba el número de funciones de en una revisión. A = Cantidad
pruebas incorporadas? es lo mejor documento de conjunta Evaluador
incorporadas pruebas incorporadas, y B = Número de funciones B = Cantidad
requerimientos
estipuladas en el incorporadas de pruebas
o diseño
requerimiento requeridas
X=A/B A viene del
dependencias que se tiene
A = Número de dependencias documento de
con otros sistemas para X=
¿Cuán independiente con otros sistemas que hayan 0 <= X <= 1 revisión. 6.4 Verificación Desarrollador
Autonomía de la pruebas que hayan sido Cantidad/Cantidad
mente puede ser sido simulados. Lo más cercano a 1 Absoluta B viene del 6.6 Revisión Mantenimiento
testeabilidad simulados y comparar con el A = Cantidad
probado el software? B = Número total de pruebas es lo mejor documento de conjunta Evaluador
número total de B = Cantidad
de dependencia con otros requerimientos
dependencias con otros
sistemas . o diseño
sistemas para pruebas.
X=A/B
Contar el número de puntos A viene del
A = Número de puntos de
de comprobación documento de
Capacidad para ¿Qué tan completos se comprobación X=
implementados según lo 0 <= X <= 1 revisión. 6.4 Verificación Desarrollador
observar el muestran los implementados según lo Cantidad/Cantidad
especificado y comparar con Lo más cercano a 1 Absoluta B viene del 6.6 Revisión Mantenimiento
progreso de las resultados durante las especificado, confirmados en A = Cantidad
el número de puntos de es lo mejor documento de conjunta Evaluador
pruebas pruebas? una revisión. B = Cantidad
comprobación requeridos por requerimientos
B = Número de puntos de
el diseño. o diseño
comprobación diseñados.
71
Métricas internas de conformidad de facilidad de mantenimiento

Tipo de Referencia
métrica 12207
Especificaciones
X=A/B
¿Qué tanto cumple la de conformidad
Contar el número de A = Número de elementos
facilidad de y normas,
elementos que requieren implementados en forma
mantenimiento del X= convenciones o
Conformidad de conformidad que han sido correcta con respecto a la 0 <= X <= 1 6.4 Verificación
producto con respecto Cantidad/Cantidad regulaciones Evaluador
facilidad de cumplidos y comparar con el conformidad de facilidad de Lo más cercano a 1 Absoluta 6.6 Revisión
a regulaciones, A = Cantidad relacionadas. Desarrollador
mantenimiento número de elementos que mantenimiento, es lo mejor. conjunta
normas o B = Cantidad Diseño
requieren conformidad en la comprobados en una revisión.
convenciones Código Fuente
especificación. B = Número total de
aplicables? Reporte de
elementos conformes.
revisión
Fuente: INACAL
Tabla 12. NTP 9126-3 2005 Métricas de Portabilidad
Métricas internas de adaptabilidad

Tipo de
Interpretación Referencia
Nombre de Propósito de la Medición, fórmula y cálculo de escala Entradas para Audiencia
Método de aplicación del valor Tipo de medida PCVS ISO/IEC
métrica métrica los elementos de datos de la medición objetivo
medido 12207
métrica
X = A/B
A = Número de las estructuras de
Contar el número de estructuras
datos que son operables y no Especificación
de datos, que son operables y no
¿Cuán adaptable es el tienen ninguna limitación 0<= X <= 1 X= de 6.4
Adaptabilidad de tienen ninguna limitación después Desarrollador
producto a cambios en después de la adaptación, Cuanto más Cantidad/Cantidad requerimientos Verificación
estructuras de de la adaptación y comparar con Absoluto Mantenimiento
las estructuras de confirmado en la revisión. cercano a 1 es A = Cantidad Diseño 6.6 Revisión
datos el número total de estructuras de Evaluador
datos? B = Número total de las lo mejor B = Cantidad Reporte de conjunta
datos que requieren capacidad de
estructuras de datos que revisión
adaptación.
requieren capacidad de
adaptación.
72
X = A/B
Contar el número de funciones A = Número de las funciones
Adaptabilidad del
implementadas que son capaces implementadas que son capaces
hardware al Especificación
¿Cuán adaptable es el de alcanzar resultados en de alcanzar resultados en el
entorno 0<= X <= 1 X= de 6.4
producto a los entornos de hardware múltiples entorno de hardware múltiples Desarrollador
(adaptabilidad a Cuanto más Cantidad/Cantidad requerimientos Verificación
cambios del entorno especificados y comparar con el según lo especificado, Absoluto Mantenimiento
dispositivos de cercano a 1 es A = Cantidad Diseño 6.6 Revisión
relacionado al número de funciones con confirmado en la revisión. Evaluador
hardware e lo mejor B = Cantidad Reporte de conjunta
hardware? requisitos de capacidad de B = Número total de funciones
instalaciones de revisión
adaptación al entorno del con requisitos de capacidad de
redes)
hardware. adaptación al entorno del
hardware.
X = A/B
Contar el número de las funciones A = Número de las funciones
Adaptabilidad al
implementadas que son capaces implementadas que son capaces
entorno Especificación
de alcanzar los resultados de alcanzar los resultados
organizacional 0<= X <= 1 X = Cantidad/ de 6.4
¿Cuán adaptable es el requeridos en organizaciones requeridos en el ambientes de Desarrollador
(adaptabilidad a Cuanto más Cantidad requerimientos Verificación
producto al cambio múltiples según lo especificado y organizaciones y de negocio Absoluto Mantenimiento
la organización y cercano a 1 es A = Cantidad Diseño 6.6 Revisión
organizacional? comparar con el número de múltiples según lo especificado, Evaluador
a la lo mejor B = Cantidad Reporte de conjunta
funciones con requisitos de confirmado en la revisión
infraestructura revisión
adaptabilidad al entorno B = Número total de funciones
de la misma)
organizacional. con requisitos de adaptabilidad
al ambiente de la organización.
X = A/B
Contar el número de las funciones
A = Número de las funciones que
implementadas que son capaces Especificación
soportan la facilidad de la
¿Cuánto esfuerzo es de soportar la facilidad de 0<= X <= 1 X= de 6.4
Facilidad de adaptación del usuario según lo Desarrollador
necesario para realizar adaptación del usuario según lo Lo más Cantidad/Cantidad requerimientos Verificación
portabilidad para especificado, confirmado en la Absoluta Mantenimiento
operaciones portables especificado y comparar con el cercano a 1 es A = Cantidad Diseño 6.6 Revisión
el usuario revisión. Evaluador
al producto? número de funciones con lo mejor B = Cantidad Reporte de conjunta
B = Número de funciones con
facilidad de adaptación a los revisión
facilidad de adaptación a los
requisitos de capacidad.
requisitos de capacidad.
X = A/B
Adaptabilidad al Contar el número de funciones
A = Número de las funciones
entorno del implementadas que son capaces
implementadas que son capaces
sistema software de alcanzar los resultados Especificación
¿Cuán adaptable es el de alcanzar los resultados
(adaptabilidad al requeridos en entornos múltiples 0<= X <= 1 X= de 6.4
producto a los requeridos en el entorno Desarrollador
sistema de sistemas de software según lo Lo más Cantidad/Cantidad requerimientos Verificación
cambios del entorno múltiple especificado del Absoluta Mantenimiento
operativo, al especificado y comparar con el cercano a 1 es A = Cantidad Diseño 6.6 Revisión
relacionados del software del sistema según lo Evaluador
software de redes número de funciones con lo mejor B = Cantidad Reporte de conjunta
software del sistema? especificado, confirmado en la
y al software de requisitos de capacidad de revisión
revisión.
la aplicación adaptación del entorno del
B = Número total de funciones
instalada) software del sistema.
con requisitos de capacidad de
73
adaptación del entorno del

software del sistema.
Métricas internas de instalabilidad

Tipo de
medido 12207
métrica
X = A/B
A = Número de reinstalaciones 0<= X <= 1 X=
¿Cuán fácil es repetir reinstalaciones implementadas y
Facilidad de implementadas, confirmadas en Lo más Cantidad/Cantidad Reporte de
el proceso de comparar con el número de Absoluta 6.5 Validación Desarrollador
reinstalación la revisión. cercano a 1 es A = Cantidad revisión
instalación? operaciones de reinstalación
B = Número total de operaciones lo mejor B = Cantidad
requeridas.
de instalación requeridas.
X = A/B
A= Número de tareas
automatizadas implementadas,
confirmadas en la revisión.
Contar el número de tareas de 0<= X <= 1 X=
¿Qué nivel de esfuerzo B= Número de tareas de
Esfuerzo de instalación automatizadas y Lo más Cantidad/Cantidad Reporte de
se requiere para la instalación requeridas. Absoluta 6.5 Validación Desarrollador
instalación comparar con el número de tareas cercano a 1 es A = Cantidad revisión
instalación? COMENTARIO(S): Ejemplo:
definidas de la instalación. lo mejor B = Cantidad
número de
ventanas/comandos/operaciones
manuales para alcanzar el
objetivo operativo.
X = A/B
A = Número de operaciones de
Contar el número de operaciones instalación personalizable
de instalación personalizable implementadas y confirmadas en Especificación
¿Cuán flexible y 0<= X <= 1 X=
implementadas según lo la revisión. de
Flexibilidad de la personalizable (s) es la Lo más Cantidad/Cantidad
especificado y comparar con el B = Número de operaciones con Absoluta Requerimientos 6.5 Validación Desarrollador
instalación capacidad de la cercano a 1 es A = Cantidad
número operaciones de capacidad de personalización Reporte de
instalación? lo mejor B = Cantidad
instalaciones con requisitos de requerida. revisión
instalación personalizable. COMENTARIO(S): Personalizable:
Ejemplo., anidado, profundidad,
número de paneles.
74
Métricas internas de co-existencia

Tipo de
medido 12207
métrica
Contar el número de entidades X = A/B
Especificación
¿Cuán flexible es el con las que el producto puede co A = Número de entidades con las
0<= X <= 1 X= de 6.4
producto para existir según lo especificado y que el producto puede coexistir Evaluador
Capacidad de Lo más Cantidad/Cantidad Requerimientos Verificación
compartir su entorno comparar con el número de según lo especificado. Absoluta Desarrollador
coexistencia cercano a 1 es A = Cantidad Diseño 6.6 Revisión
sin impactos adversos entidades en el entorno de B = Número de entidades en Mantenimiento
lo mejor B = Cantidad Reporte de conjunta
con otros productos? producción que requieran producción que requieran co
revisión
coexistencia. existencia.
Métricas internas de reemplazabilidad

Tipo de
medido 12207
métrica
X = A/B
Contar el número de elementos de A = Número de elementos de
datos, que continúan siendo datos de software que continúan Diseño
¿Cuál es la cantidad de
utilizados después del reemplazo siendo usados según lo Código
datos originales que 0<= X <= 1 X= 6.4
según lo especificado, y comparar especificado después del Fuente Evaluador
Uso continuo de permanecen sin Lo más Cantidad/Cantidad Verificación
con el número total de elementos reemplazo, confirmado en la Absoluta Reporte de Desarrollador
los datos cambios después del cercano a 1 es A = Cantidad 6.6 Revisión
de datos requeridos para ser evaluación. revisión Mantenimiento
reemplazo con este lo mejor B = Cantidad conjunta
usados por los datos anteriores B = Número de elementos de Reporte de
producto?
después del reemplazo de datos anteriores requeridos para Pruebas
software. ser usados por el software
anterior.
X = A/B
Diseño
Contar el número de funciones Código
¿Cuál es la cantidad de cubiertas por el nuevo software 0<= X <= 1 X= 6.4
cubiertas por el nuevo software Fuente Evaluador
Invariabilidad de funciones que que produce resultados Lo más Cantidad/Cantidad Verificación
que produce resultados similares y Absoluta Reporte de Desarrollador
la función permanecen sin similares, confirmado en la cercano a 1 es A = Cantidad 6.6 Revisión
comparar con el número de revisión Mantenimiento
cambios? revisión. lo mejor B = Cantidad conjunta
funciones del software anterior. Reporte de
B = Número funciones del
Pruebas
software anterior.
75
Métricas internas de la conformidad de portabilidad

Tipo de
medido 12207
métrica
Especificación
de conformidad
X = A/B a los
¿Cuán conforme es la
Contar el número de ítems que A = Número de artículos estándares,
portabilidad del
requieran que la conformidad correctamente implementados 0<= X <= 1 X= convenciones o 6.4
producto a las
Conformidad de haya sido satisfecha y comparar relacionados con la conformidad Lo más Cantidad/Cantidad regulaciones Verificación Evaluador
regulaciones, Absoluta
portabilidad con el número de artículos que referente a la portabilidad, cercano a 1 es A = Cantidad relacionadas. 6.6 Revisión Desarrollador
estándares y
requieran conformidad según la confirmada en la evaluación. lo mejor. B = Cantidad Diseño conjunta
convenciones
especificación. B = Número total de artículos Código
aplicables?
confirmados. Fuente
Reporte de
revisión
Fuente INACAL
76
Como se puede ver en las tablas anteriores, se mantienen las variables métricas de:
• Funcionalidad
• Fiabilidad
• Usabilidad
• Eficiencia
• Mantenimiento
• Portabilidad
Cada una de ellas consideran diferentes grupos y métricas como se muestra a
continuación:
77
Tabla 13. Distribución de Métricas NTP9 126-3 2005
FUNCIONALIDAD FIABILIDAD USABILIDAD

Métricas internas de aplicabilidad Métricas internas de madurez Métricas internas de entendibilidad
Adecuación funcional Detección de fallas Claridad de la descripción
Integridad de implementación funcional Eliminación de fallas Capacidad de demostración
Cobertura de la implementación funcional Suficiencia de pruebas Métricas Internas de entendibilidad
Estabilidad (volatilidad) de la especificación funcional Métricas internas de tolerancia a fallos Funciones evidentes
Métricas internas de precisión Prevención de fallos Función de comprensión
Exactitud de cálculos Prevención de operación incorrecta Métricas Internas de facilidad de aprendizaje
Integridad de la documentación del usuario y/o facilidad de
Precisión Métricas internas de recuperabilidad
ayuda
Métricas internas de interoperabilidad Capacidad de restauración Métricas Internas de operabilidad
Intercambiabilidad de datos (basado en formatos de datos) Efectividad de la capacidad de restauración Revisión de la validez de la entrada
Consistencia de las interfaces Métricas internas de conformidad de fiabilidad Capacidad de cancelar operación de usuario
Métricas internas de seguridad Conformidad de fiabilidad Métricas Internas de operabilidad
Auditoría de accesos Capacidad de deshacer operación de usuario
Control de acceso Personalización
Prevención de corrupción de datos Accesibilidad física
Encriptación de datos Capacidad para monitorear el desarrollo de las operaciones
Métricas internas de conformidad de funcionalidad Consistencia operacional
Conformidad de funcionalidad Claridad de mensajes
Conformidad con normas para intersistemas Claridad de la interfaz
Capacidad para recuperarse de un error operacional
Interacción atractiva
Personalización de la apariencia de la interfaz
Conformidad de usabilidad
78
EFICIENCIA MANTENIMIENTO PORTABILIDAD

Métricas internas del comportamiento
Métricas internas de cambiabilidad Métricas internas de adaptabilidad
en el tiempo
Tiempo de respuesta Registro de Cambios Adaptabilidad de estructuras de datos
Adaptabilidad del hardware al entorno (adaptabilidad a dispositivos
Tiempo de rendimiento Métricas internas de estabilidad
de hardware e instalaciones de redes)
Adaptabilidad al entorno organizacional (adaptabilidad a la
Tiempo de retorno Impacto de cambios
organización y a la infraestructura de la misma)
Métricas internas de utilización de los recursos Impacto de la modificación Facilidad de portabilidad para el usuario
Adaptabilidad al entorno del sistema software (adaptabilidad al
Utilización de entradas y salidas Métricas de testeabilidad sistema operativo, al software de redes y al software de la aplicación
instalada)
Densidad de los mensajes de entrada y salida Completitud de las funciones de prueba incorporadas Métricas internas de instalabilidad
Utilización de memoria Autonomía de la testeabilidad Facilidad de reinstalación
Densidad de mensajes en la utilización de memoria Capacidad para observar el progreso de las pruebas Esfuerzo de instalación
Métricas internas de conformidad de facilidad de
Utilización de la transmisión Flexibilidad de la instalación
mantenimiento
Métricas Internas de conformidad de eficiencia Conformidad de facilidad de mantenimiento Métricas internas de co-existencia
Conformidad de eficiencia Capacidad de coexistencia
Métricas internas de analizabilidad Métricas internas de reemplazabilidad
Registro de actividades Uso continuo de los datos
Preparación de funciones de diagnóstico Invariabilidad de la función
Conformidad de portabilidad
Fuente: INACAL
79
En la tabla anterior se puede ver que:
• Funcionalidad tiene 3 grupos y 14 métricas
• Fiabilidad tiene 4 grupos y 8 métricas
• Usabilidad tiene 4 grupos y 18 métricas
• Eficiencia tiene 4 grupos y 11 métricas
• Mantenimiento tiene 3 grupos y 7 métricas
• Portabilidad tiene 5 grupos y 12 métricas
Los resultados de esta fuente secundaria, permite ser la base para el planteamiento de
los objetivos establecidos en el trabajo de investigación.
4.2 Resultados Fuente Primaria
En el presente punto se analizó la fuente primaria, tomando en cuenta dos de ellos, uno
que es parte de la empresa y otro a los usuarios finales de la plataforma. En el caso del
personal de la empresa, se buscó a los responsables del desarrollo y mantenimiento del
software, siendo el rol de evaluador el gerente general y el tesista.
En esta primera fuente primaria se desarrolló tres actividades: entrevista
semiestructurada, para conocer parte del proceso, la aplicación de la métrica antes de
los cambios y después de la implementación de la NTP.
Dentro de la entrevista aplicada a 5 personas de la empresa: gerente general, gerente
administrativo, jefe de TIC, diseñador gráfico y programador del proyecto OC Tesis,
posteriormente S.O.S. Tesis, se les planteó dos preguntas:
- ¿Cómo se dan los procesos para el desarrollo de los softwares, en especial, el
S.O.S. Tesis?
80
Las personas dieron respuestas similares, pues los procesos de desarrollo del
software, se originan en la gerencia general, quien es el inventor de lo que se va
a programar, reúne al equipo, el equipo entiende lo que se desea hacer y lo
desarrollan. Cabe indicar que dentro de los pasos que se establecen, la empresa
mantiene un MOF y ROF, desde el año 2012, es decir, antes no lo tenían, en él se
aprecia también parte de los procesos, lo que no tienen es un Manual de
Procesos específico para el desarrollo de software, lo que hace evidenciar, el
porqué de algunos de los resultados de las métricas que se obtuvieron. Entonces
como parte de la relación de la Norma Técnica Peruana 9126-3, para con las
siguientes dimensiones se concluye que:
o Diagnóstico: La empresa cuenta con una MOF, ROF pero no tiene
MAPROS para el desarrollo de software, sin embargo, se puede ver en
sus documentos de gestión que si se establecen jerarquías,
responsabilidades y por supuesto una forma muy general, el proceso se
tiene para el desarrollo de software:
o Planificación: Los requerimientos humanos, materiales y económicos, no
establecen una previsión en formato alguno, más si se da un líder del
proyecto y se proyecta el tiempo a desarrollar el software, siendo lo
económico, lo que se puede prever en pagos considerados dentro de las
remuneraciones mensuales o la contratación de persona solo para el
proyecto.
o Ejecución: La ejecución, es supervisada por el jefe de TIC, quien también
mantiene los resultados de las pruebas de stress y los servidores que son
81
externos (hosting americanos) y la funcionabilidad de todos los
terminales.
o Evaluación: Reportes e Informes son revisados por la gerencia general y
la gerencia administrativa, quienes en reunión analizan la exposición del
jefe de TIC.
Estas dimensiones, se presentan al interior de la empresa, y se relacionan
con la NTP que se implementó, pues demuestra el porqué de algunos de los
resultados establecidos en la métrica.
En la figura siguiente, proporcionada por la empresa, se ve cómo es que se
da la esquematización del proceso que ellos denominan software enlatado.

82
Figura 2. Proceso general MOF y ROF
Fuente: OCEAN SRL

83
En la entrevista sostenida, indicaron que los procesos que se muestran no tienen
a la fecha una métrica establecida, que sería la primera vez que se mantenga
esta con el presente trabajo, pero si se hizo énfasis, que, del año 2012 a la fecha,
por la pandemia y otros eventos, los líderes regionales que se tienen en el MOF
y ROF, se han deshabilitado, por lo que se centra todo en la oficina con el
organigrama que proporcionaron:
Figura 3. Organigrama Funcional OCEAN SRL
Fuente: OCEAN SRL
A la fecha se mantienen las funciones, pero pueden mejorarse, como se apreció
en las respuestas que presentan en la siguiente pregunta:

84
- ¿Cómo se podría mejorar los procesos de desarrollo de los softwares, en
especial, el S.O.S. Tesis?
Señalaron que en algún momento se pensó en participar en una ISO, con el
respaldo del Estado, a través de fondos concursables, por lo menos para uno de
sus procesos, sin embargo, los costos de aquel entonces, para dar la
contrapartida, no eran favorables, por lo que no se logró mayor avance. Todos
están de acuerdo que implementar sistemas, como el de la NTP, es un avance,
para demostrar la sostenibilidad que se pueda tener, en especial, en uno de los
software que logra cada vez más usuarios, los mismos que no pagan por su uso,
ya que es parte de la cadena productiva de la empresa, considerada así a la
cadena de producción y comercialización, que se tiene, pues es como una especia
de gancho y al mismo tiempo parte de su Responsabilidad Social Empresarial
(RSE), por eso es que al aplicar el instrumento de encuesta a los usuarios, fueron
muy celosos en brindar los correos e indicaron que se proporcionará los
resultados que se requieran pero que la propia gerencia sería quien aplique el
instrumento entre sus usuarios.
La gerencia administrativa, señaló que el hecho de tener la forma de mejora
constante de PHVA les ha permitido estar en el mercado más de 18 años, pero
que los cambios que se dan en el conocimiento de software es muy radical, pues
los lenguajes de programación, bases de datos y competidores constantemente
que se dan en el mercado, no permite tener una proyección sostenible, pues
antes del 2006 se contaba con varios software enlatados, pero que proyectan
para el 2030 fortalecer los software que son I+D+i+e, pues es no solo la línea que
se adecuad a la teoría del conocimiento de los integrantes de la empresa, sino

85
también a un nicho permanente como es el de las universidades y que a pesar
que el primer OC Tesis se da en el año 2006, se espera que con esta investigación
se mantengan las métricas de evaluación que fortalecerán la calidad, en especial
del OC Tesis que es ahora S.O.S. Tesis.
Algo muy peculiar es que ese proceso de mejora y de establecimiento de
proyecto, no cuenta con la medición de la calidad, como se evidencia en la figura
que es parte de la documentación brindada por la empresa.

86
Figura 4. Formato de Proyecto
Fuente: OCEAN SRL
Con los resultados mostrados en las respuestas del personal, es que se puede indicar
que la empresa no cuenta con un sistema de calidad relacionado a NTP, sus procesos,
están definidos en forma general y al ser pocos los trabajadores es que se puede tener
87
en cuenta que ante cualquier problema se puede plantear una solución, pero eso es lo
que se desea evitar, según el jefe de TIC, no es bueno solo apagar los incendios y contar
con esta forma de medición, será mejorar la calidad que es siempre percibida por los
usuarios del software.
De la fuente primaria entonces, se obtuvo los resultados que se plasmaron en la
entrevista semiestructurada y de la cual se puede definir el proceso de la siguiente
forma:
Figura 5. Desarrollo Software S.O.S. Tesis
1- Gerente General 6- Stress y revisión 7- Difusión y

da idea de S.O.S. del software gerente colocación en el
Tesis administrativo mercado
2- Reunión con
8- Soluciones a
Gerente 5- Desarrollo del
problemas que los
Administrativo y jefe software
usuarios señalan
de TIC analizan idea
3- Se determina 4- Candelarización de
presupuestos y procesos sin métricas
tiempos de calidad normadas
Elaboración: propia
Como se ve en la figura anterior, no se presenta ninguna métrica de calidad y se plantean
problemas que se deben solucionar en el tiempo que los usuarios determinan.
El software considera la siguiente distribución:
DATOS INICIALES
· DATOS PERSONALES
· DATOS GENERALES
· TIPO DE REFERENCIA
PLAN DE TESIS
· LEGADO PARA LA HUMANIDAD
88
o FORMULACIÓN DEL PROBLEMA

§ DESCRIPCIÓN
§ PROBLEMA PRINCIPAL
§ PROBLEMA SECUNDARIO
o OBJETIVOS
§ OBJETIVO GENERAL
§ OBJETIVOS ESPECÍFICOS
o HIPÓTESIS
§ HIPÓTESIS GENERAL
§ HIPÓTESIS ESPECÍFICAS
§ HIPÓTESIS DE LA INVESTIGACIÓN
§ HIPÓTESIS ESTADÍSTICA
o VARIABLES /CATEGORÍAS
§ UNIVARIABLE
§ DEPENDIENTE
§ INDEPENDIENTE
o SUBVARIABLES / SUBCATEGORÍAS
§ INDICADORES
§ SUBCATEGORIAS
o UNIDAD DE ESTUDIO
§ HISTORIA
§ CARACTERÍSTICAS
o DELIMITACIÓN
§ ESPACIAL GEOGRÁFICA
§ TIEMPO
· ESTADO DEL ARTE
o MARCO TEÓRICO
§ REGIONALES
§ NACIONALES
§ INTERNACIONALES
o ANTECEDENTES
§ REGIONALES
§ NACIONALES
§ INTERNACIONALES
o MARCO CONCCEPTUAL
· CARACTERÍSTICAS DE LA INVESTIGACIÓN
o LINEAS DE INVESTIGACIÓN
o DISEÑO DE INVESTIGACIÓN
§ CUALITATIVO
§ CUANTITATIVO
§ MIXTO
o NIVEL DE INVESTIGACIÓN
§ EXPLORATORIO
§ DESCRIPTIVO
§ RELACIONAL
§ CORRELACIONAL
§ EXPLICATIVO
89
§ APLICATIVO
o TIPO DE INVESTIGACIÓN
§ POR REGLAMENTO DE CALIFICACIÓN Y REGISTRO DE INVESTIGADORES EN CIENCIA Y
TECNOLOGÍA DEL SINACYT: BÁSICA
TECNOLOGÍA DEL SINACYT: APLICADA
§ POR MANIPULACIÓN: OBSERVACIONAL
§ POR MANIPULACIÓN : EXPERIMENTAL
§ POR MANIPULACIÓN: CUASI EXPERIMENTAL
§ POR TIEMPO DE INTERVENCIÓN: RETROSPECTIVO
§ POR TIEMPO DE INTERVENCIÓN: PROSPECTIVO
§ POR CANTIDAD DE MEDICIONES: TRANSVERSAL
§ POR CANTIDAD DE MEDICIONES: LONGITUDINAL
§ POR EL TRATO DE VARIABLE: DESCRIPTIVO
§ POR EL TRATO DE VARIABLE: ANALÍTICO
§ POR SU FUENTE DE INFORMACIÓN: DOCUMENTAL
§ POR SU FUENTE DE INFORMACIÓN: EXPERIMENTAL
§ POR SU FUENTE DE INFORMACIÓN: DE CAMPO
o MÉTODO DE INVESTIGACIÓN
§ TEÓRICA
§ EMPÍRICA
· SOPORTE SOCIAL
o JUSTIFICACIÓN
§ ACADÉMICA
§ TÉCNICA
§ SOCIAL
§ ECONÓMICA
o IMPACTO O ALCANCE DE LA INVESTIGACIÓN
§ REGIONAL
§ NACIONAL
§ INTERNACIONAL
· INFORMACIÓN
o MUESTRA
§ PROBABILÍSTICA
§ NO PROBABILÍSTICA
§ A CONVENIENCIA
o INSTRUMENTOS
§ ENCUESTAS
§ ENTREVISTAS A PROFUNDIDAD
§ ENTREVISTAS SEMIESTRUCTURADA
§ ENTREVISTA ESTRUCTURADA
§ FICHA DOCUMENTAL
§ FICHA DE OBSERVACIÓN
§ GRUPO FOCAL
o APLICACIÓN DE INSTRUMENTOS
o ESTRATEGIA DE RECOLECCIÓN DE
INFORMACIÓN INSTRUMENTOS.
90
· REQUERIMIENTOS
o MATERIALES
o HUMANOS
CRONOGRAMA DE EJECUCIÓN
· APLICACIÓN DEL INSTRUMENTO (LUGAR, PERSONA,
FECHA Y HORA
· RECORDATORIO (A CORREO, CELULAR O AMBOS)
ESQUEMA CAPITULAR
DIAGRAMA GANTT
MATRIZ DE CONSISTENCIA
El software tiene seis menús: datos iniciales, plan de tesis, cronograma de ejecución,
esquema capitular, diagrama Gantt y matriz de consistencia y en cada uno de estos
diferentes submenús. Se detalla que hay 79 procesos, que el S.O.S. Tesis ejecuta, los
mismos que se evaluaron, para poder ver cómo es que la implementación de esta NTP,
puede mejorar los resultados. Las siguientes figuras son lo que se pudo ejecutar con
personal de la empresa, quien empleó el usuario del gerente general:

91
Figura 6. Acceso al S.O.S. Tesis
Es un usuario y contraseña el que da el acceso, para su autorización, es suficiente el
enviar un correo a [email protected] y se le brinda las indicaciones que debe cumplir
para acceder al software.
Figura 7. Diseño y distribución S.O.S. Tesis
En la figura anterior se muestra cómo es que a la izquierda aparecen las diferentes
opciones del software, mientras que en el cuerpo se muestran los menús, en la parte
92
superior y el en centro lo que se debe de llenar o las explicaciones en las celadas que el
usuario se posiciona.
Figura 8. Comunicación S.O.S. Tesis
El mismo S.O.S. Tesis, muestra mensajes como el que se ve en la figura de comunicación
con el mismo usuario.
Figura 9. Despliegue y Decisión usuario S.O.S. Tesis
Los espacios dentro del mismo S.O.S. Tesis muestra cómo es que se va desplegando
conforme va empleando el software.

93
SOS Tesis
Acceso a usuarios
Plataforma sin NTP
SOS Tesis
Identificación de
errores existentes Plataforma con NTP
El proceso de implementación, permitió que los 100 usuarios identifiquen que errores
presenta el SOS tesis, es así que se pudo detectar que, de un total de 79 acciones, 62
acciones funcionan sin problemas y señalando 17 debieron modificarse porque
presentan problemas o errores. Esta retroalimentación, permitió la implementación de
la NTP para que se de 80 acciones, la misma que luego fue medida por el staff. Si se
hubiera implementado la NTP desde el primer momento, no se hubiera perdido tiempo
en el mismo. Por eso los resultados se presentan en la siguiente información:

94
Figura 10. Error en Forma de Estilo de Referencia S.O.S. Tesis
Figura 11. Error en Desarrollo de Instrumentos S.O.S. Tesis
Además, se presentó una métrica de precisión que se relaciona con el Cálculo de la
muestra que se emplea y fue favorable

95
Figura 12. Métrica de Precisión Cálculo Muestra S.O.S. Tesis
Entre todo lo que se pudo ver, es que se plantea una corrección para que sean 80 pasos
y es que se pueda permitir en algunos casos de los menús el hecho de agregar una
96
variable más, según sea el caso, como por ejemplo tipo de variables, como se muestra
en la siguiente figura:
Figura 13. Aporte de Mejora de la Calidad S.O.S. Tesis

97
Los resultados obtenidos se pueden ver en las siguientes tablas:

98
Tabla 14. Resultados de Funcionabilidad Antes y Después de la NTP

Antes de Después de
Nombre de métrica Interpretación del valor medido
NTP NTP
Adecuación funcional 0.784810127 0.975 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
Integridad de implementación funcional 0.987341772 1 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
Cobertura de la implementación funcional 0.784810127 0.9875 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
Estabilidad (volatilidad) de la
0 0.9625 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
especificación funcional
Métricas internas de precisión

NTP NTP
Exactitud de cálculos 1 1 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
Precisión 1 1 0 <= X <= 1 Lo más cercano a 1 es lo mejor.

NTP NTP
Intercambiabilidad de datos (basado en
formatos de datos)
Consistencia de las interfaces 0 1 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
Métricas internas de seguridad

NTP NTP
0 <= X <= 1 Mientras más cercano a 1, más
Auditoría de accesos 1 1
auditable.
0 <= X <= 1 Mientras más cercano a 1, más
Control de acceso 0 1
controlable.
Prevención de corrupción de datos 0 1 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
Encriptación de datos 0 1 0 <= X <= 1 Lo más cercano a 1 es lo mejor.

NTP NTP
Conformidad de funcionalidad 0.784810127 0.9875 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
Conformidad con normas para
intersistemas
Elaboración: Propia
Como se puede ver en la tabla anterior, las métricas van siendo favorables, incluso
donde era cero, antes de la métrica, logra ser 1, es decir, mejora en un 100%,
demostrando que se da una gran incidencia en el uso de la NTP.

99
Tabla 15. Resultados de Fiabilidad Antes y Después de la NTP

NTP NTP
0 <= X Un valor alto de X implica
buena calidad de producto, mientras que si
Detección de fallas 0.215189873 0.0125
A=0 no necesariamente implica que el
producto revisado esté libre de fallas.
0 <= X Un valor alto de X implica que quedan
Eliminación de fallas 15 1
menos fallas
0 <= Y <= 1 Mientras más cercano a 1, mejor
0 1
(más fallas removidas).
Suficiencia de pruebas 0 1 0 <= X Cuando X es mayor es lo mejor.

NTP NTP
0 <= X Cuando X es mayor, mejor evitación
Prevención de fallos 0 1
de fallas
0 <= X Cuando X es mayor, mejor es la
Prevención de operación incorrecta 0 0.9875
prevención de operación incorrecta

NTP NTP
0 <= X <= 1 Cuando X es mayor, mejor
Capacidad de restauración 0 1
restaurabilidad
Efectividad de la capacidad de 0 <= X <= 1 Cuando X es mayor, mejor
0 0.9875
restauración efectividad

NTP NTP
Conformidad de fiabilidad 0.784810127 0.9875 0 <= X <= 1 Lo más cercano a 1 es lo mejor.
La fiabilidad, luego de la NTO, se mejora, pues hay una diferencia significativa entre lo
que se evaluó en su primer momento y el replanteamiento que se dio posteriormente.

100
Tabla 16. Resultados de Usabilidad Antes y Después de la NTP

NTP NTP
Claridad de la descripción 0 1 0 <=X<= 1 Lo más cercano a 1 es lo mejor
Capacidad de demostración 0 1 0 <=X<= 1 Lo más cercano a 1 es lo mejor
Métricas Internas de entendibilidad

NTP NTP
Funciones evidentes 1 1 0 <=X<= 1 Lo más cercano a 1 es lo mejor
Función de comprensión 1 1 0 <=X<= 1 Lo más cercano a 1 es lo mejor
Métricas Internas de facilidad de aprendizaje

NTP NTP
Integridad de la documentación del
1 1 0 <=X<= 1 Lo más cercano a 1 es lo mejor
usuario y/o facilidad de ayuda

NTP NTP
Revisión de la validez de la entrada 1 1 0 <=X<= 1 Lo más cercano a 1 es lo mejor
Capacidad de cancelar operación de
usuario

NTP NTP
Capacidad de deshacer operación de
usuario
Personalización 0 1 0 <=X<= 1 Lo más cercano a 1 es lo mejor
0 <= X <= 1 Lo más cercano a 1, indica una
Accesibilidad física 0 0 mejor capacidad para atender a las personas
con incapacidades físicas
Capacidad para monitorear el desarrollo
0.037974684 0.3125 0 <=X<= 1 Lo más cercano a 1 es lo mejor
de las operaciones
Consistencia operacional 0.215189873 0.1 0 <=X<= 1 Lo más cercano a 1 es lo mejor
Claridad de mensajes 0 0.125 0 <=X<= 1 Lo más cercano a 1 es lo mejor
Claridad de la interfaz 0 0 0 <=X<= 1 Lo más cercano a 1 es lo mejor
Capacidad para recuperarse de un error
operacional

NTP NTP
Interacción atractiva 16 17 Clasificación de la evaluación
Personalización de la apariencia de la
interfaz

NTP NTP
Conformidad de usabilidad 0.784810127 0.9875 0 <=X<= 1 Lo más cercano a 1 es lo mejor
101
Para el caso de usabilidad, se muestra una diferencia significativa entre lo que se tenía
y lo que se tiene en cada una de las métricas.
Tabla 17. Resultados de Eficiencia Antes y Después de la NTP

Métricas internas del comportamiento en el tiempo
Después de
Nombre de métrica Antes de NTP Interpretación del valor medido
NTP
Promedio 10 Promedio 10
Tiempo de respuesta Lo menor es lo mejor
minutos minutos
Tiempo de rendimiento Lo mayor es lo mejor.
minutos minutos
Tiempo de retorno Lo menor es lo mejor
minutos minutos
Métricas internas de utilización de los recursos

Después de
NTP
Utilización de entradas y salidas 0 0 Lo menor es lo mejor
Densidad de los mensajes de entrada y
1 1 Lo mayor es lo mejor
salida
Utilización de memoria 1000 1000 Lo menor es lo mejor
Densidad de mensajes en la utilización de
0 0 Lo mayor es lo mejor
memoria
Utilización de la transmisión 1000 1000 Lo menor es lo mejor
Métricas Internas de conformidad de eficiencia

Después de
NTP
Conformidad de eficiencia 0.784810127 0.9875 0<= X <=1 Lo más cerca de 1, es lo mejor.

Después de
NTP
0 <= X <= 1 Lo más cerca a 1, significa que
se tiene mayor cantidad de datos para
registrar el estado del sistema.
Registro de actividades 1 1
COMENTARIO: Es necesario convertir este
valor al intervalo <0,1> si se hace un
resumen de las características
0 <= X <= 1 Lo más cerca a 1, provee una
mejor implementación de las funciones de
diagnóstico
Preparación de funciones de diagnóstico 0 0
COMENTARIO: Es necesario convertir este
valor al intervalo <0,1> si se hace un
resumen de las características
La métrica de eficiencia, no muestra diferencia significativa, por el propio lenguaje en
que se desarrolló el software.

102
Tabla 18. Resultados de Mantenimiento Antes y Después de la NTP

Después
de NTP
0 <= X <= 1 Lo más cercano a 1, indica un mayor
registro. Cuando el control de cambio indica 0,
Registro de Cambios 0 1
significa un pobre control de cambios ó
pequeños cambios, alta estabilidad

Después
de NTP
Impacto de cambios 0 0.9875 0<= X <=1 Lo más cerca de 1, es lo mejor.
0 <= X <= 1 Lo más cerca de 0, menor es el
Impacto de la modificación 0 0.0125
impacto de la modificación
Métricas de testeabilidad
Después
de NTP
Completitud de las funciones de prueba
0 1 0<= X <=1 Lo más cerca de 1, es lo mejor.
incorporadas
Autonomía de la testeabilidad 0 0.9875 0<= X <=1 Lo más cerca de 1, es lo mejor.
Capacidad para observar el progreso de las
0 0.9875 0<= X <=1 Lo más cerca de 1, es lo mejor.
pruebas

Después
de NTP
Conformidad de facilidad de
0 0.9875 0<= X <=1 Lo más cerca de 1, es lo mejor.
mantenimiento
Para el caso de Mantenimiento, si se da una diferencia entre el tiempo de antes y
después, siendo, casi todas las métricas a lo óptimo.

103
Tabla 19. Resultados de Portabilidad Antes y Después de la NTP

Antes de Después
NTP de NTP
Adaptabilidad de estructuras de datos 0 1 0<= X <= 1 Cuanto más cercano a 1 es lo mejor
Adaptabilidad del hardware al entorno
(adaptabilidad a dispositivos de 0 1 0<= X <= 1 Cuanto más cercano a 1 es lo mejor
hardware e instalaciones de redes)
Adaptabilidad al entorno organizacional
(adaptabilidad a la organización y a la 0 0 0<= X <= 1 Cuanto más cercano a 1 es lo mejor
infraestructura de la misma)
Facilidad de portabilidad para el usuario 1 1 0<= X <= 1 Lo más cercano a 1 es lo mejor
Adaptabilidad al entorno del sistema
software (adaptabilidad al sistema
0 0 0<= X <= 1 Lo más cercano a 1 es lo mejor
operativo, al software de redes y al
software de la aplicación instalada)

Antes de Después
NTP de NTP
Facilidad de reinstalación 0 0 0<= X <= 1 Lo más cercano a 1 es lo mejor
Esfuerzo de instalación 0 0 0<= X <= 1 Lo más cercano a 1 es lo mejor
Flexibilidad de la instalación 0 0 0<= X <= 1 Lo más cercano a 1 es lo mejor
Métricas internas de co-existencia

Antes de Después
NTP de NTP
Capacidad de coexistencia 1 1 0<= X <= 1 Lo más cercano a 1 es lo mejor

Antes de Después
NTP de NTP
Uso continuo de los datos 0 0.9875 0<= X <= 1 Lo más cercano a 1 es lo mejor
Invariabilidad de la función 0 0.9875 0<= X <= 1 Lo más cercano a 1 es lo mejor

Antes de Después
NTP de NTP
Conformidad de portabilidad 1 1 0<= X <= 1 Lo más cercano a 1 es lo mejor
Para el caso de portabilidad, no se aprecia gran diferencia pues está desarrollado en web
site.
Las personas de la empresa dieron sus apreciaciones en relación a cada métrica, como
es que ellos perciben que la NTP, ha influido en la calidad que se puede lograr si se
aplicara a cada uno de los softwares antes de salir al mercado o entregarlo a un cliente,
los resultados se muestran a continuación.

104
Tabla 20. Percepción de Métricas NTP aplicada a S.O.S. Tesis
METRICAS DE FUNCIONALIDAD
Métricas Promedio
Adecuación funcional 4.2
Integridad de implementación funcional 4.4
Cobertura de implementación funcional 4.2
Estabilidad (volatilidad) de la especificación funcional 4.0
Métricas de precisión
Exactitud de cálculos 4.2
Precisión 4.2
Intercambiabilidad de datos (basado en formatos de
4.2
datos)
Consistencia de las interfaces 3.8
Métricas internas de Seguridad
Auditoría de accesos 4.0
Control de acceso 4.0
Prevención de corrupción de datos 3.8
Encriptación de datos 3.8
Conformidad de funcionalidad 3.8
Conformidad con normas para intersistemas 3.8
METRICAS DE FIABILIDAD
Métricas Promedio
Detección de fallas 4.4
Eliminación de fallas 4.2
Suficiencia de pruebas 4.4
Prevención de fallos 4.2
Prevención de operación incorrecta 4.0
Capacidad de restauración 3.6
Efectividad de la capacidad de restauración 3.4
Conformidad de fiabilidad 3.6
METRICAS DE USABILIDAD
Métricas Promedio
Claridad de la descripción 4.4
Capacidad de demostración 3.4
Funciones evidentes 3.8
Función de comprensión 3.6
Métricas internas de facilidad de aprendizaje
Integridad de la documentación del usuario y/o facilidad
3.8
de ayuda
Métricas internas de operabilidad
Revisión de la validez de la entrada 3.4
Capacidad de cancelar operación de usuario 3.4
Capacidad de deshacer operación de usuario 3.8
105
Personalización 3.4
Accesabilidad física 3.6
Capacidad para monitorear el desarrollo de las
3.8
operaciones
Consistencia operacional 3.6
Claridad de mensajes 3.6
Claridad de la interfaz 3.8
Capacidad para recuperarse de un error operacional 3.8
Interacción atractiva 4.0
Personalización de la apariencia de la interfaz 4.0
Conformidad de usabilidad 4.0
METRICAS DE EFICIENCIA
Métricas Promedio
Métricas internas de comportamiento en el tiempo
Tiempo de respuesta 1.8
Tiempo de rendimiento 1.8
Tiempo de retorno 3.2
Utilización de entradas y salidas 3.2
Densidad de los mensajes de entrada y salida 3.2
Utilización de la memoria 3.0
Densidad de mensajes en la utilización de memoria 2.6
Utilización de la transmisión 2.6
Métricas internas de conformidad de eficiencia
Conformidad de eficiencia 2.4
Registro de actividades 2.4
Preparación de funciones de diagnóstico 2.0
METRICAS DE MANTENIMIENTO
Métricas Promedio
Registro de cambios 4.0
Impacto de cambios 3.4
Impacto de la modificación 3.0
Métricas internas de testeabilidad
Completitud de las funciones de pruebas incorporadas 3.6
Autonomía de la testeabilidad 3.6
Capacidad para observar el progreso de las pruebas 3.6
Conformidad de facilidad de mantenimiento 3.6
106
METRICAS DE PORTABILIDAD
Métricas Promedio
Adaptabilidad de estructuras de datos 3.6
Adaptabilidad del hardware al entorno (adaptabilidad a
2.2
dispositivos de hardware e instalaciones de redes)
Adaptabilidad al entorno organizacional (adaptabilidad a
1.8
la organización y a la infraestructura de la misma)
Facilidad de portabilidad para el usuario 2.2
Adaptabilidad al entorno del sistema software
(adaptabilidad al sistema operativo, al software de redes y al 1.6
software de la aplicación instalada)
Facilidad de reinstalación 1.4
Esfuerzo de instalación 1.6
Flexibilidad de la instalación 1.6
Métricas internas de coexistencia
Capacidad de coexistencia 1.6
Uso continuo de los datos 1.8
Invariabilidad de la función 1.6
Conformidad de portabilidad 1.4
Elaboración Propia
En la tabla anterior, se aprecia como es que perciben las métricas el personal de la
empresa, en la siguiente figura se puede ver el sesgo que piensan que hay entre estas
métricas y lo excelente o máximo puntaje.

107
Figura 14. Percepción de NTP en Calidad de S.O.S. Tesis
Promedio Máxima Percepción

FUNCIONALIDAD
4.029
PORTABILIDAD FIABILIDAD
4.022
1.709
3.733
MANTENIMIENTO3.550 USABILIDAD
2.564
EFICIENCIA
Las métricas de eficiencia y portabilidad son las que tienen el mayor sesgo hacia el
máximo puntaje que es cinco, por lo que se puede indicar que en las otras 4 métricas se
da una diferencia significativa, tomando en cuenta que son el personal de la empresa
quien mantiene esta percepción.
Para el desarrollo de la parte experimental, cuyos resultados se han expuesto se muestra
la siguiente figura:
108
Figura 15. Procesos al S.O.S. Tesis con NTP en Calidad
Revisión del Revisión del

software con software con
métricas de métricas NTP
NTP (ANTES) (DESPUÉS)
Resultado de software Implementación
con métricas para de la NTP en los
modificaciones al
código fuente (42 procesos de
métricas mejoradas), producción de
con una nueva variante software de la
(actividad) para el
usuario
empresa
Percepción de Percepción de
los usuarios los usuarios
del software del software
(ANTES) (DESPUËS)
En la figura anterior, todas las métricas que deberían de cambiarse, para mejorar, se
hicieron, con la autorización de la gerencia y apoyo del personal de TIC.
En la siguiente tabla, se presenta los resultados de la percepción de los usuarios, antes
y con la nueva actividad que se agregó, lo que permite conocer cómo es que se da la
percepción de ellos, y una pregunta muy especial, que es la métrica de “Interacción
atractiva”, que obtuvo de un 16 a 17, no siendo muy significativa la diferencia de este
resultado. Se ponderó lo siguiente:
Tabla 21. Percepción de usuarios antes de NTP

Ítem de S.O.S. tesis Promedio
DATOS INICIALES 4.79
§ DESCRIPCIÓN 4.79
§ PROBLEMA PRINCIPAL 4.845
§ PROBLEMA SECUNDARIO 3.615
§ OBJETIVO GENERAL 4.675
§ OBJETIVOS ESPECÍFICOS 4.51
§ HIPÓTESIS GENERAL 4.635
§ HIPÓTESIS ESPECÍFICAS 3.74
§ HIPÓTESIS DE LA INVESTIGACIÓN 3.45
§ HIPÓTESIS ESTADÍSTICA 3.355
§ UNIVARIABLE 3.05
§ DEPENDIENTE 4.28
§ INDEPENDIENTE 4.26
109

§ INDICADORES 4.54
§ SUBCATEGORIAS 3.115
§ HISTORIA 3.835
§ CARACTERÍSTICAS 4.3
§ ESPACIAL GEOGRÁFICA 4.415
§ TIEMPO 4.365
§ REGIONALES 3.69
§ NACIONALES 3.885
§ INTERNACIONALES 3.175
§ REGIONALES 4.3
§ NACIONALES 4.55
§ INTERNACIONALES 3.655
o LINEAS DE INVESTIGACIÓN 4.615
§ CUALITATIVO 4.415
§ CUANTITATIVO 4.405
§ MIXTO 3.79
§ EXPLORATORIO 4.675
§ DESCRIPTIVO 4.73
§ RELACIONAL 4.375
§ CORRELACIONAL 4.3
§ EXPLICATIVO 4.69
§ APLICATIVO 4.71
TECNOLOGÍA DEL SINACYT: BÁSICA 3.455
TECNOLOGÍA DEL SINACYT: APLICADA 3.405
§ POR MANIPULACIÓN: OBSERVACIONAL 4.075
§ POR MANIPULACIÓN : EXPERIMENTAL 4.49
§ POR MANIPULACIÓN: CUASI EXPERIMENTAL 4.065
§ POR TIEMPO DE INTERVENCIÓN: RETROSPECTIVO 4.29
§ POR TIEMPO DE INTERVENCIÓN: PROSPECTIVO 4.345
§ POR CANTIDAD DE MEDICIONES: TRANSVERSAL 4.315
§ POR CANTIDAD DE MEDICIONES: LONGITUDINAL 4.325
§ POR EL TRATO DE VARIABLE: DESCRIPTIVO 4.26
§ POR EL TRATO DE VARIABLE: ANALÍTICO 4.24
§ POR SU FUENTE DE INFORMACIÓN: DOCUMENTAL 4.01
§ POR SU FUENTE DE INFORMACIÓN: EXPERIMENTAL 4.04
§ POR SU FUENTE DE INFORMACIÓN: DE CAMPO 4.105
§ TEÓRICA 4.55
§ EMPÍRICA 4.03
§ ACADÉMICA 4.51
§ TÉCNICA 3.665
§ SOCIAL 4.345
§ ECONÓMICA 4.095
§ REGIONAL 4.325
§ NACIONAL 4.2
§ INTERNACIONAL 3.47
o MUESTRA 5
§ PROBABILÍSTICA 4.53
§ NO PROBABILÍSTICA 4.26
§ A CONVENIENCIA 3.865
§ ENCUESTAS 4.27
§ ENTREVISTAS A PROFUNDIDAD 3.815
§ ENTREVISTAS SEMIESTRUCTURADA 3.425
§ ENTREVISTA ESTRUCTURADA 3.835
§ FICHA DOCUMENTAL 3.825
110

§ FICHA DE OBSERVACIÓN 4.21
§ GRUPO FOCAL 3.925
o APLICACIÓN DE INSTRUMENTOS 4.45
o ESTRATEGIA DE RECOLECCIÓN DE 4.45
o MATERIALES 4.605
o HUMANOS 4.46
CRONOGRAMA DE EJECUCIÓN 4.9
· APLICACIÓN DEL INSTRUMENTO (LUGAR, PERSONA, FECHA Y HORA 4.71
· RECORDATORIO (A CORREO, CELULAR O AMBOS)
ESQUEMA CAPITULAR 4.885
DIAGRAMA GANTT 4.825
MATRIZ DE CONSISTENCIA 4.925
Estos resultados de percepción fueron antes de agregar una función más al S.O.S.Tesis,
pues no fue relevante, estadísticamente hablando, pero si se le pidió diera una
respuesta, posterior al hecho de las dimensiones analizadas. Los resultados se muestran
a continuación:
111
Figura 16. Percepción de S.O.S. Tesis con NTP
Promedio Percepción máxima
FUNCIONALIDAD
4.25
PORTABILIDAD FIABILIDAD
4.82
3.89
3.95
4.92
MANTENIMIENTO USABILIDAD
4.71
EFICIENCIA
Los usuarios son un punto de referencia, pues al ser acceso gratuito lo emplean en lo
que les interesa y se les permite desarrollar sus planes de tesis sin restricción alguna,
por un lapso de un año, quizá por ello es que los resultados de ellos son diferentes a los
resultados de los integrantes de la empresa.
4.3 Comprobación de Hipótesis
Para el caso de la comprobación, son datos cuantitativos, por lo que se ve el nivel de
significancia o incidencia que hay de una variable independiente en la dependiente, para
ello se empleó dos pruebas, la primera que permite ver si es una distribución normal y
112
la segunda para determinar en base a esos resultados que estadístico se emplearía para
determinar si la diferencia de los resultados tuvo incidencia o no. En el caso de la
primera, se aplicó, Kolmogorov-Smimov, pues la cantidad de ítem que los
programadores observaron fueron superiores a los 50, a pesar que ellos eran 10. Esto
para la hipótesis general, mientras que por los resultados se aplicó el estadístico
Wilconxon.
Kolmogorov-Smirnov
Estadístico gl Sig.
Diferencia ,398 71 ,000
El planteamiento de la prueba en la hipótesis sería:
H0: la distribución es normal
Ha: la distribución no es normal
El P-value es de 0.000, siendo este menor que el valor 0.05, entonces, se rechaza la H 0,
por lo que se debe usar, para medir la significancia de antes y después de la NTP, una
prueba no paramétrica, pues no se tiene el supuesto de normalidad, siendo esta prueba
la de Wilconxon.
Para ello se considera las hipótesis estadísticas de:
H0: La NTP 9126-3 2005 no mejora la calidad del software S.O.S. Tesis
Ha: La NTP 9126-3 2005 mejora la calidad del software S.O.S. Tesis
Después - Antes
Z -4,793
Sig. asintótica(bilateral) ,000

113
El P-value es de 0.000, siendo este menor que el valor 0.05, entonces, se rechaza la H0,
por lo que se acepta que la NTP 9126-3 2005 mejora la calidad del software S.O.S. Tesis.
Para el caso de las hipótesis específicas se consideran las siguientes:
He1: La implementación de la Norma Técnica Peruana 9126-3 2005, incide
significativamente en la funcionalidad del software S.O.S. Tesis de la empresa OCean
SRL, 2021.
Para determinar la normalidad se usó Shapiro-Wilk, considerando las siguientes
hipótesis:
H0: la distribución de las métricas de funcionabilidad es normal.
Ha: la distribución de las métricas de funcionabilidad no es normal.
Shapiro-Wilk
El P-value es de 0.01, al ser menor que el valor 0.05, entonces, se rechaza la H0, por lo
que al no haber el supuesto de normalidad, se usará una prueba no paramétrica
Wilconxon, para determinar que hipótesis estadística se acepta:
H0: La implementación de la Norma Técnica Peruana 9126-3 2005 no incide
significativamente en la funcionalidad del software S.O.S. Tesis de la empresa.
Ha: La implementación de la Norma Técnica Peruana 9126-3 2005 incide
significativamente en la funcionalidad del software S.O.S. Tesis de la empresa.

114
Después - Antes
Z -2,773b
por lo que se acepta que la implementación de la Norma Técnica Peruana 9126-3 2005
incide significativamente en la funcionalidad del software S.O.S. Tesis de la empresa.
significativamente en la confiabilidad del software S.O.S. Tesis de la empresa OCean SRL,
2021.
hipótesis:
H0: la distribución de las métricas de confiabilidad es normal.
Ha: la distribución de las métricas de confiabilidad no es normal.
Shapiro-Wilk
significativamente en la confiabilidad del software S.O.S. Tesis de la empresa.

115
significativamente en la confiabilidad del software S.O.S. Tesis de la empresa.
Después - Antes
Z -1,437
El P-value es de 0.151, siendo este mayor que el valor 0.05, entonces, se rechaza la Ha,
no incide significativamente en la confiabilidad del software S.O.S. Tesis de la empresa.
significativamente en la usabilidad del software S.O.S. Tesis de la empresa OCean SRL,
2021.
hipótesis:
H0: la distribución de las métricas de usabilidad es normal.
Ha: la distribución de las métricas de usabilidad no es normal.
Shapiro-Wilk

116
significativamente en la usabilidad del software S.O.S. Tesis de la empresa.
significativamente en la usabilidad del software S.O.S. Tesis de la empresa.
Después - Antes
Z -2,392
incide significativamente en la usabilidad del software S.O.S. Tesis de la empresa.
significativamente en la eficiencia del software S.O.S. Tesis de la empresa OCean SRL,
2021.
hipótesis:
H0: la distribución de las métricas de eficiencia es normal.
Ha: la distribución de las métricas de eficiencia no es normal.
Shapiro-Wilk
117
significativamente en la eficiencia del software S.O.S. Tesis de la empresa.
significativamente en la eficiencia del software S.O.S. Tesis de la empresa.
Después - Antes
Z -1,000
no incide significativamente en la eficiencia del software S.O.S. Tesis de la empresa.
significativamente en la capacidad de mantenimiento del software S.O.S. Tesis de la
hipótesis:
H0: la distribución de las métricas de capacidad de mantenimiento es normal.
Ha: la distribución de las métricas de capacidad de mantenimiento no es normal.
Shapiro-Wilk
118
empresa.
empresa.
Después - Antes
Z -2,414
incide significativamente en la capacidad de mantenimiento del software S.O.S. Tesis
de la empresa.
119
significativamente en portabilidad del software S.O.S. Tesis de la empresa OCean SRL,
2021.
hipótesis:
H0: la distribución de las métricas de portabilidad es normal.
Ha: la distribución de las métricas de portabilidad no es normal.
Shapiro-Wilk
significativamente en la portabilidad del software S.O.S. Tesis de la empresa.
significativamente en la portabilidad del software S.O.S. Tesis de la empresa.
Después - Antes
Z -1,857

120
no incide significativamente en la portabilidad del software S.O.S. Tesis de la empresa.

121
CAPITULO V: DISCUSION, CONCLUSIONES Y RECOMENDACIONES
5.1. Discusión
Cuando se planteó la hipótesis general que señala “La implementación de la Norma
Técnica Peruana 9126-3 2005, incide significativamente en la calidad del software S.O.S.
Tesis de la empresa OCean SRL, 2021, se puede ver por los resultados que, si existe una
diferencia, pues de no existir métrica alguna a tener métricas para medir la calidad,
permite mejoras, contemplando los errores que se presentan y la solución adicional que
se ha dado.
Por otro lado, en base a la hipótesis específica planteada: “La implementación de la
Norma Técnica Peruana 9126-3 2005, incide significativamente en la funcionalidad del
software S.O.S. Tesis de la empresa OCean SRL, 2021” por la siguiente tabla se puede
ver que si se debe de aceptar:
Tabla 22. Diferencia en Métricas de Funcionabilidad
METRICAS DE FUNCIONALIDAD
Métricas Antes Después
Adecuación funcional 0.78481013 0.9750
Integridad de implementación funcional 0.98734177 1.0000
Cobertura de implementación funcional 0.78481013 0.9875
Estabilidad (volatilidad) de la especificación funcional 1.0 0.9625
Métricas de precisión
Exactitud de cálculos 1.0 1.0
Precisión 1.0 1.0
Intercambiabilidad de datos
0.0
(basado en formatos de datos) 0.9875
Consistencia de las interfaces 0.0 1.0
Métricas internas de Seguridad
Auditoría de accesos 1.0 1.0
Control de acceso 0.0 1.0
Prevención de corrupción de datos 0.0 1.0
Encriptación de datos 0.0 1.0
Conformidad de funcionalidad 0.78481013 0.9875
Conformidad con normas para intersistemas 0.0 0.9875
122
La siguiente hipótesis planteada fue: “La implementación de la Norma Técnica Peruana
9126-3 2005, incide significativamente en la confiabilidad del software S.O.S. Tesis de la
empresa OCean SRL, 2021”, la misma que se acepta, pues la confiabilidad o fiabilidad
mantiene resultados que antes de la NTP y su adaptación, se presentan:
Tabla 23. Diferencia en Métricas de Fiabilidad
METRICAS DE FIABILIDAD
Detección de fallas 0.21518987 0.0125
Eliminación de fallas 0.0 1.0
Suficiencia de pruebas 0.0 1.0
Prevención de fallos 0.0 1.0
Prevención de operación incorrecta 0.0 0.9875
Capacidad de restauración 0.0 1.0
Efectividad de la capacidad de restauración 0.0 0.9875
Conformidad de fiabilidad 0.78481013 0.9875
En la hipótesis específica: “La implementación de la Norma Técnica Peruana 9126-3
2005, incide significativamente en la usabilidad del software S.O.S. Tesis de la empresa
OCean SRL, 2021” se puede ver en la tabla siguiente que en algunos 8 de 18 métricas, si
hubo diferencia significativa, pues, el software si se plantea en las métricas de usabilidad
que son planteadas desde el primer momento del proyecto.

123
Tabla 24. Diferencia en Métricas de Usabilidad
METRICAS DE USABILIDAD
Claridad de la descripción 0.0 1.0
Capacidad de demostración 0.0 1.0
Funciones evidentes 1.0 1.0
Función de comprensión 1.0 1.0
Métricas internas de facilidad de aprendizaje
Integridad de la documentación del usuario y/o facilidad
1.0 1.0
de ayuda
Métricas internas de operabilidad
Revisión de la validez de la entrada 1.0 1.0
Capacidad de cancelar operación de usuario 1.0 1.0
Capacidad de deshacer operación de usuario 1.0 1.0
Personalización 0.0 1.0
Accesabilidad física 0.0 0.0
Capacidad para monitorear el desarrollo de las
0.0379747
Operaciones 0.3125
Consistencia operacional 0.2151899 0.1
Claridad de mensajes 0.0 0.125
Claridad de la interfaz 0.0 0.0
Capacidad para recuperarse de un error operacional 0.0 0.0
Interacción atractiva 12.0 17
Personalización de la apariencia de la interfaz 0.0 0.0
Conformidad de usabilidad 0.8 0.9875
En la hipótesis específica: “La implementación de la Norma Técnica Peruana 9126-3
2005, incide significativamente en la eficiencia del software S.O.S. Tesis de la empresa
OCean SRL, 2021”, no presenta diferencia significativa, pues se mantienen los
parámetros registrados en todas las métricas establecidas.

124
Tabla 25. Diferencia en Métricas de Eficiencia
METRICAS DE EFICIENCIA
Métricas internas de comportamiento en el tiempo
Tiempo de respuesta 10 min. 10 min.
Tiempo de rendimiento 10 min. 10 min.
Tiempo de retorno 10 min. 10 min.
Utilización de entradas y salidas 0.0 0.0
Densidad de los mensajes de entrada y salida 1.0 1.0
Utilización de la memoria 1000 bytes 1000 bytes
Densidad de mensajes en la utilización de memoria 0.0 0.0
Utilización de la transmisión 1000 bytes 1000 bytes
Métricas internas de conformidad de eficiencia
Conformidad de eficiencia 0.7848101 0.9875
Registro de actividades 1.0 1.0
Preparación de funciones de diagnóstico 0.0 0.0
El mantenimiento, se planteó en la hipótesis específica: “La implementación de la
Norma Técnica Peruana 9126-3 2005, incide significativamente en la capacidad de
mantenimiento del software S.O.S. Tesis de la empresa OCean SRL, 2021”, como se ve
en la tabla siguiente las 7 métricas si mantienen una diferencia significativa, pues no se
lleva a registro ninguna de estas, antes de implementar la NTP en el desarrollo del
software S.O.S. Tesis.

125
Tabla 26. Diferencia en Métricas de Mantenimiento
METRICAS DE MANTENIMIENTO
Registro de cambios 0.0 1.0
Impacto de cambios 0.0 0.9875
Impacto de la modificación 0.0 0.0125
Métricas internas de testeabilidad
Completitud de las funciones de pruebas incorporadas 0.0 1.0
Autonomía de la testeabilidad 0.0 0.9875
Capacidad para observar el progreso de las pruebas 0.0 0.9875
Conformidad de facilidad de mantenimiento 0.0 0.9875
La última hipótesis específica fue: “La implementación de la Norma Técnica Peruana
9126-3 2005, incide significativamente en portabilidad del software S.O.S. Tesis de la
empresa OCean SRL, 2021”, en esta se puede ver que no hay diferencias significativas,
quizá por el hecho que el software está en nube.

126
Tabla 27. Diferencia en Métricas de Portabilidad
METRICAS DE PORTABILIDAD
Adaptabilidad de estructuras de datos 0.0 1.0
Adaptabilidad del hardware al entorno
(adaptabilidad a dispositivos de hardware e instalaciones 0.0
de redes) 1.0
Adaptabilidad al entorno organizacional
(adaptabilidad a la organización y a la infraestructura de 0.0
la misma) 0.0
Facilidad de portabilidad para el usuario 1.0 1.0
Adaptabilidad al entorno del sistema software
(adaptabilidad al sistema operativo, al software de redes 0.0 0.0
y al software de la aplicación instalada)
Facilidad de reinstalación 0.0 0.0
Esfuerzo de instalación 0.0 0.0
Flexibilidad de la instalación 0.0 0.0
Métricas internas de coexistencia
Capacidad de coexistencia 1.0 1.0
Uso continuo de los datos 0.0 0.9875
Invariabilidad de la función 0.0 0.9875
Conformidad de portabilidad 1.0 1.0
5.2. Conclusiones
El objetivo general que se planteó fue analizar de qué manera la implementación de la
Norma Técnica Peruana 9126-3 2005 incide en la calidad del software S.O.S. Tesis de la
empresa OCean SRL, 2021, el mismo que se comprueba en las tablas de resultado en se
encuentra una diferencia de las 71 métricas, 42 mejoran, lo que es un 60% del producto
final.
En el objetivo específico de analizar de qué manera la implementación de la Norma
Técnica Peruana 9126-3 2005, incide en la funcionalidad del software S.O.S. Tesis de la
empresa OCean SRL, 2021, se puede visualizar que, si hay diferencia significativa, pues
de 14 métricas, se aprecia un cambio en sus indicadores en 13 de las mismas.

127
Cuando se planteó, el objetivo específico analizar de qué manera la implementación de
la Norma Técnica Peruana 9126-3 2005, incide en la confiabilidad del software S.O.S.
Tesis de la empresa OCean SRL, 2021, se presenta una aceptación del mismo, pues 9 de
9 métricas si cambiaron,
En base al objetivo específico de analizar de qué manera la implementación de la Norma
Técnica Peruana 9126-3 2005, incide la usabilidad del software S.O.S. Tesis de la
empresa OCean SRL, 2021, se puede ver que no se da una incidencia que lleve a una
diferencia significativa, pues 8 de 18 métricas cambiaron.
En el objetivo específico analizar de qué manera la implementación de la Norma Técnica
Peruana 9126-3 2005, incide en la capacidad de mantenimiento del software S.O.S. de
la empresa OCean SRL, 2021, se aprecia que, si hubo diferencia, pues se halló que 7 de
las 7 métricas mejoraron con la intervención de la NTP.
En base al objetivo específico analizar de qué manera la implementación de la Norma
Técnica Peruana 9126-3 2005, incide en la eficiencia del software S.O.S. Tesis de la
empresa OCean SRL, 2021, es que se presenta que no hay una incidencia significativa,
pues solo se ve 1 de 11 métricas que se modifican
El último objetivo específico, analizar de qué manera la implementación de la Norma
Técnica Peruana 9126-3 2005, incide en la portabilidad del software S.O.S. Tesis de la
empresa OCean SRL, 2021, señala que 4 de 12 métricas si cambian.

128
5.3. Recomendaciones
En base a la conclusión que señala que en las tablas de resultado en se encuentra una
diferencia de las 71 métricas, 42 mejoran, lo que es un 60% del producto final, se
recomienda la continuidad de intervención de lo señalado por las NTP en las nuevas
versiones del software S.O.S. Tesis, pues los resultados motivaron en la gerencia que se
acondicione nuevas funciones en el mismo, pero con la NTP ya establecida. Esto significa
que, el desarrollo de los softwares, considerando evaluaciones previas con la NTP
analizada, permite detectar y modificar el producto, para que su calidad sea mejor en el
mercado y esto permita una ventaja del mismo. Esto es factible, pues la NTP, fue
adquirida por la empresa y su aplicación, es de una fácil comprensión para los
desarrolladores de software. Si las metodologías de programación, análisis de bases de
datos e interfaz, se mantienen, estas pueden mejorarse, pues con la intervención de la
NTP, se detectan aquellas características que se puedan modificar para lograr una mejor
satisfacción del cliente. En el caso del software S.O.S. Tesis, no se tiene una competencia
directa, sin embargo, su la factibilidad de implementación de la NTP, se vio en el tiempo
que se modificaron.
Para la segunda conclusión, relacionada a la funcionalidad del software S.O.S. Tesis de
la empresa OCean SRL, donde se ve que si hay diferencia significativa, pues de 14
métricas, se aprecia un cambio en sus indicadores en 13, se recomienda que antes de
cualquier software a desarrollar, la empresa puede mejorar la calidad de
funcionabilidad, analizando los resultados de las métricas dadas en la función
matemática de la NTP implementada.
Al igual que la recomendación anterior, en el caso de las métricas de confiabilidad del
software S.O.S. Tesis de la empresa OCean SRL, que obtuvo como resultados que de 9
129
de 9 métricas si cambiaron, por lo que se concluye que, si hay diferencia significativa, es
que se recomienda el planteamiento de la NTP en la confiabilidad, pues el usuario final,
puede tener una mayor seguridad en el momento de su uso.
La implementación con baja incidencia se da en las métricas de usabilidad, pues 8 de 18
cambiaron, por lo que se recomienda que se puede mejorar el desarrollo del software
con la implementación de la NTP 9126-3 2005.
En la conclusión de capacidad de mantenimiento del software S.O.S. de la empresa
OCean SRL, al darse la conclusión que, si hubo diferencia, se tiene que 7 de las 7 métricas
mejoraron con la intervención de la NTP, por lo que se tiene que continuar con la misma,
para las demás versiones.
La métrica con menor variación fue la de eficiencia, por lo que se concluyó que no hay
una incidencia significativa, entonces, se recomienda que se mantengan los procesos en
esta métrica pues es la de menor modificación.
La métrica de portabilidad concluye que no hay diferencia significativa, con la
implementación de la Norma Técnica Peruana 9126-3 2005, por lo que se recomienda
también continuar con lo que se ha venido haciendo en la empresa.
Por las conclusiones presentadas, se recomienda que la empresa debe de continuar con
esta NTP, dentro de sus procesos, reflejados en sus documentos de gestión.

130
REFERENCIAS BIBLIOGRÁFICAS
BIBLIOGRAFÍA
• Abud Figueroa, M. A. (2004). Calidad en la Industria del Software. La norma ISO-
9126. Revista UPIICSA, 1-1. Recuperado el 13 de mayo de 2021, de
https://www.nacionmulticultural.unam.mx/empresasindigenas/docs/2094.pdf
• Arrioja Rodríguez, M., Diaz Ramos, C., Pérez González, L., Abud Figueroa, M.,
Jiménez Jerez, S., & Rodríguez Ávila, E. (2013). Calidad en la Industria del
Software. La Norma ISO-9126. Revista UPIICCSA en Línea No. 34.
• Aranguena Yllanes, M. (2015). Efecto de la Implementación del sistema web
SWEGPI en la gestión de los proyectos de investigación de la dirección de
investigación de la universidad nacional José María Arguedas.
• Arangüena Yllanes, M. (2018). Sistema Web SWGPI en la gestión de proyectos de
investigación evaluado con la ISO/IEC 9126. Universidad Nacional José María
Arguedas.
• Beltrán Sarmiento, Mario (2019). Aplicación de la metodología Scrum usando
herramientas OpenSource facilitando el aseguramiento de calidad de acuerdo
con la Norma ISO/IEC 9126.
• Bautista Sánchez, G., Castilla Medina, B., & Phili Lange, E. (2016). Bautista
Sánchez, G., Castilla Medina, B., & Philipp Lange, E. (2016). Reingeniería de la
131
estructura organizacional y de procesos de la Unidad Ejecutora 008: Proyectos
Especiales perteneciente al Pliego 003 del Ministerio de Cultura. ministerio de
cultura.
• Bejarano Arenas, L. F. (2017). Propuesta de arquitectura de software para el
desarrollo de aplicativos móviles en el sector financiero usando el enfoque de
diseño arquitectural del SEI/CMU. Universidad Carnegie Mellon (CMU).
• Consejo Nacional de Ciencia, Tecnología e Innovación Tecnológica. (s.f.). TRL
(Technology Readiness Levels) o Nivel de Madurez Tecnológica. Obtenido de
https://vinculate.concytec.gob.pe/niveles-de-madurez/
• Chávez, J. (2014). Epistemología y Metodología de la Investigación. En Capítulo 3
Metodología de la Investigación (págs. 40 - 41). México: Grupo Editorial Patria.
• Fabián Germán, C. M. (2015). Construcción de un framework que facilite la
implementación de VSE, según la norma ISO/IEC 29110.
• Fernández Rufasto, F., & Ramírez Malca, R. (2018). Fernández Rufasto, F. E., &
Ramírez M. Evaluación de Modelo de Calidad en uso para sitios Web
Institucionales utilizando la Norma ISO/IEC 9126. Universidad Señor de Sipán.

132
• Figueroa Piscoya, E., & Carrión Barco, G. (2020). La aplicación de modelo basado
en normas ISO/IEC 25000 para asegurar la calidad de plataformas E-Learning.
• García, M., Quispe, C., & Ráez, L. (2003). Mejora continua de la calidad en los
procesos. Industrial data, 6(1), 89-94.
• Instituto Nacional de la Calidad. (mayo de 2021).
https://servicios.inacal.gob.pe/. Obtenido de
https://servicios.inacal.gob.pe/datos_abiertos/NormaTecnica BIBLIOGRAPHY
• Instituto Nacional de Calidad. (2005). NTP ISO/IEC-TR 9126-3:2005 INGENIERIA
DE SOFTWARE. Calidad del producto. Parte 3: Métricas internas. Obtenido de
https://tiendavirtual.inacal.gob.pe/0/modulos/TIE/TIE_DetallarProducto.aspx?
PRO=81
• Manrique Tejada, I. M., & Manrique Tejada, R. (2020). Tendencias de la
educación y la formación en la sociedad del conocimiento. Santa Marta: Centro
Internacional de Marketing Territorial para la Educación y el Desarrollo CIMTED
2020.
• Manrique Tejada, R. (2018). Propuesta de una plataforma de tecnologías de
información y comunicaciones como metodología para estandarizar los
esquemas de planes de tesis y tesis de pregrado y posgrado en las Universidades
del Perú - 2018. Tacna: Universidad Privada de Tacna.

133
• Manrique Tejada, R., & Revollar Choque Gonzales, C. (2012). Economía Familiar.
Arequipa: OCean SRL.
• Ministerio de Educación del Perú. (2014). Ley Nº 30220, Ley Universitaria. Lima,
Perú: Congreso de la República. Recuperado el 15 de diciembre de 2020, de
http://www.minedu.gob.pe/reforma-universitaria/pdf/ley_universitaria.pdf
• Moreno Sucre, F. (2020). Modelo de gestión de calidad basada en los estándares
NTP 12207, ISO 9001 E ISO 9126, para los procesos de desarrollo de software:
caso RENIEC. universidad RENIEC.
• Moreno Sucre, F. (2020). Modelo de gestión de calidad basada en los estándares
NTP 12207, ISO 9001 E ISO 9126, para los procesos de desarrollo de software:
caso RENIEC. Universidad RENIEC.
• Ortiz Matute, M., & Huamán Villanueva, B. (2017). Evaluación de metodologías
de desarrollo web bajo el paradigma de desarrollo dirigido por modelos (MDD)
con la integración de directrices para la captura de requisitos de usabilidad
medido por la ISO.
• Ramos Secaira, F. (2019). Evaluación de la calidad del software en las empresas
de servicios tecnológicos situadas en la ciudad de Santo Domingo. Guayaquil:
Universidad Tecnológica Empresarial de Guayaquil.

134
• Sistema Integrado de Información de Comercio Exterior (SIICEX). (2009). Crea
Software Perú. Obtenido de
https://www.siicex.gob.pe/siicex/resources/sectoresproductivos/ProgramaCRE
ASOFTWAREPERU.pdf
135
ABREVIATURAS
• CMM: Capability Maturity Model
• CONCYTEC: Consejo Nacional de Ciencia, Tecnología e Innovación Tecnológica
• FURPS: Funcionality, Usability, Reliability, Perfomance, Supportability
• INACAL: Instituto Nacional de Calidad
• INDECOPI: Instituto Nacional de Defensa de la Competencia y de la Protección de la
Propiedad Intelectual
• ISO: International Standard Organization
• MTC: Medidas de tendencia central
• MOF: Manual de Organización y Funciones
• NTP: Norma Técnica Peruana
• NTP: Norma Técnica Peruana
• PHVA: Planear, hacer, verificar y actuar
• RSE: Responsabilidad Social Empresarial
• ROF: Reglamento de Organización y Funciones
• SIICEX: Sistema Integrado de Información de Comercio Exterior
• TIC: Tecnologías de Información y Comunicaciones
• TRL: Technology Readiness Levels
• WebQEM: Web Quality Evaluation Methodology

136
ANEXOS
137
ANEXO 1: MATRIZ DE CONSISTENCIA
Problema general Objetivo general Hipótesis general Variables METODO
¿De qué manera la implementación de la Analizar de qué manera la implementación de la La implementación de la Norma Técnica Peruana
Norma Técnica Peruana 9126-3 2005, incide Norma Técnica Peruana 9126-3 2005, incide en la 9126-3 2005, incide significativamente en la Norma Técnica Diseño:
en la calidad del software S.O.S. Tesis de la calidad del software S.O.S. Tesis de la empresa OCean calidad del software S.O.S. Tesis de la empresa Peruana Experimental
empresa OCean SRL, 2021? SRL, 2021. OCean SRL, 2021. Tipo:
Problema especifico Objetivo especifico Hipótesis específicas Variables Experimental puro
¿De qué manera la implementación de la Analizar de qué manera la implementación de la La implementación de la Norma Técnica Peruana Enfoque:
Norma Técnica Peruana 9126-3 2005, incide Norma Técnica Peruana 9126-3 2005, incide en la 9126-3 2005, incide significativamente en la Cuantitativo
en la funcionalidad del software S.O.S. Tesis funcionalidad del software S.O.S. Tesis de la empresa funcionalidad del software S.O.S. de la empresa Población Censal:
de la empresa OCean SRL, 2021? OCean SRL, 2021. OCean SRL, 2021. Información del periodo 2020 al
Calidad de 2021 de la empresa OCean SRL.
¿De qué manera la implementación de la Analizar de qué manera la implementación de la La implementación de la Norma Técnica Peruana Software Diseño:
Norma Técnica Peruana 9126-3 2005, incide Norma Técnica Peruana 9126-3 2005, incide en la 9126-3 2005, incide significativamente en la Experimental,.
en la confiabilidad del software S.O.S. Tesis de confiabilidad del software S.O.S. Tesis de la empresa confiabilidad del software S.O.S. de la empresa Funcionalidad Técnica de recolección de datos:
la empresa OCean SRL, 2021? OCean SRL, 2021. OCean SRL, 2021. Confiabilidad Encuesta
¿De qué manera la implementación de la Analizar de qué manera la implementación de la La implementación de la Norma Técnica Peruana Usabilidad Instrumento:
Norma Técnica Peruana 9126-3 2005, incide Norma Técnica Peruana 9126-3 2005, incide en la 9126-3 2005, incide significativamente en la Eficiencia Ficha documental, Cuestionario
en la usabilidad del software S.O.S. Tesis de la usabilidad del software S.O.S. de la empresa OCean usabilidad del software S.O.S. de la empresa Capacidad de
empresa OCean SRL, 2021? SRL, 2021. OCean SRL, 2021. Mantenimiento
Portabilidad
Norma Técnica Peruana 9126-3 2005, incide Norma Técnica Peruana 9126-3 2005, incide en la 9126-3 2005, incide significativamente en la
en la eficiencia del software S.O.S. Tesis de la eficiencia del software S.O.S. Tesis de la empresa eficiencia del software S.O.S. de la empresa
empresa OCean SRL, 2021? OCean SRL, 2021. OCean SRL, 2021.
en la capacidad de mantenimiento del capacidad de mantenimiento del software S.O.S. Tesis capacidad de mantenimiento del software S.O.S.
software S.O.S. Tesis de la empresa OCean de la empresa OCean SRL, 2021. de la empresa OCean SRL, 2021.
SRL, 2021?
en la portabilidad del software S.O.S Tesis de portabilidad del software S.O.S Tesis de la empresa portabilidad del software S.O.S. de la empresa
la empresa OCean SRL, 2021? OCean SRL, 2021. OCean SRL, 2021.
138
ANEXO 2: MATRIZ DE OPERACIONALIZACIÓN
VARIABLES DEFINICION CONCEPTUAL DEFINICION OPERACIONAL DIMENSION INDICADOR ITEM ESCALA INSTRUMENTO
Variable Reglas y principios para considerar en un Conocer e implementar la Diagnóstico MOF – ROF – MAPRO Anexo 6: Nominal Ficha Documental –
Independiente: producto denominado software. Es un NTP en los procesos de PHVA Entrevista
documento que establecen las producción de la empresa modificado
Norma Técnica especificaciones de calidad de los productos, OCEAN SRL, tomando como Planificación Requerimiento Humano, Anexo 3: Ficha Nominal Ficha Documental
Peruana 9126-3 procesos y servicios. Define las métricas caso resultante su producto Material y Económico Documental
internas para la medición cuantitativa de la S.O.S. Tesis
calidad interna del software en términos de
características y sus características definidas
en la NTP-ISO/IEC 9126-1 y se pretende que Ejecución Desarrollo, Pruebas de Nominal
sea utilizado junto con la NTP-ISO/IEC 9126- Stress, Servidor y
1. Esta NTP contiene: I. Una explicación de la Terminales
forma de aplicación de las métricas de calidad
del software; II. Un conjunto básico de
métricas para cada su característica; III. Un
ejemplo de la forma en que se aplican las
Evaluación Reportes e Informes Nominal
métricas durante el ciclo de vida del producto
software (Instituto Nacional de la Calidad -
INACAL 2005)
Variable Características aceptadas por el usuario del Analizar la percepción de la Funcionalidad Muy bueno, Bueno, 1, 2, 3, 4 Ordinal
Dependiente: software. Permite a las empresas que calidad del software de los Regular, Malo Encuesta basada en
desarrollan software conocer la calidad de usuarios de la plataforma Confiabilidad Muy bueno, Bueno, 5, 6 y 7 Ordinal el estándar ISO/IEC
Calidad del Software sus productos y a las empresas que compran S.O.S. Tesis luego de la Regular, Malo 9126
software, decidirse por una solución u otra en implementación de la NTP Usabilidad Muy bueno, Bueno, 10 y 11 Ordinal
función de sus necesidades 9126-3 Regular, Malo
(International Standard Organization-ISO Eficiencia Muy bueno, Bueno, 8y9 Ordinal
2014) Regular, Malo
Capacidad de Muy bueno, Bueno, 12 y 13 Ordinal
Mantenimiento Regular, Malo
Portabilidad Muy bueno, Bueno, 14, 15 y 16 Ordinal
Regular, Malo
139
ANEXO 3: ENCUESTA/INSTRUMENTO DE EVALUACIÓN
PREGUNTAS CUALITATIVAS “INDUCTIVAS”
Datos Generales:
Nombre: ______________________________________________________________
Cargo: _________________________________________________________________
Años laborando en le empresa: _____________________________________________
Cargos anteriores: _______________________________________________________
Sexo: __________________________________________________________________
Edad: _____________________________
¿Cómo se dan los procesos para el desarrollo de los softwares, en especial, el S.O.S
Tesis?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
Por su experiencia ¿cómo se podría mejorar los procesos de desarrollo de los softwares,
en especial, el S.O.S Tesis?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
140
ANEXO 4: CONSTANCIA EMITIDA POR LA INSTITUCIÓN DONDE SE REALIZÓ LA
INVESTIGACIÓN
141
142
143
144

TL-Donayre J-Ext

Cargado por

Copyright:

Formatos disponibles

TL-Donayre J-Ext

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TL-Donayre J-Ext

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE CIENCIAS EMPRESARIALES

CARRERA PROFESIONAL DE INGENIERIA DE

“IMPLEMENTACIÓN DE LA NORMA TÉCNICA PERUANA 9126-3

Tesis para optar el título profesional de:

Título del documento evaluado. Implementación de la Norma Técnica Peruana 9126-

Autores. Julio Francisco Donayre Martínez.

Mecanismo de revisión de originalidad. Evaluación con Turnitin (ID 1943887939).

Revisado por. Magaly Kelly Guerrero Huaracallo.

Comentarios sobre la revisión. Filtros usados: excluir fuentes de menos de 12

Gracias a Dios, por haberme dado la vida, acompañado a lo largo

A mis Padres, Reyna y Máximo por haberme forjado como

A mi esposa, Katya porque siempre eres mi fuerza y

A mis hermanos, Wilfredo y John mis mejores amigos y

A la Universidad Científica del Sur, que me dio la

Agradezco a mi asesor de Tesis Dr. Hugo Eladio

El camino fue largo con muchas pruebas, pero he

Mi más sincero agradecimiento y felicitaciones por todo

Índice general ................................................................................................................... 5

Índice de figuras ............................................................................................................... 8

Índice de tablas ................................................................................................................. 9

Índice de anexos ............................................................................................................. 11

CAPITULO I: PLANTEAMIENTO DEL PROBLEMA ............................................................. 15

1.1. Descripción de la realidad problemática............................................................ 15

1.2. Formulación del problema ................................................................................. 18

1.2.1. Problema general...................................................................................... 18

1.2.2. Problemas específicos .............................................................................. 18

1.3. Justificación de la investigación ......................................................................... 19

1.4. Limitaciones de la investigación ......................................................................... 21

1.5. Viabilidad de la investigación .................................................................................. 22

CAPITULO II: MARCO TEORICO ....................................................................................... 24

2.1. Antecedentes de la investigación ............................................................................ 24

2.1.1. Internacionales ..................................................................................... 24

2.1.2. Nacionales ............................................................................................. 26

2.2. Bases teóricas .......................................................................................................... 31

2.3. Objetivos de la investigación ................................................................................... 43

2.3.1. Objetivo general ....................................................................................... 43

2.3.2. Objetivos específicos ................................................................................ 43

2.4. Formulación de hipótesis ........................................................................................ 44

2.4.1. Hipótesis general ...................................................................................... 44

2.4.2. Hipótesis especificas ................................................................................. 45

CAPITULO III: DISEÑO METODOLÓGICO ......................................................................... 46

3.1. Diseño de la investigación ....................................................................................... 46

3.2. Tipo de investigación ............................................................................................... 46

3.4. Población ................................................................................................................. 46

3.5. Muestra ................................................................................................................... 47

3.6. Operacionalización de variables .............................................................................. 48

3.7. Técnicas para la recolección de datos ..................................................................... 49

3.8. Técnica para el procesamiento y análisis de datos ................................................. 49

3.9. Aspectos éticos ........................................................................................................ 50

CAPITULO IV: RESULTADOS ............................................................................................ 51

4.1 Resultados Fuente Secundaria ................................................................................. 51

4.2 Resultados Fuente Primaria...................................................................................... 79

4.3 Comprobación de Hipótesis ................................................................................... 111

CAPITULO V: DISCUSION, CONCLUSIONES Y RECOMENDACIONES ............................. 121

5.1. Discusión ................................................................................................................ 121

5.2. Conclusiones .......................................................................................................... 126

5.3. Recomendaciones.................................................................................................. 128

Referencias bibliográficas ............................................................................................. 130

Bibliografía .................................................................................................................... 130

Abreviaturas ................................................................................................................. 135