“Análisis de los Factores de Riesgos de los sistemas ERP en

Tecnologías de Información”.
 Indice

Contenido
1. INTRODUCCIÓN............................................................................................................... 3
2. CALIDAD DEL SOFTWARE, MÉTRICAS, MEDICIÓN E INDICADORES. .......... 4
2.1 Gestión en la calidad del software. ...................................................................................... 5
2.1.1Gestión de riesgos, errores.................................................................................................. 5
2.1.2Gestión de Errores. ............................................................................................................. 5
2.1.3Medidas para la gestión de errores .................................................................................... 6
2.1.4 El modelo Sistémico de la Calidad .................................................................................... 6
3. MODELO POR ETAPAS EN LA DEFINICIÓN DE MÉTRICAS. .............................. 6
3.1Características de una Métrica Funcional. .......................................................................... 7
3.2 Las métricas de puntos por Función. .................................................................................. 8
3.3 El Método Estándar Análisis de Puntos Función ............................................................... 8
4. ESTÁNDAR INTERNACIONAL ISO................................................................................. 8
4.1. Pasos para determinar una métrica por Puntos de Función. ........................................... 9
5. CONCLUSIONES. ................................................................................................................ 10
Bibliografía .................................................................................................................................. 11
 1. INTRODUCCIÓN.
Los sistemas de planeación de recursos empresariales (ERP) son considerados sistemas
de software de tipo gerencial que contienen módulos para diferentes áreas funcionales
como producción, ventas, distribución, finanzas, recursos humanos, mantenimiento, entre
otros.
Los sistemas ERP son usados actualmente para facilitarnos las labores gerenciales de toda
empresa a la que sea destinada, dentro del estudio de los ERP no se debe dejar atrás los
factores críticos de riesgos que abarcan parte del sistema de Software ERP, ya que no
permite tomar decisiones y entre una de ellas es ser totalmente certeros en lo que
aprobemos.
Entre sus factores tenemos la tarea ardua y costosa para su aprobación e implementación,
requiere de mucho esfuerzo, compromiso y un estudio completamente diseñado,
planificado.
Dentro del estudio realizado en este artículo podemos mencionar los factores críticos
encontrados:
 Transición al nuevo sistema
 Sobrecarga de trabajo para algunos
 Dificultad de estimar costos
 Rotación de personal clave
 Adaptación a normas legales
 Carencia de personal preparado técnicamente
 Falta de procedimientos escritos
 Adaptación de hardware y telecomunicaciones
Cabe mencionar que estos pueden ser mejorados debido a la reingeniería de los procesos
del negocio donde procederá a abordar los puntos de fallas mediante la aplicación
continua de una retroalimentación antes ya encontrada en otros casos de aplicación de
sistemas ERP y así encontrar los máximos beneficios de estos sistemas. Cabe señalar,
que los procesos de implantación de sistemas ERP el proveedor de estos debe
convertirse en el consultor de implantación con soluciones posibles.
 2. CALIDAD DEL SOFTWARE, MÉTRICAS, MEDICIÓN E
INDICADORES.

A continuación, vamos definiendo los diferentes conceptos presentados en la

introducción y así facilitar la comprensión del tema por parte del lector.
Tijerina(2014)afirma que Calidad del Software, es el cumplimiento de los requisitos de
funcionalidad y desempeño explícitamente establecidos, los estándares 1de desarrollo
explícitamente documentados y las características implícitas 2que se esperan de todo
software desarrollado profesionalmente. La calidad del software es una compleja mezcla
de factores que variarán a través de diferentes aplicaciones y según los clientes que las
pidan.
El éxito del Software depende de un conjunto de cualidades, el cual sea diseñado para dar
un alto grado de satisfacción al cliente, realizar revisiones de técnicas exhaustivas antes
de la prueba, determinar qué es lo importante de un producto, cuantitativamente antes de
empezar las pruebas, aseguramiento y fiabilidad de tener un plan de prueba, enumerar los
objetivos de las pruebas de manera concisa, el producir un Software de calidad es el
objetivo de mayor importancia para los ingenieros.
Pressman(1998) menciona que la Calidad en un Software debe añadirse en todos los
ciclos de vida del producto. Las distintas tareas para la inserción de un control de calidad
en el desarrollo del software en este análisis son:
1) Empleo de metodologías3y métodos de desarrollo,
2) Reutilización de procedimiento de revisiones formales,
3) Pruebas constantes del software en desarrollo,
4) Ajustes a las normas establecidas para el desarrollo del software,
5) Verificación de cambios, cálculos medibles y acumulación de información; y
6) Administración de informes acerca del desarrollo en la calidad del software.
Según Pressman R(1998) menciona que básicamente a pesar de que existen docenas de
métricas o medidas, exclusivamente orientadas a la calidad del desarrollo de un producto
en este caso calidad del software, en donde desde el ciclo de vida el diseño, codificación,
pruebas y mantenimiento está la necesidad de controlar diferentes atributos,
estructuración, exactitud, acoplamiento y la complejidad del mismo siendo difícil tener
un solo valor de calidad. Con distintos tipos de métricas se permite la cuantificación y
cualificación para mejorar el software final con distintos criterios de acuerdo al aspecto,
tecnologías, funcionalidades dependiendo de los requerimientos del usuario, esto permite
que la calidad sea valorada desde el momento en que se planea desarrollar un software
Una medida brinda una indicación cuantitativa de la cantidad, totalidad,
extensión, dimensión, capacidad o tamaño de algún atributo de un producto o
proceso.(Pressman R. S., 1998)

1
Establecimiento de normas en el desarrollo del software
2
Incluido en algo que se espera
3
Conjunto de procedimientos
 Una medida es un indicativo de que cantidad, dimensiones posee un producto
aplicadas en su desarrollo.
Una métrica es una evaluación del grado en que un sistema, componente o
proceso posee una tributo determinado (extensión, cantidad, dimensiones, capacidad o
tamaño).Un ingeniero de software recopila medidas y desarrolla métricas para obtener
indicadores.(Pressman R. S., 1998)
La métrica está más direccionada a los factores evaluativos del sistema,
componente o procedimiento de un determinado atributo, donde existe una agrupación de
medidas y estas se convierten en métricas para obtención de indicadores
Un indicador es una métrica, combinación de métricas que provee
reconocimientos. Estos conocimientos permitirán al jefe de proyecto o a los ingenieros
de software preparar el proceso, el proyecto o el producto para que funcionen mejor las
cosas.(Pressman R. , 1998).

2.1 Gestión en la calidad del software.

El objetivo de la administración de la calidad del software es, entender cuáles son
las expectativas del cliente en cuanto a calidad, y poner en práctica una planificación de
cómo satisfacer sus expectativas, como sabemos la calidad está definida por el cliente.
Por lo tanto, se requiere evaluar cada propiedad individual del software y así poder
determinar una o más métricas que pueden obtenerse para reflejar dichas propiedades.
Ejemplo de ello es que una característica de calidad puede ser la solución que existan
menores cantidades de errores. Se puede medir contando cuales son los errores y cuales
los defectos de una solución. (Scalone, 2006, Pág. 22)

2.1.1Gestión de riesgos, errores.

“Desde hace mucho tiempo, los proyectos de software han sido considerados
como proyectos de alto riesgo propensos al fracaso” según afirma(Bannerman, 2008) y
“se reconoce que la gestión de riesgo se suma una de las mejores prácticas de la industria
del software para reducir el factor sorpresa” según(Dolado, Aguirregoitta, & Presedo,
2010).

2.1.2Gestión de Errores.
Un aspecto clave, importante al desarrollar un software fiable4 es el análisis por
fases de la distribución de errores como se propone en los tipos de fallos definidos
en (IEEE, 1998).
Este análisis manifiesta la existencia de procedimientos para la adquisición de
datos y verificaciones, técnicas, controles periódicos de un producto software realizadas
por un equipo o personal calificado que determina su capacidad para el empleo
pretendido5 reconocerlas especificaciones y estándares que se pueden clasificar en
revisiones de requisitos, análisis, diseño y documentación que sean establecidos al
momento de la propuesta con el cliente.(Dolado, Aguirregoitta, & Presedo, 2010)

4
Que inspira seguridad
5
Querer conseguir algo
2.1.3Medidas para la gestión de errores
Existen muchas técnicas para la revisión de un producto software desde su etapa
de desarrollo, además que estas nos proporcionan una visión futura de los resultados de
un producto.
La verificación y validación pueden definirse como el proceso de asegurar que
cada fase del ciclo de vida del desarrollo implementa correctamente las especificaciones
de la fase previa y que cada producto software obtenido satisface sus requerimientos. Las
pruebas son la ejecución controlada del código del programa en busca de errores. Las
revisiones formales son revisiones planificadas y periódicas de los productos obtenidos
llevadas a cabo por desarrolladores, clientes, usuarios y gestores para evaluar el progreso.
Las inspecciones y walk-throughs6 son revisiones sistemáticas de los productos software
obtenidos realizadas por los pares con el propósito de encontrar errores(Thayer, 2001).

2.1.4 El modelo Sistémico de la Calidad

El Modelo Sistémico7 de la Calidad en el desarrollo del software nos permite
medir la Calidad Sistémica de una empresa desarrolladora de Software que parte de la
Calidad de su producto en el momento que se produce y de la Calidad del proceso en el
momento que se desarrolla el mismo. El modelo brinda la verificación de un nivel de
Calidad que cambiará entre Nulo, Básico, Intermedio y Avanzado. (Mendoza L., Pérez
M., Grimán A., 2005)
El modelo Sistémico de la Calidad indica cuales son los procesos que se tienen
que mejorar en la empresa y las propiedades que no se han cumplido en el producto de
software desarrollado. (Mendoza L., Pérez M., Grimán A., 2005)

3. MODELO POR ETAPAS EN LA DEFINICIÓN DE

MÉTRICAS.
Las etapas de este proceso se describen a continuación.
1. Identificación. - Etapa en la cual se definen los alcances al momento de crear
la métrica además de plantearnos hipótesis para llevar a cabo la medición del software
durante su desarrollo. Obteniendo de esta etapa los principales requisitos que debe
cumplir la métrica. (Serrano, Piattini, et al., 2010, Pág. 3)

2. Creación. Etapa en la que se define a la métrica de acuerdo a los requerimientos

pre-establecidos en la etapa anterior. Se necesitará realizar una validación teórica en base
a métodos estadísticos, matemáticos, entre otros que nos garantizarán que la métrica
empleada cumpla con el objetivo propuesto. También se realiza una Validación Empírica8
donde por medio de encuestas, experimentos y casos de estudio se valida la métrica.
(Serrano, Piattini, et al., 2010, Pág. 3)

3. Aceptación. - Una vez obtenida una métrica válida, suele ser necesario pasar
por una etapa de aceptación de la métrica, pruebas en entornos reales comprueban si la
métrica cumple con los objetivos deseados. (Serrano, Piattini, et al., 2010, Pág. 3)

6
Caminar a través de algo
7
Totalidad de un sistema
8
Basado en experiencia y observación
 4. Aplicación. - La métrica es aceptada y utilizada para el campo de aplicación
para la que fue creada. (Serrano, Piattini, et al., 2010, Pág. 3)
5. Acreditación. - Esta etapa corre en paralelo con la fase de aplicación y tiene
como objetivo el mantenimiento de la métrica, como consecuencia de ésta etapa una
métrica puede ser retirada, por ya n o ser útil o reutilizada para iniciar un nuevo proceso.
(Serrano, Piattini, et al., 2010, Pág. 3)
Una de las primordiales inquietudes entre las métricas de calidad se ubica en las
medidas de la usabilidad del producto producido. Si el producto es amigable con el
usuario podrá ser medible a través de las características de cómo vemos al usuario final
utilizar el sistema, que tiempo empleara en su utilización y los beneficios que a este
aporten y como valorarán de forma subjetiva los usuario al sistema producido según
menciona (Gladys Gorga , María Madoz , Patricia Pesado, s.f)
Por lo tanto cabe mencionar que si un producto desarrollado siguiendo las etapas
anteriormente mencionadas permitirán ubicar al software en un punto donde se verá si
está bien desarrollado o no, si la métrica empleada dio frutos al emprender el desarrollo
del producto o por qué haberlo desarrollado presentó o presentará falencias, claro en
nuestras breves palabras damos algo de cierto a este análisis que tiene como fin hacer una
breve descripción de los aportes que muchos autores se enfocan en las métricas y la
calidad. A continuación, se muestra un cuadro de las etapas del modelo de definición de
métricas.

Figura 1. Etapas del Método de Definición de Métricas.

3.1Características de una Métrica Funcional.

Según Duran Rubio(2003, pág 48)“El tamaño del software podría medirse en
términos de los bytes9 que ocupa en el disco, el número de programas, el número de líneas
de código, la funcionalidad que proporciona, o simplemente el número de pantallas o
reportes que tiene”. A continuación, se detalla las características de una métrica funcional:
Independencia Tecnológica. - Una vez establecida la funcionalidad que se
requiere se debe escoger la tecnología para alcanzar dicha funcionalidad.

9
Unidad fundamental de los ordenadores
 Simplicidad. - La métrica no debe requerir grandes esfuerzos para alcanzar una
medida. Una desventaja de esta característica sería que el software no sería tan detallado
para realizar resultados sensibles, como por ejemplo operaciones matemáticas.
Enfoque en la funcionalidad proporcionada. - Esto se refiere a las ventajas que
se va adquirir al implementar el nuevo software, al momento de realizar una revisión
técnica.
Basadas en los requerimientos del usuario. - Esto permite tener una idea de qué
tamaño va a tener el software sin necesidad de esperar a que esté terminado.
Consistencia. Los resultados obtenidos en diferentes sistemas y por diferentes
personas deben ser consistentes.

3.2 Las métricas de puntos por Función.

Esta métrica trata de medir la funcionalidad que el software proporciona al
usuario. Según Duran Rubio(2003, 49 )“Es una métrica para establecer el tamaño y
complejidad10de los Sistemas Informáticos basada en la cantidad de funcionalidad
requerida y entregada a los usuarios” o, “Los Puntos Función miden el tamaño lógico o
funcional de los proyectos o aplicaciones de software basados en los requerimientos
funcionales del usuario”.

3.3 El Método Estándar Análisis de Puntos Función

El método que se está convirtiendo en el estándar de la industria es el definido por
el IFPUG, que se llama Function Point Analysis (FPA) y sus autores los definen así:
“Método estándar para medir el desarrollo de software desde el punto de vista del
usuario”. (Duran Rubio, 2003, Pág. 47)
La selección de indicadores incluye la medición de esfuerzos (en horas-persona)
y costes (en dinero) tanto reales como planificados, número de entregables aceptados por
el usuario y desviaciones, esfuerzo reutilizado de otros proyectos o inactividad en
recursos humanos, número de modificaciones en el producto e información sobre su
evaluación (solicitadas, rechazadas y aceptadas), esfuerzo dedicado a la detección y
corrección de errores, número de revisiones finalizadas, e información sobre la detección
de errores para evaluar la calidad del producto (por ejemplo errores detectados antes y
después de la entrega). Asimismo, muchos de los indicadores incluyen mediciones
desglosadas por fase (por ejemplo, desglose en requerimientos, diseño, codificación y
documentación).

4. ESTÁNDAR INTERNACIONAL ISO11.

La evaluación y cálculo de la funcionalidad que cuenta un sistema informático es
de considerarse como la angustia de toda la industria dedicada al desarrollo del software,
además no solo con contar con una métrica es suficiente hoy en día sino que debe ser esta
métrica un estándar para poderla usar entre empresas o que permitan tener indicadores
entre las industrias desarrolladoras de productos de ingeniería de software que sea fácil
de manejar y entender afirman(Fairley, 2009). El poder comparar la productividad
(Puntos Función por Persona Mes) de una empresa con los datos de la industria, es
fundamental en los planes de mejora. (Duran Rubio, 2003, Pág. 50)

10
Cualidad que contiene diversos elementos
11
Organización Internacional de Normalización
4.1. Pasos para determinar una métrica por Puntos de Función.
En éste apartado vamos a describir los pasos para determinar una medida por
puntos de función, aquí el método identifica los componentes del S.I.12asignando un
número de puntos por función basándose en la complejidad, la sumatoria de esto nos da
los puntos de función sin ajustar. El ajuste final se lo realiza al final tomando en cuenta
las características generales de todo sistema informático que se está contando. (Duran
Rubio, 2003, Pág. 52)

Fuente: Duran Rubio - Pág. 14

Paso 1. Determinar el tipo de conteo. En este paso determinamos el objetivo del
conteo, se define si se cuenta en el desarrollo, mantenimiento o en un software que ya
está instalado.(Duran Rubio, 2003)
Paso 2. Identificar los alcances de la medición y los límites de la aplicación.
En esta parte se define la funcionalidad en una medida específica y puede incluir más de
una aplicación.(Duran Rubio, 2003)
Paso 3. Contar las funciones de Datos. Aquí determinamos la capacidad de
almacenamiento de datos. Se analizan el archivo lógico interno y el archivo de interfaz 13
externo. Se asigna un valor de complejidad este puede ser alto, medio o bajo,
considerando el número de datos.(Duran Rubio, 2003)
Paso 4. Contar las funciones Transaccionales. Este paso mide la capacidad de
realizar operaciones, a cada componente se le asigna un valor de complejidad alto, medio
o bajo, referenciando el número de datos en los archivos o en los procesos.(Duran Rubio,
2003)
Paso 5. Determinar los puntos de función no ajustados. En esta fase se obtiene
el total, al sumar el número de componentes conforme a la complejidad asignada.(Duran
Rubio, 2003)
Paso 6. Determinar el valor del factor de ajuste. El valor de ajuste se obtiene
sumando 0,65 a la suma total de los grados de influencia de las 14 características
generales del sistema, multiplicada por 0,01.(Duran Rubio, 2003)
Paso 7. Determinar los puntos función ajustados. En esta fase se considera los
puntos función no ajustados por el factor de ajuste.(Duran Rubio, 2003)

12
Sistemas de Información
13
Medio de comunicación hombre-máquina
5. CONCLUSIONES.

Los factores críticos de riesgo se presentan como parte de un sistema ERP, la

investigación se ha desarrollado a través de un estudio minucioso de tipo exploratorio que
no trasciende más allá de la temática de los ERP, el tipo de solución que brinda el autor
es de tipo razonable en cuanto a la representación y proporción de la información.
Las encuestas, entrevistas y cuestionarios le permiten conocer cuáles son las falencias del
sistema propuesto y que luego de la experimentación en algunas empresas pudieron
observar lo critico de estos sistemas, que con un estudio bien detallado el autor propone
retroalimentarlo y con ella a dar soluciones mediante una buena documentación donde el
proveedor debe ir más allá del conocimiento planteado.
Unos sistemas totalmente documentados con una literatura comprensible permiten a que
las empresas puedan acoplarse a la incorporación de un sistema ERP y así tomar datos
técnicos que permitan la buena utilización de este recurso, además deben basarse en la
experiencia de un sistema para acoplarlo al sistema actual
Como conclusión final de este estudio se encuentra cual es la importancia que se le da a
este proceso de selección de sistema ERP, como los factores críticos de riesgos pueden
afectar a mi sistema actual, que medidas solventan que no se produzca un caos en caso de
reemplazar el sistema vigente por uno que brinde más comodidad a nuestra empresa, que
fiable es este sistema si no contamos con la documentación, como menciona es un estudio
exploratorio donde se hayo las principales falencias de estos sistemas sin no cuentan con
un extracto que contenga información puntual sobre problemas que se presentan en los
ERP. Una buena planificación e integración con los sistemas fomentan el cambio
necesario en los procedimiento de trabajos, así como una adecuada selección del
proveedor que entregue el sistema totalmente integrado a nuestra empresa así como que
nos facilite el proceso de implantación del sistema con todos sus recursos y apoyo a
nuestra organización.
 Bibliografía

Bannerman, P. (2008). Risk and Risk Management in software projects: A reassesment. The
Journal of System & Software., 2118 - 2133.

Cochea Tomalá, S. J. (2009). Métricas de Calidad de los Sistemas de Información, aplicación en

la Certificación de Calidad de una empresa del sector Hidrocarburífero. Guayaquil:
ESPOL.

Dolado, J. J., Aguirregoitta, A., & Presedo, C. (2010). Estudio de Métricas para el Control de
Proyectos Software. Actas de las Jornadas de Ingeniería del software ey Base de Datos
(pp. 65 - 72). Barcelona: SISTEDES.

Duran Rubio, S. E. (2003). Puntos por función. Metricas estandar para establecer el tamaño del
software. Boletín de Política Informática, Num 6., 50-63.

Emanuel Irrazabal, Javier Garzas. (2010). Análisis de Métricas básica y herramientas de código
libre para medir la mantebilidad. 6(3), 58-55.

Fairley, R. (2009). Managing and Leading Software Projects. Wiley-IEEE Computer Society
Press.

Gladys Gorga , María Madoz , Patricia Pesado. (s.f). Hacia una propuesta de métrica para la
evaluación de Software Educativo. Laboratorio de Investigación y Desarrollo en
Informática, 16-18.

IEEE. (1998). Standard Dictionary of Measures to produce reliable software. IEEE.

Mendoza Luis, Pérez María, Grimán Anna. (2005, enero). Prototipo de Modelo Sistémico de
Calidad (MOSCA) del Software. Computación y Sistemas, 8, 198-199.

Olsina, L. M., Bertoa, M. F., Lafuente, G. J., Martín, M. A., Katrib, M., & Vallecillo, A. (2014).
Marco Conceptual para la Definición y Explotación de Métricas de Calidad. Malaga:
Universidad de Málaga.

Pressman, R. (1998). Ingenieria del Software (5 ed.). Madrid: McGRAW HILL.

Pressman, R. S. (1998). Buenas Practicas. Madrid: McGRAW HILL.

Scalone, F. (2006). Estudio Comparativo de los Modelos y Estándares de Calidad de Software.

Buenos Aires, Argentina.

Serrano, M., Piattini, M., Calero, C., Genero, M., & Miranda, D. (2010). Un método para la
definición de métricas de software. Castilla.: Grupo ALARCOS, Universidad de Castilla.

Tejerina, W. C. (2014). Medidas del producto para el software. Jujuy: Universidad Nacional de
Jujuy.

Thayer, R. H. (2001). Software Engineering project management. 2nd Edition. Wiley - IEEE
Computer Society Press.