"Desarrollo de Un Modelo para La Gestión de La

VICERRECTORADO DE INVESTIGACIÓN, INNOVACIÓN Y
TRANSFERENCIA DE TECNOLOGÍA
CENTRO DE POSGRADOS MAESTRÍA EN GERENCIA DE SISTEMAS,

PROMOCIÓN XVI
TRABAJO DE TITULACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO

DE MAGÍSTER EN: GERENCIA DE SISTEMAS
TEMA: “DESARROLLO DE UN MODELO PARA LA GESTIÓN DE LA

ADQUISICIÓN DE SOFTWARE COMERCIAL (ERP) PARA LAS PYMES
DEL SECTOR PRIVADO DE LA CIUDAD DE QUITO, año 2016-2017”
AUTORES: ING. CASA SALAZAR, EDISON JAVIER
ING. SANCHEZ NEACATO, LUIS EDGAR
DIRECTOR: ING. CAMPAÑA ORTEGA, MAURICIO M.I.S, M.D.U.
SANGOLQUÍ
2018
i
ii
iii
iv
DEDICATORIA
La presente tesis se la dedico a DIOS por darme la vida, la salud y una linda familia
para quienes dedico este trabajo.
A ELSITA
Mi esposa, quien desde un inicio me dio su apoyo y me inscribió para empezar este
gran proyecto y con su ayuda en nuestro entorno familiar complementó los días que
faltaba con mis hijos.
A mi madre Sra. EMMA SALAZAR
Quién con su ejemplo me ha enseñado que con esfuerzo se puede lograr muchas
cosas en la vida, nada es fácil, pero con el empuje diario se logra muchas cosas en la
vida.
A mi padre JUAN JOSÉ CASA
Por estar pendiente de mi maestría, por preguntarme y apoyarme al estar preocupado
mientras desarrollaba el presente trabajo.
Ing. Edison Javier Casa S.

v
DEDICATORIA
El presente trabajo se lo dedico a Dios por darme la fuerza y destreza para realizar
mis estudios superiores y a mi familia.
A mi hija, que es mi motivo de desarrollo y crecimiento para darle lo mejor que un
padre pueda dar a sus hijos.
A mi esposa, que ha sido un gran apoyo en todo el proceso de estudio de la
maestría de Gerencia de Sistemas.
A mi madre que siempre me ha apoyado en todo momento y gracias a ella soy
quien soy.
Ing. Luis Sánchez N.

vi
AGRADECIMIENTOS
A la Universidad de las Fuerzas Armadas ESPE, por permitir que los profesionales del
país sigamos creciendo con el conocimiento que se imparte por sus profesores en las
instalaciones.
A los profesores quienes con su experiencia impartieron el conocimiento necesario
para complementar mis estudios y desarrollar mis actividades profesionales.
A mi director de tesis, Magister MAURICIO CAMPAÑA ORTEGA, por entregar desde
el inicio su apoyo y ser nuestra guía en el desarrollo del presente trabajo.
Al Coordinador del Programa de Maestría en Gerencia de Sistemas, Magister
GEOVANNI NINAHUALPA QUIÑA, por entregar la guía necesaria para cumplir todos los
pasos necesarios para culminar con éxito el presente trabajo.
Ing. Edison Javier Casa S.

vii
AGRADECIMIENTOS
Agradezco en primer lugar a Dios ya que sin él nada es posible.
A mi esposa, Karen Aguirre quien con su motivación siempre me impulso a culminar
mis estudios superiores y a mi hija Arianna Sánchez quien es mi motivo y fortaleza para
seguir cumpliendo metas.
Al Ingeniero, MAURICIO CAMPAÑA e Ingeniero GEOVANNI NINAHUALPA, quienes
con su apoyo supieron darnos las guías para la culminación de este trabajo.
Ing. Luis Sánchez N.

viii
ÍNDICE DE CONTENIDO
CAPÍTULO I .................................................................................................................... 3
INTRODUCCIÓN ............................................................................................................. 3
1.1 Generalidades ........................................................................................................... 3
1.2 Antecedentes............................................................................................................. 4
1.3 Planteamiento del problema ...................................................................................... 4
1.4 Formulación del problema ......................................................................................... 5
1.5 Sistematización del problema .................................................................................... 5
1.6 Objetivos.................................................................................................................... 5
1.6.1. General .................................................................................................................. 5
1.6.2.Específicos ............................................................................................................. 5
1.7 Justificación e Importancia ........................................................................................ 6
1.8 Alcance ...................................................................................................................... 6
CAPÍTULO II ................................................................................................................... 8
MARCO TEÓRICO .......................................................................................................... 8
2.1 Introducción ............................................................................................................... 8
2.2. Fundamentación Teórica .......................................................................................... 8
2.3. Hipótesis ................................................................................................................... 9

ix
2.4 Variables de investigación ......................................................................................... 9
2.5 Metodología de la investigación .............................................................................. 10
2.6 Tipo de Investigación ............................................................................................... 10
2.7 Población y Muestra ................................................................................................ 11
2.7.1 Población .............................................................................................................. 11
2.7.2 Muestra................................................................................................................. 11
2.8 Técnicas de investigación........................................................................................ 11
2.9 Instrumentos de la investigación ............................................................................. 12
2.10 Recolección de la información ............................................................................... 12
2.11 Tratamiento y análisis estadístico de los datos ..................................................... 13
2.12 Estado del arte ...................................................................................................... 13
2.13 Definiciones ........................................................................................................... 14
2.13.1. ERP ................................................................................................................... 14
2.13.2 PYMES ............................................................................................................... 15
2.13.3 Proveedores ....................................................................................................... 16
2.13.4 Costo Beneficio .................................................................................................. 17
2.14 Normas y estándares............................................................................................. 17
2.14.1 Norma ISO/IEC 12207:2008 ............................................................................... 19
2.14.2 Normas ISO/IEC 9000-3:2004 ............................................................................ 19

x
2.14.3 Normas ISO/IEC 9126 ........................................................................................ 20
2.14.4 Normas ISO/IEC 14598 ...................................................................................... 20
2.15 Métricas de Software ............................................................................................. 21
2.15.1 Métricas para software desarrollado ................................................................... 21
2.15.2 Métricas para implementación de software ........................................................ 21
2.16 Modelos de calidad de Software ............................................................................ 22
2.16.1 Características de los modelos de Software ....................................................... 23
2.16.2 Modelos de McCall ............................................................................................. 24
2.16.2 Modelos de BOEHM ........................................................................................... 29
2.16.3 Modelo FURPS ................................................................................................... 31
2.16.4 Modelo de DROMEY .......................................................................................... 33
2.16.5 Modelo C-QM (Checking Quality Model) ............................................................ 35
CAPÍTULO III ................................................................................................................ 38
DEFINICIÓN DEL MODELO Y LA METODOLOGÍA A APLICAR ............................... 38
3.1 Introducción ............................................................................................................. 38
3.2 Análisis de modelos de calidad ............................................................................... 38
3.3 Análisis de ocurrencias ............................................................................................ 39
3.3.1 Funcionalidad ....................................................................................................... 43
3.3.2 Confiabilidad ......................................................................................................... 44

xi
3.3.3 Facilidad de Uso ................................................................................................... 45
3.3.4 Eficiencia .............................................................................................................. 46
3.3.5 Facilidad de Mantenimiento .................................................................................. 47
3.3.6 Portabilidad ........................................................................................................... 48
3.3.7 Procesos importantes de la norma ISO/IEC 12207:2008 ..................................... 48
3.3.7.1 Proceso de Adquisición. .................................................................................... 49
3.3.7.2 Proceso De Suministro ...................................................................................... 52
3.3.8 Algoritmo para la aplicación del modelo ............................................................... 54
3.3.9 Análisis de Métricas .............................................................................................. 55
3.4.Metodología Planteada ............................................................................................ 69
CAPITULO IV ................................................................................................................ 72
PROPUESTA ................................................................................................................ 72
4.1 Formulación del proceso de aplicación de la propuesta .......................................... 72
4.1.1 Antecedentes ........................................................................................................ 72
4.1.2 Problemática actual .............................................................................................. 73
4.1.3 Levantamiento de la información .......................................................................... 73
4.2.Aplicación del Modelo Acs ....................................................................................... 86
4.2.1 Valoración del Proceso de Adquisición................................................................. 86
4.2.2 Análisis del proceso de Adquisición ...................................................................... 87

xii
4.2.3 Análisis de la valoración de la métrica: Funcionalidad .......................................... 89
4.2.4 Análisis de la valoración de métrica: Confiabilidad ............................................... 90
4.2.5 Análisis de valoración de métrica: Facilidad de Uso ............................................. 92
4.2.6 Análisis de valoración de métrica: Eficiencia ........................................................ 93
4.2.7 Análisis de valoración de métrica: Mantenimiento ................................................ 95
4.2.8 Análisis de valoración de métrica: Portabilidad ..................................................... 96
4.2.9 Análisis del Proceso de Suministro ....................................................................... 97
4.3 Resultados Finales de la aplicación de la metodología ACM. ................................. 98
CAPITULO V ............................................................................................................... 100
CONCLUSIONES Y RECOMENDACIONES .............................................................. 100
5.1. Conclusiones ........................................................................................................ 100
5.2. Recomendaciones ................................................................................................ 102

xiii
ÍNDICE DE TABLAS
Tabla 1 Relación entre Factores de calidad y métricas de la calidad ............................ 25
Tabla 2 Factores y Características del Modelo de McCall ............................................ 26
Tabla 3 Costo – Beneficio de los Factores de Calidad .................................................. 28
Tabla 4 Relación entre los factores y criterios del Modelo de Boehm ........................... 31
Tabla 5 Modelo de FURPS ........................................................................................... 32
Tabla 6 Matriz Modelo de Dromey ................................................................................ 34
Tabla 7 Factores, Criterios y Métricas del Modelo C-QM .............................................. 35
Tabla 8 Análisis de Modelos de Calidad ....................................................................... 39
Tabla 9 Análisis de Ocurrencias de los modelos de calidad ......................................... 40
Tabla 10 Métricas del modelo de calidad ...................................................................... 58
Tabla 11 Tabla de rangos válidos de la métrica ............................................................ 63
Tabla 12 Medidas y acciones para las métricas............................................................ 65
Tabla 13 Requerimiento de las empresas en métricas ................................................. 66
Tabla 14 Valoración del Proceso de Adquisición .......................................................... 86
Tabla 15 Valoración de la métrica Funcionalidad.......................................................... 88
Tabla 16 Valoración de métrica: Confiabilidad .............................................................. 89
Tabla 17 Valoración de métrica: Facilidad de Uso ........................................................ 91
Tabla 18 Valoración de métrica: Eficiencia ................................................................... 92
Tabla 19 Valoración de métrica: Mantenimiento ........................................................... 94
Tabla 20 Valoración de métrica: Portabilidad ................................................................ 95
Tabla 21 Valoración del Proceso de Suministro............................................................ 97

xiv
ÍNDICE DE FIGURAS
Figura 1 Modelo de Boehm.......................................................................................... 30
Figura 2 Características de la calidad interna y externa .............................................. 42
Figura 3 Proceso de Adquisición ................................................................................. 51
Figura 4 Proceso de suministro ................................................................................... 53
Figura 5 Proceso de calidad ........................................................................................ 67
Figura 6 Proceso de calidad (continuación) ................................................................. 68
Figura 7 Modelo ACS .................................................................................................. 70
Figura 8 Pregunta Nro. 1 ............................................................................................. 76
Figura 9 Pregunta Nro. 2 ............................................................................................. 77
Figura 10 Pregunta Nro. 3 ........................................................................................... 78
Figura 11 Pregunta Nro. 4 ...................................................................................... 79
Figura 12 Pregunta Nro. 5 ........................................................................................ 80
Figura 17 Pregunta Nro. 10 ......................................................................................... 85
Figura 18 Valoración del proceso de Adquisición ........................................................ 87
Figura 19 Valoración la métrica: Funcionalidad. .......................................................... 88
Figura 20 Valoración de métrica: Confiabilidad ........................................................... 90

xv
Figura 21 Valoración de métrica: Facilidad de Uso ..................................................... 91
Figura 22 Valoración de métrica: Eficiencia ................................................................. 93
Figura 23 Valoración de métrica: Mantenimiento......................................................... 94
Figura 24 Métrica: Portabilidad .................................................................................... 96

1
RESUMEN
La adquisición de software para una empresa puede ser la oportunidad de cambiar y dar
un giro al negocio elevando el nivel operativo y de toma de decisiones, pero existen
también la posibilidad de que el software adquirido cumpla medianamente o casi nada
las expectativas que estaban presentes al momento de la toma de decisión. La razón
expuesta permite crear o adecuar una metodología para la adquisición de software. La
mayoría de las empresas que están en el grupo de las PYMES no tienen satisfechas sus
necesidades con el software adquirido, este es un impulso para el desarrollo del presente
documento, el mismo debe ser una guía de fácil comprensión y aplicación.
Palabras clave:
 PYMES
 ISO IEC 12207
 ADQUISICIÓN DE SOFTWARE COMERCIAL
 ERP
 MÉTRICAS DE SOFTWARE
 MODELOS DE CALIDAD.
2
ABSTRACT
Acquiring software for a company can be the opportunity to change and improve the
business by raising the operational and decision-making level, but there is also the
possibility that the software acquired is moderately small or almost nothing things that
were present at the time of decision making. This reason allows to create or adapt a
methodology for the acquisition of software. Some of the companies that are in the group
of Pymes that have acquired software, are not satisfied. This is one of the reasons for the
development of this document, it should be a guide for easy understanding and
application.
KeyWords:
 PYMES
 ISO IEC 12207
 ADQUISICIÓN DE SOFTWARE COMERCIAL
 ERP
 MÉTRICAS DE SOFTWARE
 MODELOS DE CALIDAD.
3
CAPÍTULO I
INTRODUCCIÓN
1.1 Generalidades
La adquisición del software por parte de las áreas de TI en las empresas requiere
de un análisis previo costo-beneficio, se deben validar los requerimientos de la empresa
y las bondades que el software pueda prestar para cubrir los mismos.
Las pymes en el Ecuador tienen una gran participación en la matriz productiva,
debido a que se han convertido en una fuente de empleo, ofreciendo productos y servicios
a diversos mercados ya sean estos de menor o gran tamaño.
Al ser las Pymes una categoría de empresas primordiales para la economía del
Ecuador, es necesario que cuenten con sistemas de gestión de información que permitan
su constante crecimiento y desarrollo.
Para obtener el software que las Pymes requieren, por lo general el departamento
de TI tiene que realizar una evaluación de proveedores sin un método a seguir, lo que
puede ocasionar que seleccionen un software de manera errónea y generar costos y
complicaciones operativas para las empresas.

4
Con el desarrollo del presente proyecto, se obtendrá un modelo para la gestión de
la adquisición de software comercial (ERP) para las pymes del sector privado, de tal
manera de que sirva como guía para el departamento de TI que se encuentre en la
búsqueda de software ERP.
1.2 Antecedentes
La adquisición de software se puede convertir en un proceso muy complejo o
puede ser manejado de tal manera que se alinee a parámetros establecidos que permitan
direccionar al personal del TI en este proceso.
1.3 Planteamiento del problema
Seleccionar de forma inadecuada el software de una empresa ocasiona pérdidas
económicas, retrasos en la gestión diaria y en los informes para la toma de decisiones,
el origen de una compra que no satisface las necesidades de los usuarios y los gerentes
de la empresa está en no aplicar de forma adecuada una metodología para la adquisición
de software, esto comprende seleccionar el software y el proveedor. En el medio actual
para las PYMES, la adquisición de software de Gestión está dado por referidos o por la
mejor propuesta de software en temas económicos, sin tomar en cuenta las
consecuencias de una mala selección o un fallo desde el proceso de adquisición hasta la
puesta en marcha a producción del sistema.

5
1.4 Formulación del problema
¿Cómo afecta a las empresas PYMES la carencia de un modelo de adquisición de
software comercial - ERP?
1.5 Sistematización del problema
¿Qué necesita una empresa para que no se vea afectada la gestión y los resultados
con un software?
¿Para qué sirve la metodología de gestión de software?
¿Cómo se puede verificar el costo beneficio de la metodología?
1.6 Objetivos.
1.6.1. General
Desarrollar un modelo para la gestión de la adquisición de Software Comercial
(ERP) para las empresas PYME.
1.6.2. Específicos
● Realizar una guía con las buenas prácticas de la aplicación de la ISO IEC
12207:2008, ISO/IEC 9000-3:2004, ISO/IEC 9126:2001, ISO/IEC 14598:2001 en
el área de adquisición de Software Comercial (ERP).

6
● Identificar necesidades y requerimientos en el proceso de obtención del software,
mediante el análisis de la norma ISO/IEC 12207:2008.
● Analizar mediante normas ISO ISO/IEC 12207:2008. las características básicas
para la aceptación y administración de contratos de software.
1.7 Justificación e Importancia
Mediante esta investigación se estudiará el origen de una compra de software que
no satisface las necesidades de los usuarios y los gerentes de la empresa., estableciendo
una metodología para la adquisición de software, esto comprende seleccionar el software
y el proveedor del mismo.
La investigación busca establecer parámetros estándar mediante la elaboración
de una guía con buenas prácticas basándose en normas ISO y modelos de calidad,
mediante la identificación de necesidades y requerimientos que permitan garantizar la
cadena de valor dentro de las empresas PYMES.
Los beneficiados dentro de esta investigación serán los usuarios y gerentes dando
como resultado una gestión empresarial exitosa en lo que se refiere a la contratación o
elaboración de software.
1.8 Alcance
Se pretende realizar una metodología que tenga los requisitos mínimos que deben
cumplir las empresas PYMES para adquirir un software ERP, con el objetivo que la
7
adquisición cumpla con los objetivos planteados por las jefaturas y se aliñe a la misión
de las empresas.
8
CAPÍTULO II
MARCO TEÓRICO
2.1 Introducción
Seleccionar de forma inadecuada el software de una empresa ocasiona pérdidas
económicas, retrasos en la gestión diaria y en los informes para la toma de decisiones,
el origen de una compra que no satisface las necesidades de los usuarios y de los
gerentes de la empresa se basa en la falta de aplicación de una metodología para la
adquisición de software, esto comprende seleccionar el software y el proveedor. En el
medio actual para las PYMES, la adquisición de software de Gestión está dado por
referidos o por la mejor propuesta de software sin tomar en cuenta las consecuencias de
una mala selección.
2.2. Fundamentación Teórica
El ISO/IEC 12207 es el estándar para los procesos de ciclo de vida del software
de la organización ISO el cual fue concebido para aquellos interesados en adquisición de
software, así como desarrolladores y proveedores.
“El estándar indica una serie de procesos desde la recopilación de requisitos hasta la
culminación del software y comprende 17 procesos lo cuales son agrupados en tres
categorías que son las principales, de apoyo, de organización” (Arroyo, 2017, pág. 56).
9
“Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de
vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro
procesos organizativos. Cada proceso del ciclo de vida está divido en un conjunto de
actividades; cada actividad se sub -divide a su vez en un conjunto de tareas” (Arroyo,
2017, pág. 56).
2.3. Hipótesis
Las empresas PYMES que cuentan con un modelo para la gestión de la
adquisición de Software Comercial (ERP) aseguran un crecimiento empresarial.
Las empresas PYMES que tienen problemas de software no manejan un modelo para la
gestión de la adquisición de Software Comercial (ERP) disminuyendo el crecimiento
empresarial.
2.4 Variables de investigación
Variable dependiente
Problemas con los métodos de adquisición o implementación de software de
Gestión Comercial ERP en pymes.
Variables independientes
 No apalancarse en una metodología de adquisición o desarrollo de software.
 Falta de métricas para la evaluación del software.
 Compra de software sin previa evaluación.

10
 Falta de uso por parte de los usuarios debido a su complejidad.
2.5 Metodología de la investigación
La investigación tomará una modalidad inicialmente de campo, ya que el estudio
se realizará directamente en una empresa PYMES, de ahí iniciará la investigación que
permitirá dar propuestas y opiniones que ayuden a establecer la metodología.
El método inductivo-deductivo, se realizará un estudio preliminar en el área de
Contabilidad, esto permitirá establecer los lineamientos, bases y teorías que serán
necesarias en la investigación, los cuales serán aplicados de manera específica.
Después se aplicará el método hipotético-deductivo, se podrá obtener referencias
de lo que ocurre en la empresa en base al planteamiento de la hipótesis, luego deducir
propuestas que se puedan aplicar y verificar dentro de las mismas.
2.6 Tipo de Investigación
El tipo de estudio que se aplicará en esta investigación para un mayor
entendimiento de lo acontecido será:
Exploratorio. - Se tendrá que acudir a investigaciones previas y realizar revisiones
bibliográficas sobre los procesos operativos, las cuales nos ayudan a establecer las
bases y condiciones del estudio que se pretende realizar.

11
Descriptivo. - Se realizará el estudio de los procesos que necesita cubrir el software
en la empresa, con el cual se detalla el levantamiento de la información, estableciendo
las bases del estudio.
Explicativo. - En base a los estudios realizados anteriormente y estableciendo la
relación causa-efecto, se buscará responder el acontecer de los hechos y posibles
problemáticas que presenta la metodología con respecto a los procesos operativos y de
esta forma dar conclusiones inequívocas al estudio.
2.7 Población y Muestra
2.7.1 Población
Para el presente proyecto se realizará el levantamiento de la información en un
negocio de la Ciudad de Quito una industria de productos Químicos denominada Química
Comercial Quimicial Cía. Ltda.
2.7.2 Muestra
La muestra se aplicará al total de la población, la industria Química Comercial
Quimicial Cía. Ltda., cuenta con un total de 15 personas distribuidas en las áreas de
facturación, control de inventarios, finanzas, compras, clientes, contabilidad y Gerencia
General.
2.8 Técnicas de investigación
Las técnicas de investigación que se aplicarán en el presente trabajo son:

12
Observación, este proceso se realizará en las instalaciones de Química comercial, para
la obtención de datos en el sitio donde suceden los procesos operativos y de esta manera
recopilar toda la información necesaria que será utilizada eventualmente a lo largo de la
investigación.
Entrevista, se realizará conversaciones continuas con preguntas estructuradas con las
personas involucradas laboralmente en Química comercial.
Encuesta, es un conjunto de preguntas previamente validadas que se aplica a una
muestra representativa del grupo de estudio, con la finalidad de extraer información
relevante sobre opiniones o hechos específicos que suceden en los negocios.
2.9 Instrumentos de la investigación
Los instrumentos de investigación se utilizarán son:
 Entrevistas con gerentes de negocio.
 Encuestas a administradores de negocio.
Estos dos instrumentos permitirán conocer las necesidades de las empresas y cuáles
son las expectativas que tienen cuando adquieren software que es utilizado en su gestión
operativa, administrativa y de toma de decisiones.
2.10 Recolección de la información
La información recolectada y organizada permitirá entender las necesidades que
tienen las empresas en el momento de adquirir software. Esta información constituye la

13
base de la investigación de estándares existentes y normas que se debe aplicar para
enmarcar la metodología a desarrollar.
2.11 Tratamiento y análisis estadístico de los datos
En este punto el análisis de los datos permitirá identificar las tendencias que tienen
las empresas en la adquisición de software.
2.12 Estado del arte
En los trabajos sobre metodologías de adquisición de software se ha verificado
que se basan en modelos, normas y estándares como ISO/IEC 12207, Estándar
IEEE 1062, Modelos CMMI-ACQ, modelos de medición de software como McCall.,
Boehm, Furps entre otros.
El estándar ISO/IEC 12207 puede direccionar la adquisición de software, esto
enmarca a desarrolladores y proveedores en el ciclo de vida del software.
Perú elaboró la Norma Técnica Peruana basada en la norma ISO/IEC 12207, este trabajo
se basa en tres partes importantes: Los procesos principales del ciclo de vida del
software, los procesos de apoyo del ciclo de vida y los procesos organizativos del ciclo
de vida, este trabajo sirve como referencia para los temas relacionados al software
facilitando una guía, como observación general siempre debe buscarse la última versión
de las normas (Comerciales, 2006, pág. 2).

14
Lo importante es saber que no todas las empresas son iguales, en su tamaño, en
sus políticas y las decisiones de los gerentes de TI, estos son aspectos fundamentales
para la aplicación de una guía o norma que facilite los procesos de adquisición, desarrollo
o mantenimiento del software.
Uno de los aspectos a tener en cuenta al desarrollar un método o una guía es pensar en
que el documento se convertirá en base fundamental para las empresas que necesitan
adquirir un software que les permita dar un salto tecnológico para la toma de decisiones,
esto se observa en el documento: Modelo para la selección de software ERP generado
por el departamento de procesos y Sistemas de la Universidad Simón Bolívar - Caracas
Venezuela, el trabajo basa su desarrollo en recomendaciones y resultados de encuestas
de empresas de manufactura (Castro, Borges, Baquero, & Rodriguez, 2006, pág. 1).
Microsoft indica la necesidad de establecer políticas para la adquisición de software, con
el objeto de controlar: costos, optimizar el valor del software, mantener la organización
conforme el crecimiento de la compañía (Software Asset Management, 2006, pág. 1).
2.13 Definiciones
2.13.1. ERP
Enterprise Resource Planning o Planificación de recursos empresariales. Las
operaciones de la gestión diaria en las empresas actuales están dadas por el manejo de
la información a través de sistemas los cuales se encargan del manejo de las principales
actividades como son: facturación, inventarios, costos, producción, cuentas por cobrar,
cuentas por pagar entre los más usados en nuestro medio, estos sistemas están
15
relacionados con el objeto de que la empresa pueda tener una herramienta completa para
obtener información centralizada que permita realizar análisis y consulta de manera
oportuna para la toma de decisiones (Vera, 2015, p. 18).
Estos sistemas ERP dan las facilidades a las empresas para que puedan
adaptarse a ellos o los ERP adaptarse a las necesidades de las empresas. Siendo este
último uno de las opciones que toman las empresas para ajustar a las necesidades
operativas.
Los tipos de ERP que se puede encontrar en el mercado son dos, a la hora de
tomar una decisión se puede elegir entre las opciones de software a la medida o estándar,
siendo las dos buenas opciones dependiendo de la situación de la empresa, si es un
negocio que empieza sus actividades y no tiene recursos o software estándar o si es una
empresa que ya tiene sus procesos definidos y necesita algo a medida, en este último
caso se contrata una empresa para desarrollar de acuerdo a las necesidades.
2.13.2 PYMES
Se conoce como PYMES al conjunto de pequeñas y medidas empresas que, de
acuerdo a su volumen de ventas, capital social, cantidad de trabajadores, y su nivel de
producción o activos presentan características propias de este tipo de entidades
económicas. Por lo general en nuestro país las pequeñas y medianas empresas que se
han formado realizan diferentes tipos de actividades económicas entre las que
destacamos las siguientes:

16
 Comercio al por mayor y al por menor.
 Agricultura y Pesca.
 Industrias manufactureras.
 Construcción.
 Transporte, almacenamiento, y comunicaciones.
 Bienes inmuebles y servicios prestados a las empresas.
 Servicios comunales, sociales y personales (Servicio de Rentas Internas del
Ecuador, 2017, pág. 1).
2.13.3 Proveedores
Un proveedor es una persona o una empresa que proporciona existencias y
abastecimiento a otra empresa para que ésta pueda explotarlos en su actividad
económica. Por otra parte, el concepto de proveedor puede tener varios significados que
dependen directamente de las funciones que vaya a realizar dicho proveedor. Además,
el destinatario de dichas existencias puede transformar los recursos obtenidos o por el
contrario venderlos sin más (Economía Simple, 2016, pág. 1).
Los tipos de proveedores más habituales son tres: proveedores de bienes, proveedores
de recursos o proveedores de servicios. Por norma general, los proveedores de bienes
responden ante necesidades de tipo internacional y satisfacen las necesidades del
mercado. Los proveedores de recursos responden a las necesidades económicas de la
empresa y por último los proveedores de servicios atienden a las necesidades del cliente
(Economía Simple, 2016, pág. 1).

17
2.13.4 Costo Beneficio
El análisis costo-beneficio es una herramienta financiera que mide la relación entre los
costos y beneficios asociados a un proyecto de inversión con el fin de evaluar su
rentabilidad, entendiéndose por proyecto de inversión no solo como la creación de un
nuevo negocio, sino también, como inversiones que se pueden hacer en un negocio en
marcha tales como el desarrollo de nuevo producto o la adquisición de nueva maquinaria
(Crece negocios, 2017, pág. 1).
2.14 Normas y estándares
En un ámbito formal se conoce el término estándar como acuerdos documentados que
contienen especificaciones técnicas o criterios precisos que son utilizados
consistentemente, como reglas, guías, definiciones de características para asegurar que
los materiales, productos, procesos y servicios cumplen con su propósito. En términos
sencillos son lenguajes comunes que permiten el entendimiento y la comunicación entre
los distintos actores (IDEAM Instituto de hidrología, metereología y estudios ambientales,
2014, pág. 1).
Normas ISO
Las siglas ISO (International Standarization Organization) son un conjunto de normas
cuya finalidad es organizar los procesos de una empresa u organización. Todas las
normas ISO están compuestas por guías y estándares los cuales incluyen herramientas
que permiten una mejor gestión de los procesos que forman parte de una organización
(Pérez, 2013, p. 8).

18
Las normas ISO son un modelo o patrón a seguir, las mismas definen las
características que un proceso debe tener para cumplir una compatibilidad internacional.
Estos procesos pueden ser desde la elaboración de herramientas intangibles como el
software hasta el desarrollo de un determinado producto de consumo alimenticio.
Origen
Las normas ISO surgieron en los años 80’, parten de las normas británicas BS
5450 (eran lineamientos de aplican en el campo nuclear), normas MOD 05/25 y la AQAP
149.
La primera norma ISO en ser escrita fue la ISO 9001 dedicada al aseguramiento
de la calidad, la cual se la empezó a escribirla en 1985 y su primera publicación fue en
1987.
Entre los beneficios de aplicar las normas ISO a las empresas se pueden
mencionar los siguientes:
Reducción de costos, ya se mejora la rentabilidad y eficiencia de los procesos.
Las marcas crecen en un mercado competitivo gracias a las certificaciones ISO.
Confianza para contratar los servicios ofertados debido a una certificación
internacional ISO.
Las normas ISO garantizan un servicio o un suministro de gran calidad.

19
2.14.1 Norma ISO/IEC 12207:2008
La ISO/IEC 12207 es el estándar para los procesos de ciclo de vida del software
de la organización ISO el cual fue concebido para aquellos interesados en adquisición de
software, así como desarrolladores y proveedores.
“El estándar indica una serie de procesos desde la recopilación de requisitos hasta la
culminación del software y comprende 17 procesos lo cuales son agrupados en tres
categorías que son las principales, de apoyo, de organización.” (Arroyo, 2017, pág. 89).
“Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de
vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro
procesos organizativos. Cada proceso del ciclo de vida está divido en un conjunto de
actividades; cada actividad se sub -divide a su vez en un conjunto de tareas” (Arciniega,
2017)
2.14.2 Normas ISO/IEC 9000-3:2004
Esta norma posee estándares utilizados para el desarrollo, mantenimiento y
suministro de productos de software y se los puede utilizar en el desarrollo de sistemas
Informáticos, en el proceso del ciclo de vida del software y en la calidad del software.
Mediante la aplicación de la norma ISO 9000-3:2004 se puede obtener beneficios
como el mejoramiento de la documentación de los sistemas informáticos, empleados más

20
eficientes, mejor calidad en la entrega de productos y mejoramiento en la satisfacción al
cliente.
2.14.3 Normas ISO/IEC 9126
La norma ISO 9126:2001 permite realizar la evaluación de calidad de software y
su primera publicación fue en 1991 en la cual se muestra las características principales
de un modelo de calidad siendo actualizada en el 2001.
Esta norma ISO clasifica la calidad del software en características tales como la
funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad y calidad de
uso. Cada una de estas características posee sub características las cuales a su vez
poseen atributos con los cuales pueden ser medidos o verificados (Borbón, 2013, p. 56).
2.14.4 Normas ISO/IEC 14598
Esta norma ISO permite evaluar la calidad de los productos de software mediante
métricas y requerimientos.
Se la usa junto con la norma ISO 9126 para aplicar sus conceptos definiendo las
actividades y requisitos de evaluación.
“La norma ISO/IEC 14598 consta de las siguientes características: repetitividad,
reproducibilidad, imparcialidad, objetividad las cuales son medidas mediante el Análisis
de los requisitos de evaluación, la evaluación de las especificaciones., evaluación del
diseño y definición del plan de evaluación, la ejecución del plan de evaluación y la
evaluación de la conclusión” (EcuRed conocimiento con todos y para todos, 2017, p. 67).
21
2.15 Métricas de Software
2.15.1 Métricas para software desarrollado
Las métricas para el desarrollo de software ayudan a verificar si el producto
construido cumple todas sus características de acuerdo a normas establecidas mediante
las métricas.
Existen diferentes tipos de métricas mediante las cuales se puede medir ciertas
características del software y así conocer si es un producto bien desarrollado o no.
Con el uso de métricas de software se busca que la calidad de desarrollo, código
fuente bien estructurado, diseño optimo y las pruebas realizadas al sistema permitan a
los desarrolladores evaluar su trabajo con medidas técnicas las cuales deben ser
evaluadas con objetividad y no con subjetividad.
Existen diferentes métricas las cuales se las puede aplicar al Desarrollo de
software, cada una de estas métricas se las calcula en base a medidas como por ejemplo
la prueba de errores de código, la prueba de los componentes del software, las pruebas
de carga y estrés, entre otras.
2.15.2 Métricas para implementación de software
Para hablar de métricas siempre está presenta la calidad, las métricas permiten
determinar de acuerdo a ciertos parámetros los cuales son las características básicas
que debe cumplir algún producto, para el caso de estudio actual los puntos que deberá
22
cumplir un software para su adquisición e implementación, de tal manera que cumpla las
necesidades de la empresa o negocio que adquirió el producto.
Como base para definir las métricas a considerar para la implementación de software
tomaremos como referencia a Pressman en la cual se refiere a la calidad del software
como “La concordancia con los requisitos funcionales y de rendimientos explícitamente
establecidos, estándares de desarrollo explícitamente documentados y características
implícitas que se espera de todo software desarrollado profesionalmente” (Estayno,
Dapozo, Cuenca Pletch, & Greiner, 2017, pág. 78).
Los puntos que se debe conocer al evaluar el software son:
 Tipo de aplicación se va a evaluar.
 La metodología de desarrollo.
 La calidad del desarrollo.
2.16 Modelos de calidad de Software
Los modelos de calidad de software son un conjunto de factores que se encuentran
relacionados entre sí, con la finalidad de generar una base para especificar los requisitos
de calidad y realizar una evaluación de la calidad de los componentes de un software, ya
sea este un software a la medida o uno genérico.
Con el uso de los modelos de calidad se busca mejorar la construcción de los
productos. Los modelos de calidad por lo general descomponen el software en
características y sub características de forma jerárquica, donde se les da una calificación

23
y de esta manera poder evaluar los aspectos relacionados a la calidad. Definir este tipo
de modelos es en cierta manera complejo, pero se tiene ventajas como:
 Medición de un producto de software.
 Definición de un producto de software.
 Productos de Software medidos de manera concreta.
2.16.1 Características de los modelos de Software
La norma ISO/IEC 9126 abarca 6 atributos clave para la medición de cualquier tipo
de software, con sus respectivas categorías como se muestra a continuación:
 Funcionalidad. - El software debe satisfacer los requisitos funcionales, sus
características son: adaptabilidad, exactitud, interoperabilidad y seguridad.
 Usabilidad. - El software debe poder ser usado, entendible y fácil de usar por los
usuarios, sus características son: comprensibilidad, aprendizaje y operatividad.
 Mantenimiento. - Es como el software puede ser corregido o cambiado una vez
puesto en producción, sus características son: análisis, estabilidad, cambio y
pruebas.
 Confiabilidad. - Es como el software mantiene el desempeño durante el tiempo,
sus características son: eficiencia y portabilidad
 Eficiencia. - Es como el software mantiene su rendimiento óptimo sin tender a
deteriorarse durante el tiempo, sus características son: comportamiento óptimo a
través del tiempo, uso de los recursos.

24
 Portabilidad. - El software debe permitir ser migrado en caso de emergencia de
un computador a otro sin perder ninguna de las anteriores métricas nombradas,
sus características son: Adaptación, Instalación, Coexistencia y Reemplazo.
2.16.2 Modelos de McCall
Este modelo fue desarrollado por McCall, Richards y Walters en 1977, McCall junto con
sus compañeros presentaron un esquema de medición de software el cual se centra en
las características operativas la capacidad de cambio y la adaptabilidad a cambios de
entornos. El esquema presentado se basa en una escala de puntuación desde 0
(puntuación más baja) al 10 (puntuación más alta) donde se emplean varias de las
métricas nombradas en la ISO/IEC 9126 (David, 2013, p. 98).
A continuación, se muestra la relación entre factores de calidad y métricas de la calidad
de software, donde el peso a ser asignado a cada métrica de software dependerá de la
empresa y los productos locales.

25
Tabla 1
Relación entre Factores de calidad y métricas de la calidad de software
Factor Criterio
Rastreabilidad
Correctitud Completitud
Consistencia
Consistencia
Confiabilidad Exactitud
Tolerancia a fallas
Eficiencia de ejecución
Eficiencia
Eficiencia de almacenamiento
Control de acceso
Integridad
Auditoría de acceso
Operabilidad
Usabilidad
Entrenamiento y Comunicación
Modularidad
Interoperabilidad Similitud de comunicación
Similitud de datos.
Simplicidad
Mantenibilidad
Concreción
Simplicidad
Instrumentación
Capacidad de Prueba
Auto-descriptividad
Modularidad
Auto-descriptividad
Flexibilidad Capacidad de expansion
Generalidad
Auto-descriptividad
Portabilidad Independencia del Sistema
Independencia de máquina
Auto-descriptividad
Reusabilidad Generalidad
Independencia del Sistema
Fuente: (Fenton, 1991)
26
Al modelo de McCall se lo pude identificar en la Tabla 2, la cual consta de 3 ejes
desde la cual se puede medir la calidad del producto, esta se basa en sus factores de
calidad con sus respectivas características
Tabla 2
Factores y Características del Modelo de McCall
Puntos
de vista Factor Caracteristicas
o Ejes
- Facilidad de operación.
- Facilidad de comunicación. Entradas
Facilidad de uso
- Facilidad de aprendizaje.
- Formación.
- Control de accesos.
OPERACIÓN DEL PRODUCTO
Integridad - Facilidad de auditoría.

- Seguridad.
- Completitud.
Corrección - Consistencia.
- Trazabilidad o rastreabilidad
- Precisión.
- Consistencia.
- Tolerancia a fallos.
Fiabilidad
- Modularidad.
- Simplicidad.
- Exactitud
- Eficiencia en ejecución.
Eficiencia - Eficiencia en almacenamiento.
CONTINÚA
27
Puntos
de vista Factor Caracteristicas
o Ejes
- Modularidad.
- Simplicidad.
Facilidad de
- Consistencia.
REVISIÓN DEL PRODUCTO
mantenimiento
- Concisión.
- Auto descripción.
- Modularidad.
Facilidad de - Simplicidad.
prueba - Auto descripción.
- Instrumentación.
- Capacidad de expansión.
Flexibilidad
- Generalidad.
- Modularidad.
- Generalidad.
TRANSICIÓN DEL PRODUCTO
Reusabilidad - Modularidad.
- Independencia entre sistema y software.
- Independencia del hardware.
- Modularidad.
- Compatibilidad de comunicaciones.
Interoperabilidad
- Compatibilidad de datos.
- Estandarización en los datos.
- Modularidad.
Portabilidad
- Independencia entre sistema y software.
- Independencia del hardware.
Fuente: (Constanzo, 2014)
Para usar el modelo de McCall, se debe aceptar los factores, criterios y métricas
del modelo, así como sus relaciones (factores- criterios y criterios - métricas); también se
28
debe seleccionar el subconjunto de factores de calidad sobre los que se aplicará los
requerimientos de calidad determinados para el proyecto.
Se debe seleccionar los aspectos de calidad deseados en el producto de software
para lo cual hay que considerar:
 Características del producto que se va a diseñar.
 La relación entre calidad y precio la cual se evalúa dependiendo el costo de cada
factor de calidad frente a su beneficio, esto se lo puede apreciar en la tabla 3.
 Evaluar los factores de calidad a usar para verificar cuales poseen efectos de
calidad bajos.
 Verificar las diferentes relaciones de los factores de calidad para que no entren en
conflicto entre sí.
Tabla 3
Costo – Beneficio de los Factores de Calidad
Factor Costo /Beneficio

Corrección Alto
Fiabilidad Alto
Eficiencia Bajo
Integridad Bajo
Facilidad de uso Medio
Facilidad de Mantenimiento. Alto
Facilidad de prueba Alto
Flexibilidad Medio
Portabilidad Medio
Reusabilidad Medio
Interoperabilidad Bajo
Fuente: (Constanzo, 2014)
29
En la fase de desarrollo se deberá usar las métricas elegidas, posteriormente
analizar los resultados y tomar medidas de corrección cuando los valores se encuentren
en un límite inferior de los valores mínimos aceptables.
Cuando se haya terminado el proyecto se debe verificar las medidas utilizadas y
justificar si es que se pueden usar como indicadores de valores finales.
2.16.2 Modelos de BOEHM
Barry Boehm propuso un modelo en el año de 1978 y se define la calidad de
software en términos de atributos cualitativos y métricas para realizar las medidas.
El modelo está basado en que el software debe realizar las actividades que el
usuario solicita utilizando los recursos del hardware de manera eficiente, además de que
el software debe ser fácil de usar por los usuarios, debe ser testeado y diseñado de
manera óptima y los técnicos deben poder realizar mantenimiento fácilmente.
El modelo consta de una estructura jerárquica que consta de 3 niveles:
- Nivel Alto
- Nivel Medio
- Nivel Primitivo
30
Figura 1. Modelo de Boehm

Fuente: (Fillottrani, 2007)
31
El modelo de Boehm también cuenta con una tabla de relación entre los factores y
criterios de calidad:
Tabla 4
Relación entre los factores y criterios del Modelo de Boehm
Facilidad
Facilidad de
FACTOR Portabilidad Confiabilidad Eficiencia Usabilidad de
Compresión
Prueba
CRITERIO
Independencia X
Completitud X X
Exactitud X
Consistencia X
Eficiencia X
Accesibilidad X X X
Comunicatividad X X
Estructuración X X
Auto
descriptividad X X
Concisión X
Legibilidad X
Expansividad X
2.16.3 Modelo FURPS
Este modelo fue desarrollado por Hewlett-Pacarkd en 1987, FURPS son las siglas
de 5 factores de calidad, cada uno de esos factores con atributos, el modelo de calidad
se aplica al desarrollo de software.
Los factores de calidad que comprende FURPS son:

32
 Funcionabilidad (Functionality)
 Usabilidad (Usability)
 Confiabilidad (Reliability)
 Prestación (Performance)
 Soporte (Supportability)
En la siguiente figura se puede apreciar los tipos de requerimientos y características
del modelo:
Tabla 5
Modelo de FURPS
Tipo de
Sigla Descripción
requerimiento
Características, capacidad
F Funcional y algunos aspectos de
seguridad.
Factores Humanos, ayuda,

U Facilidad de uso
documentación.
Frecuencia de fallos,
capacidad de recuperación
R Fiabilidad
de un fallo y grado de
previsión.
Tiempos de respuesta,
productividad, precisión,
P Rendimiento
disponibilidad, uso de los
recursos.
Adaptabilidad, facilidad de
mantenimiento,
S Soporte
internacionalización,
facilidad de configuración.
Fuente: (Eeles, 2014)
33
2.16.4 Modelo de DROMEY
El modelo de Robert Dromey indica que la calidad del producto está dada por la calidad
de sus componentes, es un modelo de calidad a medida, resalta el hecho de que la
calidad del producto es altamente determinada por los componentes del mismo
(incluyendo documentos de requerimientos, guías de usuarios, diseños y código)
(Rodriguez Perez, 2014, pág. 76).
El modelo define factores y criterios, sugiere el uso de cuatro categorías que implican
propiedades de calidad:
 Correctitud.
 Factores internos.
 Factores contextuales.
 Factores descriptivos.
La correctitud se expresa por los criterios de:
a) Funcionalidad.
b) Confiabilidad.
Los factores internos se expresan por los criterios de:
a) Mantenibilidad.
b) Eficiencia.
c) Confiabilidad.
Los factores contextuales se expresan por criterios de:
a) Mantenibilidad.
34
b) Reusabilidad.
c) Portabilidad.
d) Confiabilidad.
Los factores descriptivos se expresan por criterios de:
a) Mantenibilidad.
b) Reusabilidad.
c) Portabilidad.
d) Usabilidad.
El modelo de Dromey cuenta con una tabla que relaciona las características de la
calidad con la norma ISO 9126-1, el mismo que es utilizado para evaluar un producto de
software mediante las características del producto con los atributos de alto nivel. En la
siguiente tabla se puede observar lo indicado:
Tabla 6
Matriz Modelo de Dromey
Para usar el modelo de Dromey se puede seguir los siguientes pasos:
1. Seleccionar el conjunto de atributos que se necesitan evaluar.
2. Realizar una lista de todos los componentes o módulos del sistema.

35
3. Identificar las propiedades de calidad de cada componente.
4. Determinar cómo afecta cada propiedad en los atributos de calidad.
5. Evaluar el modelo de calidad.
2.16.5 Modelo C-QM (Checking Quality Model)
El modelo C-QM es una metodología para evaluar la calidad interna del software
el cual cuenta con un indicador único para característica del software (cambios,
ampliación, nuevo proyecto, etc.) el mismo que permite tener un nivel detallado de las
características de calidad del software.
Este modelo se basa en factores de calidad, en criterios y métricas como se lo puede
apreciar a continuación:
Tabla 7
Factores, Criterios y Métricas del Modelo C-QM
FACTOR CRITERIO METRICA

Adaptabilidad Métrica para la adaptabilidad
Funcionaliad Integridad Métrica para la integridad
Similidud Métrica para la similitud
Modularidad Métrica para la modularidad
Construido según
Reusabilidad
especificaciones Métrica para personalización
Comprensión Métrica para Exhaustividad
Modularidad Métrica para la modularidad
Facilidad de Carácter abstracto Métrica para la abstracción de la interfaz
Mantenimiento
Facilidad de cambio Métrica para el cambio
Conformidad estándar Métrica para la conformidad estándar
Conformidad Métrica para la conformidad del modelo de
Conformidad respecto al
modelo de referencia referencia
Fuente: (González, André, & Hernández, 2005)
36
Principios del C-QM
Basado en el estándar ISO 9126 ISO9126 es una norma de calidad de los
productos de software. Define todas las características importantes de calidad de
software para evaluar en un proceso de calidad. Es bien conocido por la comunidad, lo
que permite que todo el mundo habla el mismo idioma.
Con el modelo estructurado de Capa C-QM se puede obtener un indicador único por
unidad de software (aplicación, proyecto, solicitud de cambio, etc.), pero se puede
profundizar. En el primer nivel se mostrará un indicador para cada característica de
software C-QM (seguridad, fiabilidad, eficiencia, mantenibilidad y portabilidad). El
siguiente nivel contiene los indicadores técnicos, que dividieron a la evaluación en cada
una tecnología que hace que su unidad de software (Kiuwan, 2016, p. 89).
Beneficios de utilizar C-QM
1. Resumen de la capa técnica. La información de calidad será independiente de
lenguajes y plataformas programáticas.
2. Comparar diferentes versiones del mismo software. Esto responde a la pregunta
más importante: ¿se ha mejorado el software?
3. Comparación de la calidad de diferentes aplicaciones. No importa si son los
diferentes tipos de aplicaciones o que se desarrollan en diferentes tecnologías.
4. Evaluar los requisitos técnicos con el fin de aceptar el software de un proveedor
de terceros.
37
5. Agregaciones de datos. Se puede agregar la información de calidad de diferentes
aplicaciones con el fin de obtener una evaluación del software producido por un
proveedor, un país o área de TI en comparación con otros.
6. Proceso de mejoramiento continuo. Se puede aplicar una metodología de control
de calidad en su proceso de ciclo de vida del software (Kiuwan, 2016, p. 89).

38
CAPÍTULO III
DEFINICIÓN DEL MODELO Y LA METODOLOGÍA A APLICAR EN LA SELECCIÓN
DEL SOFTWARE
3.1 Introducción
Previo a definir un modelo y una metodología se continúa con el análisis de los
modelos de calidad y las normas ISO, estas últimas son estándares que dan las pautas
necesarias para la selección del software. Otro punto importante de esta definición son
las métricas las cuales permitirán a través de indicadores evaluar el software que se
piensa adquirir o incluso evaluar un software adquirido para contar con una auditoria que
indique el estado del software.
Al hablar de calidad de software se indica la base fundamental sobre la cual se
desarrolla o implementa un software con el propósito de que pueda cumplir el objetivo
para el cual se está seleccionando el producto.
3.2 Análisis de modelos de calidad
A continuación, se tiene la tabla # 8 donde se muestran las características de
calidad (atributos claves) planteadas en todos los modelos de calidad, posteriormente se
procede a colocar una X donde dicha característica es aplicable al modelo mostrado en

39
las columnas superiores y finalmente se realiza un análisis de ocurrencias de
características de modelos de calidad.
Tabla 8
Análisis de Modelos de Calidad
Modelo Modelo Modelo Modelo Modelo
Características de Calidad
Boehm Dromey McCall FURPS C-QM
Facilidad de uso X X X
Integridad X
Corrección X
Confiabilidad X X X X
Eficiencia X X X
Facilidad de mantenimiento X X X X
Facilidad de prueba X X
Flexibilidad X
Facilidad de reutilización X X
Interoperabilidad X
Portabilidad X X X
Ingeniería humana X
Fácil de entender X
Fácil de modificar X
Funcionalidad X X X
Performance X
Facilidad del soporte X
Conformidad X
Fuente: (Jorge Arturo Reinoso Espinosa, 2018)
3.3 Análisis de ocurrencias
Las ocurrencias acumuladas de cada característica de calidad se resumen en la
siguiente tabla:
40
Tabla 9
Análisis de Ocurrencias de las características de los modelos de calidad de software
Características de Calidad Ocurrencias
Confiabilidad 4
Facilidad de uso 3
Eficiencia 3
Facilidad de mantenimiento 3
Portabilidad 3
Funcionalidad 3
Facilidad de prueba 2
Facilidad de reutilización 2
Integridad 1
Corrección 1
Flexibilidad 1
Interoperabilidad 1
Ingeniería humana 1
Fácil de entender 1
Fácil de modificar 1
Performance 1
Facilidad del soporte 1
Conformidad 1
Como se puede observar en la tabla 9 de análisis de ocurrencias, las
características de calidad más comunes entre los modelos analizados Modelo Boehm,
Modelo Dromey, Modelo McCall, Modelo FURPS, Modelo C-QM son Confiabilidad,
Facilidad de uso, Eficiencia, Facilidad de mantenimiento, Portabilidad, Funcionalidad.
Para este análisis, estas características de calidad son las planteadas en la ISO/IEC
9126-1:2001.
41
La norma ISO/IEC 9126-1:2001 en el ámbito de la calidad de producto de software
consta con 6 características de calidad tanto interna y externa, las mismas que contienen
sub características.
La característica externa es aquella que evalúa al software para que cumpla las
necesidades del usuario teniendo en cuenta las condiciones especificadas para su
creación.
La característica interna es aquella que evalúa todos los atributos del software
teniendo en cuenta las condiciones especificadas para su creación.
Estas características pueden ser aplicadas a cualquier tipo de software, obteniendo una
terminología equilibrada en lo que se refiere a la calidad del producto de software
En la siguiente figura se puede apreciar la clasificación de la calidad externa e
interna:
42
Figura 2. Características y sub características de la calidad interna y externa

Fuente: (Garcia & Mazo, 2005)
43
3.3.1 Funcionalidad
La funcionalidad significa cuantas posibilidades provistas tiene un software.
Cuando un líder de proyecto es asignado a un proyecto de software, debe estar en la
capacidad de dimensionar cuanta funcionalidad va a tener el sistema informático. Esto
debido a que los clientes que requieren de la construcción de software siempre están
solicitado requerimientos o funciones de una manera desmedida y las consecuencias de
complacer dichos requerimientos pueden ser muy malas para proyectos internos y
catastróficos para productos comerciales.
Este tipo de requerimientos causa dos tipos de problemas:
El problema fácil, es cuando el software pierde consistencia debido al aumento de
funciones viéndose perjudicada la facilidad de uso. La solución es trabajar en un producto
consistente tratando de cumplir la mayoría de requerimientos en ideas globales. La idea
de realizar un software de calidad es que debe estar basado en un conjunto reducido de
buenas ideas.
El problema difícil es cuando en la construcción del software se enfocan
demasiado en “adornos” y se olvidan de otros factores de calidad. Ocurre en muchos
desarrollos de sistemas informáticos donde se ha querido agregar demasiadas funciones
innecesarias al sistema, perdiendo calidad y haciendo que los programadores tengan

44
muchos días de trabajo arduo tratando de arreglar los problemas de código desgastando
y disminuyendo su productividad.
La solución es enfatizar todos los factores de calidad antes de apresurarse a
realizar una nueva característica o “adorno”, de tal manera que se mantenga el nivel de
calidad en todos los aspectos del proyecto y solo avanzar en nuevas funciones cuando
las anteriores ya estén maduras.
3.3.2 Confiabilidad
La confiabilidad también es nombrada como fiabilidad y está definida como la
probabilidad de que un software realice su trabajo satisfactoriamente y sin fallos en un
determinado periodo de tiempo y en un entorno especifico. La confiabilidad es una
característica muy importante ya que, si un programa contiene fallos concurrentes en su
funcionamiento, no importara si es que cumple a cabalidad todo el resto de factores de
calidad, el sistema no podrá funcionar de manera correcta y por ende no será un software
de calidad.
Una de las ventajas de la confiabilidad con respecto a otros factores de calidad es
que esta puede ser medida mediante datos históricos.
Cuando se habla de una falla en sistema o de un fallo en el software se refiere a
errores de código o falta de concordancia con los requisitos planteados en la solicitud del
programa. Pueden existir fallos que se pueden corregir en minutos mientras que otro tipo
de fallos puede durar días o meses incurriendo en la producción de más fallos que
degraden el sistema.
45
Los tipos de fallos del software pueden ser por dos tipos:
 Por problemas de diseño.
 Por problemas de implementación.
Los modelos de fiabilidad del software pueden ser de dos tipos:
 Modelos que pronostican la fiabilidad como una función cronológica del tiempo
(calendario).
 Modelos que pronostican la fiabilidad como una función del tiempo de
procesamiento transcurrido (tiempo de ejecución de CPU).
3.3.3 Facilidad de Uso
La facilidad de uso hace referencia a que tan fácil es usar el software para los
usuarios y con qué rapidez lo pueden usar para resolver problemas, también se incluye
la facilidad de instalación, operación y monitoreo.
Los diseñadores de software tienen que pensar en cómo proveer de información
de calidad a los usuarios principiantes y como no aburrir a los expertos, es aquí cuando
entran los diseñadores de interfaz de usuario los cuales deben diseñar el software de
manera interactiva, suponiendo que los usuarios van a leer, mover un mouse y dar clics
en las diferentes opciones del software.
Actualmente se debe construir software que este más centrado en el usuario y
menos centrado en el desarrollador, debido a que existe un mercado competitivo en el
cual se están destinando más recursos para contratar personal dedicado al desarrollo de
46
interfaces amigables al usuario. Las empresas que no construyan un software que sea
fácil de usar por el usuario, corren mucho riesgo de quebrar ya que pueden perder
valiosos clientes.
3.3.4 Eficiencia
La eficiencia hace énfasis a como el software utiliza lo menos posible los recursos
de hardware como tiempos de uso del procesador, uso de memoria, uso de disco duro,
uso de ancho de banda, etc., la eficiencia es igual a la velocidad de ejecución de un
determinado proceso ejecutado por el software.
Si el software es eficiente, este realizará un uso óptimo de los recursos del
hardware y si es ineficiente consumirá demasiados recursos.
El uso de la eficiencia se lo mide en:
 Tiempo de ejecución en el CPU.
 Tiempo de uso de memoria principal.
 Tiempo de uso de memoria secundaria.
 Tiempo de uso de canales de entrada y salida.
 Velocidad de ejecución.
 Tiempo de respuesta.
47
Cuando los programadores se encuentran desarrollando el software, relacionan el
desempeño del software con la eficiencia y es aquí donde los desarrolladores toman dos
aspectos:
 Ciertos desarrolladores toman el asunto del desempeño como una obsesión,
llevándolos a dedicar mucho tiempo en realizar tareas innecesarias en
optimización.
 Otro tipo de desarrolladores ignoran por completo los aspectos de eficiencia, lo
cual hace que el software se vea afectado en rendimiento, alegando que “el
hardware que lo ejecute en un siguiente año será más rápido que el actual”.
3.3.5 Facilidad de Mantenimiento
La facilidad de mantenimiento hace referencia a la facilidad con la cual se puede
corregir errores de código en el software, siendo esta actividad la que más esfuerzo
representa en la ingeniería de software.
Los errores no solo son por parte del código del software, sino que también se los
ve reflejados por errores de levantamiento de requerimientos, cambios de entorno,
cambios de requisitos de clientes entre otros.
La métrica en la facilidad de mantenimiento es el tiempo medio entre cambios, el
cual consta de analizar el cambio solicitado o necesitado por el software para
posteriormente diseñar una modificación, luego implementar dicha modificación, hacer
pruebas y proceder con el paso a producción del cambio.

48
Para el software que tenga un nivel de facilidad de mantenimiento alto, le tomara
muy poco tiempo el realizar los cambios solicitados mientras que los que tengan un nivel
bajo, les tomara mucho más tiempo el aplicar dichos cambios.
3.3.6 Portabilidad
La portabilidad refiere a como se puede trasladar el software a diferentes entornos
de hardware y software (arquitecturas 32 y 64 bits).
El software puede ser construido en máquinas con grandes capacidades y
características en lo que es hardware y software, pero hay que tomar en cuenta que
muchos de los clientes finales no dispondrán de computadores con buenas
características.
Es por eso que el software debe disponer de un manual donde se indique las
características básicas en hardware y software en las que se puede ejecutar.
3.3.7 Procesos importantes de la norma ISO/IEC 12207:2008
De la norma ISO/IEC 12207:2008, hay que tomar en cuenta dos procesos importantes
para uso y aplicación del presente documento son:
 Proceso de adquisición
 Proceso de suministro
49
3.3.7.1 Proceso de Adquisición.
El proceso de adquisición contiene las actividades y las tareas del adquiriente. El proceso
comienza con la identificación de la necesidad de adquirir un sistema, un producto
software o un servicio software. El proceso continúa con la preparación y publicación de
una solicitud de propuestas, la selección de un proveedor y la gestión del proceso de
adquisición hasta la aceptación del sistema, del producto software o del servicio software
(SlideShare, 2006, págs. 17-18).
Todo el proceso para adquirir software tiene actividades que deben ser cumplidas
para que las partes que intervienen en la adquisición de software lleguen con acuerdos
que permita tener un producto de calidad.
En este proceso existe un adquiriente y un proveedor, cada uno con sus equipos
de trabajos que son los encargados de gestionar por su lado las necesidades del proyecto
de acuerdo al requerimiento inicial que es la necesidad del software para un objetivo.
El adquiriente debe tener muy claras las características requeridas del producto,
no puede darse por sentado que un software referido tiene las mejores características
para un negocio, así como un proveedor no puede dar por sentado que tiene el mejor
software hasta que no sea evaluado por el adquiriente.
Entonces es deber de cada parte una vez iniciado un proceso de adquisición gestionar
algunas actividades que nos llevan a determinar si la solución de software propuesta es
la más acertada para la necesidad generada en el entorno de la empresa, para entender
la norma y los pasos que contiene se revisa las actividades de la norma técnica ISO/IEC
50
12207:2008 que está compuesta de las siguientes actividades: (SlideShare, 2006, págs.
17-18).
a) Inicio.
b) Preparación de la solicitud de las propuestas.
c) Preparación y actualización del contrato.
d) Seguimiento del proveedor.
e) Aceptación y finalización.
Estas actividades se comprenden de mejor manera en la siguiente figura:

51
Figura 3. Proceso de Adquisición

52
3.3.7.2 Proceso De Suministro
El proceso de suministro contiene las actividades y tareas del proveedor. El
proceso se puede iniciar ya sea por la decisión de preparar una oferta para contestar una
solicitud de propuestas de un adquiriente, o por la firma e inicio de un contrato con el
adquiriente para proporcionarle un sistema, producto software o servicio software. El
proceso continúa con la determinación de los procedimientos y recursos necesarios para
gestionar y asegurar el proyecto, incluyendo la preparación y ejecución de los planes del
proyecto hasta la entrega al adquiriente del sistema, producto o servicio software.
(SlideShare, 2006, págs. 17-18)
En la siguiente figura se puede visualizar el proceso de suministro:

53
Figura 4. Proceso de suministro

54
El proceso de adquisición y suministro se convierten en partes necesarias de la
metodología, en el proceso de adquisición en el punto de evaluación de cumplimiento de
condiciones se validan las características de calidad que debe cumplir el software, con el
uso de las métricas se establecen parámetros válidos que nos dan las pautas para
seleccionar el software, es decir debe cumplirse los valores mínimos para continuar en el
proceso, si no se cumple un determinado valor se debe dar por finalizado el proceso y
continuar con la validación de otras propuestas, claro está a menos que el proveedor
pueda ajustarse a los requerimientos y pueda ser validado otra vez por la metodología y
sus características de calidad.
3.3.8 Algoritmo para la aplicación del modelo de para la Gestión de la Adquisición
de Software Comercial (Erp) para las Pymes del Sector Privado de la ciudad de
Quito.
Una vez realizado el análisis respectivo de los modelos de calidad de software se
obtuvo como resultado que las características de calidad más importantes entre los
modelos Boehm, Modelo Dromey, Modelo McCall, Modelo FURPS, Modelo C-QM son
Confiabilidad, Facilidad de uso, Eficiencia, Facilidad de mantenimiento, Portabilidad,
Funcionalidad.
55
Comparando todas las normas ISO relacionadas al desarrollo o implantación de
Software se obtuvo que en la norma ISO/IEC 9126-1:2001 aplica las mismas 6
características de calidad antes mencionadas.
Para complementar el algoritmo de aplicación del modelo se tomará los procesos
de Adquisición y suministro de la norma ISO/IEC 12207:2008.
3.3.9 Análisis de Métricas
Las métricas a emplear se basan en el análisis de los modelos de calidad, los
cuales de acuerdo a las características más importantes permiten establecer un cuadro
de validación.
Para establecer un rango válido de las métricas a aplicar se establece los rangos tomando
como referencia las métricas de producto: “Una métrica debe tener propiedades
matemáticas deseables” (Pressman, 2010, pág. 529).
Para el desarrollo de métricas es necesario establecer los puntos que se van a medir,
las medidas que se van a tomar en cuenta en este proceso son las relacionadas a las
métricas de calidad del software:
 Funcionalidad: ¿Cumple los requerimientos de funcionalidad internos y externos
el software?
 Usabilidad: ¿El software está desarrollado de forma interactiva, es fácil para el
manejo del usuario?

56
 Mantenimiento: ¿El software es de fácil mantenimiento ante nuevos
requerimientos o correcciones a su código fuente?
 Confiabilidad: ¿El software es confiable en el desarrollo de su trabajo en las
actividades diarias?
 Eficiencia: ¿El sistema usa correctamente los recursos del hardware?
 Portabilidad: ¿Es fácil el cambio entre hardware de mayor o menor capacidad o
sistema operativo para su ejecución?
Y a los dos procesos de mayor importancia en la compra de un software:
Adquisición
Requerimientos de software
¿Se han elaborado los requerimientos del software necesario en base a los
requerimientos de la institución?
Publicación de propuestas
¿Se realizó las publicaciones para recibir propuestas de proveedores?
Selección de proveedor
Se debe validar que el software del proveedor cumpla con:
1. Requerimientos del producto.
2. Documentación disponible.
3. Derechos de marca y garantías.
4. Mantenimiento futuro del software.

57
Gestión de adquisición
En el proceso de adquisición se debe verificar:
1. Que se cumpla con los requerimientos del sistema.
2. Se valide el tipo de contrato a utilizar.
3. Debe existir un tipo de soporte una vez instalado el producto.
Suministro. - En este punto se evalúan los temas relacionados al ciclo de vida del
software, temas de calidad, documentación y riesgos.

58
Tabla 10
Métricas del modelo de calidad
GUÍA DE OBSERVACIÓN
PUNTOS A VALORACIÓN
No. Descripción
OBSERVAR 0A1
Funcionalidad Métrica de calidad
Realizar adecuadamente cierta actividad, función o
1 Aptitud
servicio
Capacidad del software de acercarse al valor de la
2 Exactitud
magnitud real
Capacidad de módulos al compartir datos e intercambiar
3 Interoperabilidad
información y conocimiento
Seguridad de Proteger los datos sensibles mediante encriptación o
4
acceso contraseñas
TOTALES
VALORACIÓN
No. PUNTOS A OBSERVAR Descripción
0A1
Confiabilidad Métrica de calidad
Estado del sistema al alcanzar su
1 Madurez
desarrollo óptimo
Capacidad del sistema para
2 Tolerancia a fallos continuar con su funcionamiento
cuando algún componente
59
Capacidad de restaurar el sistema

3 Capacidad de recuperación hasta el momento en que se
produjo el error
Capacidad del sistema para poder
4 Disponibilidad usarse cuando se necesite, 24
horas 365 días del año
Capacidad del sistema para
5 Degradabilidad
descomponerse o degradarse
TOTALES
No. Descripción
OBSERVAR 0A1
Facilidad de uso Métrica de calidad
Capacidad para ser Facilidad con la que los usuarios comprenden el
1
entendido sistema
Capacidad para ser Facilidad con la que los usuarios aprenden el
2
aprendido sistema
Capacidad para ser
3 Facilidad con la que los usuarios usan el sistema
operado
Grado en el que el usuario se encuentra satisfecho
4 Satisfacción
con el sistema
Nivel con el que el sistema logra cumplir las metas y
5 Logro de la meta
necesidades del usuario
TOTALES
60
No. Descripción
OBSERVAR 0A1
Eficiencia Métrica de calidad
Eficiencia con
1 Qué tan rápido es el sistema para ejecutar cálculos
respecto al tiempo
El sistema consume altos niveles de recursos de
2 Utilización de recursos
hardware
TOTALES
No. Descripción
OBSERVAR 0A1
Facilidad de
Métrica de calidad
mantenimiento
Capacidad para ser Con que facilidad pueden los programadores
1
analizado analizar el código para un buen entendimiento
Capacidad para ser Capacidad para cambiar el software si es que
2
cambiado solicita el cliente o el negocio
Capacidad para funcionar sin fallos por largos
3 Estabilidad
períodos de tiempo
Capacidad para ser Capacidad para realizar pruebas de cambios
4
probado antes de paso a producción
TOTALES
61
No. Descripción
OBSERVAR 0A1
Portabilidad Métrica de calidad
Qué tan facil es adaptar el sistema ante
1 Adaptabilidad
cambios del sistema operativo
2 Facilidad de instalación El sistema es fácil de instalar o no
El sistema es parecido o tiene similitud con
3 Conformidad
otros sistemas en el mercado
4 Facilidad de reemplazo El sistema es fácil de ser reemplazado o no
VALORACIÓN
No. PUNTOS A OBSERVAR Descripción
0A1
Adquisición Proceso
Se han elaborado los requerimientos del
1 Requerimientos de software software necesario en base a los
requerimientos de la institución
Se realizó las publicaciones para recibir
2 Publicación de propuestas
propuestas de proveedores
El software del proveedor cumple con los
Selección de proveedor
requerimientos del producto
El software del proveedor tiene documentación
disponible
El software del proveedor tiene derechos de
marcas y garantías
3
El software del proveedor ofrece mantenimiento
futuro
Se cumple con los requerimientos del sistema
Se validó el tipo de contrato a utilizar
Existirá un tipo de soporte una vez realizada la
instalación
Suministro
El proveedor ha definido un modelo de ciclo de
1
vida para el software
62
El proveedor ha generado el plan de

instalación, cronograma con fechas y
entregables
El proveedor ha generado un contrato válido
con los puntos necesarios que den las
garantías necesarias a la instalación del
software
El proveedor ha definido los intervinientes para
el proyecto
El proveedor ha definidio un plan para
documentar y gestionar los requerimientos
El proveedor ha definido el plan para el
aseguramiento de la calidad
El proveedor ha identificado los riesgos
potenciales del proyecto
TOTALES
63
Las tablas anteriores indican cada uno de los atributos a ser evaluados, se observa
que existe valores que se pueden asignar (entre 0 y 1), siendo el número 0 el puntaje
más bajo y el número 1 como el valor con más alto puntaje del atributo.
Los valores están definidos en la siguiente tabla:
Tabla 11
Tabla de rangos válidos de la métrica
Medida Descripción Observaciones

No cumple las
< 0.5 No aceptable características
establecidas.
Cumple la mitad de
Entre 0.5 y <0.75 Medio
las características.
Cumple todas las

>= 0.75 a 1 Aceptable
características.
Luego de obtener la puntuación para cada atributo hay que aplicar lo que establece
la siguiente formula de evaluación de calidad de software, que viene dado por la
sumatoria de todos los valores evaluados de cada uno de los atributos de las
características de calidad, dividido para el numero de atributos a ser evaluados por 100:
∑ 𝑉𝑎𝑙𝑜𝑟𝑒𝑠 𝑒𝑣𝑎𝑙𝑢𝑎𝑑𝑜𝑠 𝑝𝑜𝑟 𝑎𝑡𝑟𝑖𝑏𝑢𝑡𝑜

𝐶𝑎𝑙𝑖𝑑𝑎𝑑 𝑑𝑒 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = ( ) 𝑥 100
𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑎𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 𝑒𝑣𝑎𝑙𝑢𝑎𝑑𝑜𝑠
Después de ser aplicada la formula se obtendrá valores en porcentaje que oscilará
entre 0% y 100%.
64
El porcentaje de características cumplidas dan la pauta necesaria para aceptar el
producto, es decir que pueda ser asumido por el cliente o rechazado, es importante
destacar como identificar si el producto es aceptado o rechazado, para esto se usará el
modelo MOSCA.
El modelo MOSCA (Modelo Sistemático de Calidad) es un prototipo desarrollado para
evaluar la calidad de los sistemas de software, este modelo se basa en dos modelos:
Calidad del producto y Calidad del proceso, en los cuales se debe cumplir con un valor
mínimo del 75% para que sea un producto de calidad. (Luis E. Mendoza, 2004).
La metodología del presente trabajo tiene mucha relación con el modelo MOSCA,
por tal motivo se toma como base fundamental para determinar el porcentaje mínimo
requerido para aceptar el software que se está adquiriendo (75%).
El resultado obtenido de cada uno de los atributos debe ser normalizado para
obtener el resultado final y tomar la decisión correcta con respecto al software.
Estos valores serán definidos de acuerdo a la siguiente tabla:

65
Tabla 12
Medidas y acciones para las métricas
Medida Descripción Observación Acción

No cumple las
Parar la validación,
< =50% No aceptable características
desechar la propuesta
establecidas.
Entre 0.5 y Cumple la mitad de Debe mejorar las

Medio
<0.75 las características. características propuestas.
>=75% y <= Cumple todas las Cumple las características

Aceptable
100% características. deseadas.
Los valores obtenidos en la ecuación de calidad de software hay que evaluarlos
junto con la tabla 12. La tabla 12 consta de:
Medidas. Valores a ser evaluados junto con la calificación obtenida en la ecuación
de calidad de software.
Descripción. Muestra si la calidad es aceptable, si la calidad se la puede mejorar
o definitivamente no es aceptable.
Observación. Una breve reseña sobre el significado de la descripción.
Acción. Es la acción a realizar después de haber sido evaluada la calificación
obtenida en la ecuación de calidad de software entre los rangos de las Medidas (Tabla
#12)
La aplicación de la tabla #12 busca cumplir con el 80% de las características de
calidad.
66
Ejemplo de evaluación de la métrica para la característica:
Funcionalidad, atributo: Aptitud.
La empresa XXX adquiere un software de ventas para inventario, la empresa
necesita que maneje multi bodega, varias listas de precios, transferencias de productos,
transferencias de bodegas, y facturación electrónica sin la dependencia de proveedores.
El requerimiento de la empresa es muy claro con respecto a ciertas características,
las cuales se puede observar en la siguiente tabla:
Tabla 13
Requerimiento de las empresas en métricas
Atributo
Métrica Valor evaluado
Aptitud
Multi Bodegas 0-1 1
Listas de
0-1 0.5
precios
Transferencias
0-1 1
de productos
Transferencias
0-1 1
de bodegas
Facturación
0-1 1
electrónica
Totales 5 4.5
Análisis del resultado: el 100% de la métrica está representando por 5 puntos, para
el caso se obtiene 4.5 puntos que corresponde al 90%. En este caso la métrica de la
característica de calidad (funcionalidad), si cumple con los valores de calidad de software.
En la figura #14 se encuentra el diagrama de flujo de funciones cruzadas donde
se puede apreciar el proceso a seguir para la evaluación de las características de calidad.

67
Figura 5. Proceso de Calidad

68
Figura 6. Proceso de Calidad

69
3.4. METODOLOGÍA PLANTEADA
La metodología que se define en el documento es el resultado del análisis de las
normas: ISO/IEC 9126-1:2001 en relación a la calidad y: ISO/IEC 12207:2008 en relación
a dos procesos importantes en la adquisición de software.
El modelo queda planteado indicando que la calidad es importante y es un requisito
necesario para seguir en el proceso de adquisición, como punto de control para la calidad
se definen las métricas estas entregan los valores necesarios que permiten identificar si
el software adquirido o por adquirir cumple los valores mínimos de la metodología 0.75.
Basando en el texto explicado de las normas, los procesos y las métricas; se define
la metodología “ACS” (Adquisición, Calidad y Suministro):
A: Proceso de Adquisición
C: Calidad.
1. Funcionalidad
2. Fiabilidad
3. Usabilidad
4. Eficiencia
5. Mantenibilidad
6. Portabilidad
S: Proceso de suministro
70
A continuación, se puede observar en la gráfica cómo evaluar el software a adquirir
con la metodología planteada.
Figura 7. Modelo ACS
Para aplicar este modelo ACS (Proceso de Adquisición, Métricas de Calidad,
Proceso de Suministro) debe existir la necesidad de adquirir un software, el modelo indica
que existe un proceso de adquisición (ISO/IEC 12207:2008), en este proceso existe un
sub proceso importante: Análisis de requerimientos:
El adquiriente definirá y analizará los requerimientos del sistema. Conviene que los
requerimientos del sistema incluyan requerimientos de negocio, organizativos, de
usuario, así como de seguridad física, junto con los procedimientos y normas de diseño,
pruebas y conformidad relacionados (SlideShare, 2006, págs. 17-18).

71
En la validación de requerimientos se debe indicar que uno de los principales es
la calidad, se hace mucho énfasis en la calidad porque es la garantía de funcionalidad
del producto (ISO/IEC 9126-1:2008), debe asegurarse que el producto a adquirir cumpla
los seis puntos definidos en la norma “ACS”.
Para evaluar la calidad se asigna valores a cada una de las características de las
métricas de calidad, las cuales indican los valores obtenidos en las pruebas, los puntajes
obtenidos indican si el software puede ser adquirido.
Para finalizar la aplicación del modelo definido ACS, se debe validar el proceso de
suministro, este proceso permite validar todos los puntos necesarios para la adquisición
del software, que debe cumplir el proveedor para entregar el producto final su seguimiento
y soporte futuro.
72
CAPITULO IV
PROPUESTA
4.1 Formulación del proceso de aplicación de la propuesta
4.1.1 Antecedentes
El levantamiento de la información para el desarrollo de la metodología a aplicar
se realizó en la empresa Química Comercial Cía. Ltda.
La empresa Química Comercial es una empresa que ha contribuido al país desde
el año 1980 entregando materias primas en plásticos. En el año 2007 incrementa su
producción con una nueva planta para producir plásticos en distintos colores
(masterbatch).
La empresa cuenta con certificación ISO 9001:2000, certificación obtenida en el
año 2004, en la actualidad cuenta con certificación ISO 9001:2008 por SGS.
La empresa en sus más de 30 años de servicio ofrece todo el asesoramiento
necesario a las empresas que requieren de sus productos, son líderes en los mercados
a los cuales sirve, actualmente cuenta con una oficina en Perú, Química Comercial es
una empresa en crecimiento que realiza operaciones y exportaciones.

73
4.1.2 Problemática actual
La empresa Química Comercial Cía. Ltda. realizó un cambio de software ya que el
anterior no satisfacía las necesidades de los procesos internos, no contaban con un
software que sean en línea con todos los módulos operativos, existían módulos
independientes que no se conectaban adecuadamente, ni reportes que permitan evaluar
la ejecución del sistema.
El software estaba desarrollado en plataforma obsoleta que no permitía tener el
crecimiento hacia donde está enfocada la Compañía.
Debido a los inconvenientes descritos la compañía decidió contratar el desarrollo
de un Software personalizado con el nombre GAFYC (Gestión Administrativa Financiera
y Contable), este sistema permite solventar las necesidades de crecimiento al contar con
una herramienta desarrollada con tecnología actual y dentro de las más usadas en el
mercado.
Con el modelo ACS se pretende analizar si el software GAFYC cumple con los
requerimientos necesarios de calidad que indica la norma desarrollada.
4.1.3 Levantamiento de la información
Para la aplicación de la metodología ACS se aplicó tres técnicas de investigación
para la recopilación y análisis de información.

74
4.1.3.1 Observación
En la observación se realizó dos visitas en las cuales se pudo validar dos casos:
a. Proceso operativo de los usuarios.
b. Consultas área gerencial.
Estos dos casos permitieron evaluar la instalación de la aplicación actual con las
tablas para validar la calidad del software y la calidad de los procesos de adquisición y
suministro.
4.1.3.2 Encuesta
La encuesta está enfocada a levantar información sobre nivel de satisfacción de
software la cual fue realizada a 5 personas que ocupan cargo de jefatura en la empresa
como son El Gerente General, Analista Financiero, Jefe de Producción, Jefe Operativo,
Jefe de Sistemas.
75
Encuesta
Preguntas:
1. ¿Cuenta con todos los reportes necesarios para su actividad diaria?
2. ¿Cuenta con los reportes necesarios que son solicitados por Gerencia General?
3. ¿Los reportes tienen que ser manipulados en Excel u otra herramienta antes de la
entrega al usuario final?
4. ¿Los archivos de texto que genera el sistema cumplen con las características
necesarias en base a los requerimientos iniciales?
5. ¿Las pantallas operativas tienen las ayudas necesarias para usuarios nuevos?
6. ¿Los resultados obtenidos en los reportes financieros son confiables?
7. ¿Necesita de reprocesos en la información cuando se detecta novedades?
8. ¿Es necesaria la intervención de personal de sistemas para realizar procesos de
cierre anuales?
9. ¿Todos los formatos pre impresos de la empresa han sido ajustados a las
necesidades?
10. ¿El software da la facilidad de actualizar datos con los respectivos controles de
auditoria?
4.1.3.3 Tabulación de la encuesta.
La encuesta como se mencionó anteriormente, se la realizó a 5 gerentes:

76
Resultados de la Encuesta
Figura 8. Pregunta Nro. 1
Análisis:
En la gráfica se observa que el 80% de los reportes se cumplen, quedando un 20%
sin cumplirse, en este punto se debe analizar si todos los reportes que se solicitaron se
crearon y si son nuevos reportes los que están generando que se obtenga el 20% de
faltante para llegar al cumplimiento total. En el caso de ser reportes solicitados en un
inicio se debe efectuar un control de acuerdo al proceso de calidad en el punto
requerimientos.
77
Análisis.
Se observa que se cumple con los reportes de Gerencia, es decir los
requerimientos iniciales para esta área fueron satisfechos.

78
Análisis.
Se observa que un 40% los reportes finales del sistema sufren cambios para ser
entregados, aquí conviene identificar si los cambios son por requerimientos nuevos para
esto debe asegurarse que el proceso de suministro en la característica gestionar los
requerimientos se apliquen para evitar manipulación en la información y en el caso de ser
solo por presentación de la misma manera gestionar las actualizaciones necesarias a los
reportes.
79
Análisis.
Se observa que un 20% de archivos de texto no cumplen las características, esto
se puede deber a cambios en los formatos solicitados es decir son obsoletos, para
corregir esta novedad se debe aplicar el proceso de suministro, gestionar los
requerimientos.
80
Análisis.
El 20% indica que todas las pantallas no cuentan con las ayudas necesarias, para
este efecto se debe validar que se cuente con todos los manuales actualizados, al ser
software desarrollado a medida los cambios realizados deben actualizarse en todos los
documentos de ayudas.
81
Análisis.
Existe un 80% de confianza en los reportes, esta debe ser una característica
cumplida al 100% las decisiones de la Compañía dependen de la información que se
procesa en el sistema. Para este caso se debe validar los reportes que no satisfacen la
confianza del usuario para analizar las entradas de la información y los procesos que se
efectúan sobre esta para detectar las novedades y aplicar las correcciones, esta actividad
se debe realizar aplicando el proceso de suministro gestionar los requerimientos.

82
Análisis.
El 60% de la información necesita reprocesos, se debe identificar cuál es el motivo
que genera los reprocesos de información, se observa que es un porcentaje alto lo que
indica que existe falla de usuarios, falla de sistema o fallas no controladas en la base de
datos.
83
Análisis.
El 20% indica que existen procesos que son ejecutados por personal de sistemas,
al ser un CRM debe tener procesos automatizados que no necesariamente requiera la
intervención de personal de sistemas, siendo solo necesarios en procesos de
administración de bases de datos y software, en procesos operativos no debe existir
manipulación por parte del equipo de TI.

84
Análisis.
Existe un 40% de formatos que no satisfacen la necesidad, se debe evaluar si son
nuevos requerimientos o requerimientos insatisfechos, en el caso de ser formatos
solicitados en un inicio se debe efectuar un control de acuerdo al proceso de calidad en
el punto requerimientos.
85
Análisis.
El 40% que no permite tener el control de auditorías debe ser ajustado para que
se guarde todos los cambios de información para esto se debe aplicar el proceso de
suministro gestionar los requerimientos para solucionar el inconveniente.

86
4.2. APLICACIÓN DEL MODELO ACS
A continuación, se muestra la evaluación del software GAFYC (Gestión
Administrativa Financiero y Contable) junto con las métricas y las descripciones de los
procesos internos de la empresa Química Comercial Cía. Ltda.
La evaluación viene dada por la definición los Procesos de Adquisición, Procesos
de Suministro, Procesos de Calidad, Métricas de Calidad y la fórmula de Calidad de
Software presentados en el capítulo 3.
4.2.1 Valoración del Proceso de Adquisición
Tabla 14
Valoración del Proceso de Adquisición
VALORACIÓN
No. Puntos a Observar Descripción
0 A1
Adquisición Proceso
¿Se han elaborado los requerimientos del
Requerimientos de
1 software necesario en base a los 0.9
software
requerimientos de la institución?
Publicación de ¿Se realizó las publicaciones para recibir
2 0.5
propuestas propuestas de proveedores?
¿El software del proveedor cumple con los
0.85
requerimientos del producto?
¿El software del proveedor tiene
0.9
documentación disponible?
¿El software del proveedor tiene derechos de
0
marcas y garantías?
Selección de ¿El software del proveedor ofrece
3 1
proveedor mantenimiento futuro?
¿Se cumple con los requerimientos del
0.95
sistema?
¿Se validó el tipo de contrato a utilizar? 0.5
¿Existirá un tipo de soporte una vez realizada

1
la instalación?
TOTALES 74%
87
Figura 18. Valoración del proceso de Adquisición
4.2.2 Análisis del proceso de Adquisición
En los procesos de calidad se detecta que la característica requerimientos de
software se cumplen es decir se han elaborado los requerimientos por parte del equipo
en base a las necesidades del negocio, en la característica publicación de propuestas,
no se han realizado las publicaciones necesarias para tener una lista de diferente tipo de
software y proveedores que puedan ser calificados, esto indica que está seleccionando
a un proveedor referido o conocido para el empresa, por tal motivo la barra de Selección
de proveedor no llega al valor requerido.

88
Tabla 15
Valoración de la métrica Funcionalidad
VALORACIÓN
0 A1
Funcionalidad Métrica de calidad Detalle
El sistema se adapta al proceso de manejo

Realizar adecuadamente cierta actividad,
1 Aptitud de inventario de producción para transformar 1
función o servicio
materias primas en productos terminado?
El sistema permite estimar los costos reales

Capacidad del software de acercarse al valor
2 Exactitud desde la materia prima hasta el producto 1
de la magnitud real
terminado?
El sistema permite conciliar la información
Capacidad de módulos al compartir datos e
3 Interoperabilidad de los módulos transaccionales con el 1
intercambiar información y conocimiento
modulo contable?
Proteger los datos sensibles mediante El sistema usa algún tipo de algoritmo de
4 Seguridad de acceso 0.5
encriptación o contraseñas encriptación para contraseñas y datos?
TOTALES 88%
Figura 19. Valoración la métrica: Funcionalidad.

89
4.2.3 Análisis de la valoración de la métrica: Funcionalidad
Se puede observar que, en la métrica de funcionalidad, la aptitud, exactitud e
interoperabilidad cumplen los valores requeridos, la Seguridad de acceso no llega al valor
de satisfacción necesario, para esto es necesario que el proveedor realice los ajustes, la
seguridad en cuanto a accesos, encriptación de datos son necesarios ahora en el medio
que tenemos acceso por internet.
Tabla 16
Valoración de métrica: Confiabilidad
VALORACIÓN
0 A1
Confiabilidad Métrica de calidad Detalle
Estado del sistema al alcanzar su desarrollo Los procesos estandarizados de la empresa

1 Madurez 1
óptimo han sido automatizados en el sistema?
Capacidad del sistema para continuar con su El sistema cuenta con procesos alternos
2 Tolerancia a fallos 1
funcionamiento cuando algún componente falla para su funcionalidad en caso de fallas?
El sistama cuenta con los respaldos de

Capacidad de Capacidad de restaurar el sistema hasta el Base de Datos y aplicacion? El sistema
3 0.25
recuperación momento en que se produjo el error posee almacenamiento redundante tanto en
base de datos como en la aplicacion?
Capacidad del sistema para poder usarse El sistema se lo puede usar las 24 horas
4 Disponibilidad 1
cuando se necesite, 24 horas 365 días del año 365 días del año?
¿Esta preparado el software para cambios

Capacidad del sistema para descomponerse o
5 Degradabilidad del medio como requerimientos de 1
degradarse
organismos de control?, ejemplo el SRI
TOTALES 85%
90
Figura 20. Valoración de métrica: Confiabilidad
4.2.4 Análisis de la valoración de métrica: Confiabilidad
En esta métrica, la madurez, tolerancia a fallos, disponibilidad y degradabilidad
cumplen los valores requeridos, el software no cuenta con una buena capacidad de
recuperación presentado un valor más bajo del requerido, es necesario ajustar las
características en este punto.
Es indispensable que el software y la base de datos se puede activar después de ocurrir
un error.
91
Tabla 17
Valoración de métrica: Facilidad de Uso
VALORACIÓN
0 A1
Facilidad de uso Métrica de calidad Detalle
Capacidad para ser Facilidad con la que los usuarios comprenden ¿El sistema es intuitivo en los mensajes y en
1 1
entendido el sistema las etiquetas que muestra?
¿El sistema cuenta con ambientes de
Capacidad para ser Facilidad con la que los usuarios aprenden el
2 pruebas para realizar las pruebas de cada 1
aprendido sistema
módulo?
¿El sistema cuenta con teclas de acceso
Capacidad para ser Facilidad con la que los usuarios usan el
3 rápido, teclas de función o comodines para 1
operado sistema
la operación?
Grado en el que el usuario se encuentra ¿Se han realizado encuestas de
4 Satisfacción 0
satisfecho con el sistema satisfacción?
Nivel con el que el sistema logra cumplir las ¿Los reportes satisfacen las necesidades de
5 Logro de la meta 0.9
metas y necesidades del usuario información?
TOTALES 78%
Figura 21. Valoración de métrica: Facilidad de Uso

92
4.2.5 Análisis de valoración de métrica: Facilidad de Uso
En este caso 3 de las cinco características de facilidad de uso son cumplidas,
capacidades para: Ser entendido, aprendido y operado, se debe aplicar encuestas de
satisfacción a las áreas Gerenciales y Jefaturas operativas para obtener un valor
aceptable de satisfacción.
El sistema puede trabajar en las actividades operativas, pero en procesos en lote,
batch o en reportes no genera satisfacción por ende es inevitable realizar encuestas para
entender el punto de satisfacción. En cuanto a la característica de logro de la meta si
cumple el valor mínimo requerido 0.75, pero con las encuestas de satisfacción se puede
detectar lo que le falta al sistema para cumplir la característica logro de la meta.
Tabla 18
Valoración de métrica: Eficiencia
VALORACIÓN
0 A1
Eficiencia Métrica de calidad Detalle
Existe cantonización e índices en la base de
Eficiencia con Qué tan rápido es el sistema para ejecutar
1 datos que acelere la ejecución de datos en el 1
respecto al tiempo cálculos
sistema?
El sistema consume altos niveles de recursos El sistema consume altos niveles de
2 Utilización de recursos 0.6
de hardware recursos de hardware?
TOTALES 80%
93
Métrica de la Eficiencia
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Eficiencia con respecto al tiempo Utilización de recursos
Caracterisiticas de la Eficiencia
Figura 22. Valoración de métrica: Eficiencia
4.2.6 Análisis de valoración de métrica: Eficiencia
La métrica de eficiencia para el caso de utilización de recursos debe ser ajustada
para llegar al valor aceptable. Se trata de dos opciones posibles las cuales no permiten
que la característica de la métrica muestre ese valor: la base de datos no está bien
optimizada a los requerimientos de la empresa, o la aplicación cuenta con procesos mal
programados que usan demasiados recursos de memoria o disco.

94
Tabla 19
Valoración de métrica: Mantenimiento
VALORACIÓN
0 A1
Facilidad de
Métrica de calidad Detalle
Mantenimiento
¿En caso de requerir cambios el software
Capacidad para ser Con que facilidad pueden los programadores
1 tiene comentarios en su código y cuenta con 0.75
analizado analizar el código para un buen entendimiento
acceso al código fuente?
¿Se cuenta con el código fuente para
Capacidad para ser Capacidad para cambiar el software si es que realizar cambios al sistema o cuenta con
2 1
cambiado solicita el cliente o el negocio módulos administrables que permitan
modificar sus pantallas?
¿Los módulos han sido probados y
Capacidad para funcionar sin fallos por largos
3 Estabilidad ejecutados en producción en otras 1
períodos de tiempo
empresas?
Capacidad para ser Capacidad para realizar pruebas de cambios ¿Se cuenta con un ambiente de pruebas
4 1
probado antes de paso a producción para aplicación y base de datos?
TOTALES 94%
Figura 23. Valoración de métrica: Mantenimiento

95
4.2.7 Análisis valoración de métrica: Mantenimiento
El análisis de la métrica indica que las características: Capacidad para ser
cambiado, estabilidad y capacidad para ser probado cumplen a satisfacción y la
capacidad para ser analizado no llega al valor mínimo requerido, en este punto para exigir
este requerimiento se debe validar si la compra se está haciendo con código fuente o sin
código, sin embargo se observa que cumple el valor mínimo lo cual da una pauta para
dejar esta característica abierta para a futuro comprar el código fuente en caso de requerir
y dejar la independencia del proveedor.
Tabla 20
Valoración de métrica: Portabilidad
VALORACIÓN
0 A1
Portabilidad Métrica de calidad Detalle
¿El sistema ha sido probado en los
Qué tan fácil es adaptar el sistema ante
1 Adaptabilidad sistemas operativos que maneja la 1
cambios del sistema operativo
empresa?
¿El sistema se instala desde un servidor de
Facilidad de aplicaciones o en cada máquina del usuario,
2 El sistema es fácil de instalar o no 1
instalación en este caso se cuenta con archivos
instaladores?
El sistema es parecido o tiene similitud con ¿El sistema es customizado o es software
3 Conformidad 1
otros sistemas en el mercado estándar?
Facilidad de ¿El sistema es customizado o es software
4 El sistema es fácil de ser reemplazado o no 1
reemplazo estándar?
TOTALES 100%
96
Figura 24 Métrica: Portabilidad
4.2.8 Análisis de valoración de métrica: Portabilidad
La métrica de portabilidad cumple todos los puntos requeridos, no se requiere
ajustes es un software que ayuda al usuario de IT en el proceso de instalación y re
instalación.
97
Tabla 21
Valoración del Proceso de Suministro
VALORACIÓN
0 A1
Suministro Proceso
¿El proveedor ha definido un modelo de ciclo
0
de vida para el software?
¿El proveedor ha generado el plan de
instalación, cronograma con fechas y 1
entregables?
¿El proveedor ha generado un contrato válido
con los puntos necesarios que den las
1
garantías necesarias a la instalación del
Actividades de
1 software?
Proveedor
¿El proveedor ha definido los intervinientes
1
para el proyecto?
¿El proveedor ha definido un plan para
0
documentar y gestionar los requerimientos?
¿El proveedor ha definido el plan para el
0
aseguramiento de la calidad?
¿El proveedor ha identificado los riesgos
0.5
potenciales del proyecto?
TOTALES 50%
4.2.9 Análisis del Proceso de Suministro
El proceso de suministro cumple con la calidad, se puede observar que se ha realizado
cronogramas para los entregables, así como la documentación requerida para cada
entregable. Como todo proyecto siempre va a existir un rango potencial de riesgo, se ha
definido los potenciales riesgos de calidad.
Por otro lado, se puede observar que no se cumple con la característica de ciclo de vida
para la entrega del software como son el modelo de ciclo de vida del software
98
4.3 Resultados Finales de la aplicación de la metodología ACM al software
GAFYC para la empresa Química Comercial Cía. Ltda.
La aplicación del modelo ACS nos indica las características de cada proceso de
calidad que no cumplen el valor mínimo requerido y que deben ser ajustadas al sistema
y solicitadas al proveedor de acuerdo al contrato de mantenimiento que se disponga.
Se debe validar si son requerimientos no satisfechos pero entregados, en el análisis
se identifica las siguientes características:
 En el proceso de adquisición la publicación de propuestas.
 En la métrica de interoperabilidad.
 En la métrica de confiabilidad la característica de capacidad de recuperación.
 En la métrica facilidad de uso la característica satisfacción.
 En la métrica de eficiencia la característica de utilización de recursos.
 En la métrica de mantenimiento la capacidad para ser analizado.
Estas seis características deben ser reforzadas para que el software ERP GAFYC
cumpla con los estándares de calidad establecida en el modelo ACS creado en el
presente documento.
A nivel general las características establecidas en el modelo cumplen el valor mínimo
del 75% establecido para la evaluación de calidad, esto se puede apreciar en los
siguientes resultados:
99
Tabla 22
Resultados de la aplicación de la metodología
Concepto % Obtenido
Proceso De
74%
Adquisición
Funcionalidad 88%
Confiabilidad 85%
Facilidad de
78%
uso
Eficiencia 80%
Facilidad de
84%
mantenimiento
Portabilidad 100%
Proceso de
76%
suministro
Se obtiene un resultado satisfactorio del 83% a nivel general de cumplimiento de
la calidad en el Software GAFYC implementado en la empresa QUÍMICA COMERCIAL
CIA. LTDA.
100
CAPITULO V
CONCLUSIONES Y RECOMENDACIONES
5.1. CONCLUSIONES
El presente trabajo se basa en un objetivo principal y dos objetivos específicos de los
cuales podemos concluir lo siguiente en base al estudio realizado.
5.1.1. Se realizó la metodología ACS (Adquisición, calidad y suministro) como
propuesta para la adquisición de software utilizando valores definidos para
medir la calidad y como al aplicar esta metodología se puede conocer si el
software que se propone contratar cumple o no con los requerimientos de
calidad.
5.1.2. Se identificó las necesidades, requerimientos y competencias que debe tener
un software mediante el análisis de modelos, características de calidad y
normas ISO obteniendo como resultado el modelo ACS (Adquisición, calidad y
suministro).
5.1.3. En el medio existen varios estándares de calidad que pueden ser usados y
aplicados, para esto las personas encargadas de TI deben basar sus procesos
en la literatura, texto de normas y estándares internacionales que ya existen,

101
los estándares para la adquisición son guías con las mejores prácticas para
ayudar a que los procesos de TI estén bien organizados, planificados y
ejecutados, de acuerdo al negocio deben aplicarse para generar calidad en los
procesos internos.
5.1.4. Cuando el negocio no dispone de un departamento de TI puede sub contratar
estos servicios para que realicen el levantamiento de necesidades y ajusten
sus procesos de requerimientos para mejoramiento de los sistemas, el objetivo
es lograr calidad en los productos de software, no se puede dejar por un lado
a las actividades de adquisición o mantenimiento de software sin aplicar
estándares que generen calidad en sus entregables. En el presente documento
se puede apreciar como al unir dos estándares más procesos de calidad y
métricas de software, se puede mejorar notablemente todo el proceso de
adquisición y mantenimiento, con preguntas sencillas que nos dan la pauta
para identificar el estado del software y los entregables.
5.1.5. Para el caso actual de estudio con la empresa Química Comercial, se puede
notar que existe cierto porcentaje de no satisfacción en cuanto a reportes y
entregables, los administradores de sistemas deben solicitar las respectivas
mejoras o adquisición de software para evitar la manipulación o creación de
reportes en Excel por parte de los usuarios generando errores de información,
en cuanto a seguridades la aplicación del modelo ACS (Adquisición, calidad y

102
suministro) indica que faltan controles de auditoria, un punto importante para
conocer qué pasó con la información cuando se detecte inconsistencias.
5.2. RECOMENDACIONES
5.2.1 Se recomienda la aplicación del modelo ACS (Adquisición, calidad y
suministro) a fin de cubrir todos los puntos de adquisición, requerimientos,
mejoramiento y mantenimiento del software para contar con un software de
calidad.
5.2.1. Para adquirir software no se debe hacer la selección de manera aleatoria sin
una verificación previa, en la presente investigación se pudo constatar que no
siempre el software con mejor apariencia es el adecuado para la empresa,
analizar y medir las características básicas del software es necesario para
saber si tendrá un desempeño correcto, una de las formas de conseguirlo es
aplicando el modelo ACS (Adquisición, Calidad y Suministro).
5.2.2. Se recomienda evaluar el software (ERP) mediante métricas de características
de calidad, estas permiten obtener índices numéricos con los cuales se puede
realizar una correcta evaluación al software y en el modelo ACS (Adquisición,

103
Calidad y Suministro) se encuentra las mejores características de calidad
analizadas entre modelos de calidad y Normas ISO.
5.2.3. Según el proceso de Suministro explicado en el modelo ACS (Adquisición,
Calidad y Suministro), es necesario que el proveedor transparente el plan de
mantenimiento mientras está desarrollándose el proyecto de instalación del
software, una vez instalado el sistema se podrá realizar los ajustes necesarios
y el seguimiento para explotar al máximo las características.
5.2.4. Se recomienda que se aplique el modelo ACS (Adquisición, Calidad y
Suministro), para que el personal de TI tenga una referencia válida, y sirva de
guía en el proceso de selección de software.

104
5.3. BIBLIOGRAFÍAS:
Arciniega, F. (2017). Normas y estandáres de calidad para el desarrollo de software.

Recuperado el 3 de 7 de 2017, de https://fernandoarciniega.com/normas-y-
estandares-de-calidad-para-el-desarrollo-de-software/
Arroyo, V. H. (2017). ISO 12207. Recuperado el 4 de Julio de 2017, de
http://unfviso12207.webcindario.com/
Borbón, N. (12 de 03 de 2013). Evaluación del Software. Recuperado el 15 de 02 de
2017, de http://actividadreconocimiento-301569-8.blogspot.com/2013/03/norma-
de-evaluacion-isoiec-9126.html
Castro, N., Borges, A. M., Baquero, N., & Rodriguez, S. (Marzo de 2006). Scielo.
Recuperado el 15 de 03 de 2017, de
http://www.scielo.org.ve/scielo.php?script=sci_arttext&pid=S0798-
40652006000100012
Comerciales, C. d. (2006). Norma técnica Peruana. Recuperado el 16 de 02 de 2017, de
http://www.senasa.gob.pe/senasa/wp-content/uploads/2014/11/Certificacion-
citricos-a-mexico_26_mayo_2105_2.pdf
Constanzo, M. (2014). Dialnet. Recuperado el 15 de 02 de 2018, de
https://dialnet.unirioja.es/descarga/articulo/5123569.pdf
Crece negocios. (2017). CreceNegocios. Recuperado el 4 de Julio de 2017, de
http://www.crecenegocios.com/el-analisis-costo-beneficio/
David, D. (06 de 10 de 2013). CodeJobs. Recuperado el 23 de 20 de 2017, de
https://www.codejobs.biz/es/blog/2013/10/06/la-calidad-de-diseno-del-software
Economía Simple. (2016). Economía Simple.net. Recuperado el 4 de 7 de 2017, de
http://www.economiasimple.net/glosario/proveedores
EcuRed conocimiento con todos y para todos. (2017). Obtenido de
https://www.ecured.cu/Norma_ISO/IEC_14598
Eeles, P. (2014). IBM DeveloperWorks. Recuperado el 19 de 02 de 2018, de
https://www.ibm.com/developerworks/rational/library/3975.html
Estayno, M., Dapozo, G., Cuenca Pletch, L., & Greiner, C. (2017). Módelos y métricas
para evaluar calidad de software. Recuperado el 14 de 07 de 2017, de
http://sedici.unlp.edu.ar/bitstream/handle/10915/19762/2397-
Estayno_UNNE_UTN.pdf?sequence=1
105
F. J. Pino, F. G. (2014). Researchgate. Recuperado el 02 de 02 de 2017, de

https://www.researchgate.net
Fenton. (1991). Recuperado el 06 de 01 de 2018, de http://grupo281v.blogspot.com/
Fillottrani, P. (2007). Universidad Nacional del Sur. Recuperado el 08 de 01 de 2018, de
http://cs.uns.edu.ar/~prf/teaching/SQ07/clase6.pdf
Garcia, C., & Mazo, E. (2005). Recuperado el 10 de 01 de 2018, de
https://jrvargas.files.wordpress.com/2009/03/guia_tecnica_para_evaluacion_de_s
oftware.pdf
González, A., André, M., & Hernández, A. (2005). Researchgate. Recuperado el 22 de
02 de 2018, de
https://www.researchgate.net/publication/301289888_Analisis_comparativo_de_
modelos_y_estandares_para_evaluar_la_calidad_del_producto_de_software
IDEAM Instituto de hidrología, metereología y estudios ambientales. (2014).
http://www.ideam.gov.co/. Recuperado el 4 de Julio de 2017, de
http://www.ideam.gov.co/web/ecosistemas/normas-estandares
Jorge Arturo Reinoso Espinosa, C. R. (2018). Análisis de los modelos de calidad de
software. Recuperado el 10 de 4 de 2017, de
https://www.researchgate.net/profile/Maria_Macias_Mendoza/publication/287921
01_Analisis_De_Los_Modelos_De_Calidad_De_Software_Existentes_Y_Su_Apo
yo_Al_Cumplimiento_De_Requerimientos_En_Empresas_No_Dedicadas_Al_De
sarrollo_De_Software/links/540db7f00cf2f2b2
Kiuwan. (2016). Models and CQM. Recuperado el 17 de Agosto de 2017, de
https://www.kiuwan.com/docs/display/K5/Models+and+CQM
Luis E. Mendoza, M. A. (16 de Diciembre de 2004). Computación y sistemas. Recuperado
el 15 de 5 de 2017, de
http://www.scielo.org.mx/scielo.php?script=sci_arttext&pid=S1405-
55462005000100005
Pérez, F. H. (2013). El modelo de estándares ISO. Recuperado el 25 de 02 de 2017, de
http://huttab-iso.blogspot.com/
Pressman, R. S. (2010). Ingeniería de Software Enfoque práctico (2010 ed.). México:
McGraw-Hill. Recuperado el 5 de 10 de 2017, de
http://cotana.informatica.edu.bo/downloads/ld-
Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF
106
Rodriguez Perez, E. M. (2014). www.edumarciencias.com. Recuperado el 30 de 7 de

2017, de http://www.edumarciencias.com/wp-
content/uploads/2015/11/MODELOS-DE-CALIDAD-DEL-SOFTWARE.pdf
Servicio de Rentas Internas del Ecuador. (2017). SRI. Recuperado el 4 de Julio de 2017,
de http://www.sri.gob.ec/web/guest/67
SlideShare. (13 de 07 de 2006). Recuperado el 1 de 9 de 2017, de
https://es.slideshare.net/oprbguitar/norma-tecnica-peruana-iso-12207
Software Asset Management. (2006). Recuperado el 23 de 01 de 2017, de
http://www.senasa.gob.pe/senasa/wp-content/uploads/2014/11/Certificacion-
citricos-a-mexico_26_mayo_2105_2.pdf
Vera, Á. B. (01 de 2017 de 2015). http://chitita.uta.cl. Recuperado el 24 de 01 de 2017,
de http://chitita.uta.cl/cursos/2011-2/0001007/recursos/r-1.pdf

"Desarrollo de Un Modelo para La Gestión de La

Cargado por

Información del documento

Título original

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

"Desarrollo de Un Modelo para La Gestión de La

Cargado por

Copyright:

Formatos disponibles

VICERRECTORADO DE INVESTIGACIÓN, INNOVACIÓN Y

CENTRO DE POSGRADOS MAESTRÍA EN GERENCIA DE SISTEMAS,

TRABAJO DE TITULACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO

TEMA: “DESARROLLO DE UN MODELO PARA LA GESTIÓN DE LA

AUTORES: ING. CASA SALAZAR, EDISON JAVIER

ING. SANCHEZ NEACATO, LUIS EDGAR

DIRECTOR: ING. CAMPAÑA ORTEGA, MAURICIO M.I.S, M.D.U.

para quienes dedico este trabajo.

faltaba con mis hijos.

A mi madre Sra. EMMA SALAZAR

A mi padre JUAN JOSÉ CASA

Por estar pendiente de mi maestría, por preguntarme y apoyarme al estar preocupado

mientras desarrollaba el presente trabajo.

Ing. Edison Javier Casa S.

mis estudios superiores y a mi familia.

A mi hija, que es mi motivo de desarrollo y crecimiento para darle lo mejor que un

padre pueda dar a sus hijos.

A mi esposa, que ha sido un gran apoyo en todo el proceso de estudio de la

maestría de Gerencia de Sistemas.

A mi madre que siempre me ha apoyado en todo momento y gracias a ella soy

Ing. Luis Sánchez N.

A los profesores quienes con su experiencia impartieron el conocimiento necesario

para complementar mis estudios y desarrollar mis actividades profesionales.

A mi director de tesis, Magister MAURICIO CAMPAÑA ORTEGA, por entregar desde

el inicio su apoyo y ser nuestra guía en el desarrollo del presente trabajo.

Al Coordinador del Programa de Maestría en Gerencia de Sistemas, Magister

pasos necesarios para culminar con éxito el presente trabajo.

Ing. Edison Javier Casa S.

Agradezco en primer lugar a Dios ya que sin él nada es posible.

A mi esposa, Karen Aguirre quien con su motivación siempre me impulso a culminar

seguir cumpliendo metas.

Al Ingeniero, MAURICIO CAMPAÑA e Ingeniero GEOVANNI NINAHUALPA, quienes

Ing. Luis Sánchez N.

1.1 Generalidades ........................................................................................................... 3

1.3 Planteamiento del problema ...................................................................................... 4

1.4 Formulación del problema ......................................................................................... 5

1.5 Sistematización del problema .................................................................................... 5

1.6.1. General .................................................................................................................. 5

1.7 Justificación e Importancia ........................................................................................ 6

1.8 Alcance ...................................................................................................................... 6

MARCO TEÓRICO .......................................................................................................... 8

2.1 Introducción ............................................................................................................... 8

2.2. Fundamentación Teórica .......................................................................................... 8

2.3. Hipótesis ................................................................................................................... 9

2.4 Variables de investigación ......................................................................................... 9

2.5 Metodología de la investigación .............................................................................. 10

2.6 Tipo de Investigación ............................................................................................... 10

2.7 Población y Muestra ................................................................................................ 11

2.7.1 Población .............................................................................................................. 11

2.8 Técnicas de investigación........................................................................................ 11

2.9 Instrumentos de la investigación ............................................................................. 12

2.10 Recolección de la información ............................................................................... 12

2.11 Tratamiento y análisis estadístico de los datos ..................................................... 13

2.12 Estado del arte ...................................................................................................... 13

2.13 Definiciones ........................................................................................................... 14

2.13.1. ERP ................................................................................................................... 14

2.13.2 PYMES ............................................................................................................... 15

2.13.3 Proveedores ....................................................................................................... 16

2.13.4 Costo Beneficio .................................................................................................. 17

2.14 Normas y estándares............................................................................................. 17

2.14.1 Norma ISO/IEC 12207:2008 ............................................................................... 19

2.14.2 Normas ISO/IEC 9000-3:2004 ............................................................................ 19

2.14.3 Normas ISO/IEC 9126 ........................................................................................ 20