evaluacion tecnico funcional erp

Ministerio del Poder Popular paralas Telecomunicaciones y la Informática

Centro Nacional de Tecnologías de Información

EVALUACIÓN TÉCNICO-FUNCIONAL DE SISTEMAS INTEGRADOS DE GESTIÓN ADMINISTRATIVA, PARA LAS INSTITUCIONES ADSCRITAS AL MINISTERIO DEL PODER

POPULAR PARA LAS TELECOMUNICACIONES Y LA INFORMATICA

Caracas, 04 de Octubre de 2007

Av. Universidad, Esquina El Chorro, Torre Ministerial, piso 11, La Hoyada, CaracasTelf. 0212-7718800. Fax 0212-771.86.48

Sitio Web: www.cnti.gob.ve

http://www.cnti.gob.ve/

Índice de contenido 1.- ABREVIATURAS..........................................................................................4

2.- INTRODUCCIÓN.........................................................................................5

3.- JUSTIFICACIÓN...........................................................................................7

4.- OBJETIVO GENERAL....................................................................................9

5.- OBJETIVOS ESPECIFICOS.............................................................................9

6.- PROPUESTA METODOLÓGICA....................................................................10

6.1.Metodología (MEECS)...........................................................................11

a) Preselección del Software...................................................................11

b) Ajuste del Modelo de Estimación de la Calidad de Software...............12

c) Aplicación del Modelo de Calidad Ajustado ........................................12

d) Elaboración de Informe de Calidad.....................................................12

e) Selección Final del Software................................................................13

6.2.- Modelo de Estimación de Calidad de Software (MOECS)...................14

1) Matriz de Calidad MOECS...................................................................15

2) Matriz de Calidad Ajustada a Software de tipo ERP (MOECSA)..........16

7.- MECANISMO DE APLICACIÓN DE LA METODOLOGÍA (SAMOECS).............17

8.- SISTEMAS DE GESTIÓN ADMINISTRATIVA INTERNA SELECCIONADOS PARA

EL PROCESO DE EVALUACIÓN.........................................................................18

8.1. SAI......................................................................................................21

8.2. K2B ERP..............................................................................................22

8.3.SIGESP.................................................................................................24

9.- ASPECTOS FUNCIONALES Y TÉCNICOS EVALUADOS................................25

10.- INSTITUCIONES PARTICIPANTES. EQUIPOS DE TRABAJO........................26



11.- PROCESO DE EVALUACIÓN Y CRONOGRAMA DE EJECUCIÓN...............28

12.- RESULTADOS OBTENIDOS.....................................................................31

12.1. Resultados de la Evaluación Por Sistema..........................................31

12.2.Resultados de la Evaluación Por Tipos de Métricas............................32

12.3.Resultados de la Evaluación Por Dominios........................................33

12.4.Resultados de la Evaluación Por Categoría de Calidad......................34

13.- CONSIDERACIONES Y RECOMENDACIONES FINALES.............................36

14.- APENDICE A. CARACTERICTISCAS POR CATEGORIA DEL MODELO MOECS

.......................................................................................................................38

15.- APENDICE B. METRICAS TECNICAS DEL MODELO MOECS AJUSTADO A

SOFTWARE DE TIPO ERP (MOECSA)................................................................56

16.- APENDICE C. METRICAS FUNCIONALES Y LEGALES DEL MODELO MOECS

AJUSTADO A SOFTWARE DE TIPO ERP (MOECSA)............................................68

17.- APENDICE D. GRUPOS DE OPCIONES Y VALORES PARA LAS METRICAS EN

MOECS............................................................................................................80

18.- REFERENCIAS........................................................................................82



1. ABREVIATURAS

Abreviatura Significado

AP Administración Pública

CNTI Centro Nacional de Tecnologías de Información

ERP Enterprise Resource Planning o Gestión (de Información) Organizacional.

GGIS Gerencia General de Ingeniería de SW del CNTI

ISO International Standard Organization u Organización de Estándares Internacionales

MEECS Metodología de Estimación de la Calidad de Software

MOECS Modelo de Estimación de la Calidad de Software

MOECSA MOECS ajustado según el tipo de software a evaluar

MPPTI Ministerio del Poder Popular para las Telecomunicaciones y la Informática



2. INTRODUCCIÓN

En el marco de la ejecución de los lineamientos del Ministerio del Poder Popular

para las Telecomunicaciones y la Informática (MPPTI), dirigidos a establecer una

estructura para la certificación y generación de estándares generales en tecnologías de

información, con la finalidad de unificar, normar, estandarizar y certificar la instalación y

uso de estas tecnologías en la Administración Pública (AP), el Centro Nacional de

Tecnologías de Información (CNTI), como organismo adscrito al MPPTI y encargado de

ejecutar tales lineamientos, ha llevado a cabo entre los meses de Septiembre y Octubre

del 2007, un proceso de evaluación y selección de sistemas de gestión administrativa

con el propósito de determinar, en muy corto plazo, la mejor alternativa disponible que

pueda ser implantada en el Ministerio del Poder Popular para las Telecomunicaciones y

la Informática (MPPTI) y sus organismos adscritos.

Como parte de este proceso, el CNTI se ha propuesto la conceptualización y

diseño de una metodología de estimación de calidad de software (sistemas), cuyo

propósito no es sólo aplicarla al proceso en cuestión, sino proponerla como una

metodología estándar. Dicha metodología comprende la evaluación de diversos

aspectos funcionales y técnicos de los sistemas sujetos a selección, agrupados por

categorías, y está basada en estándares internacionales.

Las ventajas de desarrollar y aplicar una metodología de este tipo para los fines

ya descritos, radica en que puede ser mejorada en la medida que su aplicación sea

continua en los organismos de la AP, pues generará aprendizaje y conocimientos cuyo

análisis e interpretación permitirá adecuar conceptos, criterios, categorías, atributos e

instrumentos que se estén utilizando, además que establecerá prácticas de trabajo

inter-institucionales en materia de evaluación y selección de sistemas para la AP, que



sustenten la toma de decisiones y fomenten la cooperación entre organismos públicos.

En ese sentido, el presente informe tiene como propósito describir el trabajo

realizado por el CNTI, en lo relacionado a la metodología de estimación de calidad de

sistemas, diseño de los mecanismos de implementación, alternativas seleccionadas

para el proceso de evaluación (que en este caso corresponde a sistemas para la

gestión administrativa interna), características evaluadas (producto del esfuerzo de

profesionales expertos en las áreas funcionales y técnicas), resultados obtenidos

durante el proceso de evaluación, y las recomendaciones.

Por último, se anexan los cuestionarios respondidos por el grupo de expertos

evaluadores seleccionados para participar en el proceso (procedentes de organismos

de la AP , rectores en la materia), algunos de los cuales participaron no sólo con su

opinión, sino en la formulación y selección de nuevas características o métricas

evaluadas.



3. JUSTIFICACIÓN

El desarrollo y aplicación de la metodología aquí propuesta, y el proceso de

evaluación en sí, se justifican por varias razones:

● Por la necesidad de obtener resultados concretos y de impacto en el Plan de

Migración a Software Libre, replicables en el resto de la AP, y en particular en el

campo de las grandes aplicaciones o sistemas informáticos.

● Por la necesidad imperante de implantar un sistema de tipo ERP para su uso en

los organismos adscritos al MPPTI.

● Por la naturaleza del ambiente tecnológico en las instituciones de la AP, en el

sentido de que existen disponible una variedad de productos de software libre

que requieren ser evaluados según técnicas y criterios objetivos, a fin de

determinar su nivel de adecuación para satisfacer los requerimientos de estas

instituciones.

● Por darle cabal cumplimiento al cuerpo de políticas, lineamientos y leyes en

tecnologías de información, que se han dictado en el país en los últimos años y

en especial al Decreto N° 3.390, que deben traducirse en técnicas, criterios e

instrumentos aplicables a la evaluación y selección de productos de software

para las instituciones de la AP.

● Por la utilidad potencial de la aplicación de la metodología en organismos de la

AP en la medida que permita lo siguiente:

Medir Madurez, Tolerancia a Fallos y Recuperabilidad de los productos de

software para la AP, sobre la base de criterios objetivos.



Difundir terminologías y procedimientos en evaluación y selección de

productos de software entre organismos de la AP.

Desarrollar experticia para sustentar la toma de decisiones interinstitucional

pública vinculada al uso e instalación de software de uso común en la AP.

Establecer prácticas de trabajo institucionales alineadas con normas

internacionales (Ej. Normas ISO).

Mejorar la gestión de riesgos y de la calidad de procesos y productos de

software (para minimizar los factores de riesgo y detectar errores de análisis,

diseño e implementación de manera temprana).



4. OBJETIVO GENERAL

Ejecutar un proceso de selección y evaluación de sistemas de gestión

administrativa, con miras a determinar la alternativa que más se adapte a los

requerimientos del MPPTI, y sus organismos adscritos.

5. OBJETIVOS ESPECIFICOS

Diseñar e implementar una metodología de estimación de calidad para los

sistemas informáticos.

Diseño e implementar mecanismos o sistema para la aplicación de la

metodología.

Identificar un conjunto de alternativas para la automatización de la gestión

administrativa interna en el MPPTI y sus organismos adscritos.

Identificar las características funcionales y técnicas a ser evaluadas en las

alternativas seleccionadas.

Conformar los equipos de expertos técnicos y funcionales que llevarán adelante

el proceso de evaluación.

Definir y ejecutar el cronograma de sesiones de evaluación técnica y funcional,

conforme a la metodología seleccionada.

Generar el informe de calidad, con los resultados y recomendaciones.



6. PROPUESTA METODOLÓGICA

En el marco del proceso de evaluación llevado adelante por el CNTI, se propone

el uso de una nueva metodología, denominada Metodología de Estimación de la

Calidad del Software (MEECS), la cual utiliza el modelo integrado y simplificado

denominado Modelo de Estimación de la Calidad de Software (MOECS).

MEECS es el resultado de unificar en un conjunto de pasos:

● ISO 14598 (Modelo para el Proceso de Evaluación del Producto de Software)

[CNT001].

● CMMI (Capability Maturity Model Integration).

● INFOCAS (Integración Formal de Modelos de Calidad con Enfoque Sistémico)

[MOS001].

MOECS es el resultado de unificar en una matriz de calidad:

ISO 9126 (Modelo de Calidad Externa e Interna) [ABU001] y sus variantes (9241,

10741, 11581, 18019, 13407, 16982, 16071, 15910, 20282) [CNT001].

Mc Call (Modelo de Calidad de la Operación, Revisión y Transición del Producto

de Software) [PAZ001].

MOSCA (Modelo de Calidad Sistémica de Software) [MOS001].



6.1.Metodología (MEECS)

En la aplicación de la metodología participan tres equipos de trabajo cuyos roles

se describen a continuación:

Equipo de Calidad: se encarga de controlar y hacer seguimiento al proceso de

evaluación en cuanto a MEECS y el MOECS ajustado que se aplique. Deberá

estar formado en la aplicación de las normas en las que se basa MOECS.

Equipo Evaluador: se encarga de la preselección y evaluación del software por

medio de la aplicación de la MEECS suministrado por el equipo de calidad;

además de la revisión y presentación del informe de calidad al equipo

seleccionador.

Equipo Seleccionador: se encarga de la revisión y aprobación final del informe

de calidad, así como de la inclusión formal en dicho informe de la decisión del

equipo seleccionador respecto al software seleccionado por su nivel de calidad.

A continuación se listan y describen cada uno de los pasos de MEECS:

a) Preselección del Software

El equipo evaluador se dedicará a seleccionar los sistemas que serán sometidos

a la evaluación mediante la aplicación de MOECSA (MOECS ajustado según el tipo de

solución a evaluar). Esta preselección inicial se fundamenta en los requerimientos

básicos (iniciales) que deben cumplir el software en cuestión (es decir, El software a

evaluar debe ser de tipo ERP).



b) Ajuste del Modelo de Estimación de la Calidad de Software

El equipo de calidad de software procederá a refinar y revisar en forma conjunta

con todos los equipos restantes, la matriz de calidad de MOECS, a través de la

selección de las categorías, características y métricas1 para la creación de un modelo

ajustado denominado MOECSA (Ajustado al tipo de solución a evaluar, en este caso de

tipo ERP). Este ajuste permitirá determinar a través de un enfoque sistémico si el

software cumple eficiente y eficazmente con los requerimientos de diseño y de uso,

presentes y futuros.

c) Aplicación del Modelo de Calidad Ajustado

El equipo evaluador procederá a la ponderación de las métricas de MOECSA

debidamente escritas en cuestionarios para cada uno de los software preseleccionados.

Los cuestionarios contienen las métricas para cada rol del equipo evaluador al cual

están destinadas (usuarios finales, auditores, desarrolladores, líderes del proyecto,

etc.). La ponderación de las métricas se realiza de acuerdo a un grupos de opciones

con valores ascendentes “+” ó descendentes “-” (cuando se invierten los valores de las

opciones) (Véase en los apéndice Grupo de Opciones y Valores de las Métricas en

MOECS).

d) Elaboración de Informe de Calidad

El equipo evaluador procederá a elaborar y revisar en forma conjunta con todos

los equipos restantes, el informe de calidad, donde se representará a través de cuadros

y gráficos el resultado de haber aplicado MOECSA.

1 Véase apéndice B y C del presente informe.



Para realizar esto, se establecen los valores netos (%) obtenidos para cada una

de las características a través del promedio de los valores obtenidos en la métricas por

cuestionario y por software, y seguidamente, se establecen los valores netos (%)

obtenidos para cada categorías a través del promedio de los valores netos (%)

obtenidos para las características.

Finalmente, con los valores netos para cada una de las categorías y

características, recomendamos para la selección final, establecer los siguientes

indicadores:

Nivel de calidad por categoría/características: baja (0 - 49%), media (50 –

84%) ó alta (85 – 100%) - adaptación del modelo de Mc Call - [PAZ001].

Tasa de cumplimiento por categoría/características: no satisfecha (0 - X%) ó

satisfecha (X+1 a 100 %) siendo el nivel de satisfacción de X %, donde X es 60%

como mínimo - adaptación del modelo [MOS001].

e) Ejemplo del Cálculo de Métricas

Para verificar la teoría veamos un ejemplo práctico y supongamos que:

● Existe un (1) software A (Obviemos el subíndice c de la fórmula Ri,c, donde c diferencia a varios software en una evaluación).

● Existen dos (2) evaluadores E1 y E2 de índole funcional (m=2).

● Existen dos (2) métricas M1 y M2 de las cuales sabemos que son dirigidas a



evaluadores del tipo funcional (n=4, y además, i=”f” de “funcional”).

● La métrica M1 tiene tres (3) opciones: Opción 1. Bajo (0-33%), Opción 2. Medio (33-66%), Opción 3. Alto (66-100%).

● La métrica M2 tiene dos (2) opciones: Opción 1. Si (100-100%), Opción 2. No (0-0%).

● El mínimo (tope inferior) de la opción 2 de M1 es 33%.

● El máximo (tope superior) de la opción 2 de M2 es 0%)

● Y la siguiente matriz de opciones seleccionadas como respuestas a las preguntas de las métricas M1 y M2:

MétricaEvaluadores

E1 E2

M1 Bajo (0-33%) Medio (66-100%)

M2 No (0-0%) Si (100-100%)

Aplicando la fórmula con los Oijk donde:

i = “f” criterio funcional,j = {1, 2} evaluadores,k = {1, 2} métricas,

Tenemos lo siguiente:

O'f11 = | min(Of11) + max(Of11) | / 2O'f11 = | 0% + 33% | / 2 = 16,5%

O'f12 = | min(Of12) + max(Of12) | / 2O'f12 = | 0% + 0% | / 2 = 0%



O'f21 = | min(Of21) + max(Of21) | / 2O'f21 = | 66% + 100% | / 2 = 83,5%

O'f22 = | min(Of22) + max(Of22) | / 2O'f22 = | 100% + 100% | / 2 = 100%

m n

Ri,c = ∑ [( ∑ O'ijk) / n] j=1 k=1

Hacemos i=”f” y eliminamos la c (Software A, el único):

Rf = [(16,5% + 0%)/2] + [(83,5% + 100%)/2] = 50%

Lo que significa que el nivel de calidad obtenido por el software A en el aspecto funcional medido por las métricas M1 y M2 es de 50%.

6.2.- Modelo de Estimación de Calidad de Software (MOECS)

MOECS esta formado por un conjunto de características (o atributos esperados

de la solución), agrupadas por categorías y evaluadas a través de métricas (criterios)

capaces de ser expresadas en forma numérica asociadas a factores internos y externos

relativos al producto (el software) y al proceso (de desarrollo de software).

Los factores internos y externos del dominio del producto y del proceso que

tienen asociados las características se describen a continuación [MOS001]:

Factores Externos del Producto: se refieren a las actividades de identificación

de requerimientos, diseño de interfaces y diseño general de la plataforma, debido

a que la misma está relacionada con la adecuación y comodidad del usuario.



Factores Internos del Producto: se refieren a las actividades de diseño interno

y programación, ya que un producto eficiente es alcanzado cuando se aplican las

prácticas correctas de diseño y programación en su desarrollo.

Factores Externos del Proceso: se refieren a las actividades generales de

gerencia, tales como liderazgo, administración de cambio, relaciones humanas y

grupales, ya que las mismas conducen a establecer buenas relaciones entre los

integrantes del equipo responsable del desarrollo de software.

Factores Internos del Proceso: se refieren a las actividades de gerencia de

proyectos, las cuales incluyen el cumplimiento de fechas de entrega, aumento de

la productividad y ahorro de recursos.

Matriz de Calidad Ajustada a Software de tipo ERP (MOECSA)

En el Apéndice E, de este documento podemos conocer la matriz de calidad

propuesta original de MOECS, sobre la cual, se deberá hacer la refinación de

categorías y características a ajustar e incluir en MOECSA, de acuerdo al tipo de

sistema a evaluar. La matriz de calidad de MOECSA ajustada para soluciones de tipo

ERP, sobre la cual, se definirán el conjunto de métricas que permitirán estimar la calidad

del Software, se muestra a continuación:



7. MECANISMO DE APLICACIÓN DE LA METODOLOGÍA (SAMOECS)

El Sistema para la Aplicación del Modelo de Estimación de la Calidad de

Software (SAMOECS), es una aplicación Web desarrollada por el CNTI, con el objeto

de automatizar el proceso de evaluación. Entre las funcionalidades de este sistema se

destacan las siguientes:

● Registro Electrónico de los diferentes evaluadores.

● Aplicación electrónica de los cuestionarios de evaluación dependiendo del rol al



-

-

- - - -

Categorías del Producto

Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

Características Externas

Adecuación, Exactitud,

Interoperabilidad, Seguridad,

Conformidad

Madurez, Toleracia a Fallos, Recuperabilidad

Compresibilidad, Fac. Aprendizaje, Interfaz Gráfica,

Operabilidad.

Tiempo y Recursos

Cap. de Análisis, de Cambio, de

Pruebas, Estabilidad

Adaptabilidad, Fac. Instalación,

Conformidad

Características Internas

Estructurado, Especificado

CorrectoCompleto, Efectivo,

Documentado.

Acoplado, Cohesivo,

Encapsulado, Simple,

Estructurado, Descriptivo,

Modular

Parametrizado, Documentado,

Categorías del Proceso de Desarrollo

Cliente – Proveedor Ingeniería Soporte Gestión Organizacional


Adquisión DesarrolloResolución de

Problemas

Lineamiento Org., Mejoramiento del

Proceso


Documentación, Gestión de la

Conf.,

cual van dirigidas las métricas de los mismos (funcional o técnica) .

● Emisión de actas finales de evaluación para cada uno de los evaluadores y por

software.

● Generación de reportes dinámicos, estadísticos con los resultados de la

evaluación (tablas y gráficos).



8. SISTEMAS DE GESTIÓN ADMINISTRATIVA INTERNA SELECCIONADOS PARA EL PROCESO DE EVALUACIÓN

Para el caso que nos compete, un Sistema de Gestión Administrativa, Sistema

de Gestión Gubernamental, o ERP -como es llamado por algunos expertos- debe

automatizar (al menos), de manera integrada, los procesos de:

● Presupuesto (Formulación/Planificación)

● Compras

● Ordenación de Pagos

● Tesorería

● Cuentas por Cobrar

● Cuentas por Pagar

● Inventario

● Almacén

● Activo Fijo

● Contabilidad

● Ingresos Propios (si aplica al organismo)

● Recursos Humanos (preferiblemente)

● Gestión de Proyectos

● Producción (si aplica al organismo)

● Control de Obras (si aplica al organismo)

● Entre otros.



A través de estos sistemas se puede formular el presupuesto de la institución,

ejecutar el mismo a través de los procesos de compras, ordenación de pagos, tesorería,

y mantener la situación presupuestaria y contable actualizada de manera automática, a

partir de las operaciones realizadas en los procesos mencionados anteriormente.

Este tipo de sistemas generalmente son producto de desarrollos particulares y

son utilizados en las organizaciones bajo licenciamiento “copyright”, se caracterizan por

su alta complejidad dado el alto número de procesos que cubren, dependen de la

utilización de grandes capacidades tecnológicas de procesamiento y almacenamiento, y

requieren complejos procesos de instalación y configuración.

Además de los requerimientos funcionales generales mencionados

anteriormente, el ordenamiento legal vigente establece la utilización, de manera

prioritaria, de software libre en los organismos de la AP, de manera que este es un

requisito adicional a tomar en cuenta a la hora de realizar la preselección.

Sin embargo, un altísimo porcentaje de las alternativas disponibles están

diseñadas para operar sobre plataformas basadas en software propietario, lo cual

reduce enormemente la disponibilidad de soluciones que cumplen con los

requerimientos iniciales. Es así, que durante el año 2007 el CNTI se ha dedicado a la

tarea de buscar alternativas para este tipo de aplicaciones, desarrolladas y licenciadas

bajo los lineamientos del ordenamiento legal establecido.

La preselección inicial de sistemas quedó conformada por las siguientes

alternativas:

● SAI (Sistema desarrollado por la Fundación Instituto de Ingeniería, organismo



adscrito al Ministerio del Poder Popular para la Ciencia y la Tecnología, y en

proceso de implantación en esta institución, adicionalmente han desarrollado una

versión para el Instituto Postal Telegráfico de Venezuela, IPOSTEL).

● K2B ERP (Sistema adquirido por el CNTI a través del convenio de cooperación

energética entre Uruguay – Venezuela, actualmente CVG dispone de una

versión parametrizada de dicho software).

● SIGESP (Sistema Integrado de Gestión Pública, en funcionamiento en el

Ministerio del Poder Poder para la Cultura y sus organismos adscritos).

A continuación se describen brevemente las alternativas a ser evaluadas, de

acuerdo a la información suministrada por el proveedor:



8.1. SAINombre SAI

Descripción SAI es un sistema desarrollado para la planificación de recursos empresariales y gestión de todos los procesos administrativos de una organización de tipo “Administración CENTRAL”. Basado en el sistema administrativo de LA FUNDACION INSTITUTO DE INGENIERIA, pero adaptado a los procesos administrativos y convertido a herramientas de Software Libre por requerimiento del Ministerio de Ciencia y Tecnología.

Módulos/Procesos ✔ Presupuesto

✔ Compras

✔ Contabilidad

✔ Transporte

✔ Inventario

✔ Boleto

✔ Memo

✔ Tesorería

✔ Servicios

✔ Caja Chica

✔ Bienes Nacionales

✔ Viáticos

✔ Punto de Cuenta

Plataforma Linux/Apache/JavaScript/PHP/PostgreSQL. Funciona vía WEB

Equipo desarrollador FUNDACION INSTITUTO DE INGENIERIA (http://www.fii.org)



Nombre SAI

Comentarios Características más resaltantes:

✔ Incluye Módulo de PUNTOS DE CUENTA✔ Basado en esquema de trabajo tipo “Workflow”. Todo se hace desde

una bandeja de entrada similar a la de un gestor de correo-e✔ AUTENTICACION LDAP, lo cual facilita y permite mantener centralizado

el proceso de administración de usuarios.✔ Mecanismos de seguridad para seguimiento de documentos físicos

(anexos).✔ Incorporación de Firmas Electrónicas✔ Adaptado a la nueva moneda “BOLIVAR FUERTE”✔ Con respecto al licenciamiento, se espera sea liberado bajo algún tipo

de licencia libre, aunque la misma no se ha especificado aún.

8.2. K2B ERPNombre K2B, ERP

Descripción K2B ERP es un producto que contiene un importante conocimiento de los procesos de “negocio” de las organizaciones de hoy, asegurando no solamente acompañar los cambios de la organización sino también promoverlos haciendo a la empresa más competitiva.

Módulos/Procesos ✔ Planificación del Presupuesto

✔ Compras y Suministros

✔ Almacén

✔ Activo Fijo

✔ Cuentas x Pagar

✔ Cuentas x Cobrar

✔ Contabilidad

✔ Tesorería

✔ RRHH (opcional)

✔ Gestión de Proyectos (opcional)

✔ Expedientes (opcional)

Plataforma Linux/Apache/Apache TOMCAT/Java J2EE/PostgreSQL/MySQL. Funciona vía WEB. Certificado su funcionamiento para SUSE Enterprise 9

Equipo desarrollador Genexus INTERNACIONAL (http://www.genexusconsulting.com)



Nombre K2B, ERP

URL http://www.genexusconsulting.com

Comentarios K2B es un sistema que entra en la categoría de los ERP (“Enterprise Resource Planning”). Está diseñado con tecnología de última generación, permitiendo:

Organizar y controlar automáticamente los procesos de la empresa utilizando tecnología de workflow

Ajustar la aplicación en tiempo de ejecución adaptándose rápidamente a los cambios de la empresa y del mercado.

Trabajar con el concepto de “Organización Extendida” o “Extranet”, de forma tal de involucrar a clientes, proveedores, y socios de negocio en general en los procesos B2B.

Integrarse al resto de las aplicaciones de la empresa bajo el concepto de “servicios”.

Brindar información de gestión y estratégica para los niveles gerenciales y de gestión utilizando tecnología de Business Intelligence.

Dar más flexibilidad en la gestión organizacional: K2B está construido como una plataforma altamente adaptable (meta ERP) que permite su adaptación a las necesidades específicas de cada país (localización), industria (especialización), y cliente (personalización).

Otras características resaltantes:

✔ Multi-empresa

✔ Multi-moneda

✔ Orientación a Procesos

✔ Orientación a Servicios

✔ Integración vía Portal

Producto opera bajo plataformas libres. Sin embargo su mantenimiento depende de herramientas que funcionan sólo bajo Windows. Libertad de uso y replicación en el territorio nacional.



8.3.SIGESPNombre SIGESP

Descripción SIGESP es un sistema administrativo integrado, conformado por una serie de módulos, los cuales una vez implantados, permiten dar respuesta inmediata y oportuna a las necesidades de registro presupuestario, patrimonial, contable y administrativo en las organizaciones públicas, tales como: ministerios, gobernaciones, alcaldías, institutos autónomos, sociedades anónimas, asociaciones civiles, servicios autónomos sin personalidad jurídica, etc.

Módulos/Procesos ✔ Planificación Estratégica y Formulación de Presupuestos.✔ Contabilidad Presupuestaria de Gastos.✔ Contabilidad Presupuestaria de Ingresos, Contabilidad Financiera.✔ Rentas Municipales.✔ Facturación para Hidrológicas.✔ Solicitud de Ejecución Presupuestaria.✔ Compras y Almacén.✔ Ordenación de Pagos.✔ Caja y Bancos.✔ Personal.✔ Indicadores de Gestión.✔ Proveedores, Beneficiarios y Contratistas.✔ Registro y Seguimiento de Obras y Contratos.✔ Activos Fijos o Bienes.

Plataforma Linux/Apache/PHP/Mysql o PostgreSQL. Funciona vía WEB

Proveedor SIGESP C.A. (http://www.sigesp.com)

Comentarios Sistema desarrollado bajo herramientas de software libre, pero su uso está regido por el licenciamiento establecido por el proveedor.

Tipos de instituciones donde ha sido instalado:

✔ Educativas.✔ Hidrológicas.✔ Vivienda y Desarrollo Urbano.✔ Cultura y Deporte.✔ Financieras de Apoyo Agrícola y Comercial✔ Instituciones de Turismo.✔ Instituciones de Desarrollo Social.✔ Instituciones de Aviación Civil y Transporte.✔ Seguridad Pública✔ Gobernaciones y Alcaldías



9. ASPECTOS FUNCIONALES Y TÉCNICOS EVALUADOS

Las métricas de índole técnica a ser evaluadas fueron definidas por expertos en

últimas tecnologías, en particular en aplicaciones orientadas a la Web, software libre,

arquitectura orientada a servicios y Facilidad de uso. De manera similar, las

características o métricas funcionales fueron determinadas por otro grupo de expertos

en procesos y procedimientos dentro de la AP, quienes se apoyaron en el ordenamiento

legal existente, y en su experiencia como funcionarios públicos, algunos de ellos con

amplia trayectoria en organismos rectores en la materia.

El Apéndice B de este documento muestra todas las métricas técnicas y

funcionales que fueron evaluadas en este proceso, las cuales conforman, organizadas

por característica y categoría, la matriz del modelo de estimación de calidad MOECS.



10. INSTITUCIONES PARTICIPANTES. EQUIPOS DE TRABAJO

El CNTI, con el propósito de hacer de éste un proceso transparente y abierto, ha

incorporando el talento humano perteneciente a instituciones del estado rectoras tanto

en los procesos como en la materia tecnológica, contando con la participación de las

siguientes instituciones en la evaluación:

● Ministerio del Poder Popular de Finanzas (MPPF)

● Oficina Nacional del Tesoro (ONT)

● Oficina Nacional de Presupuesto (ONAPRE)

● Electrificación del Caroní (EDELCA)

● Oficina Nacional de Contabilidad Pública (ONCOP)

Además, participaron profesionales de diferentes Gerencia del CNTI, y otras

personas en calidad de consultores independientes en el área tecnológica,

conformando equipos de la siguiente forma:

● Equipo de Calidad: conformado por el personal del CNTI de la Gerencia

General de Ingeniería de Software, Gerencia General de Automatización y

Procesos, Gerencia General de Planificación y Presupuesto, Gerencia General

de Gestión de Proyectos, Gerencia General de Informática y

Telecomunicaciones, y otras unidades administrativas de esta Institución. Este

equipo actuó en calidad de planificadores del proceso, en la conformación de la

plataforma tecnológica para la instalación de los sistemas, asesoría técnica a los

proveedores de las soluciones durante la instalación, soporte tecnológico,



diseñadores de los mecanismos de aplicación del metodología, moderadores de

las sesiones de evaluación, logística de apoyo y otras actividades.

Equipo Evaluador: quedó conformado por personal de la Gerencia General de

Ingeniería de Software, la Gerencia General de Automatización y Procesos, La

Gerencia General de Planificación y Presupuesto, la Gerencia General de

Informática y Telecomunicaciones del CNTI, los delegados de las instituciones

participantes, mencionadas al comienzo de esta sección. Además, durante el

proceso, participó personal de los responsables de cada sistema evaluado, como

apoyo a la labor de los evaluadores.

Equipo Seleccionador: conformado por personal de la alta directiva del CNTI y

representantes de alto nivel provenientes de organismos de la AP, quienes

analizarán los resultados de la evaluación y tomarán las decisiones

correspondientes.



11. PROCESO DE EVALUACIÓN Y CRONOGRAMA DE EJECUCIÓN.

La conformación de la plataforma tecnológica de soporte al proceso de

evaluación (instalación de servidores y software de base, sistemas a evaluar,

mecanismos de implementación de la metodología), se llevó a cabo entre el 5 y el 7 de

Septiembre de 2007.

Las sesiones de evaluación técnica y funcional de los sistemas preseleccionados

se llevaron a cabo, entre el 10 de Septiembre y el 2 de Octubre de 2007, en la sede de

la Academia de Software Libre del CNTI, de acuerdo al siguiente cronograma:

10 al 14 de Septiembre de 2007



Mañana

Lunes 10 Martes 11 Miércoles 12 Jueves 13 Viernes 14

Evaluación TECNICA SAI (E)

Ajustes INSTALACION

K2B

Evaluación FUNCIONAL SAI (no ejecutada por

problemas técnicos)

Evaluación FUNCIONAL SAI (E)


TardeAjustes

INSTALACION K2B

Evaluación TECNICA SAI (E)

Evaluación TECNICA SAI (adicional x problemas

técnicos) (E)

Evaluación TECNICA K2B (E)

Evaluación TECNICA K2B (E)



01 al 05 de Octubre de 2007

Como herramienta de apoyo en la aplicación de la metodología, se utilizó el

mecanismo mencionado en el punto 7 (sistema SAMOECS), desarrollado por el CNTI

durante la ejecución de este proyecto. Los evaluadores recibieron la respectiva

inducción en el uso del herramienta en las primeras sesiones de evaluación técnica y



Mañana



Evaluación FUNCIONAL SIGESP

(E)

Tarde

Mañana


Evaluación FUNCIONAL K2B

(suspendida)

Evaluación FUNCIONAL K2B(E)


Evaluación FUNCIONAL SIGESP(E)

Evaluación FUNCIONAL SIGESP(E)

TardeAjustes a la

instalación de SIGESP

Ajustes a la instalacion de

SIGESP

Evaluación TECNICA SIGESP(E)

Evaluación TECNICA

SIGESP(E)

Mañana



funcional, en las cuales también se explicó la dinámica de desarrollo de las actividades

(formulación y explicación de las preguntas por parte de los moderadores, respuestas

por parte del personal de las empresas proveedoras, solicitud de aclaratorias y

demostraciones de parte de los evaluadores, y registro de la opinión acerca de cada

métrica, a través del sistema SAMOECS).

La información registrada por los evaluadores quedó almacenada en una base

de datos, a partir de la cual, de acuerdo a la ponderación establecida para cada métrica

según el Apéndice D, podrán generarse los resultados en forma automática (totales y

por tipo de evaluación para cada alternativa evaluada)



12. RESULTADOS OBTENIDOS

Debido a que los valores de las respuestas no son valores discretos sino rangos

de valores para cada opción (Véase Apéndice D), los cuales, tienen un valor mínimo

(tope inferior) y máximo (tope superior). Los resultados de la evaluación se obtienen

calculando el promedio (Prom. %) de los valores de todas las respuestas, donde el

valor de cada respuesta es igual al promedio de los topes de la opción seleccionada

para la misma.

Así mismo, el promedio de los topes inferiores es "Prom. Mín. %" y el de los

superiores es "Prom. Máx. %", por lo tanto, debe considerarse que el resultado "Prom.

%" es un valor estimado que oscila en un rango acotado.

12.1. Nivel de Calidad Obtenido por Software



Ref. # Software Prom. (%) Prom./Mín. (%) Prom./Máx. (%)

R 1 SAI - 2007 51.30 46.90 55.69

R 1 K2B - 2007 63.60 58.34 68.85

R 1 SIGESP - 2007 44.22 39.79 48.65

Esta gráfica muestra los resultados obtenidos a nivel global (nivel de calidad obtenido), sin ninguna clasificación específica por cada alternativa evaluada.

12.2 Nivel de Calidad Obtenido por Dominio

Ref. # Dominio Software Prom. (%) Prom./Mín. (%) Prom./Máx. (%)

R1 Proceso SAI - 2007 67.01 62.07 71.94

R1 Proceso K2B - 2007 75.67 70.50 80.83

R1 Proceso SIGESP - 2007 50.00 44.61 55.39

R2 Producto SAI - 2007 50.82 46.45 55.20

R2 Producto K2B - 2007 63.23 57.97 68.48

R2 Producto SIGESP - 2007 44.04 39.64 48.43



Esta gráfica muestra los resultados obtenidos (nivel de calidad obtenido), por cada alternativa evaluada, clasificados por “dominio” de la evaluación (R1=proceso de desarrollo del software, R2= características o métricas del software)

12.3 Nivel de Calidad Obtenido por Roles (de Evaluadores)

Ref. # Rol Software Prom. (%) Prom./Mín. (%) Prom./Máx. (%)

R1 Funcional SAI - 2007 44.42 40.08 48.75

R1 Funcional K2B - 2007 56.65 51.17 62.14

R1 Funcional SIGESP - 2007 41.75 37.42 46.08

R2 Técnico SAI - 2007 68.79 64.25 73.34

R2 Técnico K2B - 2007 81.22 76.55 85.89

R2 Técnico SIGESP - 2007 50.47 45.80 55.13



Esta gráfica muestra los resultados obtenidos (nivel de calidad obtenido) por cada alternativa evaluada, clasificados por tipo de evaluación – o rol del evaluador – (R1=funcional, R2=técnico)



12.4 Nivel de Calidad Global Obtenido en la Categoría de “Funcionalidad” para la Característica de “Adecuación (Funcional)”, por Software.

Ref. #

SoftwareProm.

(%)Prom./Mín.

(%)Prom./Máx.

(%)

R1 SAI - 2007 44.37 40.74 48.00

R1 K2B - 2007 57.88 52.85 62.90

R1SIGESP - 2007

42.05 38.30 45.80

Esta gráfica muestra los resultados obtenidos (nivel de calidad obtenido) por cada alternativa evaluada, para todas las métricas relacionadas a los aspectos funcionales.



12.5 Nivel de Calidad Obtenido en la Categoría de “Funcionalidad” para todas las Características de “Adecuación (Funcional)” por Software.

Ref. # Característica Software Prom. (%) Prom./Mín. (%)

Prom./Máx. (%)

R1 Adecuación del Módulo de Adquisiciones

SAI - 2007 83.33 82.29 84.37


K2B - 2007 78.82 77.78 79.86


SIGESP - 2007

75.00 73.96 76.04

R2 Adecuación del Módulo de Almacén SAI - 2007 77.78 74.07 81.48

R2 Adecuación del Módulo de Almacén K2B - 2007 80.86 77.16 84.57

R2 Adecuación del Módulo de Almacén SIGESP - 2007

65.43 61.73 69.13

R3 Adecuación del Módulo de Bienes Nacionales

SAI - 2007 73.81 72.22 75.40


K2B - 2007 64.29 64.29 64.29


SIGESP - 2007

39.29 37.30 41.27

R4 Adecuación del Módulo de Contabilidad SAI - 2007 71.74 64.73 78.74

R4 Adecuación del Módulo de Contabilidad K2B - 2007 73.91 66.67 81.16

R4 Adecuación del Módulo de Contabilidad SIGESP - 2007

69.80 62.56 77.05

R5 Adecuación del Módulo de Control Interno

SAI - 2007 63.13 46.46 79.79


K2B - 2007 49.24 32.83 65.65


SIGESP - 2007

26.77 15.66 37.88

R6 Adecuación del Módulo de Evaluación SAI - 2007 8.80 8.33 9.26

R6 Adecuación del Módulo de Evaluación K2B - 2007 34.49 31.94 37.04

R6 Adecuación del Módulo de Evaluación SIGESP - 2007

2.31 1.39 3.24



R7 Adecuación del Módulo de Ingresos SAI - 2007 0.00 0.00 0.00

R7 Adecuación del Módulo de Ingresos K2B - 2007 13.89 12.96 14.81

R7 Adecuación del Módulo de Ingresos SIGESP - 2007

29.17 28.70 29.63

R8 Adecuación del Módulo de Obras SAI - 2007 0.00 0.00 0.00

R8 Adecuación del Módulo de Obras K2B - 2007 65.51 53.24 77.78

R8 Adecuación del Módulo de Obras SIGESP - 2007

41.20 31.48 50.92

R9 Adecuación del Módulo de Presupuesto SAI - 2007 49.24 47.08 51.39

R9 Adecuación del Módulo de Presupuesto K2B - 2007 54.03 50.83 57.22

R9 Adecuación del Módulo de Presupuesto SIGESP - 2007

27.43 26.53 28.33

R10 Adecuación del Módulo de RRHH SAI - 2007 4.17 2.08 6.25

R10 Adecuación del Módulo de RRHH K2B - 2007 71.18 68.05 74.31

R10 Adecuación del Módulo de RRHH SIGESP - 2007

42.19 39.93 44.44

R11 Adecuación del Módulo de Tesorería SAI - 2007 44.13 36.42 51.85

R11 Adecuación del Módulo de Tesorería K2B - 2007 50.46 42.28 58.64

R11 Adecuación del Módulo de Tesorería SIGESP - 2007

37.81 30.55 45.06

R12 Adecuación del Módulo Generador de Reportes

SAI - 2007 79.36 76.98 81.75


K2B - 2007 85.71 80.95 90.48


SIGESP - 2007

69.05 66.67 71.43



Esta gráfica muestra los resultados obtenidos (nivel de calidad obtenido) por cada alternativa evaluada, clasificados por las categorías (R1,R2,R3,.....,R12), las cuales agrupan todas las métricas o características evaluadas.



12.6 Resultados de la Evaluación por Categoría de Calidad

Ref. # Categoría Software Prom. (%) Prom./Mín. (%) Prom./Máx. (%)

R 1 Cliente - Proveedor SAI - 2007 72.67 72.00 73.33

R 1 Cliente - Proveedor K2B - 2007 78.20 76.92 79.49

R 1 Cliente - Proveedor SIGESP - 2007 67.28 65.43 69.14

R 2 Eficiencia SAI - 2007 72.22 69.44 75.00

R 2 Eficiencia K2B - 2007 85.42 81.94 88.89

R 2 Eficiencia SIGESP - 2007 50.00 47.22 52.78

R 3 Fiabilidad SAI - 2007 76.19 69.05 83.33

R 3 Fiabilidad K2B - 2007 87.30 80.16 94.44

R 3 Fiabilidad SIGESP - 2007 65.87 58.73 73.01

R 4 Funcionalidad SAI - 2007 46.59 42.42 50.76

R 4 Funcionalidad K2B - 2007 58.60 53.38 63.81

R 4 Funcionalidad SIGESP - 2007 41.69 37.52 45.86

R 5 Ingeniería SAI - 2007 100.00 100.00 100.00

R 5 Ingeniería K2B - 2007 100.00 100.00 100.00

R 5 Ingeniería SIGESP - 2007 0.00 0.00 0.00

R 6 Mantenibilidad SAI - 2007 61.83 55.55 68.11

R 6 Mantenibilidad K2B - 2007 88.72 82.22 95.22

R 6 Mantenibilidad SIGESP - 2007 41.61 35.11 48.11

R 7 Organizacional SAI - 2007 35.65 20.37 50.92

R 7 Organizacional K2B - 2007 43.05 27.78 58.33

R 7 Organizacional SIGESP - 2007 56.94 41.66 72.22

R 8 Portabilidad SAI - 2007 54.38 45.61 63.16

R 8 Portabilidad K2B - 2007 69.74 60.96 78.51

R 8 Portabilidad SIGESP - 2007 47.08 38.30 55.85

R 9 Soporte SAI - 2007 60.65 50.93 70.37

R 9 Soporte K2B - 2007 84.72 75.00 94.44



R 9 Soporte SIGESP - 2007 24.54 14.81 34.26

R 10 Facilidad de uso SAI - 2007 78.83 76.28 81.38

R 10 Facilidad de uso K2B - 2007 84.98 82.28 87.69

R 10 Facilidad de uso SIGESP - 2007 62.76 60.06 65.46

Esta gráfica muestra los resultados obtenidos (nivel de calidad obtenido) por cada alternativa evaluada, clasificados por las categorías (R1,R2,R3,.....R10,), las cuales agrupan todas las métricas o características evaluadas.



12.7 Resultados de la Evaluación Sobre las Funcionalidades

Esta gráfica muestra los resultados obtenidos (nivel de calidad obtenido), por cada alternativa evaluada relacionada con la funcionalidad, aquí se incluye las características funcionales consideradas por el equipo evaluador técnico como: ( especificado,interoperabilidad, adecuación, seguridad), clasificados por las categorías (R1,R2,R3,.....R17,), las cuales agrupan todas las métricas o características evaluadas en la funcionalidad de cada solución.



Ref. #

Característica Software Prom. (%) Prom./Mín. (%)

Prom./Máx. (%)

R 1 Adecuación (Técnica) SAI - 2007 100.00 100.00 100.00

R 1 Adecuación (Técnica) K2B - 2007 83.33 83.33 83.33

R 1 Adecuación (Técnica) SIGESP - 2007 0.00 0.00 0.00

R 2 Adecuación del Modulo de Adquisiciones SAI - 2007 83.33 82.29 84.37

R 2 Adecuación del Modulo de Adquisiciones K2B - 2007 78.82 77.78 79.86

R 2 Adecuación del Modulo de Adquisiciones SIGESP - 2007 75.00 73.96 76.04

R 3 Adecuación del Modulo de Almacén SAI - 2007 77.78 74.07 81.48

R 3 Adecuación del Modulo de Almacén K2B - 2007 80.86 77.16 84.57

R 3 Adecuación del Modulo de Almacén SIGESP - 2007 65.43 61.73 69.13

R 4Adecuación del Modulo de Bienes Nacionales

SAI - 2007 73.81 72.22 75.40

R 4 Adecuación del Modulo de Bienes Nacionales K2B - 2007 64.29 64.29 64.29

R 4 Adecuación del Modulo de Bienes Nacionales SIGESP - 2007 39.29 37.30 41.27

R 5 Adecuación del Modulo de Contabilidad SAI - 2007 71.74 64.73 78.74

R 5 Adecuación del Modulo de Contabilidad K2B - 2007 73.91 66.67 81.16

R 5 Adecuación del Modulo de Contabilidad SIGESP - 2007 69.80 62.56 77.05

R 6 Adecuación del Modulo de Control Interno SAI - 2007 63.13 46.46 79.79

R 6 Adecuación del Modulo de Control Interno K2B - 2007 49.24 32.83 65.65

R 6 Adecuación del Modulo de Control Interno SIGESP - 2007 26.77 15.66 37.88

R 7 Adecuación del Modulo de Evaluación SAI - 2007 8.80 8.33 9.26

R 7 Adecuación del Modulo de Evaluación K2B - 2007 34.49 31.94 37.04

R 7 Adecuación del Modulo de Evaluación SIGESP - 2007 2.31 1.39 3.24

R 8 Adecuación del Modulo de Ingresos SAI - 2007 0.00 0.00 0.00

R 8 Adecuación del Modulo de Ingresos K2B - 2007 13.89 12.96 14.81

R 8 Adecuación del Modulo de Ingresos SIGESP - 2007 29.17 28.70 29.63

R 9 Adecuación del Modulo de Obras SAI - 2007 0.00 0.00 0.00

R 9 Adecuación del Modulo de Obras K2B - 2007 65.51 53.24 77.78

R 9 Adecuación del Modulo de Obras SIGESP - 2007 41.20 31.48 50.92

R 10 Adecuación del Modulo de Presupuesto SAI - 2007 49.24 47.08 51.39

R 10 Adecuación del Modulo de Presupuesto K2B - 2007 54.03 50.83 57.22



R 10 Adecuación del Modulo de Presupuesto SIGESP - 2007 27.43 26.53 28.33

R 11 Adecuación del Modulo de RRHH SAI - 2007 4.17 2.08 6.25

R 11 Adecuación del Modulo de RRHH K2B - 2007 71.18 68.05 74.31

R 11 Adecuación del Modulo de RRHH SIGESP - 2007 42.19 39.93 44.44

R 12 Adecuación del Modulo de Tesorería SAI - 2007 44.13 36.42 51.85

R 12 Adecuación del Modulo de Tesorería K2B - 2007 50.46 42.28 58.64

R 12 Adecuación del Modulo de Tesorería SIGESP - 2007 37.81 30.55 45.06

R 13Adecuación del Modulo Generador de Reportes

SAI - 2007 79.36 76.98 81.75


K2B - 2007 85.71 80.95 90.48


SIGESP - 2007 69.05 66.67 71.43

R 14 Conformidad SAI - 2007 50.66 35.55 65.77

R 14 Conformidad K2B - 2007 40.44 28.00 52.88

R 14 Conformidad SIGESP - 2007 43.55 30.22 56.89

R 15 Especificado SAI - 2007 66.67 66.67 66.67

R 15 Especificado K2B - 2007 100.00 100.00 100.00

R 15 Especificado SIGESP - 2007 66.67 66.67 66.67

R 16 Interoperabilidad SAI - 2007 68.18 66.67 69.70

R 16 Interoperabilidad K2B - 2007 74.24 72.73 75.76

R 16 Interoperabilidad SIGESP - 2007 19.70 18.18 21.21

R 17 Seguridad SAI - 2007 62.80 59.90 65.70

R 17 Seguridad K2B - 2007 78.74 75.84 81.64

R 17 Seguridad SIGESP - 2007 46.86 43.96 49.76



CONSIDERACIONES Y RECOMENDACIONES FINALES

MEECS y MOECS para la evaluación de la calidad de software pueden ser

sustituidos por otros estándares compatibles con ISO 9126, siempre y

cuando los mismos cumplan con los lineamientos del Plan Nacional de Migración

a software libre, y sea fácil la comprobación de su completitud y objetividad para

el proceso de estimación de la calidad del software.

El conjunto de características de MOESC se debe considerar como un modelo

de estimación de la calidad y no como una determinación absoluta de la

misma.

El conjunto de características de MOESC (referido anteriormente) no es

definitivo y deberá ser revisado, antes de su aplicación en los procesos

evaluación, con la finalidad de garantizar su completitud y correspondencia a los

requerimientos del Estado Venezolano.

De acuerdo a los resultados obtenidos, K2B, es el sistema con mayores

bondades técnicas y funcionales (estableciendo las funcionales como la

sumatoria de todas las características de las categorías del producto). La

categoría se encuentra dividido de acuerdo a producto y proceso de desarrollo,

en particular la funcionalidad tiene características externas e internas

relacionadas con la categoría del producto: la adecuación, exactitud,

interoperabilidad, seguridad, conformidad, estructurado y especificado. si nos



enfocamos a la funcionalidad desde la característica externa “Adecuación” el

K2B, debe ser adaptado a las necesidades de los organismos adscritos al

MPPTI. Sin embargo, su replicación en estas instituciones, y demás organismos

de la AP, debe estar sujeta a la eliminación del uso de herramientas

PROPIETARIAS de desarrollo, para su mantenimiento y escalabilidad funcional.



13. APENDICE A. CARACTERICTISCAS POR CATEGORIA DEL MODELO MOECS

Las categorías y características a evaluar a través de métricas asociadas a

factores internos y externos relativos al producto y al proceso se presentan a

continuación:


Categoría de Funcionalidad (FUN): Capacidad del producto del software para proveer

funciones que cumplan con las necesidades específicas, cuando el software es utilizado

bajo ciertas condiciones [MPG001].

Características relativas a factores externos:

FUN-01 Adecuación: Se enfoca a evaluar si el software cuenta con un

conjunto de funciones apropiadas para efectuar las tareas que fueron

especificadas en los requerimientos [ABU001].

FUN-02 Exactitud y Precisión: Este atributo permite evaluar el grado de

precisión con los que el software realizó los cálculos, presenta los resultados

o ejecuta las operaciones con sus efectos acordes a las necesidades para las

cuales fue creado [ABU001 y PAZ001].

FUN-03 Interoperabilidad: Permite evaluar la habilidad del software de

interactuar con otros sistemas previamente especificados [ABU001].



FUN-04 Conformidad: Evalúa si el software se adhiere a estándares,

convenciones o regulaciones en leyes, regulaciones, reglamentos y

prescripciones similares respecto de las funcionalidades que ofrece

[ABU001].

FUN-05 Seguridad: Se refiere a la habilidad de prevenir el acceso no

autorizado, ya sea accidental o premeditado, a los programas y datos

[ABU001].

Características relativas a factores internos:

FUN-06 Correctitud: se refiere a los atributos del software que garantizan el

cumplimiento de los contratos establecidos para cada funcionalidad (y

responsabilidad de los elementos, procesos o componentes) del mismo,

hasta dónde satisface un programa su especificación y logra los objetivos

propuestos por el cliente [PRES001], con respecto a la funcionalidad.

FUN-07 Estructurado: se refiere a los atributos del software que establece la

estructura de los datos, la información, los procesos y el control de flujo de los

mismo [PAZ001], con respecto a la funcionalidad.

FUN-08 Encapsulado: se refiere a los atributos del software que determinan

el grado de encapsulamiento (abstracción, ocultación y agrupación) de los

datos, información y operaciones similares (funcionalmente) dentro de los

elementos o componentes del software [PRE001], con respecto a la

funcionalidad.



FUN-09 Especificado: se refiere a los atributos del software que

proporcionan una traza o especificación formal desde los requisitos a la

implementación con respecto a un entorno operativo concreto [PAZ001].

Fiabilidad (FIA): Capacidad del producto de software para mantener un nivel

especificado de rendimiento cuando es utilizado bajo ciertas condiciones [MPG001].


FIA-01 Madurez: Permite medir la frecuencia de falla por errores en el

software [ABU001].

FIA-02 Tolerancia a fallas: Se refiere a la habilidad de mantener un nivel

específico de funcionamiento en caso de fallas del software o de cometer

infracciones de su interfaz específica [ABU001].

FIA-03 Recuperabilidad: Se refiere a la capacidad de restablecer el nivel de

operación y recobrar los datos que hayan sido afectados directamente por

una falla, así como al tiempo y el esfuerzo necesarios para lograrlo [ABU001].


FIA-04 Correcto: se refiere a los atributos del software que garantizan el


responsabilidad de los elementos, procesos o componentes) del mismo.

Hasta dónde satisface un programa su especificación y logra los objetivos

propuestos por el cliente [PRES001], con respecto a la fiabilidad.



FIA-04 Estructurado: se refiere a los atributos del software que establece la


mismo [PAZ001], con respecto a la fiabilidad.

FIA-05 Encapsulado: se refiere a los atributos del software que determinan



elementos o componentes del software [PRE001], con respecto a la fiabilidad.

Categoría de Facilidad de uso (USA): Capacidad del producto de software para ser

atractivo, entendido, aprendido y utilizado por el usuario bajo condiciones específicas

[MPG001].


USA-01 Comprensibilidad: Se refiere al esfuerzo requerido por los usuarios

para reconocer la estructura lógica del sistema y los conceptos relativos a la

aplicación del software [ABU001].

USA-02 Facilidad de Aprendizaje: Establece atributos del software relativos

al esfuerzo que los usuarios deben hacer para aprender a usar la aplicación

[ABU001].

USA-03 Interfaz Gráfica: Se refiere a las atributos mínimas (u óptimas) que

debe tener la interfaz gráfica de interacción con el usuario [ABU001].



USA-04 Capacidad de operar: Agrupa los conceptos que evalúan la

operación y el control del sistema [ABU001].

USA-05 Conformidad con los estándares: Permite evaluar si el software

se adhiere y/o coexiste en conformidad con estándares o convenciones

relativas a Facilidad de uso [ABU001].


USA-06 Completo: se refiere al conjunto de atributos de software que

proporcionan la implementación completa de todas las funciones requeridas

[PAZ001].

USA-07 Consistente: se refiere al conjunto de atributos del software que

proporcionan uniformidad en las técnicas y notaciones de diseño e

implementación [PAZ001].

USA-08 Efectivo: se refiere al conjunto de atributos del software que

determinan la satisfacción del usuario (el software hace lo que se le pide que

haga) [PAZ001], con respecto a la Facilidad de uso.

USA-09 Especificado: se refiere a los atributos del software que



USA-10 Documentado: se refiere a la documentación disponible para los

implicados en el uso y mantenimiento del software [PAZ001].



USA-11 Autodescriptivo: se refiere a los atributos del software que

proporcionan información sobre su operación, estado, registros, bitácoras,

logs, etc [PAZ001].

Categoría de Eficiencia (EFI): Capacidad del producto de software para proveer un

rendimiento apropiado, relativo a la cantidad de recursos utilizados, bajo condiciones

específicas [MPG001].


EFI-01 Comportamiento con respecto al Tiempo: Atributos del software

relativos a los tiempos de respuesta y de procesamiento de los datos

[ABU001].

EFI-02 Comportamiento con respecto a los Recursos: Atributos del

software relativos a la cantidad de recursos usados y la duración de su uso en

la realización de sus funciones [ABU001].


EFI-03 Efectivo: se refiere al conjunto de atributos del software que

determinan la satisfacción del usuario (el software hace lo que se le pide que

haga) [PAZ001], con respecto a la eficiencia.

EFI-04 No Redundante: se refiere al conjunto de atributos del sistema que

garantizan la no redundancia, las entidades con las cuales se hace referencia



y se utilizan los datos, la información y los procesos explícitos e implícitos del

software [PRE001].

EFI-05 Discreto: se refiere al conjunto de atributos del sistema que permiten

identificar unívocamente las entidades, con las cuales se hace referencia y

utilizan los datos, la información y los procesos explícitos e implícitos del

software [PRE001].

EFI-06 Utilizado: se refiere al conjunto de atributos del sistema que permiten

justificar y determinar el grado de utilización de cada una de las

funcionalidades ofrecidas por el sistemas (el sistema no contiene partes sin

fin o uso definido) [PRE001].

Categoría de Mantenibilidad (MAN): Capacidad del producto para ser modificado y

actualizado [MPG001].


MAN-01 Capacidad de Análisis: Relativo al esfuerzo necesario para

diagnosticar las deficiencias o causas de fallas, o para identificar las partes

que deberán ser modificadas [ABU001].

MAN-02 Capacidad de Cambio: Mide el esfuerzo necesario para modificar

aspectos del software, remover fallas, adaptar o expandir el software para

que funcione en un ambiente diferente [ABU001].

MAN-03 Estabilidad: Permite evaluar los riesgos de efectos inesperados.



debido a las modificaciones realizadas al software

MAN-04 Capacidad de Prueba: Se refiere al esfuerzo necesario para validar

el software una vez que fue modificado [ABU001].


MAN-05 Acoplado: se refiere a los atributos del software que determinan el

grado de relación (dependencia) entre los elementos o componentes de

distintos paquetes (se espera el menor grado de acoplamiento[PRE001].

MAN-06 Cohesivo: se refiere a los atributos del software que determinan el

grado de relación (similitud) entre los elementos o componentes colocados

dentro de un mismo paquete de software (se espera la mayor cohesión

posible)[PRE001].

MAN-07 Encapsulado: se refiere a los atributos del software que determinan

el grado de encapsulamiento(abstracción, ocultación y agrupación) de los


elementos o componentes del software[PRE001].

MAN-08 Conciso: Lo compacto que es el programa en términos de líneas de

código [PRE001].

MAN-09 Simple: El grado de facilidad con que se puede entender un

programa [PRE001].



MAN-10 Maduro: Permite medir la frecuencia de falla por errores en el

software [ABU001].

MAN-11 Estructurado: se refiere a los atributos del software que establece la


mismo [PAZ001].

MAN-12 Descriptivo: se refiere a los atributos de software que proporcionan

una descripción del código de implementación del mismo de forma sencilla,

clara, general y/o específica [PRE001].

MAN-13 Correcto: se refiere a los atributos del software que garantizan el


responsabilidad de los elementos, procesos o componentes) del mismo.

Hasta dónde satisface un programa su especificación y logra los objetivos

propuestos por el cliente [PRE001].

MAN-14 Modular: Atributos del software que proporcionan una estructura de

módulos altamente independientes [PAZ001].

Categoría de Portabilidad (POR): Capacidad del producto de software para ser

transferido de un ambiente de ejecución a otro [MPG001].


POR-01 Adaptabilidad: Evalúa la oportunidad para adaptar el software a



diferentes ambientes sin necesidad de aplicarle modificaciones. [ABU001].

POR-02 Facilidad de Instalación: Es el esfuerzo necesario para instalar el

software en un ambiente determinado [ABU001].

POR-03 Conformidad: Permite evaluar si el software se adhiere y/o

coexiste en conformidad con estándares o convenciones relativas a

portatilidad [ABU001].

POR-04 Capacidad de Reemplazo: Se refiere a la oportunidad y el

esfuerzo usado en sustituir el software por otro producto con funciones

similares [ABU001].


POR-05 Consistente: El empleo de un diseño uniforme y de técnicas de

documentación a lo largo del proyecto de desarrollo del software.

POR-06 Parametrizado: se refiere a los atributos del software que

determinan el grado de con el cual se puede cambiar la configuración del

mismo para su adaptación ejecución correcta en una nueva plataforma con el

menor impacto posible en su operación normal.

POR-07 Encapsulado: se refiere a los atributos del software que determinan



elementos o componentes del software[PRE001].



POR-08 Cohesivo: se refiere a los atributos del software que determinan el

grado de relación (similitud) entre los elementos o componentes colocados

dentro de un mismo paquete de software (se espera la mayor cohesión

posible)[PRE001].

POR-09 Especificado: se refiere a los atributos del software que



POR-10 Documentado: se refiere a la documentación disponible para los

implicados en el uso y mantenimiento del software [PAZ001].

POR-11 Autodescriptivo: Atributos del software que proporcionan

explicaciones sobre la Implementación de las funciones [PAZ001].

POR-12 No Redundante: se refiere al conjunto de atributos del sistema que

garantizan la no redundancia las entidades con las cuales se hace referencia

y se utilizan los datos, la información y los procesos explícitos e implícitos del

software [PRE001].

POR-13 Auditable: se refiere al conjunto de atributos del sistema que

proporcionan mecanismos para la auditoría formal e informal del mismo.

POR-14 Manejo de la Calidad: se refiere al conjunto de atributos del sistema

que garantizan la calidad de su operación en una nueva plataforma de

ejecución.



POR-15 Conciso: Lo compacto que es el programa en términos de líneas

de código [PRE001].

POR-16 Simple: El grado de facilidad con que se puede entender un

programa [PRE001].

Categorías del Proceso

Categoría Cliente – Proveedor (CLP): Esta conformada por procesos que impactan

directamente al cliente, apoya el desarrollo y la transición del Software hasta el cliente y

provee la correcta operación y uso del producto o servicio de software.


CLP-01 Adquisión: se refiere al proceso de adquisición por parte del cliente

y transferencia e implantación del producto por parte del proveedor.

CLP-02 Determinación de Requerimientos: se refiere al proceso mediante

el cual se establecen los requerimientos del producto por parte del proveedor,

que consiste en reunir procesar y hacer seguimiento de la evolución de las

necesidad y requerimientos.


CLP-03 Suministro: se refiere al proceso de suministro del original, las

modificaciones y adaptaciones del software al cliente.



CLP-04 Operación: se refiere al proceso que asegura la correctitud de la

operación del software durante el uso al que fue destinado y en el ambiente

donde fue instalado; es decir, especifica y hace seguimiento a las condiciones

de operación del producto. Asegura completitud y consistencia.

Categoría de Ingeniería (ING): Consiste en procesos directamente que especifican,

implementan o mantienen el producto de software, su relación con el Sistema y su

documentación.


ING-01 Desarrollo: se refiere a las características del proceso de generar el

software.


ING-02 Mantenimiento: se refiere a las características del proceso de

mantenimiento del software.

Categoría de Soporte (SOP): Consta de procesos que pueden ser empleados por

cualquiera de los procesos (incluyendo a los de soporte) en varios niveles del ciclo de

vida de adquisición.


SOP-01 Aseguramiento de la Calidad: se refiere a los procesos y



estándares de calidad aplicados en el proyecto de desarrollo de software, de

manera tal que los procesos del proyecto cumplan con los requerimientos

específicos y se adhieran a los planes establecidos.

SOP-02 Revisión Conjunta: se refiere a los procesos y estándares utilizados

para la revisión, validación, aceptación y certificación conjunta (cliente,

proveedor e interesados) del software.

SOP-03 Auditoría: se refiere a los procesos y estándares utilizados en la

auditoría del software para el establecimiento de su funcionalidad, fiabilidad,

etc.

SOP-04 Resolución de Problemas: se refiere a los procesos y estándares

utilizados en la resolución de problemas relativos al software.


SOP-05 Documentación: se refiere a los procesos y estándares utilizados en

la documentación del software.

SOP-06 Gestión de Configuración: se refiere a los procesos y estándares

utilizados en la gestión y documentación de la configuración del software.

SOP-07 Verificación: se refiere a los procesos y estándares utilizados en la

confirmación de las funcionalidades del software respecto de los

requerimientos especificados.



SOP-08 Validación: se refiere a los procesos y estándares utilizados en la

validación de las funcionalidades del software.

SOP-09 Revisión Conjunta: se refiere a los procesos y estándares utilizados

para la revisión, validación, aceptación y certificación conjunta (cliente,

proveedor e interesados) del software.

SOP-10 Auditoría: se refiere a los procesos y estándares utilizados en la

auditoría del software para el establecimiento de su funcionalidad, fiabilidad,

etc. respecto de los requerimientos, planes y contratos pertinentes.

SOP-11 Resolución de Problemas: se refiere a los procesos y estándares

utilizados en la resolución de problemas relativos al software.

Categoría de Gestión (GES): Abarca los procesos que contienen prácticas genéricas,

que pueden ser utilizadas por cualquier personal que dirija algún tipo de proyecto o

proceso.


GES-01 Gestión: se refiere a los procesos y/o prácticas involucrados en la

gestión proyecto y/o proceso de desarrollo de software.

GES-02 Gestión del Proyecto: se refiere a los procesos y/o prácticas

involucrados en la gestión del proyecto de desarrollo de software.

GES-03 Gestión de Calidad: se refiere a los procesos y/o prácticas



involucrados en la gestión y monitorización de la calidad de los productos y/o

servicios inherentes al proceso de desarrollo de software.

GES-04 Gestión del Riesgo: se refiere a los procesos y/o prácticas

involucrados en la gestión de riesgos del proyecto de desarrollo de software.


GES-05 Gestión: se refiere a los estándares específicos utilizados para la

gestión proyecto y/o proceso de desarrollo de software.

GES-06 Gestión del Proyecto: se refiere a los estándares específicos

utilizados para la gestión del proyecto de desarrollo de software.

GES-07 Gestión de Calidad: se refiere a los estándares específicos

utilizados para la gestión de la calidad del proceso de desarrollo de software.

GES-08 Gestión del Riesgo: se refiere a los estándares específicos

utilizados para la gestión de riesgos del proyecto de desarrollo de software.

Categoría de Organizacional (ORG): Agrupa los procesos que establecen las metas

comerciales de la organización y desarrollan bienes (valores) de proceso, producto y

recurso, que ayudarán a la organización a alcanzar sus metas en los proyectos.


ORG-01 Lineamientos Organizacionales: se refiere a los lineamientos



generales de la organización respecto del proyecto y/o proceso de desarrollo

del software.

ORG-02 Gestión del Cambio: se refiere a los procesos, prácticas y

estándares utilizados para la gestión del cambio del software y de la

organización.

ORG-03 Mejoramiento del Proceso: se refiere a los procesos, prácticas y

estándares utilizados para el mejoramiento del proyecto y/o proceso de

desarrollo del software.

ORG-04 Medición: se refiere a los procesos, prácticas y estándares

utilizados para medir la eficiencia y efectividad del proceso del desarrollo de

software.

ORG-05 Reuso: se refiere a la capacidad organizacional para la reutilización

(retroalimentación) del proyecto, proceso y producto relativos al desarrollo de

software.


ORG-06 Establecimiento del Proceso: se refiere a los procesos, prácticas y

estándares aplicados en la definición del proyecto y/o proceso de desarrollo

del software.

ORG-07 Evaluación del Proceso: se refiere a los procesos, prácticas y

estándares aplicados para la evaluación del proyecto y/o proceso de




ORG-08 Mejoramiento del Proceso: se refiere a los procesos, prácticas y

estándares utilizados para el mejoramiento del proyecto y/o proceso de


ORG-09 Gestión de RRHH: se refiere a las gestión, control y seguimiento de

los recursos humanos que participan en el proyecto de desarrollo del

software.

ORG-10 Infraestructura: se refiere a las gestión, control y seguimiento de los

recursos de infraestructura requeridos en el proyecto de desarrollo del

software.



14. APENDICE B. METRICAS TECNICAS DEL MODELO MOECS AJUSTADO A SOFTWARE DE TIPO ERP (MOECSA).

Número Código Característica Métrica Opciones

1 161 FUN1.- AdecuaciónEl sistema ejecuta un proceso especializado de control y seguimiento de los procesos del negocio (BPM)

+A

2 162 FUN1.- Adecuación

El sistema proporciona mecanismos (BAM) para la monitorización y análisis de los procesos con el objeto de optimizarlos (BPM).

+A

3 163FUN3.- Interoperabilidad

El sistema utiliza un motor de integración (EAI) en su operación interna.

+A


El sistema utiliza un motor de flujo de procesos (WF) en su operación interna.

+A


El sistema utiliza un motor de flujo de procesos (WF) que utiliza el lenguaje BPEL como estándar de modelado.

+A


El sistema utiliza un bus de servicios empresariales (ESB) en su operación interna.

+A


El sistema ofrece soporte nativo para publicar servicios Web (WS) de consumo interno.

+A


El sistema ofrece soporte nativo para publicar servicios Web (WS) de consumo externo.

+A


El sistema ofrece soporte nativo para consumir servicios Web (WS) internos del sistema.

+A


El sistema ofrece soporte nativo para consumir servicios Web (WS) externos del sistema.

+A


El sistema proporciona conectores nativos (built-in) que permiten la integración con diversas bases de datos locales o remotas.

+A




El sistema proporciona compatibilidad con conectores no nativos (externos) que permiten la integración con diversas bases de datos locales o remotas.

+A


Grado de similitud del sistema respecto a una arquitectura orientada a servicios (SOA).

+B

14 174 FUN4.- ConformidadEl sistema está acorde con los lineamientos generales del Plan Nacional de Migración.

+A

15 175 FUN4.- ConformidadEl sistema está acorde con los lineamientos generales del Decreto N° 3390.

+A

16 176 FUN4.- Conformidad

El sistema contempla en su diseño actual o en sus desarrollos actuales sobre mejoras los efectos del proceso de reconversión monetaria BCV.

+B

17 178 FUN5.- Seguridad

Grado de granularidad con que el sistema maneja los permisos sobre los elementos manipulables de la interfaz (módulos, pantallas, gráficos, documentos, botones)

+B


Grado de granularidad con que el sistema maneja los permisos sobre los elementos no manipulables de la interfaz (archivos, documentos, acciones, eventos, tareas, procesos).

+B

19 180 FUN5.- SeguridadTodo usuario es fácilmente identificado a través de un identificador (login) y una contraseña (password).

+A

20 181 FUN5.- SeguridadEl sistema permite la eliminación de usuarios.

-A

21 182 FUN5.- SeguridadEl sistema permite la desactivación de usuarios

+A

22 183 FUN5.- SeguridadEl sistema exige complejidad de las contraseñas.

+A

23 184 FUN5.- SeguridadEl sistema lleva un historial de uso de las claves del usuario para evitar repeticiones de uso en intervalos cortos de tiempo.

+A

24 185 FUN5.- Seguridad El sistema cifra las contraseñas antes de su almacenamiento en la base de datos.

+A

25 186 FUN5.- Seguridad El sistema lleva un registro de los intentos de acceso al sistema.

+B

26 187 FUN5.- Seguridad El sistema maneja una política de +A



seguridad (Policy) para la publicación y consumo de servicios Web (WS).

27 188 FUN5.- Seguridad El sistema es accedido vía Web a través de un túnel SSL/TLS.

+A


El sistema utiliza una infraestructura (Public Key Infraestructure) PKI para garantizar la seguridad a nivel de servicios Web (WS) ofrecidos

+A


El sistema utiliza una infraestructura (Public Key Infraestructure) PKI para garantizar la seguridad a nivel de acceso del usuario (Nav. Web).

+A

30 191 FUN5.- Seguridad El sistema no muestra errores inesperados a los usuarios por las pantallas.

+A

31 192 FUN5.- Seguridad El sistema registra los errores inesperados en una bitácora o log.

+A

32 193 FUN5.- SeguridadEl sistema verifica las entradas de los usuarios antes de enviar un POST/GET con Javascript (evitando inyección SQL, etc).

+A


El sistema verifica las entradas de los usuarios después de recibir un POST/GET en lenguaje nativo (evitando inyección SQL, etc).

+A


El sistema verifica las entradas de los usuarios antes de iniciar una transacción SQL sin delegarla al SMBD (evitando inyección SQL, etc).

+A

35 196 FUN5.- SeguridadEl sistema utiliza/soporta el cifrado de las URL (URI) visualizadas en el Navegador Web.

+A

36 197 FUN5.- SeguridadEl sistema utiliza una bitácora o registro de seguridad a nivel operaciones de la base datos.

+B

37 198 FUN5.- SeguridadEl sistema utiliza un usuario/grupo/rol distinto al administrador de base de datos.

+A


El sistema utiliza distintos usuarios/grupos/roles de base de datos para cada uno de los usuarios finales del sistema.

+A

39 200 FUN5.- SeguridadEl sistema utiliza dispositivos de hardware especializados para soportar la seguridad física y/o virtual durante el uso del sistema.

+A



40 201 FUN9.- Especificado

Existe un claro registro de relaciones entre los requerimientos de diseño (del fabricante) y las funcionalidades ofrecidas por los módulos del sistema (Ver Código fuente).

+A

41 202 FIA1.- Madurez

Capacidad del sistema de generar alertas (por pantalla, por correo electrónico, por teléfono, SMS, por base de datos, etc) según la severidad del error ocurrido.

+B

42 203 FIA1.- Madurez

El número de errores corregidos en el sistema entre las dos últimas versiones del software (sin tomar en cuenta las nuevas funcionalidades).

+B

43 204 FIA1.- MadurezFrecuencia anual de publicación de actualizaciones para la versión actual del sistema.

+B

44 205 FIA1.- Madurez Frecuencia anual de publicación de versiones del sistema.

+B

45 206FIA2.- Tolerancia a Fallas

El sistema ofrece en que medida mecanismos internos para continuar con un flujo alternativo después de sucedido un error.

+B


El sistema ofrece en que medida mecanismos internos para detectar y depurar fácilmente los errores del sistema.

+B


El sistema manejador de base de datos (SMBD) soportal la replicación de datos en forma nativa.

+A


El sistema manejador de base de datos (SMBD) soporta la implementación de clustering nativo.

+A


El sistema manejador de base de datos (SMBD) soporta la implementación del balanceo de carga nativo.

+A

50 211 FIA2.- Tolerancia a Fallas

El servidor de aplicaciones (AS) donde se ejecuta el sistema soporta clustering nativo.

+A


El servidor de aplicaciones (AS) donde se ejecuta el sistema soporta el balanceo de carga nativo.

+A

52 213 FIA3.- Recuperabilidad

El sistema es ofrece mecanismos internos (Módulo de recuperación y monitorización) para realizar una recuperación después de

+A



un fallo grave.

53 214 FIA3.- Recuperabilidad

El sistema se apoya en mecanismos externos (SMBD, SO, SBK, etc) para realizar una recuperación después de un fallo grave.

+A

54 215FIA3.- Recuperabilidad

La base de datos (formato) del sistema cumple con el estándar ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) descrito en ISO/IEC 10026-1: 1992 sección 4.

+A

55 216 USA1.- Comprensibilidad

El sistema utiliza términos en idioma foráneos.

-A

56 217USA1.- Comprensibilidad

El sistema es compatible con la internacionalización y configuración regional de idioma/fecha/moneda para el español (Venezuela).

+A


El sistema usa términos afines al área de estudio propia de los usuarios finales (administración, finanzas, gerencia, recursos humanos, etc.)

+A


El sistema es textualmente sencillo y preciso.

+A


El sistema utiliza metáforas pictóricas fácilmente reconocibles de forma intuitiva.

+A


Los nombres o texto de las funcionalidades representan las funciones que realizan (explícitamente).

+A

61 222USA2.- Facilidad de Aprendizaje

El sistema esta diseñado como un portal Web de contenidos dinámicos.

+A


En que nivel se puede considerar al sistema como amigable al usuario.

+B


En que nivel se puede considerar al como fácilmente manipulable por el usuario.

+B


El sistema cuenta con ayuda en línea (multimedia estática).

+A


El sistema cuenta con ayuda en línea (multimedia dinámica).

+A

66 227 USA2.- Facilidad de Aprendizaje

Los manuales de usuario son de fácil lectura y están enfocados en los aspectos funcionales del sistema (pantallas, procesos, eventos, errores de alto nivel,

+B



consideraciones, advertencias, etc).

67 228 USA2.- Facilidad de Aprendizaje

Existe material multimedia (dinámica) que ayude al proceso de adiestramiento de los usuarios (videos de cursos, ejemplos de operaciones, etc.).

+A

68 229 USA3.- Interfaz Gráfica

La pantalla pagina principal del sistema permite el acceso a todas sus funcionalidades dependiendo de los permisos del usuario en el sistema.

+A

69 230USA3.- Interfaz Gráfica

El sistema permite cambiarse entre pantallas (páginas) o pestañas simultáneamente.

+A


El sistema usa iconos descriptivos para la presentación de las funcionalidades granulares (exportación de documentos, impresión, ordenamiento, etc).

+A


Grado de fluidez de navegación de la interfaz del sistema respecto a los procesos modelados (+ compatible con BPMN).

+B


Grado en que la interfaz permite realizar drill-down a través de un cuadro de mando sencillo (es decir, Menúes desplegables o hipervínculos: “Inicio :: Compras :: Ordenes de Compra :: Solicitar”)

+B


El sistema permite a los usuarios el acceso a su información a través de una bandeja de entrada estandarizada (INBOX).

+A


El sistema es una aplicación Web. +A

75 236USA4.- Capacidad de operar

El sistema puede ser accedido y operado a través de navegador Web.

+A

76 238 USA6.- CompletoEl sistema proporciona interfaces gráficas (UI) para la simulación de flujos de procesos del negocio (WF Simulation)

+A

77 239 USA6.- Completo

El sistema proporciona interfaces gráficas (GUI) para el modelado de los procesos y flujos de trabajo del negocio (WF Modeling).

+A

78 240 USA6.- CompletoEl sistema proporciona interfaces gráficas (GUI) para la integración de los procesos (EAI).

+A

79 241 USA6.- Completo El sistema proporciona interfaces gráficas +A



(GUI) para la monitorización y Análisis de los procesos (BAM).

80 242 USA6.- CompletoEl sistema proporciona una interfaz estándar y generalizada para el desarrollo del sistema adaptada a los desarrolladores.

+A

81 243 USA6.- CompletoEl sistema proporciona una interfaz estándar y generalizada para la gestión del sistema adaptada a los analista y gestores.

+A


El sistema proporciona una interfaz estándar y generalizada para la utilización del sistema adaptada a los empleados y otros usuarios.

+A


Grado en que los servicios Web (WS) ofrecidos por el sistema ofrecen funcionalidades de grano grueso (completas)

+B

84 246 USA8.- Efectivo El usuario puede ser capaz de realizar las tareas comunes con un esfuerzo razonable.

+A

85 247 USA8.- Efectivo Las tareas comunes pueden ser realizadas con solo uno o dos pasos.

+A

86 248 USA8.- EfectivoEl sistema provee de mecanismos de notificación vía correo electrónico a los usuarios.

+A

87 249 USA8.- EfectivoEl sistema provee de mecanismos de interacción vía correo electrónico con los usuarios.

+A

88 250 USA10.- Documentado

Los manuales son de fácil entendimiento. +A


El sistema tiene un manual de usuario por módulo.

+A


La documentación del sistema es diferente para cada una de las versiones del mismo.

+A

91 253USA10.- Documentado

El sistema tiene documentación de alto nivel sobre el flujo de los procesos modelados dentro del mismo.

+A

92 254EFI1.- Comportamiento con respecto al tiempo

Tiempo de respuesta para la visualización de datos. -E

93 255EFI1.- Comportamiento con respecto al tiempo

Tiempo de respuesta para la ejecución de los procesos (eventos).

-E



94 256

EFI2.- Comportamiento con respecto a los recursos

El sistema utiliza un servidor de aplicaciones (AS).

+A

95 257


El sistema utiliza un servidor de base de datos (SMBD).

+A

96 258


El sistema utiliza un servidor de flujos de procesos (Workflow)

+A

97 259


La interfaz del sistema utiliza componentes (portles o beans).

+A

98 260MAN1.- Capacidad de Análisis

El flujo de los procesos del negocio embebidos en el sistema pueden ser trazados sobre los componentes del sistema sin necesidad de comprender su funcionamiento interno de bajo nivel.

+A


El conjunto de procesos del negocio de tipo repetitivo (Compras) pueden ser trazados sobre los componentes del sistema sin necesidad de comprender su funcionamiento interno de bajo nivel.

+A

100 262 MAN1.- Capacidad de Análisis

El conjunto de procesos del negocio de tipo no repetitivo (Planificación y Presupuesto) pueden ser trazados sobre los componentes del sistema sin necesidad de comprender su funcionamiento interno de bajo nivel.

+A


El sistema ejecuta un proceso especializado de control y seguimiento de los procesos del negocio en un servidor (BPM).

+A


El sistema proporciona mecanismos (BAM) para la monitorización y análisis de los procesos.

+A

103 265MAN2.- Capacidad de Cambio

Reductibilidad del Sistema (capacidad del sistema para ejecutar y operar con sólo algunos módulos).

+B

104 266 MAN2.- Capacidad de Grado de escalabilidad el sistema +E



Cambio (capacidad para crear/integrar nuevos módulos nativos o externos).


El sistema utiliza un motor de flujos de procesos (WFE) que permite la definición y reconfiguración de las reglas de los procesos del negocio sin la necesidad de requerir conocimientos de programación.

+B


El sistema utiliza un motor de flujos de procesos (WFE) que permite la simulación de los procesos del negocio sin la necesidad de requerir conocimientos de programación.

+A

107 269MAN4.- Capacidad de Prueba

Grado de trazabilidad de las fallas en los componentes específicos (menor esfuerzo posible) disponible para el programador.

+B


El diseño del sistema permite realizar fácilmente pruebas de caja blanca por parte de los programadores del sistema.

+C


El diseño del sistema permite realizar fácilmente pruebas de caja negra por parte de los implementadores del sistema.

+C

110 272 MAN5.- AcopladoLa programación del sistema es orientada a objetos.

+A

111 273 MAN6.- CohesivoOrden de ejecución predeterminado de los componentes (aun cuando no se utilice un motor de flujo de procesos).

+E

112 274 MAN7.- Encapsulado El sistema esta desarrollado en lenguaje orientado a objeto.

+A

113 275 MAN7.- EncapsuladoOrientación a componentes (portlets o beans) y paquetes (espacios de nombre o módulos) del diseño del sistema.

+E

114 276 MAN11.- Estructurado

El sistema esta desarrollado mediante la utilización de marcos de trabajo (frameworks) de acceso a datos de alto nivel (XML) orientados a objetos (OO) (i.e. Hibernate, Metastorage, etc ).

+B

115 277 MAN11.- Estructurado

El sistema esta desarrollado mediante la utilización de marcos de trabajo (frameworks) basados en patrones (i.e. Patterns For PHP, Django, Spring, Jblueprint, Jfaces, Struts, RubyOnRails, etc).

+B



116 278 MAN11.- Estructurado El sistema se basa en una arquitectura cliente / servidor web.

+A

117 279 MAN11.- Estructurado El sistema se basa en una arquitectura de 3 capas (datos, lógica y presentación).

+A

118 280 MAN11.- EstructuradoEl sistema se basa en una arquitectura de 4 capas (datos, lógica de automatización, flujo de procesos y presentación).

+A

119 281 MAN14.- Modular

Grado de delimitación de las funcionalidades y responsabilidades de cada uno de los módulos que componen al sistema.

+B

120 285 POR1.- Adaptabilidad

Esfuerzo y modificaciones requeridas en los parámetros de configuración del sistema para que pueda ser ejecutado en distintos sistemas operativos Linux (compatibles con Debian).

+E


El sistema no depende de una plataforma distinta al sistema operativo Linux (i.e. Windows, Solaris, etc.) para garantizar la eficacia, eficiencia o existencia de todas las funcionalidades que ofrece en una instalación recomendada.

+A


El sistema puede ser accedido y operado desde cualquier navegador Web libre o comercial sin menoscabo de las funcionalidades o requerimientos de ajustes internos.

+C

123 288POR2.- Facilidad de Instalación

Es inductivo el procedimiento de instalación del sistema.

+E


Grado de complejidad del proceso de instalación.

-B


Tiempo estimado para la instalación del sistema.

+E


Grado de documentación del proceso de instalación.

+B

127 292POR3.- Conformidad con los Estándares

Los marcos de trabajo (lenguajes, estándares, protocolos, tecnologías, etc.) usados en la implementación del sistema cumplen con estándares internacionales de portabilidad.

+B

128 293 POR3.- Conformidad con los Estándares

El sistema utiliza un motor de orquestación del flujo de los procesos del negocio

+A



compatible con el lenguaje BPEL.

129 294 POR3.- Conformidad con los Estándares

El sistema utiliza un motor de orquestación del flujo de los procesos del negocio compatible con el lenguaje BPEL para servicios Web (WS).

+A

130 295 POR6.- ParametrizadoExiste un modulo de gestión de los módulos / ítems del sistema.

+A

131 296 POR6.- Parametrizado

Los ajustes internos necesarios para la instalación del sistema en múltiples plataformas de hardware y software se hacen a través de parámetros de alto nivel en los archivos de configuración del sistema (*.ini, *.xml).

+A

132 297 POR6.- Parametrizado

Los ajustes externos necesarios para la instalación del sistema en múltiples plataformas de hardware y software se hacen a través de parámetros de alto nivel provistos por la plataforma/sistema donde éste se ejecuta.

+A

133 298 POR6.- parametrizadaSe requiere la parametrización de bajo nivel (técnica) del sistema para su correcto funcionamiento.

+A

134 299 POR6.- parametrizadaSe requiere la parametrización de alto nivel (funcional) del sistema para su correcto funcionamiento.

+A

135 300 POR10.- Documentado

Documentación de los ajustes del sistema que deben realizarse en el sistema para garantizar su portabilidad en múltiples plataformas de hardware y software.

+B

136 301POR10.- Documentado

Documentación sobre los procesos de parametrización técnica del sistema.

+B

137 302POR10.- Documentado

Documentación sobre los procesos de parametrización funcional del sistema.

+B

138 303 POR10.- Documentado

Documentación sobre los errores presentados por las distintas versiones del sistema y cual es la solución de los mismos.

+B

139 304 CLP1.- AdquisiónEl licenciamiento del sistema es de código abierto.

+A

140 305 CLP1.- AdquisiónEl uso del sistema esta restringido comercialmente.

-A

141 306 CLP1.- Adquisión El licenciamiento del sistema es GNU/GPL. +A



142 307 CLP1.- Adquisión El fabricante contempla la transferencia tecnológica del sistema como producto.

+A

143 308 CLP1.- AdquisiónEl fabricante contempla la transferencia tecnológica del proceso de desarrollo del sistema.

+A

144 309 CLP1.- AdquisiónEl fabricante contempla la transferencia tecnológica del proceso de implantación del sistema.

+A

145 310 CLP1.- Adquisión El fabricante contempla la transferencia del ciclo completo de vida del sistema.

+A

146 311 CLP1.- Adquisión Dependencia de terceros (empresas de servicios) al adquirir o implantar el sistema.

+B*

147 312 CLP1.- AdquisiónExiste una metodología propuesta por el fabricante para la implantación del sistema en sus clientes con un enfoque BPM.

+A

148 313 ING1.- Desarrollo

El fabricante utiliza una metodología de desarrollo compatible con fuertemente documentada y adaptada a grandes desarrollos (i.e. RUP)

+A

149 314 ING1.- DesarrolloExiste una metodología propuesta por el fabricante para el desarrollo del sistema con un enfoque BPM.

+A

150 315SOP4.- Resolución de Problemas

El fabricante provee de foros u otros mecanismos de soporte en línea sobre los diferentes aspectos de ciclo de vida del sistema para todos sus usuarios.

+C

151 316SOP5.- Documentación

Madurez y uso de la metodología de implantación utilizada por el fabricante en cuanto a documentación y estandarización.

+B

152 317 SOP6.- Gestión de Configuración

El fabricante utiliza un sistema de versiones concurrente (CVS, SUBVN, etc) para mantener un repositorio de las versiones del sistema.

+A

153 318ORG1.- Lineamientos Organizacionales

Años de experiencia en el desarrollo de SW de tipo ERP.

+E

154 319ORG1.- Lineamientos Organizacionales

Número de clientes que han adquirido e implantado el SW.

+B

155 320 ORG3.- Mejoramiento del Proceso

Certificación ISO 9000:2000 del fabricante u otro estándar, entorno a los procesos y clientes involucrados el proceso de desarrollo de SW.

+B



156 282MAN15.- Documentado

El sistema tiene un diagrama conceptual y lógico de la base de datos, completamente especificado y detallado por entidad, atributo y relación.

+A

157 283MAN15.- Documentado

El sistema tiene un diagrama conceptual y lógico de los flujos de procesos, completamente especificado y detallado por proceso, entrada, salida, etc.

+A

158 284 MAN15.- Documentado

El sistema tiene un manual de administrador.

+A

15. APENDICE C. METRICAS FUNCIONALES Y LEGALES DEL MODELO MOECS AJUSTADO A SOFTWARE DE TIPO ERP (MOECSA).

Número Código Característica Métrica Opciones

1 423FUN1.- Adecuación

El sistema valida el RNC como campo obligatorio.

+A


El sistema permite actualizar el catálogo interno de materiales.

+A


El sistema valida el RIF como campo obligatorio. +A


El sistema realiza la planificación de compras por períodos (mensual, trimestral, anual).

+A


El sistema permite realizar la solicitud de requisición a través de una interfaz con los usuarios.

+A


El sistema permite realizar la solicitud de viáticos y pasajes a través de una interfaz con los usuarios.

+A


El sistema valida el límite de UT para determinar el tipo de adquisición (compra/servicio o licitación).

+A


El sistema genera la solicitud de cotización para los proveedores.

+A


El sistema genera el análisis de las ofertas de los proveedores.

+A

10 432 FUN1.- El sistema permite emitir la orden de compra y/o +A



Adecuación servicio.


El sistema valida la disponibilidad presupuestaria al emitir la orden de compra y/o servicio.

+Bz


El sistema registra el compromiso presupuestario al aprobar la orden de compra y/o servicio.

+A


El sistema muestra el estado de las órdenes de compra y/o servicio.

+A


El sistema permite registrar la recepción de materiales, suministros y activos.

+A


El sistema permite registrar las salidas de materiales, suministros y activos.

+A


El sistema emite alertas de control de existencias.

+A


El sistema valida las existencias en inventario al recibir la solicitud de requisición.

+A


El sistema permite controlar las requisiciones. +Bz


El sistema permite controlar el Inventario. +Bz


El sistema permite el control de múltiples almacenes.

+A


El sistema permite el control de la incorporación de bienes.

+A


El sistema permite el control de la desincorporación de bienes.

+A


El sistema permite planificar el mantenimiento preventivo de los bienes.

+Bz


El sistema integra el módulo de bienes con el módulo de adquisiciones.

+A


El sistema integra el módulo de bienes con el módulo de almacén.

+A


El sistema integra el módulo de bienes con el módulo de contabilidad.

+A


El sistema permite registrar la recepción de servicios.

+A


El sistema registra el causado al validar la recepción de servicios.

+A




El sistema permite registrar el compromiso-causado de los viáticos y pasajes al ser aprobados.

+A


El sistema registra el causado al validar la recepción de materiales, suministros y activos.

+A


El sistema afecta la contabilidad patrimonial al registrar el causado de los activos.

+A


El sistema integra el módulo de bienes con el módulo de obras.

+A


El sistema permite el control de la contratación de obras.

+Bz


El sistema permite el control de las valuaciones de obras.

+Bz


El sistema permite el control de las inspecciones de obras.

+Bz


El sistema permite el control del incremento/disminución de obras.

+Bz


El sistema permite el control de la paralización/reinicio de obras.

+Bz


El sistema permite el control de la recepción provisional de obras.

+Bz


El sistema permite el control de la recepción definitiva de obras.

+Bz


El sistema permite el seguimiento y control de una obra con múltiples contratos.

+Bz


El sistema permite el seguimiento y control de la ejecución física de la obra.

+Bz


El sistema integra el módulo de obras con el módulo de presupuesto.

+A


El sistema integra el módulo de obras con el módulo de tesorería.

+A


El sistema integra el módulo de obras con el módulo de tesorería.

+A


El sistema valida la disponibilidad presupuestaria al ingresar el estimado anual de nómina

+Bz


El sistema registra el compromiso presupuestario al aprobar el estimado anual de nómina

+A




El sistema genera la nómina +A


El sistema registra el causado presupuestario al aprobar la nómina

+A


El sistema genera el asiento contable al registrar el causado de la nómina

+A


El sistema mantiene un histórico del recurso humano (vida laboral)

+Bz


El sistema realiza el cálculo de prestaciones (Pasivos Laborales)

+Bz


El sistema permite el registro y actualización de necesidades de adiestramiento

+A


El sistema cuenta con mecanismos para la medición y evaluación del desempeño laboral

+A


El sistema permite la actualización del Registro de Estructura de Cargo (RAC)

+Bz


El sistema permite la actualización del Plan de Carrera

+A


El sistema mantiene un registro histórico de deducciones

+A


El sistema realiza el cálculo de tiques de alimentación

+A


El sistema integra el módulo de RRHH con el módulo de Presupuesto

+A


El sistema integra el módulo de RRHH con el módulo de Contabilidad

+A


El sistema integra el módulo de RRHH con el módulo de Tesorería

+A


El sistema posee mecanismos para la formulación de proyectos.

+Bz


El sistema posee mecanismos para la generación del POAI

+Bz


El sistema utiliza la técnica de presupuesto por proyectos y acciones centralizadas para asignar y distribuir los recursos.

+Bz


El sistema utiliza el Clasificador Presupuestario de Recursos y Egresos aprobados por la ONAPRE.

+A

65 487 FUN1.- El sistema permite actualizar el Clasificador +A



Adecuación Presupuestario de Recursos y Egresos aprobados por la ONAPRE.


El sistema genera la información para la actualización de la data financiera de los proyectos en Nueva Etapa.

+A


El sistema genera el Anteproyecto de Presupuesto de Recursos.

+A


El sistema genera el Anteproyecto de Presupuesto de Egresos.

+A


El sistema genera la cuenta ahorro-inversión-financiamiento.

+A


El sistema permite registrar la distribución general del presupuesto de gastos (Título II).

+A


El sistema permite ajustar el Anteproyecto de Presupuesto (Título III).

+A


El sistema permite registrar la estructura para la ejecución financiera del presupuesto de gastos.

+A


El sistema asocia la estructura presupuestaria con la estructura financiera.

+A


El sistema permite registrar la distribución administrativa de los créditos presupuestarios.

+A


El sistema permite realizar la programación de la ejecución física del presupuesto.

+Bz


El sistema restringe la modificación del valor de la UT durante el ejercicio económico.

+A


El sistema permite efectuar pagos directos contra las cuentas bancarias.

+A


El sistema prevee la administración de los fondos en avance.

+Bz


El sistema prevee la administración de los fondos girados en anticipo.

+Bz


El sistema prevee la administración de los fondos de caja chica.

+Bz


El sistema permite registrar el reintegro de remanentes de fondos.

+A


El sistema valida los criterios de autorización de las modificaciones presupuestarias conforme al Reglamento N° 1 de la LOAFSP.

+Bz

83 505 FUN1.- El sistema permite registrar traspasos de +A



Adecuación créditos presupuestarios.


El sistema permite registrar créditos adicionales. +A


El sistema permite registrar rectificaciones. +A


El sistema permite registrar insuficiencias. +A


El sistema permite registrar anulaciones de créditos presupuestarios (rebajas).

+A


El sistema permite registrar ajustes por reducción de créditos presupuestarios.

+A


El sistema permite generar la solicitud de modificación presupuestaria por UEL.

+A


El sistema permite generar la solicitud de modificación presupuestaria consolidada por estructura presupuestaria.

+A


El sistema permite generar la solicitud de modificación presupuestaria de la descripción de proyectos, acciones centralizadas y acción específica.

+A


El sistema permite generar la solicitud para la creación de nueva estructura presupuestaria.

+A


El sistema permite generar la solicitud de re-programación de metas de las proyectos.

+A


El sistema permite generar la solicitud de re-programación financiera de las acciones centralizadas.

+A


El sistema cumple las normas de liquidación y cierre del presupuesto conforme al Reglamento N° 1 de la LOAFSP.

+Bz


El sistema permite determinar el resultado del presupuesto de gastos al cierre del ejercicio.

+A


El sistema genera el listado de compromisos no causados al cierre del ejercicio.

+A


El sistema genera la información para la formación de la Cuenta General de Hacienda.

+Bz


El sistema consolida el presupuesto de distintas instituciones.

+A


El sistema permite realizar la programación de la ejecución financiera del presupuesto.

+Bz




El sistema contiene el módulo de formulación del presupuesto de ingresos.

+A


El sistema permite estimar los ramos de ingreso para los nuevos ejercicios (Título III).

+A


El sistema permite formular el presupuesto de ingreso por fuente de financiamiento (Título II).

+A


El sistema en el proceso de formulación valida el equilibrio entre las cantidades autorizadas para el gasto y aplicaciones financieras y el total de las cantidades estimadas como ingresos y fuentes financieras.

+A


El sistema asocia los rubros con las fuentes. +A


El sistema contiene el módulo de ejecución del presupuesto de ingreso.

+A


El sistema permite el registro del presupuesto de ingresos por ramo (corrientes y de capital).

+A


El sistema integra la liquidación del presupuesto de ingreso con la ejecución del presupuesto de gasto.

+A


El sistema registra de manera automática los Restablecimientos de créditos presupuestarios.

+A


El sistema para la liquidación de Ingresos contempla el proceso de Devolución o Reintegros de las órdenes de Pago Directo.

+A


El sistema para la liquidación de Ingresos contempla el proceso de Devolución o Reintegros de los Fondos en Avances y Anticipo.

+A


El sistema contempla el registro de distintos medios de financiamiento (tributos, endeudamiento, disminución de activos, aumento de pasivos, operaciones de compra-venta).

+Bz


El sistema contempla el registro de los derechos pendientes.

+A


El sistema permite determinar el monto de los Recursos (ingresos y fuentes financieras) recaudados al cierre del ejercicio.

+A


El sistema permite el registro presupuestario del Devengado al momento de hacerse exigible el derecho pendiente.

+A




El sistema realiza el registro contable y presupuestario del Devengado de forma simultánea.

+A


El sistema permite el registro presupuestario del Recaudado al extinguirse los derechos pendientes por cualquier medio o forma de pago.

+A


El sistema realiza el registro contable y presupuestario del Recaudado de forma simultánea.

+A


El sistema permite el registro y emisión de pagos.

+A


El sistema permite hacer seguimiento a los pagos efectuados.

+Bz


El sistema registra el pagado presupuestario al ordenar el pago.

+A


El sistema genera el asiento contable al registrar el pagado presupuestario.

+A


El sistema posee parámetros de control de los compromisos de pagos.

+Bz


El sistema controla el flujo de caja. +Bz


El sistema controla los gastos bancarios y otros costos financieros.

+Bz


El sistema permite el seguimiento de la posición diaria de créditos e inversiones.

+Bz


El sistema permite la conciliación bancaria automatizada.

+Bz


El sistema permite programar cuotas de desembolsos.

+Bz


El sistema controla los flujos de ingresos (cantidad, forma, tipo y tiempo).

+Bz


El sistema controla los movimientos de las cuentas bancarias.

+Bz


El sistema controla la autorización de apertura de cuentas.

+Bz


El sistema controla las firmas autorizadas para el manejo de los recursos.

+A


El sistema mantiene un registro contable de ingresos y egresos del tesoro (genera el flujo de

+A



efectivo).


El sistema integra el módulo de ingresos con el módulo de tesorería.

+A


El sistema integra el módulo de presupuesto con el módulo de tesorería.

+Bz


El sistema integra el módulo de tesorería con el módulo de contabilidad.

+A


El sistema permite el manejo del Plan de Cuentas Patrimoniales atado a los clasificadores dictados por la ONAPRE, ONCOP, MPPPD y la ONT.

+Bz


El sistema cumple el principio de unicidad del registro (proporciona un tratamiento y registro único de los datos en el sitio más cercano a donde ocurre cada transacción).

+Bz


El sistema permite la apertura del ejercicio económico financiero que arrastre los saldos financieros del ejercicio anterior y la información de la Ley de Presupuesto vigente.

+Bz


El sistema permite el reverso de las transacciones en cualquier momento contable del ingreso y del gasto.

+Bz


El sistema permite realizar operaciones de cierre y ajuste contable.

+Bz


El sistema recopila, valúa, procesa y expone los hechos económicos financieros que afecten o puedan afectar el patrimonio de las instituciones públicas.

+Bz


El sistema está diseñado y operara en función de las normas de contabilidad aplicables en el sector público.

+Bz


El sistema emite los estados financieros periódicamente ( estados de ejecución presupuestaria de ingresos y gastos, liquidación anual de presupuesto, origen y aplicación de fondos, balance general y sus auxiliares, estado de resultados, estados económicos).

+Bz


El sistema cubre la totalidad de las operaciones financieras en el ámbito presupuestario y no presupuestario.

+A


El sistema permite realizar el cierre contable por períodos varios.

+A




El sistema consolida los estados financieros de distintas instituciones.

+A


El sistema incluye cuentas auxiliares. +A


El sistema mantiene y permite la emisión del Libro de Banco.

+A


El sistema mantiene y permite la emisión del Libro de Compras.

+A


El sistema mantiene y permite la emisión del Libro Diario.

+A


El sistema identifica la transacción contenida en cada documento fuente.

+A


El sistema especifica cada cuenta afectada por la transacción y la clasifica por tipo (activo, pasivo, patrimonio, ingresos, egresos o de orden).

+A


El sistema determina si la transacción aumenta o disminuye cada cuenta.

+A


El sistema determina la cuenta que se ha de debitar y la que se ha de acreditar.

+A


El sistema emite los reportes de retenciones al momento de autorizar el pago.

+A


El sistema permite el control electrónico de expedientes.

+A


El sistema produce la información de gestión y financiera necesaria para la toma de decisiones.

+Bz


El sistema presenta la información contable y la respectiva documentación de apoyo ordenados de forma que facilite el ejercicio del control y auditoría interna o externa

+Bz


El sistema dispone de una herramienta de flujos de trabajo dinámica (se ajusta a la naturaleza, estructura y fines de las instituciones públicas).

+Bz


El sistema dispone de mecanismos para restringir la modificación de parámetros.

+Bz


El sistema considera aspectos integrales de índole presupuestaria, económica, financiera, patrimonial, normativa y de gestión de la organización.

+Bz

163 587 FUN1.- El sistema incluye los elementos de control +Bz



Adecuación previo adaptables a la estructura interna de la organización.


El sistema incluye los elementos de control posterior adaptables a la estructura interna de la organización.

+Bz


El sistema dispone de mecanismos que permitan determinar el incumplimiento de las normas dictadas por los órganos rectores de la administración financiera.

+Bz


El sistema cumple el principio de confiabilidad (ofrece certeza de los datos, los hechos y las cifras).

+Bz


El sistema cumple el principio de verificabilidad (favorece o posibilita el seguimiento de una pista auditable de todas las transacciones).

+Bz


El sistema cumple el principio de oportunidad (posibilidad u oportunidad de obtener información sobre las transacciones realizadas en el momento en que se producen).

+Bz


El sistema cumple el principio de utilidad (apoya el proceso de la toma de decisiones y la simplificación de procedimientos).

+Bz


El sistema cumple el principio de transparencia (da información clara y pública sobre la gestión económico-financiera).

+Bz


El sistema analiza la ejecución de las variables físicas en el tiempo estimado.

+A


El sistema analiza la ejecución de las variables físicas con los costos estimados.

+A


El sistema controla el cumplimiento de los tiempos para el logro de las metas físicas.

+Bz


El sistema permite desarrollar indicadores de eficiencia y eficacia del desempeño institucional.

+A


El sistema permite desarrollar indicadores de eficiencia y eficacia de la gestión presupuestaria.

+A


El sistema permite desarrollar indicadores de eficiencia y eficacia de la gestión financiera.

+A


El sistema permite realizar el seguimiento efectivo de los proyectos.

+Bz


El sistema genera el análisis de la información para la evaluación de proyectos.

+A




El sistema presenta indicadores físicos, financieros y de desempeño dentro de un sistema de seguimiento.

+A


El sistema permite la detección preventiva de desviaciones en metas físicas.

+A


El sistema permite la detección preventiva de desviaciones en metas financieras.

+A


El sistema genera, envía y presenta alertas sobre eventos y condiciones relevantes.

+A


El sistema permite la realización de consultas parametrizables.

+A


El sistema permite la modificación de la apariencia de los reportes.

+A


El sistema presenta una vista preliminar de los reportes.

+A


El sistema tiene un motor de búsqueda general. +A


El sistema permite la exportación de reportes a diferentes formatos o estándares manipulables (Hoja de cálculo, imágenes, documentos de texto, etc).

+Bz


El sistema permite la generación de gráficos. +Bz


El sistema permite que los reportes sean accedidos a través de la Web.

+A

190 614FUN4.- Conformidad

El sistema cumple lo establecido en la Constitución Nacional.

+Bz


El sistema cumple lo establecido en la Ley Orgánica de Planificación.

+Bz


El sistema cumple lo establecido en la Ley Orgánica de Administración Financiera del Sector Público (LOAFSP).

+Bz


El sistema cumple lo establecido en los Reglamentos de la LOAFSP (N° 1, N° 2, N° 3, N° 4).

+Bz


El sistema cumple lo establecido en la Ley de Presupuesto Anual.

+Bz


El sistema cumple lo establecido en el Clasificador Presupuestario.

+Bz

196 620 FUN4.- El sistema cumple lo establecido en el Plan de +Bz



Conformidad Cuentas Patrimoniales.


El sistema cumple lo establecido en las providencias de cada oficina rectora en el ámbito administrativo financiero (ONAPRE, ONCOP, TESORERIA NACIONAL, CREDITO PUBLICO, SENIAT, SUNAI).

+Bz


El sistema cumple lo establecido en la Ley Orgánica de la Hacienda Pública Nacional en materia de bienes.

+Bz


El sistema cumple lo establecido en la Ley Orgánica de la Contraloría General de la República (normas de control interno y externo).

+Bz


El sistema cumple lo establecido en las normas de la SUNAI (Superintendencia Nacional de Auditoría Interna).

+Bz

16. APENDICE D. GRUPOS DE OPCIONES Y VALORES PARA LAS METRICAS EN MOECS

Número Abreviatura Descripción Opciones

1 +A Afirmación o Negación • No (0.00% - 0.00%)• Si (100.00% - 100.00%)

1 -A Afirmación o Negación • No (100.00% - 100.00%)• Si (0.00% - 0.00%)

1 +B Tres (3) Niveles Genéricos• Bajo (0.00% - 33.33%)• Medio (33.33% - 66.66%)• Alto (66.66% - 100.00%)

1 -B Tres (3) Niveles Genéricos• Bajo (66.66% - 100.00%)• Medio (33.33% - 66.66%)• Alto (0.00% - 33.33%)

1 +E Cuatro (4) Cantidades Cualitativas

• Poco (0.00% - 25.00%)• Regular (25.00% - 50.00%)• Mucho (50.00% - 75.00%)• Bastante (75.00% -

100.00%)

1 -E Cuatro (4) Cantidades Cualitativas • Poco (75.00% - 100.00%)• Regular (50.00% - 75.00%)



• Mucho (25.00% - 25.00%)• Bastante (0.00% - 25.00%)

1 +C Cuatro (4) Apreciaciones de Calidad

• Malo (0.00% - 25.00%)• Bueno (25.00% - 50.00%)• Muy Bueno (50.00% -

75.00%)• Excelente (75.00% -

100.00%)

1 +A* Afirmación o Negación con N/A

• No (0.00% - 0.00%)• Si (100.00% - 100.00%)• No Aplica (-1.00% -

-1.00%)

1 -A* Afirmación o Negación con N/A

• No (100.00% - 100.00%)• Si (0.00% - 0.00%)• No Aplica (-1.00% -

-1.00%)

1 +B* Tres (3) Niveles Genéricos con N/A

• Bajo (0.00% - 33.33%)• Medio (33.33% - 66.66%)• Alto (66.66% - 100.00%)• No Aplica (-1.00% -

-1.00%)

1 -B* Tres (3) Niveles Genéricos con N/A

• Bajo (66.66% - 100.00%)• Medio (33.33% - 66.66%)• Alto (0.00% - 33.33%)• No Aplica (-1.00% -

-1.00%)

1 +E*Cuatro (4) Cantidades Cualitativas con N/A

• Poco (0.00% - 25.00%)• Regular (25.00% - 50.00%)• Mucho (50.00% - 75.00%)• Bastante (75.00% -

100.00%)• No Aplica (-1.00% -

-1.00%)

1 -E*Cuatro (4) Cantidades Cualitativas con N/A

• Poco (75.00% - 100.00%)• Regular (50.00% - 75.00%)• Mucho (25.00% - 25.00%)• Bastante (0.00% - 25.00%)• No Aplica (-1.00% -

-1.00%)

1 +C* Cuatro (4) Apreciaciones de Calidad con N/A

• Malo (0.00% - 25.00%)• Bueno (25.00% - 50.00%)• Muy Bueno (50.00% -

75.00%)• Excelente (75.00% -



100.00%)• No Aplica (-1.00% -

-1.00%)

1 +Bz Tres (3) Niveles Genéricos (Con Nada)

• Nada (0.00% - 0.00%)• Bajo (0.00% - 33.33%)• Medio (33.33% - 66.66%)• Alto (66.66% - 100.00%)

17. APENDICE E. MATRIZ DE CALIDAD MOECS




Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad


Adecuación, Exactitud,

Interoperabilidad, Seguridad,

Conformidad

Madurez, Toleracia a Fallos, Recuperabilidad

Compresibilidad, Fac. Aprendizaje, Interfaz Gráfica,

Operabilidad, Conformidad.

Tiempo y Recursos

Cap. de Análisis, de Cambio, de

Pruebas, Estabilidad

Adaptabilidad, Fac. Instalación,

Conformidad, Cap. de Reemplazo.


Correcto, Encapsulado, Estructurado, Especificado

Correcto, Estructurado, Encapsulado

Completo, Consistente,

Efectivo, Especificado,

Documentado, Autodescriptivo

Efectivo, No Redudante,

Discreto, Utilizado

Acoplado, Cohesivo,

Encapsulado, Conciso, Simple,

Maduro, Estructurado, Descriptivo,

Correcto, Modular

Consistente, Parametrizado, Encapsulado,

Cohesivo, Especificado,

Documentado, No Redudante,

Auditable, Manejo de la Calidad,

Conciso, Simple

Categorías del Proceso de Desarrollo

Cliente – Proveedor Ingeniería Soporte Gestión Organizacional


Adquisión, Determinación de Requerimientos.

Desarrollo y Mantenimiento

Aseg. Calidad, Revisión Conjunta,

Auditoría, Resolución de

Problemas

Gestión, Ges.

Proyecto, Ges.

Calidad, Ges.

Riesgo.

Lineamiento Org., Gestión del

Cambio, Mejoramiento del

Proceso, Medición, Reuso


Suministro, Operación

Desarrollo y Mantenimiento

Documentación, Gestión de la

Conf., Verifcación, Validación,

Revisión Conjunta, Auditoría,

Resolución de Problemas.

Gestión, Ges.

Proyecto, Ges.

Calidad, Ges.

Riesgo.

Establecimiento del Proceso, Eval. Del

Proceso, Mejoramiento del Proceso, Gestión

de RRHH, Infraestructura

APENDICE F. MODELO DEL CÁLCULO

Debido a que los valores de las opciones seleccionables como respuestas para las métricas son rangos de valores (Véase Apéndice D), los cuales, tienen un valor mínimo (tope inferior) y un valor máximo (tope superior), se tiene que los resultados de la evaluación se obtienen calculando el promedio (Prom. %, también referido por Ri,c) de los valores de todas las respuestas, donde el valor de cada respuesta es igual al promedio de los topes de la opción seleccionada para la misma.

Así mismo, el promedio de los topes inferiores es "Prom. Mín. %" y el de los topes superiores es "Prom. Máx. %", por lo tanto, debe considerarse que el resultado "Prom. %" es un valor estimado que oscila en un rango acotado de promedios.

Fórmulas Matemáticas usadas en las Estadísticas

m n

Ri,c = ∑ { [ ∑ (O'ijk)] / n} j=1 k=1

O'ijk = | min(Oijk) + max(Oijk) | / 2

min(Oijk) es el tope inferior del rango representado por la opción Oijk.max(Oijk) es el Tope superior del rango representado por la opción Oijk.

Nota: Donde Oijk es la opción seleccionada como respuesta por el evaluador j en la pregunta de la métrica k para el software c (i.e. rojo, verde, azul, etc.), siendo i el conjunto de criterios (filtros de las opciones a utilizar como datos estadísticos) propios de las métricas (y por ende de sus opciones asociadas) a saber: dominio (Producto o Proceso),



categoría (Funcionalidad, Portabilidad, etc.), característica (Adecuación, Seguridad, etc.) y rol a quien va dirigida la pregunta de la métrica (Funcional o Técnico).

Las estadísticas (la parte interesante de las consulta SQL), lo hace de esta forma:

(...) " , round(avg(abs(o.minimo+o.maximo)/2),2) AS puntaje"; " , round(avg(abs(o.minimo)),2) AS tope_inferior"; " , round(avg(abs(o.maximo)),2) AS tope_superior"; (...)

Donde o es la opción seleccionada por un evaluador para una respuesta para un software dado.

No hay otras fórmulas... no hay otros cálculos... no hay otro nivel de complejidad.

Los resultados se obtienen filtrando las respuestas de acuerdo a:- dominio (Producto o Proceso)- y/o categoría (Facilidad de uso, Portabilidad, ...)- y/o característica (Interfaz Gráfica, Sistemas Operativos Soportados, ...) - y/o rol (Funcional o Técnico)

Todos estos datos están asociados a las métricas directa o indirectamente, siguiendo las relaciones jerárquicas siguientes: una métrica tiene un rol y una característica, una característica tiene una categoría y una categoría pertenece a un dominio.



18. REFERENCIAS

[ABU001] Abud F., María A. Calidad en la Industria del Software. La Norma ISO-9126. Instituto

Tecnológico y de Estudios Superiores de Monterrey.

[PAZ001] Cervera Paz, Ángel. El modelo de McCall como aplicación de la calidad a la revisión del

software de gestión empresarial. Universidad de Cádiz, obtenido el 24 de abril del 2001 del sitio web.

http://www.monografias.com/trabajos5/call/call.html

[CNT001] CNTI. Aspectos Conceptuales y Metodología para la Definición de Estándares en Tecnologías

de Información. Centro Nacional de Tecnologías de Información (CNTI). Caracas, Venezuela. 09 de Mayo

de 2003.

[DAM001] Dávila, Leticia y Mejías, Pedro. Evaluación de la Calidad de Software en Sistemas de

Información en Internet. CINVESTAV-IPN. México-DF, 2003.

[LRY001] Liendo, V., Reaño, Y., Reitmaier, O. Proyecto de Implementación del Laboratorio de Solftware

Libre. Centro Nacional de Tecnologías de Información (CNTI). Caracas, Venezuela. Agosto de 2007.

[MPG001] Mendoza, Luis E., Pérez, María A. y Grimán, Anna C. Prototipo de Modelo Sistémico de

Calidad (MOSCA) del Software. Universidad Simón Bolívar. Caracas, Venezuela. 2004.








[PRE001] Pressman, Roger S. Ingeniería de Software, Un enfoque práctico, 4ª. Edición. Editorial Mc

Graw Hill. México. 1998.



evaluacion tecnico funcional erp

Documents