Contabilidad Tesis

Universidad de las Ciencias Informáticas
Título: Análisis y Diseño del Subsistema Contabilidad

General del Sistema Integral de Gestión de Entidades.
Trabajo de Diploma para optar por el título de

Ingeniero en Ciencias Informáticas
Autor(es): Annilié Manresa Bernal.
Rosalina Ibarra González.
Tutor(a): Ing. Aneyvis Hernández Chinea.
Co-tutor(a): Ing. Ileana Centelles Rubiera.
Ciudad de la Habana, Mayo, 2009
I
Resumen
En los últimos años con el avance de las nuevas tecnologías los procesos de la Contabilidad general se
han visto influenciados por el constante desarrollo. A pesar de que existe una gran variedad de
soluciones contables en aplicaciones de software, tanto nacionales como extranjeras, que facilitan
dichos procesos no se ha logrado obtener un estándar funcional para todos estos sistemas, que
responda a las especificidades de la contabilidad que se realiza en las entidades cubanas.
Este trabajo tiene como objetivo central llevar a cabo la modelación de los procesos de negocio
inherentes al subsistema Contabilidad general, identificar los requisitos funcionales, y crear una
propuesta de diseño de forma tal que constituya el punto de partida para futuros Sistemas de gestión
contable en Cuba. Para lograr este propósito se empleó el modelo de desarrollo de software definido por
los especialistas del proyecto en general y las herramientas igualmente establecidas para el desarrollo
de acuerdo a los diferentes roles.
Para elaborar esta propuesta, fue necesario dividir todo el contenido de trabajo en diversos subsistemas,
y éstos a su vez en componentes, los cuales guardan una estrecha relación entre sí,
independientemente de que se trabajen por separado. Aunque, para captar los detalles esenciales del
negocio con los clientes, se mantuvo íntegra la información, separándola por temas sólo al comenzar el
diseño de la solución y la posterior implementación.
Palabras Claves: Contabilidad general, Procesos de negocio, Requisitos funcionales, Diseño, Sistemas
de gestión contable, modelo de desarrollo.
II
Tabla de Contenido
 INTRODUCCIÓN ...................................................................................................................................... 1
 CAPÍTULO 1 Fundamentación teórica. .................................................................................................. 5
1. Introducción............................................................................................................................................... 5
1.1 Fundamentación del tema ................................................................................................................... 5
1.1.1 Contabilidad. ..................................................................................................................................... 5
1.1.2 Sistemas contables ........................................................................................................................... 6
1.1.3 Sistemas contables financieros presentes en entidades cubanas. Tratamiento del subsistema
Contabilidad general. ....................................................................................................................................... 6
1.2 Modelo de desarrollo y herramientas empleadas ............................................................................ 10
1.2.1. Modelo de Desarrollo orientado a componentes ......................................................................... 10
1.2.2. Lenguaje Unificado para Modelado (UML) ................................................................................... 13
1.2.3. BPMN (Notación para Modelar los Procesos de Negocio) ......................................................... 13
1.2.4. Visual Paradigm para UML ............................................................................................................ 14
1.3 Conclusiones parciales ...................................................................................................................... 15
 CAPÍTULO II: Descripción de la solución propuesta........................................................................... 16
2. Introducción............................................................................................................................................. 16
2.1 Modelo de Negocio ............................................................................................................................. 16
2.2 Modelo de Negocio basado en procesos. ........................................................................................ 16
2.3 Procesos que tienen lugar en el subsistema Contabilidad general ............................................... 17
2.4 Patrones de Control de flujo empleados........................................................................................... 31
2.5 Mapa de Procesos de negocio .......................................................................................................... 31
2.6 Modelos Conceptuales o de dominio. ............................................................................................... 32
2.7 Requerimientos ................................................................................................................................... 36
2.7.1 Técnicas empleadas para la captura de requisitos...................................................................... 36
III
2.7.2 Requisitos funcionales.................................................................................................................... 37
2.7.3 Especificaciones de requisitos:...................................................................................................... 39
2.8 Validación de los requisitos ............................................................................................................... 59
2.9 Prototipos de interfaces. .................................................................................................................... 60
2.10 Conclusiones parciales: ..................................................................................................................... 80
 CAPÍTULO III: Construcción y validación de la solución propuesta. ................................................ 81
3. Introducción............................................................................................................................................. 81
3.1 Descripción y presentación del Diagrama de componentes: .......................................................... 81
3.2 Patrones de Diseño a emplear en la solución:................................................................................. 82
3.3 Diagrama de Clases del diseño......................................................................................................... 83
3.4 Evaluación del Modelo de diseño propuesto.................................................................................... 97
3.5 Resultados de la evaluación de las métricas ................................................................................... 98
3.6 Conclusiones parciales. ................................................................................................................... 100
 Conclusiones ........................................................................................................................................ 101
 Recomendaciones ................................................................................................................................ 102
 Bibliografía ............................................................................................................................................ 103
 Glosario de Términos ........................................................................................................................... 106
IV
 INTRODUCCIÓN
Actualmente el mundo de los negocios avanza a pasos agigantados, y este movimiento arrollador va de
la mano con los cambios que surgen en la tecnología, las nuevas demandas de información, los cambios
sociales, culturales y económicos existentes en este nuevo entorno. Todo esto pone de manifiesto el
nuevo horizonte en el curso de la contabilidad y el profesional contable, pues esta ciencia es quizás una
de las más importantes dentro del campo de los negocios, para no llevar el término al absolutismo; dada
su naturaleza de informar acerca del incremento de la riqueza, la productividad y el posicionamiento de
las empresas en los ambientes competitivos.
La importancia de los sistemas de información contable radica en la utilidad que tienen estos tanto para
la toma de decisiones en las empresas como para aquellos usuarios externos.
Las nuevas demandas de información abren campo a la introducción de nuevos conceptos que pueden
llegar a potencializar la empresa dentro del mercado si se le da el adecuado manejo, reconocimiento y
medición.
En la búsqueda de estos beneficios, se encuentran en uso actualmente gran diversidad de sistemas

contables tanto de fabricación cubana como importados, que favorecen la contabilización de las
transacciones que tienen lugar en las empresas del país, a propósito de ello se pueden mencionar el
VERSAT-Sarasola, RODAS XXI, SISCONT5, CONDOR, el Exact Globe, el ASSETS NS y el SAP.
Sin embargo a pesar de la gran diversidad de sistemas, no existe una solución única e integral para
tratar los procesos contables específicos de la contabilidad cubana. Muchos de los sistemas que hoy
están en el mercado carecen de una estructura de soporte adaptable y en otros casos sufren los efectos
de decisiones no previstas en su creación, por lo que se necesita un producto totalmente configurable y
flexible. Además gran cantidad de empresas en el territorio, utilizan productos importados trayendo
consigo gastos considerables de divisas por conceptos de mantenimiento y licencia, en adición a la falta
de manejo de la dualidad monetaria, con relación a las particularidades de la contabilidad nacional.
Es por ello que se crea el proyecto ERP-Cuba coordinado por el Ministerio de Finanzas y Precios,
compuesto por especialistas de diversos organismos, quienes de conjunto con estudiantes y profesores
de la Universidad de las Ciencias Informáticas tienen la misión de diseñar y construir una solución
integral que cumpla con los requerimientos funcionales y técnicos que estén a la altura de las mejores
soluciones de este tipo a nivel mundial.
1
Implementar un sistema con tales características es un proceso largo, costoso, complejo y requiere de
gran cantidad de personal. Siendo más factible dividir su desarrollo en subsistemas que representen las
distintas áreas de la empresa, de forma que se optimice todo el proceso.
La presente investigación se centrará en la fase inicial de desarrollo de la solución, específicamente en

el subsistema Contabilidad general. Dicha fase fue establecida por el líder nacional del proyecto; en
función de la priorización de aquellos procesos que resultan fundamentales en la introducción de
cualquier Sistema contable; ubicando en posteriores etapas de desarrollo los restantes procesos que
complementarán el producto final.
Dadas las necesidades previamente descritas se hace necesario plantear como problema a resolver:
¿Cómo contribuir al desarrollo de una solución contable que estandarice el manejo de la Contabilidad
cubana de manera tal que se emplee la dualidad monetaria y; que sea flexible y adaptable?
Para dar solución al problema existente, se propone como objeto de estudio los procesos de negocio
que tienen lugar en la Contabilidad financiera. Siendo el campo de acción el modelado de los procesos
contables del subsistema Contabilidad general.
Teniendo en cuenta el problema anterior se traza como objetivo general realizar el Análisis y Diseño
del subsistema Contabilidad general. Para dar solución al objetivo general planteado se proponen los
siguientes objetivos específicos:
 Realizar el marco teórico de la investigación.
 Desarrollar el Modelado del Negocio por procesos.
 Identificar y describir los Requisitos funcionales.
 Modelar el Diseño de cada componente definido.
Dentro de las tareas que se proponen para dar solución a los objetivos trazados se encuentran:
 Buscar información sobre Sistemas contables nacionales y extranjeros para fundamentar la

investigación.
 Llevar a cabo entrevistas con los especialistas funcionales de contabilidad para comprender los
procesos de negocio que se llevan a cabo en el subsistema.
 Consultar documentación sobre los procesos de negocio, elaborada por los especialistas de
contabilidad y finanzas.
 Realizar talleres de investigación y exploración con funcionarios y desarrolladores del sistema
contable VERSAT-Sarasola para intercambiar ideas y experiencias.
2
 Estudiar el modelo de desarrollo propuesto por el proyecto.
 Crear los artefactos correspondientes al negocio mediante la modelación por procesos, esto
permitirá posteriormente una buena captura de los requisitos funcionales.
 Determinar y especificar los requerimientos funcionales.

 Diseñar los prototipos de interfaz de usuario.
 Validar con los clientes las especificaciones de los requerimientos detectados, para de esta forma
dejar constancia de que éstos se ajustan a sus necesidades.
 Elaborar los artefactos definidos por el modelo de desarrollo para el flujo de trabajo de Diseño.
Se plantea como idea a defender: un buen Análisis y Diseño de los procesos contables que tienen lugar
en el subsistema Contabilidad general permitirá, una posterior implementación que se ajuste a las
necesidades de las entidades cubanas.
Métodos Teóricos
En el presente trabajo se emplearán los diferentes métodos de investigación:
 Lógico - histórico: se emplea para estudiar el desarrollo lógico e histórico de los principales
criterios sobre el tema. El empleo de este método permitió describir y explicar las características
del objeto y representar un nivel de la investigación, cuyo contenido es sometido a elaboración
racional.
 Modelación: pues se crean abstracciones que explican la realidad, por ejemplo, todos los
modelos y diagramas presentados.
Para lograr una sustentación más sólida de la investigación el documento se ha estructurado de la

siguiente manera: Introducción, tres Capítulos, Conclusiones, Recomendaciones, Bibliografía y Glosario
de Términos:
Capítulo 1: Fundamentación teórica. En este capítulo se hace un estudio del estado del arte de las
herramientas para el Modelado de negocio y Gestión de requisitos. Además se explica el modelo de
desarrollo, herramientas, notación y lenguaje de modelado a utilizar para el desarrollo del Análisis y
Diseño de la futura solución.
3
Capítulo 2: Descripción de la solución propuesta. En este capítulo se reflejará el trabajo de investigación
sobre los procesos de negocio inherentes a la Contabilidad general, de una empresa cubana, mediante
el Modelado de Negocio. Además se incluyen las descripciones de los requisitos o condiciones relativas
a las necesidades de los clientes coleccionadas a través de los diferentes métodos de captura de
información para estos propósitos, constituyendo la Gestión de requisitos de dicha solución. Con
basamento en los requisitos, se realizaron los prototipos de interfaces para la solución a desarrollar.
Capítulo 3: Construcción y validación de la solución propuesta. En este capítulo luego de un estudio

sobre las herramientas dispuestas por la dirección del proyecto y el equipo de arquitectura se realiza el
Diseño de clases web para darle cumplimiento a los objetivos anteriormente señalados. Se emplearán
patrones de diseño como el Modelo-Vista-Controlador, bajo una forma de diseño nueva establecida por
los arquitectos empleando especializaciones confeccionadas por el equipo de desarrollo también de
arquitectura.
4
 CAPÍTULO 1 Fundamentación teórica.
1. Introducción
En el presente capítulo se agregan conceptos sobre la Contabilidad general, para una mayor
comprensión del alcance de esta ciencia y al mismo tiempo como subsistema de un Sistema contable.
De estos últimos se realiza un estudio donde se brinda una visión general de sus características más
significativas y los subsistemas que se han automatizado en ellos de mayor importancia para la
Contabilidad, profundizando en los de mayor número de implantaciones en Cuba. A continuación se
realiza una descripción del modelo de desarrollo, tecnologías y herramientas a utilizar para la
consecución de la solución propuesta, así como una breve descripción del papel que desempeñan los
roles vinculados a esta investigación.
1.1 Fundamentación del tema
1.1.1 Contabilidad.
La contabilidad es una ciencia de naturaleza económica que tiene por objeto producir información para
hacer posible el conocimiento pasado, presente y futuro de la realidad económica en términos
cuantitativos en todos sus niveles organizativos, mediante la utilización de un método específico
apoyado en bases suficientemente contrastadas, con el fin de facilitar la adopción de las decisiones
financieras externas y las de planificación y control internas. (Cañibano, 1974)1
Como ciencia que es, constituye un sistema informativo que emite datos estructurados y relevantes de
los distintos entes que componen la realidad económica, como son las familias, las empresas, el sector
público y la nación. Estos datos, tras ser analizados e interpretados, son empleados por los sujetos
económicos para controlar los recursos con los que cuentan y tomar las medidas oportunas para
hacerlos más fructíferos y, en todo caso, para evitar una situación deficitaria que pondría en peligro su
supervivencia. En principio, estos datos indican cuáles son los recursos económicos y financieros de los
que dispone la unidad económica objeto de análisis. Para que esta información sea útil a aquellos que la
emplean, ha de ser objetiva, creíble, oportuna, clara, asequible y completa (Oliver, y otros, 1990).
1
Concepto de contabilidad más actualizado que existe, expresado por un especialista reconocido.
5
1.1.2 Sistemas contables
Con el avance de la tecnología y la informática, se han ideado y materializado, sistemas que

automatizan la gestión de la información financiera, los conocidos sistemas contables. Los cuales
operan de diversas maneras, pero esencialmente en el desarrollo y comunicación de dicha información
para la organización que los implanta. El uso de los sistemas directamente en computadores, no
interfiere en la actividad manual de acuerdo a las comodidades del usuario, el cual puede realizar
algunas actividades contables mediante el uso de registros e informes impresos, si lo desea.
Un Sistema contable sigue un modelo básico y bien diseñado, ofreciendo así, control, compatibilidad,
flexibilidad y una relación de costo/beneficio. En la contabilidad de cualquier empresa
independientemente del sistema contable que utilice, se deben ejecutar tres pasos básicos relacionados
con las actividades financieras; los datos se deben registrar, clasificar y resumir, sin embargo el
proceso contable involucra además la comunicación a quienes estén interesados y la interpretación de la
información contable para ayudar en la toma de decisiones comerciales.
1.1.3 Sistemas contables financieros presentes en entidades cubanas. Tratamiento del

subsistema Contabilidad general.
Existen muchas empresas dedicadas a la creación y comercialización de Sistemas contables por todo el
mundo, esta investigación expondrá algunos rasgos significativos de los más usados en varias
empresas nacionales, pudiéndose mencionar por tanto:
ASSETS NS
Es un Sistema de gestión integral, estándar y parametrisado que permite el control de los procesos de
Compras, Ventas, Producción, Taller, Inventario, Finanzas, Contabilidad, Presupuesto, Activos fijos,
Útiles y herramientas; y Recursos humanos. Como Sistema integral todos sus módulos trabajan en
estrecha relación, generando, automáticamente, al subsistema de Contabilidad los Comprobantes de
operaciones por cada una de las transacciones efectuadas, esto permite que se pueda trabajar bajo el
principio de Contabilidad al día, si se elige generar automáticamente los asientos diarios de cada una de
las transacciones efectuadas a través del sistema en los diferentes módulos.
Se podrá además, confeccionar otros asientos diarios de operaciones no controladas por ASSETS y
emitir en cualquier momento los Estados financieros de la entidad en múltiples monedas atendiendo a la
6
tasa de cambio. Los Estados financieros se pueden emitir para toda la compañía, por centros de costo o
agrupaciones (D'Marco, 2006).
Exact Globe para Windows
Es una solución completa de oficina. Cubre todas las funcionalidades en las áreas de Contabilidad,
Distribución, Logística, Servicios, Recursos humanos, Nóminas, Proyectos, Fabricación, entre otras. Es
un software modular diseñado para cualquier tipo de empresa que ha sido traducido a múltiples idiomas.
Además, soporta regímenes legales y comerciales en más de 20 legislaciones diferentes.
El innovador diseño de Exact Globe aporta una nueva dimensión a la Contabilidad. Las cuentas
financieras ya no son un elemento aparte de la gestión de operaciones. Todos los documentos que han
sido incluidos en los procesos principales generan automáticamente asientos en el libro mayor. Por lo
tanto, el balance y la cuenta de pérdidas y ganancias están siempre actualizados (Exact, 2006).
SAP
Está basado en una plataforma abierta que proporciona un completo control sobre su operativa y
estrategia empresarial. Mejora, al mismo tiempo, la productividad ya que proporciona la flexibilidad
necesaria para adaptar la estrategia corporativa a las necesidades empresariales cambiantes,
basándose en informaciones claras y en tiempo real. Entre las funcionalidades que SAP ERP le ofrece,
cabe destacar: Análisis empresarial, Contabilidad financiera e interna, Gestión del capital humano,
Gestión de operaciones, Gestión de servicios corporativos, Autoservicios.
Contabilidad financiera e interna, ofrece control e integración de toda la información financiera y contable
esencial para la toma de decisiones estratégicas y operativas. Esta herramienta mejora la gestión de
controles internos, auditoria, simplifica el análisis financiero y le permite llevar a cabo procesos de
negocio adaptables a cambios en el mundo de las finanzas. Todo esto le permitirá transformar sus
controles financieros de una simple función administrativa, en una parte de su empresa centrada en la
estrategia, el valor y la rentabilidad del capital. Rentabilidad y crecimiento sostenibles metas alcanzables
con esta solución financiera. Permite mantener el control y la responsabilidad de las finanzas y
contabilidad al mismo tiempo que capacita a su empresa para conseguir altos niveles de crecimiento
sostenible. Esta solución financiera le facilita, acelerar el proceso de cierre mediante la automatización
de procesos, flujo de trabajo y colaboración interna y externa; mejorar la eficacia de sus esfuerzos de
conformidad mediante auditorías completas, informes más exhaustivos y gestión de controles internos,
mejorar el análisis de negocio y el soporte para la toma de decisiones, implantando herramientas de
7
gestión que analizan toda la empresa y sus recursos y maximiza el flujo de caja mediante la mejora de la
facturación, las cuentas de deudores, los cobros y la gestión de tesorería. (SAP, 2009)
VERSAT-Sarasola
El programa VERSAT-Sarasola, sistema cubano de contabilidad, permite enviar información, de forma

inmediata y eficaz, desde lugares apartados, a la vez que ofrece mayor organización, control y disciplina
en cada gestión. Fue éste el primer sistema de contabilidad cubano certificado, en cuya evaluación
participaron el Ministerio de Finanzas y Precios, consultorías internacionales y el organismo encargado
de la seguridad informática. Es un sistema económico integrado. Constituido por los módulos de
Configuración y seguridad, Contabilidad general y de gastos, Costos y procesos, Análisis económico
empresarial, Control de activos fijos, Finanza y caja, Planificación y presupuestos, Control de
Inventarios, Pago de salario, Paquete de gestión, Contratación, Facturación.
El módulo de Contabilidad general y de gastos permite llevar el control y el registro contable individual
de todos los hechos económicos que se originan en las estructuras internas de las entidades y obtener
los Estados financieros y los análisis económicos y financieros en estos niveles. El análisis de la
información puede realizarse a partir de los Clasificadores de cuentas, Centros de costos o desde los
Comprobantes contables, hasta los “Documentos primarios” que dieron origen a cada una de las
operaciones. Se estructura en un grupo de subsistemas, donde se procesan y contabilizan documentos
primarios y se anotan los movimientos de los recursos materiales, financieros y laborales que se utilizan
en una entidad a partir de una configuración previa de los comprobantes que se originan.
Actualmente lo utilizan alrededor de 200 entidades de varias provincias y en lo adelante lo introducirán

más de dos mil 500 unidades presupuestadas del país, entre las que figuran organismos de la
Administración central del estado, las direcciones municipales de finanzas, tesorerías, la ONAT y otros
(Habasoft, 2005).
RODAS XXI
Es un sistema multi-empresa y multiusuario creado por CITMATEL para la automatización de la gestión

empresarial. Contiene los módulos Contabilidad, Efectivo caja y banco, Nóminas, Activos fijos tangibles,
Inventarios, Cobros y pagos, Facturación, Finanzas y Tele-cobranza, que pueden usarse de forma
integrada o independiente
Además, cuenta con el módulo Administrador, que brinda mayor integralidad al sistema y garantiza
facilidades adicionales durante su instalación y explotación.
8
El módulo de Contabilidad del sistema RODAS XXI, al ser éste un sistema integral, incluye la
importación de comprobantes generados por las operaciones en el resto de los módulos permitiendo su
revisión antes de ser traspasados al Mayor general, es posible incluso realizar ajustes a los
comprobantes importados antes de traspasarlos. Además de la importación, en este módulo pueden
realizarse comprobantes de operaciones directamente, contabilizando operaciones que por sus
particularidades no se realizan en ninguno de los otros módulos del sistema o sencillamente realizando
comprobantes de ajuste de operaciones. Este módulo le brinda, mediante una opción, la posibilidad de
revertir comprobantes de forma automática facilitando la realización de ajustes (RodasXXI, 2002).
SISCONT5
Este sistema se aviene a las definiciones y conceptos del Ministerio de la Industria básica aunque por
las acciones contables financieras que permite puede ser utilizado en otras entidades nacionales.
Está formado por los módulos, Efectivo en caja y banco, Inventarios, Cobros y pagos, Facturación,
Activos fijos tangibles, Nóminas y Contabilidad.
Puede ser explotado en régimen mono-usuario y multiusuario. Se define para mono-entidad y multi-
entidad, para esta última existe el control de su acceso para las entidades en un mismo equipo de
cómputo como servidor (Siscont5, 2008).
CONDOR
El Sistema de gestión contable CONDOR, que ofrece soluciones informáticas óptimas adaptadas a las
normas y principios de la Contabilidad general aceptados en Cuba de conformidad con las normas y
procedimientos establecidos por los Ministerios de Finanzas y precios y; de Informática y
Comunicaciones. Cuenta actualmente con más de 1000 clientes en el Ministerio del Transporte y en el
Instituto Nacional de Recursos hidráulicos (SICS, 2008). Está compuesto por módulos como el de
Contabilidad general, Activos fijos, Nómina/Pre-nómina, Inventario, Condexce2 y Disponibilidad
financiera permitiendo el intercambio entre ellos automáticamente y por opciones.
El módulo de Contabilidad general controla todas las transacciones propias de la contabilidad. Permite el
enlace con los demás módulos mediante Comprobantes de operaciones, permite hacer consolidado de
múltiples compañías dentro de una misma entidad (SICS, 2008).
2
Convertidor de la información contable del módulo Condor - Contabilidad general a un libro Excel, permitiendo la
elaboración y el análisis de la información en las diferentes etapas de forma automática y sencilla, garantizando la seguridad y
confiabilidad en los datos.
9
1.2 Modelo de desarrollo y herramientas empleadas
Todo desarrollo de software es riesgoso y difícil de controlar, es por eso que se debe tener un especial
cuidado a la hora de seleccionar una metodología adecuada de desarrollo de software porque puede
que al final los clientes no queden satisfechos y los desarrolladores aún más insatisfechos. Para la
solución contable en desarrollo, un conjunto bien notable de especialistas decidió establecer un Modelo
de Desarrollo de Software orientado a Componentes como modelo idóneo a emplear.
1.2.1. Modelo de Desarrollo orientado a componentes
El ERP3 es un sistema integral de gestión empresarial que está diseñado para modelar y automatizar la
mayoría de los procesos en la empresa (Contabilidad general, Caja, Banco, Costos y procesos, Cobros
y pagos, Inventario, Auditoría, Planificación, entre otros). Su misión es facilitar la planificación de todos
los recursos de la empresa. El software ERP planea y automatiza muchos procesos con la meta de
integrar información a lo largo de la empresa y elimina los complejos enlaces entre los sistemas de las
diferentes áreas del negocio. Es un proyecto que por su complejidad en los procesos de negocio,
tamaño, integración entre los subsistemas que lo conforman y además por el cúmulo de información que
almacenan y analizan, requiere de una largo período de elaboración, construcción y coordinación entre
los equipos de desarrollo (Producción, 2009).
Para la exitosa realización de un proyecto de tales magnitudes es necesario establecer modelos

estandarizados para los equipos inmersos en el desarrollo e implementación, así como una definición
clara y precisa de las responsabilidades de los roles involucrados en la solución (ver Fig. 1).
3
Enterprise Resource Planning (Planificación de recursos de la empresa).
10
Fig. 1: Organización por roles de la línea.
Rol de Analista:
El Analista debe poseer grandes habilidades de comunicación además de conocimiento del proceso de
desarrollo definido para el ERP. Debe ser capaz de identificar, delimitar y describir los procesos de
negocio. Representándolos a través de la notación BPMN. Debe tener habilidades para identificar y
describir los requisitos de software.
Responsabilidades:
 Participar en las sesiones de trabajo para identificar, describir y validar los procesos de negocio y
los requisitos de software.
 Elaborar la descripción de Procesos de negocio, Especificación de requisitos y Casos de prueba

según los estándares establecidos para ello.
 Participar en el taller de diseño.
Actividades en las que participa:
 Construir mapa de procesos.

11
 Especificar procesos.
 Taller de diseño.
 Diseñar casos de prueba.
Artefactos que genera:
 Plan de trabajo individual.
 Modelo de procesos de negocio.
 Descripción de procesos de negocio.
 Modelo conceptual.
 Prototipo de interfaz de usuario.
 Especificación de requisitos.
 Casos de prueba.
Rol de Diseñador de Lógica de Negocio:
Se especializa en la capa Lógica de negocios. Debe ser capaz de identificar, organizar y dividir en
componentes su Línea de desarrollo.
Responsabilidades:
 Diseñar y construir los componentes de software de la línea.
Actividades en la que participa:
 Taller de Análisis.
 Diseño de lógica de negocio.
 Validación de las Interfaces de usuario.
 Reunión de implementación.
 Implementación.
Artefactos que genera:

12
 Diagrama de clases.
 Descripción de las clases del diseño.
El modelo de desarrollo antes expuesto fue creado dadas las necesidades y particularidades del
proyecto ERP-Cuba, el cual está en función principalmente de la arquitectura definida. En la presente
investigación se emplearon los roles de Analista y Diseñador de lógica de negocio, con todos los
artefactos y actividades que el modelo determina se deben generar y dar seguimiento respectivamente.
1.2.2. Lenguaje Unificado para Modelado (UML)

El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se usa para
especificar, visualizar, construir y documentar artefactos de un sistema de software. Captura decisiones
y conocimientos sobre los sistemas que se deben construir. Se usa para entender, diseñar, configurar,
mantener, y controlar la información sobre tales sistemas. Está pensado para emplearse con todos los
métodos de desarrollo, etapas del ciclo de vida, dominios de aplicación y medios. El lenguaje de
modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores
prácticas actuales en un acercamiento estándar. UML incluye conceptos semánticos, notación, y
principios generales. Tiene partes estáticas, dinámicas, de entorno y organizativas. Está pensado para
ser utilizado en herramientas interactivas de modelado visual que tengan generadores de código así
como generadores de informes. La especificación de UML no define un proceso estándar pero está
pensado para ser útil en un proceso de desarrollo iterativo. Pretende dar apoyo a la mayoría de los
procesos de desarrollo orientados a objetos (Rumbaugh, y otros, 2000).
1.2.3. BPMN (Notación para Modelar los Procesos de Negocio)
BPMN (Business Process Modelling Notation (Notación para el Modelado de Procesos de Negocio)) es
una iniciativa de la BPMI (Business Process Management Initiative, un consorcio de negocios) que
apunta a definir una notación gráfica común para modelar los procesos de negocio.
La notación BPMN permite separar la información de negocio, de la información técnica (elementos

técnicos del sistema de información) para maximizar su capacidad de ser transferida de una compañía a
la otra. Se puede calificar como una notación UML aplicada a la administración de procesos de negocio
(Dumas, y otros, 2005).
13
1.2.4. Visual Paradigm para UML
El Visual Paradigm es una Suite de herramientas CASE que utiliza “UML” como lenguaje de modelado.
Es independiente de plataforma, dotada de una buena cantidad de productos o subsistemas para
facilitar el trabajo durante la confección de un software, lo cual garantiza la calidad del producto final. Es
una herramienta que en la universidad ha incrementado los niveles de aceptación, ya que actualmente
se han comprado las licencias para su uso. Este ofrece:
 Entorno de creación de diagramas para UML.
 Diseño centrado en casos de uso y enfocado al negocio que generan un software de mayor
calidad.
 Uso de un lenguaje estándar común a todo el equipo de desarrollo que facilita la comunicación.
 Capacidades de ingeniería directa (versión profesional) e inversa.
 Garantiza que el modelo y el código permanezcan sincronizados en todo el ciclo de desarrollo.
 Disponibilidad de múltiples versiones, para cada necesidad.
 Disponibilidad en múltiples plataformas.
 Es útil para la generación de código fuente en PHP.
Otra de las características que posee es que resulta una herramienta amigable para el usuario ya que
contiene facilidades para redactar especificaciones de Casos de Uso del Sistema utilizando plantillas
que se encuentran definidas o que pueden ser creadas por los usuarios, permite la sincronización entre
Diagramas de Entidad Relación y Diagramas de Clases, la generación de Código / Ingeniería Inversa.
Además permite la integración entre distintos ambientes de Desarrollo Integrados (IDE) como Visual
Studio y Eclipse entre otros (International, 2006).
Para realizar el diseño se consultaron las siguientes herramientas que fueron definidas por los
especialistas para llevar a cabo la implementación:
ExtJs framework: es un framework para Java Script muy utilizado en el desarrollo de aplicaciones Web
con AJAX. Tiene una librería inmensa que permite configurar las interfaces Web de manera semejante a
aplicaciones de escritorio. Contiene la mayoría de los controles de los formularios Web incluyendo Grids
para mostrar datos y elementos semejantes a la programación de escritorio como los formularios,
14
paneles, barras de herramientas, menús y muchos otros. Dentro de su librería de componentes incluye
elementos para el manejo de datos, lectura de XML, lectura de datos JSON e implementaciones
basadas en AJAX. Presenta el uso de Java Script con una programación orientada a objetos (Diseño
Avanzado de Aplicaciones Web., 2009).
Doctrine framework: es un potente y completo sistema ORM (Object Relational Mapper) para PHP 5.2+
con un DBAL (Database Abstraction Layer) incorporado. Entre muchas otras cosas tiene la posibilidad
de exportar una base de datos existente a sus clases correspondientes y también a la inversa, es decir
convertir clases (favorablemente creadas siguiendo las pautas del ORM) a tablas de una base de datos.
(Diseño Avanzado de Aplicaciones Web., 2009).
Zend_Ext framework: es uno de los más utilizados para PHP y utiliza el patrón MVC como base de su
funcionamiento. Es fácilmente integrable a las aplicaciones debido a su composición ya que contiene
diferentes clases de gran utilidad, como por ejemplo en la búsqueda dinámica de ficheros a incluir o
utilizar. Cuenta con un importante mecanismo de manejo de controladores y vistas por lo que se
propone tenerlo en cuenta para el diseño de estos dos componentes de la arquitectura. (Diseño
Avanzado de Aplicaciones Web, 2009).
1.3 Conclusiones parciales
En este capítulo se expusieron conceptos relacionados con la contabilidad, señalando su importancia

para el progreso de cualquier empresa y la necesidad de crear sistemas contables más capaces y
confiables que permitan al usuario mantener un orden en sus recursos y tomar decisiones certeras en el
mercado. También fueron expuestos algunos de los sistemas implantados en Cuba que cumplen con la
mayoría de los requisitos indispensables, pero que aún no conforman una solución única e integral para
tratar los procesos específicos de la contabilidad cubana. Luego se expuso la definición de los
especialistas del proyecto, al establecer un Modelo de desarrollo orientado a componentes, del cual se
emplean los roles, artefactos y actividades; además de que se utilizaría la notación BPMN, el lenguaje
UML y la herramienta case Visual Paradigm, sentado las bases para el inicio de la compleja fase de
análisis de la solución.
15
 CAPÍTULO II: Descripción de la solución propuesta.
2. Introducción
En este capítulo se presenta una propuesta de lo que será el sistema a partir del análisis realizado
posteriormente al negocio, detallando la descripción de los procesos que lo componen y determinando
cuáles de estos procesos se automatizarán para conformar el producto final.
Aparecen también enumerados los requisitos funcionales del sistema a desarrollar, logrando establecer
de este modo los rasgos imprescindibles que debe tener el mismo una vez que haya sido terminado,
para que las necesidades y solicitudes de los clientes queden en su mayoría satisfechas.
2.1 Modelo de Negocio

Un sistema, por pequeño que sea, generalmente es complicado. Por eso se necesita dividirlo en piezas
si se pretende comprenderlo y gestionar su complejidad. Esas piezas se pueden representar a través de
modelos que permitan abstraer sus características esenciales.
Una técnica para la especificación de los requisitos más importantes del sistema, que da soporte al
negocio, es el modelo del negocio, con lo cual se refuerza la idea de que sea el propio negocio lo que
determine los requisitos.
2.2 Modelo de Negocio basado en procesos.

Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto de procesos
de negocio. Cada uno de ellos se caracteriza por una colección de datos que son producidos y
manipulados mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o
departamentos) participan de acuerdo a un flujo de trabajo determinado. Por tanto, la finalidad del
modelado de negocio es describir cada proceso, especificando sus datos, actividades (o tareas), roles (o
agentes). El primer paso del modelado de negocio consiste en capturar los procesos de negocio de la
organización bajo estudio. La definición del conjunto de procesos de negocio es una tarea crucial, ya
que define los límites del proceso de modelado posterior (Molina, y otros, 2000).
Un proceso puede ser definido como un conjunto de actividades enlazadas entre sí que, partiendo de
una o más entradas las transforma, generando un resultado (Aiteco, 2006).
16
2.3 Procesos que tienen lugar en el subsistema Contabilidad general
En la presente investigación se definieron cinco procesos principales para el subsistema Contabilidad
general, éstos son:
 Configurar nomenclador de cuentas para la entidad.
 Realizar apertura.
 Emitir comprobante de operaciones.
 Realizar cierre.
 Emitir estados financieros.
A continuación se explica brevemente en que consiste cada proceso así como los diagramas donde se
muestra la secuencia de pasos para llevarlos a cabo. Una descripción exhausta se puede encontrar en
los documentos de descripción de procesos que se adjunta a la investigación, como parte de los anexos.
Proceso de Negocio: Configurar nomenclador de cuentas para la entidad
El Nomenclador de cuentas nacional es un documento oficial que está reflejado en la Resolución No. 9
del 2007 emitido por el Ministerio de Finanzas y Precios. El proceso Configurar nomenclador de cuentas
para la entidad consiste en seleccionar de ese nomenclador las cuentas y subcuentas específicas que
emplea cada entidad para organizar su información contable. El nomenclador configurado se aprueba,
se imprime y pasa a formar parte del Manual de procedimiento de contabilidad de la entidad.
17
Diagrama del proceso:
Fig. 2: Diagrama del proceso Configurar nomenclador de cuentas para la entidad.
Proceso de Negocio: Realizar apertura
La apertura no es más que el paso inicial para realizar la contabilidad en cualquier entidad, sus
características varían de acuerdo al nivel de procesamiento de la información contable, ya sea de forma
manual, automatizada o para una entidad nueva. Debe hacerse al inicio del año o Ejercicio económico, o
en el momento en que surja la nueva entidad. Para establecer comparaciones entre los resultados del
concluido ejercicio, se emitirán los Estados financieros que muestran el estado en el que inicia el nuevo
año la entidad.
18
Diagrama del proceso:
Fig. 2: Diagrama del proceso Realizar apertura.
Sección1 - Subproceso Apertura de ejercicio contable: ésta se lleva a cabo después de un cierre de
Ejercicio contable donde se actualizan todas las cuentas reales transfiriendo sus saldos de fin de
período, como los iniciales del año, poniéndolas en vigencia.
19
Diagrama del subproceso Apertura de ejercicio contable:
Fig. 3: Diagrama del subproceso Apertura de ejercicio contable.
Sección2 - Subproceso Apertura por cambio de sistema: este proceso de apertura resulta más
sencillo, ya que la incorporación o captura del Nomenclador de cuentas, del Codificador de centros de
costo y de los Elementos y subelementos del gasto, se realizan por importación del Sistema en uso
hasta ese momento.
20
Diagrama del subproceso Apertura por cambio de sistema:
Fig. 4: Diagrama del proceso Apertura por cambio de sistema.
21
Sección3 - Subproceso Apertura inicial: en ella se definen paso por paso todos los recursos
necesarios como nomencladores, Cuentas reales, Cuentas nominales y de existir las de Orden. Se
asienta el primer Comprobante de operaciones en el libro Mayor, lo que permite la emisión del Balance
de comprobación de saldos registrando el inicio de la entidad.
Diagrama del subproceso Apertura inicial:
Fig. 5: Diagrama del proceso Apertura inicial.
22
Proceso de negocio: Emitir comprobante de operaciones
En cada subsistema se procesan, registran y contabilizan, mediante Comprobantes de operaciones,

todos los hechos económicos afines a las características y contenidos inherentes a éstos,
transfiriéndose sus resultados al subsistema Contabilidad general para, conjuntamente con los
Comprobantes de operaciones elaborados en éste último, asentarlos en los registros contables y con
ello obtener los Estados financieros y otras informaciones necesarias para la administración de la
entidad. Estos Comprobantes de operaciones tienen como objetivo contabilizar las transacciones que
son anotadas en los diferentes Submayores específicos que se habiliten en los diversos subsistemas,
para su posterior pase a las cuentas control del Mayor y subcuentas de los Submayores, afectadas.
Además se utiliza para contabilizar aquellas operaciones que no se reflejan en ningún Submayor
específico y que se generan en el subsistema Contabilidad general.
Diagrama del proceso Emitir comprobante de operaciones:
Fig. 6: Diagrama del proceso Emitir comprobante de operaciones.

23
Proceso de negocio: Realizar cierre
Los procedimientos de cierre en este subsistema están condicionados a que no existan operaciones
pendientes de posteo (asentados) y que hayan efectuado el cierre correspondiente los restantes
subsistema en uso. Procesados todos los hechos económicos mediante las diferentes opciones y
subsistemas, y asentados en los registros contables, así como terminados los procedimientos que se
deben seguir desde el punto de vista contable, se procede a cerrar un período económico, el cual se
divide en tres categorías: Cuando no es mes 12, Cuando es mes 12 y Cuando es mes 13 o Cierre de
Ejercicio contable.
Diagrama del proceso Cierre:
Fig. 7: Diagrama del proceso Realizar cierre.
24
Sección1 - Subproceso Cuando no es mes 12: estos cierres son de tipo mensuales, que se hacen
dentro del Año o Ejercicio contable. Los períodos pueden ser de uno a seis meses según estime la
entidad y su objetivo es saber el estado de la entidad en ese tiempo.
Diagrama del subproceso Cuando no es mes 12:
Fig. 8: Diagrama del proceso Cuando es mes 12.
25
Sección2 - Subproceso Cuando es mes 12: éste es el último cierre de período que se hace y es en el
mes de Diciembre.
Diagrama del subproceso Cuando es mes 12:
26
Sección3 - Subproceso Cuando es mes 13: el objetivo central es emitir los Estados financieros para
comprobar la situación contable en la que cierra la entidad.
Diagrama del subproceso Cuando es mes 13:

27
Proceso de negocio: Emitir estados financieros
En este proceso figura la elaboración de los Estados financieros, que constituyen una representación
estructurada de la situación y rendimiento financieros de la entidad. Los Estados financieros también
muestran los resultados de la gestión realizada por los administradores con los recursos que se les han
confiado. Para cumplir este objetivo los Estados financieros suministran información acerca de los
siguientes elementos de la entidad:
 Activos.
 Pasivos.
 Patrimonio neto o Capital contable.
 Ingresos y Gastos, en los cuales se incluyen las Pérdidas y Utilidades.
 Otros cambios en el Patrimonio neto.
 Flujos de efectivo.
Entre los Estados financieros fundamentales de la entidad figuran: Balance de comprobación de saldos,
Estado de situación, Estado de resultado, Reporte de utilidad acumulada.
Balance de comprobación de saldos: una vez asegurado que se han contabilizado todas las
operaciones que procedan y los libros cuadrados, se elabora un Balance de comprobación de saldos
pre-cierre, con los saldos de las cuentas, subcuentas, análisis y sub-controles, a fin de comprobar el
cuadre de los saldos deudores con los acreedores y facilitar la emisión de los Estados financieros que
procedan. Para emitir este reporte la entidad no precisa de un período específico, puede ser en
cualquier momento que lo estime necesario.
Estado de situación (o Balance general): se elabora a partir del Balance de comprobación de saldos y
en él se incluirán, como mínimo, rúbricas específicas con los importes correspondientes a las siguientes
partidas:
 Efectivo y otros medios líquidos equivalentes.
 Deudores comerciales y otras Cuentas a cobrar.
 Inventarios.
28
 Activos fijos tangibles.
 Activos fijos intangibles.
 Inversiones financieras (excluidas las mencionadas anteriormente).
 Inversiones contabilizadas utilizando el método de la participación.
 Acreedores comerciales y otras cuentas a pagar.
 Pasivos y Activos de naturaleza fiscal.
 Provisiones.
 Pasivos no circulantes con intereses.
 Intereses minoritarios.
 Inversión estatal y reservas o Capital emitido y reservas, según corresponda.
Estado de resultado: este reporte también se emite a partir del Balance de comprobación de saldos y
en él se incluirán, como mínimo, rúbricas específicas con los importes que correspondan a las siguientes
partidas:
 Ingresos ordinarios.
 Gastos financieros.
 Participación en el resultado del ejercicio de las asociadas y negocios conjuntos que se

contabilicen según el método de la participación.
 Pérdidas o utilidades antes de impuestos, que se hayan reconocido por la venta o disposición por
otra vía de Activos, así como por la cancelación de Pasivos correspondientes a explotaciones en
interrupción definitiva.
 Impuesto sobre Utilidades.
 Resultado del ejercicio.
Se presentará un desglose de los gastos utilizando para ello una clasificación basada en la naturaleza
de los mismos o en la función que cumplan dentro de la entidad.
29
En el Estado de resultado, se presentarán rúbricas adicionales que contengan otras partidas, así como
agrupaciones y subtotales de las mismas, cuando tal presentación sea relevante para la comprensión
del rendimiento financiero de la entidad o sea exigido por alguna norma en particular.
Diagrama del proceso Emitir estados financieros:
Fig. 11: Diagrama del proceso Emitir estados financieros.
30
2.4 Patrones de Control de flujo empleados
Para realizar los diagramas de procesos de negocio, se emplearon diversos patrones de control de flujo
que aportaron más flexibilidad y organización, permitiendo crear una notación estandarizada que
representara los aspectos más significativos de comportamiento de los procesos en una entidad. Estos
patrones son:
 Secuencia: estandariza la habilidad de representar secuencias de actividades.
 División paralela: representa una división de una sola línea de control en múltiples líneas o
ramas de control que puedan ser ejecutadas concurrentemente.
 Opción exclusiva: es un punto de decisión en el flujo de un proceso donde una sola rama de
varias, es seleccionada.
 Unión simple: representa un punto en el flujo de trabajo del proceso donde dos o más ramas
alternativas se unen sin incluir sincronización.
Todos estos patrones están divididos en categorías para lograr un mayor alcance y representación de la
información, de los utilizados se presentan las divisiones:
 Opción exclusiva - Compuerta exclusiva (XOR Gateway): El cual parte de una actividad que
debe orientarse por una sola rama, escogiendo entre varias opciones, es por ello que al tomar la
deseada, se excluyen las demás.
 División paralela - a través de Sub-actividades (through sub-activities): Parte desde una

actividad, enlazándose con otra que contiene un conjunto de sub-actividades en su interior con
cierto orden de prioridad para su ejecución.
 Unión simple - Implícito (Implicit): Constituye la unión de varias actividades en una final, donde
desde varias entradas converge la información hasta obtener una única salida.
2.5 Mapa de Procesos de negocio

Una vez definidos los procesos de negocio con el mayor grado de detalle, para incluir todas las
especificidades de la Contabilidad general, se crea el Mapa de procesos (ver Fig. 4), en el cual se
representan las relaciones que existen entre los procesos en cuestión.
31
Fig. 12: Mapa de procesos para el subsistema Contabilidad general.
2.6 Modelos Conceptuales o de dominio.

El Modelo de dominio (o Modelo conceptual) es una representación visual de los conceptos u objetos del
mundo real significativos para un problema o área de interés. Representa clases conceptuales del
dominio del problema. Así como conceptos del mundo real, no de los componentes de software.
32
Modelo conceptual del proceso Configurar nomenclador de cuentas para la entidad:
Fig. 13: Modelo conceptual del proceso Configurar nomenclador de cuentas para la entidad.
Modelo conceptual del proceso Realizar apertura:
Fig. 14: Modelo conceptual del proceso Realizar apertura.

33
Modelo conceptual del proceso Emitir comprobante de operaciones:
Fig. 15: Modelo conceptual del proceso Emitir comprobante de operaciones.
34
Modelo conceptual del proceso Realizar cierre:
Fig. 16: Modelo conceptual del proceso Realizar cierre.
Modelo conceptual del proceso Emitir estados financieros:
Fig. 17: Modelo conceptual del proceso Emitir estados financieros.
35
2.7 Requerimientos
Los requerimientos representan las necesidades de los usuarios y los objetivos del sistema. Deben ser
concisos, completos y especificar claramente todo lo que se necesita llevar a cabo, ya sean entradas,
salidas, válidas o no; todas las posibles respuestas y situaciones. No deben ser ambiguos, sólo deben
tener una interpretación. Deben ser verificables, es decir; se debe poder chequear que cada requisito es
cumplido por el software. Además, los requisitos deben ser lo más adaptables y modificables posible
(Torres, 2008). Los requerimientos deben ser capaces de satisfacer todos y cada uno de los objetivos
del sistema.
La IEEE4 define un requerimiento como: (1) “Una condición o necesidad de un usuario para resolver un
problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema
o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento
formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2)”. (IEEE,
1993)
2.7.1 Técnicas empleadas para la captura de requisitos

La captura de requisitos es la actividad mediante la que el equipo de desarrollo de un sistema de
software extrae de cualquier fuente de información disponible, las necesidades que debe cubrir dicho
sistema. El proceso de captura de requisitos puede resultar complejo, principalmente si el entorno de
trabajo es desconocido para el equipo de analistas, y depende mucho de las personas que participen en
él. Por la complejidad que todo esto puede implicar, la ingeniería de requisitos ha trabajado desde hace
años en desarrollar técnicas que permitan hacer este proceso de una forma más eficiente y precisa.
A continuación se presentan un grupo de técnicas que de forma clásica han sido utilizadas para esta
actividad en el proceso de desarrollo de todo tipo de software.
La Entrevista es una técnica para recopilar información a partir de un intercambio directo entre
personas o grupos (López, 2004). Esta fue la primera técnica empleada para la captura de los requisitos
con los que debía cumplir el subsistema Contabilidad general. La misma estuvo dirigida a especialistas
en contabilidad que han manejado diversos Sistemas contables que forman parte del equipo de trabajo.
La investigación documental consiste en el estudio de documentos escritos sobre un objeto

determinado, es decir son todos aquellos documentos registrados en diferentes dispositivos físicos a los
4
Institute of Electrical and Electronics Engineers (IEEE). (Instituto de Ingenieros Eléctricos y Electrónicos), una asociación
técnico-profesional mundial dedicada a la estandarización, entre otras cosas.
36
que podemos tener acceso en forma directa o indirecta para su consulta (González). Esta técnica se
utilizó para estudiar y analizar las descripciones del negocio hechas por los especialistas, tanto como los
Manuales de usuario, de Sistemas contables como el Versat-Sarasola y otros documentos relativos a la
Contabilidad general, lo que permitió además tener conocimiento de otros requisitos necesarios que no
fueran capturados durante la entrevista.
Brainstorming (Tormenta de ideas) es también una técnica de reuniones en grupo cuyo objetivo es
que los participantes muestren sus ideas de forma libre. Consiste en la mera acumulación de ideas y/o
información sin evaluar las mismas. (Escalona, y otros, 2002). Para el empleo de esta técnica se
reunieron los integrantes del equipo de trabajo, por varios días, donde surgieron ideas novedosas, lo que
permitió optimizar al máximo el trabajo a desarrollar.
Concept Mapping (Modelo conceptual) son grafos en los que los vértices representan conceptos y las
aristas representan posibles relaciones entre dichos conceptos. (Escalona, y otros, 2002). Permitieron
un mejor entendimiento del negocio a través del modelado de los conceptos fundamentales que se
asocian en los procesos de negocio tratados.
2.7.2 Requisitos funcionales

R1 Gestionar entidad económica.
R1.1 Adicionar entidad económica.
R1.2 Eliminar entidad económica.
R2 Gestionar grupos y subgrupos contables.
R2.1 Crear grupo o subgrupo contable.
R2.2 Modificar grupo o subgrupo contable.
R2.3 Eliminar grupo o subgrupo contable.
R2.4 Buscar grupo o subgrupo contable.
R3 Gestionar contenido económico.
R3.1 Crear contenido económico.
R3.2 Modificar contenido económico.

37
R3.3 Eliminar contenido económico.
R3.4 Buscar contenido económico.
R4 Configurar los estados financieros.
R5 Definir cuentas de ingresos y gastos para las diferencias por redondeo en monedas y variaciones de
tipo de cambio por monedas.
R6 Gestionar cuenta contable del nomenclador de cuentas.
R6.1 Crear cuenta contable.
R6.2 Crear apertura de árbol de cuentas.
R6.3 Crear apertura por otro nomenclador.
R6.4 Modificar cuentas contables o aperturas.
R6.5 Eliminar cuentas contables o aperturas.
R6.6 Buscar cuentas contables o aperturas.
R6.7 Configurar cuentas contables de ingresos, gastos y resultado.
R7 Configurar nomenclador para apertura por otro nomenclador.
R7.1 Adicionar nomenclador para apertura por otro nomenclador.
R7.2 Modificar nomenclador para apertura por otro nomenclador.
R8 Gestionar comprobante de operaciones.
R8.1 Nuevo comprobante de operaciones.
R8.2 Validar comprobante de operaciones.
R8.3 Crear registro anexo al pase.
R8.4 Abrir comprobante de operaciones.
R8.5 Eliminar comprobante de operaciones.
R8.6 Buscar comprobante de operaciones.

38
R8.7 Revertir comprobante de operaciones.
R8.8 Generar comprobante de operaciones a partir de comprobante anterior.
R8.9 Cambiar el número del comprobante de operaciones.
R8.10 Terminar comprobante de operaciones.
R8.11 Asentar comprobante de operaciones.
R8.12 Pasar día contable.
R9 Cierre
R9.1 Cerrar período contable cuando no es mes 12.
R9.2 Cerrar período contable cuando es mes 12.
R9.3 Cerrar ejercicio económico (período 13).
R10 Reapertura de período o ejercicio anterior.
R11 Calcular mayor.
R12 Calcular submayor.
R13 Obtener estados financieros.
R13.1 Generar reporte de balance de comprobación de saldos.
R13.2 Generar reporte de estado de situación (Balance general).
R13.3 Generar reporte de estado de resultado.
R13.4 Generar reporte de utilidades acumuladas.
2.7.3 Especificaciones de requisitos:

En las especificaciones de requisitos se registran las características y condiciones definidas con que
debe cumplir cada requisito funcional. A continuación se expondrán las descripciones principales,
brindando una idea más profunda de su realización. Todas se pueden encontrar en los documentos de
Especificación de requisitos que se adjuntan a la investigación, constituyendo artefactos generados
durante el proceso de captura y descripción de los mismos.
39
R6 Gestionar cuenta contable del nomenclador de cuentas
R6.1 Especificación de requisitos: Crear cuenta contable.
Conceptos tratados Conceptos Atributos
Cuenta Código, Naturaleza, Contenido económico, Descripción,

contable. Fecha inicio, Fecha fin.
Precondiciones Precondiciones Pre-requisito
Deben estar Crear contenido económico.

Creados los
Contenidos
económicos.
Debe estar
creada la
Estructura
económica.
Descripción En esta primera apertura se define la Cuenta sin ningún tipo de apertura
específica. Se crea la cabeza de la cuenta, de acuerdo con sus atributos
Código, Descripción, Naturaleza, Contenido económico, Fecha inicio, Fecha
fin.
Validaciones Los datos introducidos en el campo Código estarán definidos según la

máscara de nomencladores de Configuración.
En el campo Descripción se podrán introducir los datos definidos

según la máscara de nomencladores de Configuración.
El campo Naturaleza esta definido por el nomenclador de Naturaleza

que tiene como atributos (Deudora, Acreedora, Mixta). No puede ser
vacío.
El campo Contenido económico estará definido según la máscara de

nomencladores de Configuración.
40
En los campos de Fecha se seleccionarán datos de fecha. Siendo
obligatorio definir Fecha inicio. En caso de definir una Fecha fin, esta
debe ser mayor que la de Inicio.
El sistema debe permitir crear tantas Cuentas contables, como se

desee.
Post-condiciones Se ha creado una Cuenta contable.
Post-requisito No procede.
R6.2 Especificación de requisitos: Crear apertura de árbol de cuentas.
Cuenta Código, Tipo de apertura, Descripción, Naturaleza, Fecha

contable. inicio, Fecha fin.
Debe estar Crear cuenta contable.

creada la cuenta
a la que se le
realizará la
apertura.
Descripción Para ello se realizará una apertura del árbol de cuentas sin usar otro
nomenclador, a cualquier nivel de la máscara.
Primero se selecciona la cuenta a la que se le realizará la apertura, y a que

nivel se realizará la misma.
Se permitirá introducir los datos de la nueva cuenta de la apertura con los

campos de Código, Descripción, la Naturaleza, Fecha inicio y Fecha fin.
Validaciones - Los datos introducidos en el campo Código estarán definidos según la

máscara de nomencladores de Configuración.
41
- En el campo Descripción se podrán introducir los datos definidos
según la máscara de nomencladores de Configuración.
- En el campo Tipo de apertura se escogerá a que nivel se quiere hacer

la apertura (Subcuenta, Subcontrol, etc.).
- El campo Naturaleza estará definido según la máscara de

- El campo Contenido económico estará definido según la máscara de

- En los campos de Fecha se seleccionarán datos de fecha. Siendo

obligatorio definir Fecha inicio. En caso de definir una Fecha fin, esta
debe ser mayor que la de Inicio.
- En caso de que el padre no tenga Fecha fin definida, la hija puede o

no tenerla definida.
- Si la apertura se le va a realizar a una cuenta contable que tenga

fecha de inicio y fin definidos, el sistema debe de validar que la fecha
de inicio de la nueva cuenta sea igual o mayor a la cuenta padre, y
que la fecha de fin esté comprendida en el rango de fecha inicio-fin de
la cuenta padre.
Post-condiciones Se ha creado una apertura al árbol de Cuenta contable.
R6.3 Especificación de requisitos: Crear apertura por otro nomenclador.
No procede No procede
Deben estar
42
configurados los
nomencladores
por los que se
puede realizar la
apertura.
Debe estar Crear cuenta contable.

creada la cuenta
a la que se le
realizará la
apertura por otro
nomenclador.
Descripción En este tipo de apertura se le realizará a la cuenta una apertura usando otro
nomenclador, a un nivel definido por la máscara.
Primero se selecciona la cuenta a la que se le realizará la apertura, y por cuál

criterio se realizará la misma (estos son los distintos niveles de apertura).
Se deben mostrar todos los nomencladores que existen en el sistema para

escoger uno. Luego el sistema debe mostrar la lista de todos los elementos
que componen al nomenclador seleccionado permitiendo que se incluyan en
la apertura de la cuenta, todos los que se desee. Al realizar la apertura se
deberá guardar la referencia desde donde procede el nomenclador, para
conformar un historial.
Validaciones - El sistema valida los datos introducidos para la creación de la cuenta

de acuerdo con el formato establecido por Configuración.
Post-condiciones Se ha creado una apertura a una cuenta por otro nomenclador.
R8 Gestionar comprobante de operaciones.
R8.1 Especificación de requisitos: Crear comprobante de operaciones.
43
Comprobante de Fecha, Descripción, Número, Códigos de las

operaciones. cuentas afectadas según la Máscara del
Formato, Moneda, Tasa, Factor de conversión,
Débito, Crédito.
Registro de Comprobante Comprobante de operaciones.

de operaciones.
No procede.
El usuario se haya
autenticado en el sistema y
tenga permisos para
ejecutar la acción.
El Nomenclador de cuentas
debe contener información
y deben haberse realizado
los enlaces
correspondientes con otros
clasificadores como los de
clientes, los de persona, los
de centros de costo, los de
elementos del gasto u otros
creados en la solución.
Debe estar creada la

Estructura económica.
Descripción
El sistema permite adicionar un nuevo Comprobante de operaciones, donde
los atributos van a estar en dependencia de la máscara del Nomenclador de
cuentas y de los campos de los clasificadores que están enlazados con cada
una de las cuentas.
Si no existen errores, al cerrar el comprobante se salvará con el estado “Sin
44
error”.
Si existen errores en los datos el sistema los notifica al usuario y permite

corregirlos. En caso de que se mantengan los errores y el usuario desee
cerrar el comprobante este se salvará pero el estado será “Con error”.
En ambos casos el número del comprobante será el consecutivo del registro

de comprobantes que se generará de manera automática y se fijará en el
momento de la primera salva. Se mostrarán los opciones de: adicionar un
nuevo pase, eliminar un pase, Ver Registro anexo al pase, duplicar pase (se
creará un nuevo pase con las mismas operaciones del pase duplicado),
validar el comprobante (permite mostrar los errores de validación que tenga el
comprobante), imprimir, documentos primarios (Se mostrará un listado de
pases en los documentos primarios donde queden registrados los hechos
ocurridos), desglose Débito/Crédito (de los pases). En el caso que una cuenta
sea de gasto se mostrará de manera automática el Registro anexo al pase.
Ver requisito Crear Registro anexo al pase.
Validaciones
- Se deben introducir de forma obligatoria los campos: Descripción,
Importe (Débito o Crédito) y Fecha. En el caso de que no introduzca la
fecha se pondrá por defecto la del día actual (Si la fecha actual no es
la del período activo, se pondrá la fecha del último día del período
activo).
En el cuerpo del comprobante:
- La sumatoria de los débitos igual a la sumatoria de los créditos por

tipos de monedas.
- La suma de control de todos los niveles del árbol de cuenta.
- Para comprobantes importados además de todas las validaciones:
- Chequear el árbol de cuenta.
- En el Registro anexo al pase:
- Chequear en cada pase que tenga anexo que la sumatoria del anexo
al pase sea igual al importe que tiene el pase en débito o crédito, por
tipo de monedas.
45
- Suma de control de todos los niveles de centros y elementos.
- En el pase, cuando trabajo con una moneda diferente a la moneda

base procedo:
- Importe moneda original / Factor de conversión * Tasa de cambio y

guardo en importe moneda base.
- Si introduzco modificación en la tasa o en el factor de conversión,

tengo que guardar esta información en Configuración. El id que se
guarda es el nuevo.
- Si el pase en moneda base, invalido factor de conversión y tasa en la

vista.
- Si la cuenta está controlada por otro subsistema se genera un error y

no permite la creación del pase.
Postcondiciones Se ha creado un nuevo Comprobante en estado “Sin error” o “Con error”
según sea el caso.
Post-requisito No procede
Criticidad Importante.
R8.3 Especificación de requisitos: Crear registro anexo al pase.
Registro anexo al pase. Tipo, Importe y otros atributos

según lo definido en la máscara de
Centros de costo y Elementos de
gastos, para las entidades
empresariales, y en la máscara de
Grupo presupuestario y Objetos de
gastos en las entidades
presupuestadas.
46
Precondiciones Precondiciones
Pre-requisito
No procede.
El usuario se haya autenticado en el
sistema y tenga permisos para
ejecutar la acción.
Este pase sólo se podrá crear

cuando el usuario haya elaborado
en el comprobante una cuenta de
gastos.
Descripción
Después de hacer un pase en una cuenta de gastos el sistema solicitará
realizar un pase en el Registro anexo al pase, además de imprimir el
Registro anexo al pase. Una vez creado el Registro anexo al pase se
muestra una suma control de los valores de cada columna de manera
automática. En caso de contener algún error el sistema permitirá corregir el
pase deseado.
Validaciones
- El Registro anexo al pase sólo podrá ser eliminado si se elimina la
cuenta de gastos a la cual pertenece.
- En el caso del campo importe su valor no puede ser ni letra ni

símbolos.
- -El Registro anexo al pase sólo podrá ser modificado o actualizado

cuando el comprobante tiene cualquier estado que no sea el de
“Asentado”.
- El importe del Registro anexo al pase debe ser igual al importe del
pase registrado en el comprobante.
Postcondiciones Se ha registrado un pase en el Registro anexo al pase.
R8.4 Especificación de requisitos: Abrir comprobante de operaciones.
47
Comprobante de operaciones. Fecha, Descripción, Número, Códigos

de las cuentas afectadas según la
Máscara del Formato, Moneda, Tasa,
Factor de conversión, Débito, Crédito.
El usuario se ha identificado y No procede.

autenticado ante el sistema y tiene
permisos para ejecutar esta acción.
Debe existir el Comprobante de
operaciones.
Descripción El sistema permitirá editar el comprobante seleccionado. Si está en estado

“Asentado” el comprobante no podrá ser modificado y sólo se podrá visualizar.
Si no esta en estado “Asentado” entonces se podrá hacer modificaciones en la

Descripción y la Fecha del comprobante, tanto así como en los campos de
cualquier pase que se seleccione previamente, manteniendo siempre la
naturaleza del mismo. Dichos pases también se podrán duplicar (se creará un
nuevo pase con las mismas operaciones del pase duplicado) y eliminar.
Validaciones
Si el comprobante está en estado “Asentado”
Sólo se podrá visualizar.
Si no está en estado “Asentado” se validará:
- Que sólo se podrán introducir valores alfanuméricos en el campo

Descripción.
En caso de modificar un pase se validará:
- La sumatoria de los débitos igual a la sumatoria de los créditos por tipos

de monedas.
- Para comprobantes importados además de todas las validaciones:
- Chequear el árbol de cuenta.

48
En el Registro anexo al pase:
- Chequear en cada pase que tenga anexo que la sumatoria del anexo al
pase sea igual al importe que tiene el pase en débito o crédito, por tipo
de monedas (Base/Original).
- Suma de control de todos los niveles de centros y elementos.
- En el pase, cuando trabajo con una moneda diferente a la moneda base

procedo:
- Importe moneda original / Factor de conversión * Tasa de cambio y

guardo en importe moneda base y moneda original.
- Si se necesita cambiar la tasa o el factor de conversión, con el que se

esta trabajando, se seleccionará de Configuración cualquier registro
anterior de la tasa o del factor de conversión.
- Si el pase es en moneda base, invalido factor de conversión y tasa en la

vista.
Postcondiciones Si se ha modificado se salvará el comprobante en estado “Sin error” o “Con
error” según sea el caso.
R8.10 Especificación de requisitos: Terminar comprobante de operaciones.
Comprobante de operaciones. Estado.

49
Debe existir el comprobante y estar No procede.
en estado “Sin error”.
Descripción El sistema permitirá cambiar el comprobante de estado “Sin error” a

“Terminado”. Este cambio puede hacerse a un comprobante o a un grupo
seleccionado previamente.
Validaciones
El Comprobante de operaciones debe estar en estado “Sin error”.
Postcondiciones Se ha cambiado el estado del comprobante a Terminado.
R8.11 Especificación de requisitos: Asentar comprobante de operaciones.
Comprobante de operaciones. Estado.

Debe existir el comprobante y estar No procede.

en estado “Terminado”.
Descripción El sistema permitirá cambiar el comprobante de estado “Terminado” a

estado “Asentado”.
Este cambio puede hacerse a un comprobante o a un grupo de estos

seleccionado previamente.
Validaciones
El Comprobante de operaciones debe estar en estado “Terminado”.
No debe haber saltos en el consecutivo de los Comprobantes asentados.
50
Postcondiciones Se ha cambiado el estado del comprobante.
R9 Cierre
R9.1 Especificación de requisitos: Cerrar período contable cuando no es mes 12.
Comprobante de operaciones. Campos según máscara, Moneda,

Factor de conversión, Debe, Haber,
registro Anexo al pase.
Precondiciones El contador debe haberse identificado y autenticado ante el sistema.
Pre-requisito No procede.
Descripción
Los procedimientos de cierre están condicionados a que no existan
documentos pendientes de contabilizar y que haya efectuado el cierre
correspondiente en los restantes módulos en uso.
Validaciones
- Verificar que todos los subsistemas estén cerrados. El sistema
debe verificar que todos los subsistemas se encuentren en estado
“Cerrado”. De existir algún subsistema que no haya cerrado se
muestra un mensaje de error notificando que el período no se
puede cerrar.
- Verificar estado de los Comprobantes de operaciones. El sistema

verificará que todos los comprobantes de operaciones se
encuentren en estado “Asentado”. De existir algún comprobante
que no este asentado se muestra un mensaje de error notificando
que el período no se puede cerrar.
- Verificar la naturaleza de las Cuentas. El sistema verificará que no

existan cuentas con saldos contrarios a su naturaleza, lo cual
significa que las cuentas que son de naturaleza deudoras no
51
tengan el saldo como acreedoras y las cuentas que son acreedoras
no tengan el saldo como deudoras. En caso de que existan, se
puede cerrar.
- Verificar Saldos contarios a la naturaleza de los Elementos del

gasto. El sistema verificará que los elementos de gastos no tengan
saldos contrarios a su naturaleza. En caso de que existan, se
muestra un mensaje de error notificando que el período o el
Ejercicio Contable (según el que se este cerrando) no se puede
cerrar. De igual forma se procede con los objetos de gastos.
- Verificar Saldos contarios a la naturaleza de las Cuentas asociadas

a los Centros de costo. El sistema verificará que los centros de
costo no tengan saldos contrarios a su naturaleza. En caso de que
existan, se muestra un mensaje de error notificando que el período
no se puede cerrar. De igual forma se procede con los grupos
presupuestarios.
- Si el cierre es del período 0 “Apertura”, deberá solicitarse que

período se desea activar.
Postcondiciones
- El subsistema cambia de fecha activa para el nuevo período.
R9.2 Especificación de requisitos: Cerrar período contable cuando es mes 12.
Comprobantes de operaciones. Campos según máscara, Moneda,

52
Precondiciones El contador debe haberse identificado y autenticado ante el sistema.
Pre-requisito No procede.
Descripción
Los procedimientos de cierre están condicionados a que no existan
operaciones pendientes de asientos y que hayan efectuado el cierre
correspondiente los restantes módulos de contabilidad en uso. Procesados
todos los hechos económicos mediante las diferentes opciones y
subsistemas, y asentados en los registros contables, así como terminados
los procedimientos que se deben seguir desde el punto de vista contable,
se procede a cerrar un período ejercicio económico.
Validaciones
El sistema valida los datos de la siguiente manera:
- Verificar estado de los Comprobantes de operaciones. El sistema

verificará que todos los comprobantes de operaciones se
encuentren en estado “Asentado”. De existir algún comprobante
que no este asentado se muestra un mensaje de error notificando
que el período no se puede cerrar.
- Verificar la naturaleza de las Cuentas. El sistema verificará que no

existan cuentas con saldos contrarios a su naturaleza, lo cual
significa que las cuentas que son de naturaleza deudoras no
tengan el importe como acreedoras y las cuentas que son
acreedoras no tengan el importe como deudoras. En caso de que
existan, se muestra un mensaje de error notificando que el período
no se puede cerrar.
- Verificar Saldos contarios a la naturaleza de los Elementos del

gasto. El sistema verificará que los elementos de gastos no tengan
saldos contrarios a su naturaleza. En caso de que existan, se
puede cerrar. De igual forma se procederá con los objetos del
gasto.
- Verificar Saldos contarios a la naturaleza los Centros de costo. El

sistema verificará que los centros de costo no tengan saldos
53
contrarios a su naturaleza. En caso de que existan, se muestra un
mensaje de error notificando que el período no se puede cerrar. De
igual forma se procederá con los grupos presupuestarios.
Postcondiciones
- Al cerrar el período, el subsistema cambia la fecha de
procesamiento para el próximo período.
R9.3 Especificación de requisitos: Cerrar ejercicio económico (período 13).
Comprobantes de operaciones. Campos según máscara, Moneda,

El nuevo ejercicio y sus períodos

deben haberse creado en
configuración.
El contador debe haberse No procede.

identificado y autenticado ante el
sistema.
Debe realizarse el cierre del mes No procede.

12.
Descripción
El sistema cerrará el Ejercicio económico.
54
Validaciones
El sistema valida los datos según:
- Se realiza luego de cerrar el mes 12, y se hace de la siguiente

manera:
- Las Cuentas nominales tienen saldo “Cero”. De ocurrir un error

inesperado el sistema cancela el cierre del
ejercicio económico y emite un mensaje de notificación.
Postcondiciones
- Al cerrar el ejercicio económico, el subsistema cambia la fecha de
procesamiento para el próximo año y período, activando un nuevo
ejercicio contable.
R13 Obtener estados financieros
La característica más importante de los Estados financieros y lo que los hace diferentes; es la
información que deben contener. Los detalles de cada uno de ellos están comprendidos también dentro
del paquete de Especificaciones de requisitos anexados a la investigación. Se decidió por los autores no
reflejar estas especificaciones en el presente documento, dada su extensión y nivel de complejidad por
lo que sólo se muestra una figura de la información que deben contener:
55
R13.1 Especificación de requisitos: Generar reporte de balance de comprobación de saldos:
Fig. 18: Formato del Estado financiero, Generar reporte de balance de comprobación de saldos.
56
R13.2 Especificación de requisitos: Generar reporte de estado de situación:
Fig. 19: Formato del Estado financiero, Generar reporte de estado de situación.
57
R13.3 Especificación de requisitos: Generar reporte de estado de resultado:
Fig. 20: Formato del Estado financiero, Generar reporte de estado de resultado.
58
R13.4 Especificación de requisitos: Generar reporte de utilidad acumulada:
Fig. 21: Formato del Estado financiero, Generar reporte de utilidad acumulada.
2.8 Validación de los requisitos
Los requisitos una vez definidos necesitan ser validados. La validación de requisitos tiene como misión
demostrar que la definición de éstos precisa realmente el sistema que el usuario necesita o el cliente
desea (Lowe & Hall, 1999). Es necesario asegurar que el análisis realizado y los resultados obtenidos de
la etapa de definición de los requisitos sean correctos. Pocas son las propuestas existentes que ofrecen
técnicas para la realización de la validación y muchas de ellas consisten en revisar los modelos
obtenidos en la definición de requisitos con el usuario; para detectar errores o inconsistencias.
Aún así, existen algunas técnicas que pueden aplicarse para ello, como la Revisión técnica formal, las
Listas de chequeo, las Auditorías, y los Prototipos.
59
De estas técnicas sólo se empleó la Revisión técnica formal donde los analistas del subsistema una
vez terminadas las especificaciones de requisitos realizaron la reunión de revisión, a la cual convocaron
a la especialista funcional a cargo del subsistema Contabilidad general Ernestina Lourdes Iglesias
Planas, al Dr. José Carlos Del Toro Ríos Director nacional del proyecto ERP-Cuba; al Ing. Rolando
Ramírez Concepción representante del UCID, a la MsF. Ana Inés Maury Agaisse representante del
MAC, al Ing. Osmar Leyet Fernández el entonces Jefe de línea y la analista principal Ing. Yanet Vega
Minet los cuales firmaron y aprobaron las especificaciones descritas sin posteriores modificaciones.
2.9 Prototipos de interfaces.

La creación de las interfaces de usuario ha sido un área del desarrollo de software que ha evolucionado
dramáticamente a partir de la década de los ´70; siendo la interfaz de usuario el vínculo entre el usuario
y el programa de computadora. Una interfaz es un conjunto de comandos o menús a través de los
cuales el usuario se comunica con el programa (Segovia, 1999).
Esta es una de las partes más importantes de cualquier programa que determina la facilidad con que
puede ser ejecutado lo que el usuario desea hacer. Un programa muy poderoso con una interfaz
pobremente elaborada tiene poco valor para un usuario no experto.
Para el subsistema Contabilidad general se definieron los siguientes prototipos de interfaz de usuario
según los requisitos descritos (Para ver las especificaciones de las interfaces dirigirse al Manual de
usuario de Contabilidad general, el cual se encuentra anexado a la investigación).
60
 Prototipo de interfaz del requisito: R1 Gestionar entidad económica.
Fig. 22: Prototipo de interfaz Gestionar entidad económica.
Esta interfaz mostrará en forma de árbol todas las Entidades económicas creadas. Permitiendo las
opciones de adicionar una nueva o eliminar alguna existente para lo cual será necesario
seleccionarla previamente.
61
 Prototipo de interfaz del requisito: R1.1 Adicionar entidad económica.
Fig. 23: Prototipo de interfaz Adicionar entidad económica.
Mediante esta interfaz se podrá crear una nueva Entidad económica, llenando cada campo según
sus especificidades. Donde los datos de los campos Criterio económico, Formato y, Estructura y
composición; se asignarán desde otros subsistemas. Después de introducidos los datos, para
realizar la inserción de la nueva entidad, podrá presionarse el botón Aplicar si se desea continuar
adicionado entidades, sino bastaría con presionar el botón Adicionar para crearla y cerrar la interfaz.
62
 Prototipo de interfaz del requisito: R2 Gestionar grupo o subgrupo contable.
Fig. 24: Prototipo de interfaz Gestionar grupo o subgrupo contable.
Esta interfaz mostrará en forma de árbol el nombre y el código de cada Grupo y Subgrupo contable
que se haya creado hasta el momento. Brindando además las opciones de crear, modificar, buscar o
eliminar Grupos o Subgrupos contables. Para llevar a cabo esta última operación se deberá
seleccionar previamente el grupo o subgrupo que se desea eliminar.
 Prototipo de interfaz del requisito: R2.1 Crear grupo o subgrupo contable.
Fig. 25: Prototipo de interfaz Adicionar grupo o subgrupo contable.
63
A través de esta interfaz se podrá crear un nuevo Grupo o subgrupo contable según sea el caso.
Para ello se deberán llenar todos sus campos.
 Prototipo de interfaz del requisito: R2.2 Modificar grupo o subgrupo contable.
Fig. 26: Prototipo de interfaz Modificar grupo o subgrupo contable.
Esta interfaz editará los datos del Grupo o subgrupo contable en su campo correspondiente
permitiendo modificar cualquiera de ellos. En el caso de los Grupos contables sólo se podrán
modificar los que no contengan subgrupos asociados.
 Prototipo de interfaz del requisito: R3 Gestionar contenido económico.
64
Fig. 27: Prototipo de interfaz Gestionar contenido económico.
Esta interfaz mostrará listados todos los Contenidos económicos. A su vez permitirá la opción de
adicionar, modificar, buscar o eliminar cualquiera de ellos. En el caso de la opción eliminar, se podrá
llevar a cabo siempre y cuando el Contenido económico previamente seleccionado no esté asociado
a ninguna cuenta en el Nomenclador de cuentas.
 Prototipo de interfaz del requisito: R3.1 Crear contenido económico.
Fig. 27: Prototipo de interfaz Adicionar contenido económico.
Mediante esta interfaz se podrá adicionar un nuevo Contenido económico. Para ello se deberán
llenar todos los campos necesarios, en este caso el campo Fecha fin podrá quedar vacío ya que no
necesariamente se sabe cuando dejará de estar en vigencia un Contenido económico.
65
 Prototipo de interfaz del requisito: R3.2 Modificar contenido económico.
Fig. 28: Prototipo de interfaz Modificar contenido económico.
Esta interfaz editará los datos del Contenido económico seleccionado y permitirá modificar
cualquiera de ellos.
66
 Prototipo de interfaz del requisito: R4 Configurar estados financieros.
Fig. 29: Prototipo de interfaz Configurar estados financieros.
Esta interfaz brindará la opción de configurar y definir los Estados financieros que serán emitidos por
la entidad, así como la información que deben mostrar. En caso de ocurrir algún error en el momento
de su creación los Grupos y Conceptos se podrán eliminar seleccionándolos previamente.
67
 Prototipo de interfaz del requisito: R5 Definir cuentas de ingresos y gastos para las diferencias
por redondeo en monedas y variaciones de tipo de cambio por monedas.
Fig. 30: Prototipo de interfaz Definir cuentas para redondeo.
Mediante esta interfaz se mostrarán las cuentas de Ingreso y Gasto por diferencia de tasa de
cambio, así como la cuenta Resultado. En caso de surgir algún error o cambio, cualquiera de ellas se
podrá eliminar, seleccionándola previamente.
 Prototipo de interfaz Asignar cuenta del requisito: R5 Definir cuentas de ingresos y gastos
para las diferencias por redondeo en monedas y variaciones de tipo de cambio por monedas.
Fig. 31: Prototipo de interfaz Asignar cuentas.
68
Esta interfaz permitirá seleccionar las cuentas de Ingreso y Gasto por diferencia de tasa de cambio
así como la de Resultado. Para ello en cada campo se cargarán las cuentas correspondientes.
 Prototipo de interfaz del requisito: R6 Gestionar cuenta contable del nomenclador de cuentas.
Fig. 32: Prototipo de interfaz Gestionar cuenta contable.
Esta interfaz permitirá adicionar, modificar, eliminar y crear una apertura de una cuenta contable.
Además se podrán realizar búsquedas en función del código o la descripción de las cuentas
deseadas, así como su vigencia. Para ello se mostrarán las cuentas en forma de árbol de manera tal
que sólo se pueda adicionar una cuenta padre a partir de la raíz del árbol.
 Prototipo de interfaz del requisito: R6.1 Crear cuenta contable.
Fig. 33: Prototipo de interfaz Adicionar cuenta contable.

69
Mediante esta interfaz se podrán crear las Cuentas contables, siendo necesario completar
previamente todos los campos obligatorios.
 Prototipo de interfaz del requisito: R6.2 Crear apertura de árbol de cuenta.
Fig. 34: Prototipo de interfaz Crear apertura.
La interfaz anterior permitirá crearle aperturas a las cuentas padres, para ello en los campos Código
y Descripción se cargarán los datos de la cuenta padre y en el campo Apertura en: se mostrará el
nivel de la cuenta en el cual se va a hacer dicha apertura.
 Prototipo de interfaz Asignar tipo de cuenta del requisito: R6.2 Crear apertura de árbol de
cuenta.
Fig. 35: Prototipo de interfaz Tipo de apertura.
Esta pequeña interfaz es la que permitirá seleccionar el nivel de la apertura.
70
 Prototipo de interfaz Crear cuenta apertura del requisito: R6.2 Crear apertura de árbol de
cuenta.
Fig. 36: Prototipo de interfaz Crear cuenta apertura.
Una vez seleccionado el nivel, se introducen los datos de la apertura, manteniendo ésta el mismo
Contenido económico que la cuenta padre por lo que no se redefine.
 Prototipo de interfaz del requisito: R6.3 Crear apertura por otro nomenclador.
Fig. 37: Prototipo de interfaz Apertura por otro nomenclador.
71
Existen ciertos casos en los que se hace necesario realizar aperturas por nomencladores que están
definidos en otros subsistemas, por ejemplo el Nomenclador de persona en Capital humano. La
interfaz anterior permitirá mostrar los nomencladores disponibles para hacer aperturas y luego de
seleccionar el nomenclador se podrán escoger los criterios específicos del mismo.
 Prototipo de interfaz del requisito: R6.4 Modificar cuenta contable o apertura.
Fig. 38: Prototipo de interfaz Modificar cuenta contable.
 Prototipo de interfaz Modificar cuenta apertura del requisito: R6.4 Modificar cuenta contable o
apertura.
Fig. 39: Prototipo de interfaz Modificar cuenta apertura.
72
En caso de ocurrir errores o cambios en los datos de las cuentas o sus aperturas éstos se podrán
modificar en cualquiera de sus campos mediante las interfaces anteriores respectivamente.
 Prototipo de interfaz del requisito: R6.7 Configurar cuentas contables de ingresos, gastos y
resultado.
Fig. 40: Prototipo de interfaz Asignar tipo de cuenta.
Una vez creadas las Cuentas contables, éstas se deben clasificar según su naturaleza en Ingreso,
Gasto o Resultado, esta acción se podrá realizar a través de la interfaz anterior.
 Prototipo de interfaz del requisito: R7 Configurar nomenclador para apertura por otro
nomenclador.
Fig. 41: Prototipo de interfaz Configurar nomenclador para apertura.
73
En esta interfaz se mostrarán los nomencladores por los que se pueden hacer aperturas.
Permitiendo adicionar, modificar o eliminar dichos nomencladores.
 Prototipo de interfaz del requisito: R7.1 Adicionar nomenclador para apertura por otro
nomenclador.
Fig. 42: Prototipo de interfaz Adicionar nomenclador para apertura.
A través de esta interfaz se podrán adicionar y configurar los nomencladores creados por otros
subsistemas, necesarios para el uso en Contablidad general por los cuales se pueden hacer
aperturas.
 Prototipo de interfaz del requisito: R7.2 Modificar nomenclador para apertura por otro
nomenclador.
Fig. 43: Prototipo de interfaz Modificar nomenclador para apertura.

74
En caso de ocurrir algún error durante la configuración del nomenclador o algún cambio en los datos,
éstos se podrán modificar mediante la interfaz anterior.
 Prototipo de interfaz del requisito: R8 Gestionar comprobante de operaciones.
Fig. 44: Prototipo de interfaz Registro de comprobantes de operaciones.
En esta interfaz se listarán todos los Comprobantes de operaciones existentes en la entidad,

pudiéndose trabajar con cualquiera de ellos en caso de necesitarlo. Es por ello que operaciones
básicas como adicionar, modificar, eliminar entre otras muchas, están incluidas en esta página
principal.
75
 Prototipo de interfaz del requisito: R8.1 Nuevo comprobante de operaciones.
Fig. 45: Prototipo de interfaz Comprobante de operaciones.
Esta interfaz permite crear nuevos Comprobantes de operaciones, introduciendo todos los datos
requeridos.
 Prototipo de interfaz Registro anexo al pase del requisito: R8.1 Nuevo comprobante de
operaciones.
Fig. 46: Prototipo de interfaz Registro anexo al pase.
76
En esta interfaz se introducirán todos los datos relacionados con los pases que contengan saldos de
cuentas de Gastos. En el campo Importe el saldo debe coincidir con el saldo en el campo Débito de
la cuenta que lo originó.
 Prototipo de interfaz del requisito: R8.4 Abrir comprobante de operaciones.
En esta interfaz el usuario podrá abrir cualquier Comprobante de operaciones que desee, y si el
estado del mismo no es “Asentado”, de ser necesario podrá modificar cualquiera de sus elementos.
 Prototipo de interfaz del requisito: R8.6 Buscar comprobante de operaciones.
Fig. 48: Prototipo de interfaz Buscar comprobante.

77
Esta pequeña interfaz permitirá buscar cualquier Comprobante de operaciones introduciendo
cualquiera de los rangos de búsqueda ahí representados.
 Prototipo de interfaz del requisito: R8.9Cambiar número del comprobante de operaciones.
Fig. 49: Prototipo de interfaz Cambiar número.
A través de esta pequeña interfaz se podrá cambiar el número de un Comprobante de operaciones.

La aplicación debe ser capaz de manejar excepciones para no permitir que se repita alguno ya
existente.
 Prototipo de interfaz del requisito: R11 Calcular mayor.
Fig. 50: Prototipo de interfaz Mayor.

78
En esta interfaz se mostrará el saldo total de una cuenta específica, calculando sus afectaciones en
cada Comprobante de operaciones donde esté presente. Este cálculo se podrá realizar según los
diferentes parámetros que se muestran y luego si se desea se podrá visualizar cada Comprobante
de operaciones que contiene la cuenta.
 Prototipo de interfaz del requisito: R12 Calcular submayor.
Fig. 51: Prototipo de interfaz Submayor.
 Prototipo de interfaz Comprobante de operaciones de los requisitos: R11 Calcular mayor y

R12 Calcular submayor.
79
Interfaz que permitirá visualizar el Comprobante de operaciones al que pertenece la cuenta o subcuenta
seleccionada en el Mayor y Submayor respectivamente. En caso de que la cuenta o subcuenta sea de
gasto se permitirá también ver el Registro anexo al pase de la misma.
2.10 Conclusiones parciales:

En este capítulo se le da introducción al Análisis de la solución iniciándose con el Modelo de negocio y la
descripción de los procesos identificados como Configurar nomenclador de cuentas para la entidad,
Realizar apertura, Emitir comprobante de operaciones, Realizar cierre, Emitir estados financieros,
incluyéndose los diagramas de cada uno de ellos. Además para la modelación se determinaron los
Patrones de control de flujo. Seguidamente se muestran el Mapa de procesos, los Modelos conceptuales
o de dominio, los requisitos identificados así como las descripciones de aquellos que resultan más
significativos para la presente investigación, aclarando que el resto aparece contenido en los
documentos anexos a este trabajo. Se contemplaron las técnicas utilizadas para la captura de los
requerimientos y los métodos de validación de los mismos. Por último se agregaron los prototipos de
interfaces que demuestran que todos los requerimientos captados y descritos contienen todas las
necesidades de los clientes y que conjuntamente con dichos prototipos contribuirán al desarrollo e
implementación de la solución con la calidad y funcionalidad necesarias.
80
 CAPÍTULO III: Construcción y validación de la solución propuesta.
3. Introducción
El diseño debe definir una solución que satisfaga de modo efectivo y eficiente los requisitos
especificados en el análisis, y al hacer ésto el modelo incorporará nuevos artefactos (clases, atributos y
operaciones para las mismas, entre otros) y tendrá en cuenta la plataforma tecnológica concreta sobre
la que debe construirse el sistema informático. De hecho, el diseño debe proporcionar una solución
creativa para el problema especificado en el análisis.
Para llevar a cabo el diseño de la solución propuesta, se consideraron las herramientas a emplearse en
la implementación y se realizó un estudio sobre las mismas, por lo que las clases del diseño web se
modelaron basadas en el patrón Modelo-Vista-Controlador (MVC), utilizando mecanismos de diseño de
clases generadas estándares para todas las vistas creadas con ExtJs framework. Además como otro
mecanismo se incluyó un paquete llamado Doctrine del cual heredaran las clases generadas en base de
datos o mapeadas, incluidas en el domain. Para crear las clases controladoras y modelos, se utilizó
Zend_Ext framework. Lo que permite estructurar la aplicación por capas: capa de Presentación (vista),
capa de Negocio (controlador) y la de Acceso a Datos (modelo), esta arquitectura posibilita un trabajo
más seguro, rápido y eficiente (Diseño Avanzado de Aplicaciones Web., 2009).
3.1 Descripción y presentación del Diagrama de componentes:
El subsistema Contabilidad general está formado por un conjunto de componentes que encapsulan
funcionalidades que representan el núcleo del Sistema integral de gestión de entidades. Los mismos se
interrelacionan entre sí y con otros componentes de otros subsistemas para dar respuesta a las
necesidades de lograr agrupar todas las características y especificidades en un único sistema que
norme las actividades contables y financieras, y que permita tener un óptimo control de los recursos.
Componentes definidos:
 Configuración: en este componente se gestionan una serie de nomencladores que son la base
para el componente Nomenclador de cuentas, entiéndase Grupos y subgrupos contables,
Contenidos económicos de las cuentas y; Estructuras económicas que representan a los
propietarios de esas cuentas.
 Nomenclador de cuenta: este componente es el encargado de gestionar el árbol de cuentas en
el mayor sentido de la palabra, entiéndase las cuentas y sus aperturas, sean del tipo que sean,
controladas por otros subsistemas.
81
 Comprobantes de Operaciones: este componente es el encargado de contabilizar los
Comprobantes de operaciones de todos los subsistemas que componen la solución contable en
desarrollo.
 Cierre: es el encargado de cerrar los Períodos y Ejercicios contables, y a la vez darle apertura a
los próximos.
 Recuperaciones: este componente es el encargado de gestionar todos los reportes del
subsistema, dando la información necesaria y oportuna para la toma de decisiones.
Fig. 53: Diagrama de Componentes de subsistema Contabilidad general
3.2 Patrones de Diseño a emplear en la solución:
Un patrón describe un problema que ocurre una y otra vez en nuestro entorno y describe también el
núcleo de la solución al problema, de forma que puede ser reutilizado continuamente.
82
Modelo-Vista-Controlador:
Es un patrón de diseño que plantea la separación de diferentes clases en dependencia de la función que
realizan de manera tal que sea posible manejar dinámicamente la forma en que se procesan solicitudes
y gestionar cómo se mostrarán los resultados al usuario final. En otras palabras separa la presentación
del dominio de la aplicación.
 Modelo: administra el comportamiento y los datos del dominio de aplicación, responde a

requerimientos de información sobre su estado (usualmente formulados desde la vista) y
responde a instrucciones de cambiar el estado (habitualmente desde el controlador).
 Vista: Maneja la visualización de la información. Esta existe para mantener separado el script de
la vista, del modelo y del controlador. Provee un sistema de ayuda, filtros de salida y variables de
escape.
 Controlador: Son las clases que gestionan el manejo de la lógica del negocio. Por lo general
incluyen las restricciones y validaciones fundamentales determinadas por las reglas. Pueden
utilizarse más de una.
Se emplearon otros patrones en la solución, los cuales están implícitos en el framework como el
Decorator en la clase Zend_View, que se encarga de asignarle responsabilidades a objetos de manera
dinámica y configurarlos con nuevos atributos. El Zend framework tiene implementado el patrón Front
Controller que implica que todas las solicitudes son dirigidas a un único script PHP 5 que se encarga de
instanciar al controlador frontal y redirigir las llamadas. Tiene una instancia única del controlador frontal
disponible mediante el patrón Singleton para lograr una vía de entrada única a las solicitudes.
3.3 Diagrama de Clases del diseño
En el presente epígrafe se muestran los diagramas de clases del diseño de cada componente, con sus
respectivos modelos de dominio donde se incorporan las entidades con las que se relacionan. Las
descripciones de los diagramas de clases están reflejadas en documentos anexos a la presente
investigación ya que fueron artefactos que se generaron durante el flujo de trabajo y donde se exponen
5
PHP (PHP Hypertext Pre-processor) es un lenguaje de programación interpretado, diseñado originalmente para la creación
de páginas web dinámicas.
83
una serie de rasgos esenciales de cada una de las clases y métodos que las componen, a continuación
se listan las imágenes relativas a dichas propuestas de diseño:
84
 Configuración.
Fig. 54: Diagrama de clases de Estructura económica.
85
Fig. 55: Diagrama de clases de Nomenclador de grupo o subgrupo contable.
86
Fig. 56: Diagrama de clases de Nomenclador de contenido económico.
87
Fig. 57: Diagrama de clases de Configurar cuentas para redondeo.
88
Fig. 58: Diagrama de clases de Configurar estados financieros.
Fig. 59: Diagrama del paquete Domain del componente.

89
 Nomenclador de cuentas.
Fig. 60: Diagrama de clases de Nomenclador de cuentas.
90
91
 Comprobante de operaciones.
Fig. 62: Diagrama de clases de Comprobante de operaciones.
92
93
 Cierre.
Fig. 64: Diagrama de clases de Comprobante de operaciones.
94
 Recuperaciones.
Fig. 66: Diagrama de clases de Mayor.
95
Fig. 67: Diagrama de clases de Submayor.
96
3.4 Evaluación del Modelo de diseño propuesto
Las métricas de diseño a nivel de componentes se concentran en las características internas de los
componentes del software e incluyen medidas de la cohesión, acoplamiento y complejidad del
subsistema. Estas tres medidas pueden ayudar al desarrollador de software a juzgar la calidad de un
diseño a nivel de los componentes (Pressman, 1998).
Entre los tipos de Métricas que se utilizan para evaluar el diseño están:
 Tamaño operacional de clase (TOC): está dado por el número de métodos asignados a una
clase.
 Relaciones entre clases (RC): está dado por el número de relaciones de uso de una clase con
otras.
 Profundidad de herencia (PH): está dado por la profundidad en al herencia de las clases
heredadas de un nodo padre.
 Número de descendientes (ND): está dado por la cantidad de clases que heredan de un padre.
97
 Número de operaciones redefinidas para una clase hija (NOR): está dado por la cantidad de
operaciones redefinidas en cada clase hija.
Para evaluar el diseño se empleó la métrica Tamaño operacional de clase (TOC), la cual mide la calidad
de acuerdo a los atributos Responsabilidad, Complejidad de implementación y Reutilización de las
clases. Sólo se empleó ésta debido a que en la propuesta de diseño realizada no existen ni casos de
herencia, ni utilización de relaciones de uso, lo que descarta la posibilidad de aplicar las otras métricas.
En la TOC los atributos de calidad Responsabilidad, Complejidad de implementación son inversamente
proporcionales a la Reutilización, lo que puede ser traducido como, mientras mayor sea la
Responsabilidad y Complejidad de implementación de una clase, menor será su nivel de Reutilización.
Atributos de calidad que se abarcan en la métrica TOC:
 Responsabilidad. Consiste en la responsabilidad asignada a una clase en un marco de

modelado de un dominio o concepto, de la problemática propuesta.
 Complejidad de implementación. Consiste en el grado de dificultad que tiene implementar un

diseño de clases determinado.
 Reutilización. Consiste en el grado de reutilización presente en una clase o estructura de clase,

dentro de un diseño de software.
3.5 Resultados de la evaluación de las métricas
En este epígrafe sólo se mostrarán las gráficas y las valoraciones que merecen los resultaros después
de aplicar la métrica, para la cual se tuvieron en cuenta el número de métodos de las clases
Controladoras y Modelos reflejadas en el diseño de acuerdo a la propuesta planteada por arquitectura.
Todo el cálculo está contenido en el documento Métricas para el diseño el cual está dentro de los
archivos anexos a esta investigación.
98
Tamaño operacional de las clases
Fig. 69: Gráfico de los resultados generales de acuerdo a la cantidad de procedimientos.
Fig. 70: Gráfico de la Responsabilidad por clases.
Fig. 71: Gráfico de la Complejidad de implementación por clases.
99
Fig. 72: Gráfico del nivel de Reutilización de las clases.
Analizando los resultados obtenidos en la evaluación de la métrica TOC se puede concluir que el diseño
de los componentes Configuración, Nomenclador de cuentas, Comprobante de operaciones, Cierre y
Recuperaciones tienen una calidad aceptable teniendo en cuenta que el 90 % de las clases incluidas en
estos componentes posee menos cantidad de operaciones que la mitad del valor máximo registrado en
las mediciones. Además el 96% de las clases poseen evaluaciones positivas en los atributos de calidad
(Responsabilidad, Complejidad de implementación y Reutilización).
3.6 Conclusiones parciales.
En este capítulo, se ha expuesto todo lo referente al diseño, los patrones empleados, en este caso el
más importante el Modelo-Vista-Controlador, que fue el que sirvió de basamento para la realización del
diseño como tal. Se incluyen los diagramas de diseño de las clases web de todos los componentes, el
diagrama de componentes y los paquetes de dominio relativos a los componentes. Además como
recurso indispensable se aplicaron métricas al diseño, para determinar cuan factible es éste, arrojando
buenos resultados.
100

 Conclusiones
 El modelo de desarrollo definido por el proyecto permitió realizar el trabajo de una forma
organizada, priorizando actividades y la generación de artefactos que influyeran
satisfactoriamente en la solución.
 El análisis realizado permitió cumplir con todas las necesidades que fueron definidas en las
entrevistas con los clientes.
 Brindó la posibilidad de trabajar con herramientas avanzadas de diseño que le dieron

una buena estructura a las clases.
 Constituyó la primera fase de un largo proceso de desarrollo del software que se

entregó como producto final y que está en despliegue para prueba piloto en algunas
entidades de la capital, lo que demostró el cumplimiento a cabalidad del objetivo propuesto.
101
 Recomendaciones
 Se recomienda el seguimiento del Análisis y Diseño para futuras transformaciones en la

medida en que las necesidades de los clientes puedan ser modificadas por el avance de la
ciencia Contable y del mundo en general.
 Es de vital importancia que se inicie la fase dos, del Análisis y Diseño, donde se modele el
negocio relacionado con los otros procesos que no fueron incluidos en la primera parte:
Agregación y Consolidación, los cuales tienen gran peso en el funcionamiento correcto y
completo del software y de la Contabilidad general como tal.
 Faltaría recomendar a los demás proyectos que empleen el modelo de desarrollo consultado y
aplicado en esta investigación.
102
 Bibliografía
A., Myers B. 1996. Fismat. [Online] 1996. [Cited: Febrero 22, 2009.]
http://www.fismat.umich.mx/~crivera/tesis/node6.html.
Apellaniz. 2000. Contabilidad Financiera. 2000.
Cañibano, Calvo. 1974. [Online] 1974. [Cited: Marzo 3, 2009.] http://www.contabilidad.tk/concepto-

actual-de-contabilidad-5.htm.
Cortes, Jesús. 1932. Biblioteca del hombre de negocios moderno. [Online] 1932. [Cited: 3 3, 2009.]
Diseño Avanzado de Aplicaciones Web. Arias, Yuniel Eliades Proenza. 2009. 8, s.l. : Opentelematics,
2009.
D'Marco. 2006. Assets NS. [Online] 2006. [Cited: 04 08, 2009.] http://assets.co.cu/index.asp.
Dumas, Marlon, et al. 2005. Pattern-based Analysis of BPMN. 2005.
Escalona, María José and Koch, Nora. 2002. Ingeniería de Requisitos en Aplicaciones para la Web-Un
estudio comparativo. Sevilla : s.n., 2002.
Exact, Globe. 2006. Exact Software. [Online] 2006. [Cited: 3 3, 2009.] www.exactsoftware.es.
Figueroa, Roberth G., Solis, Camilo J. and Cabrera, Armando A. 2008. Adonisnet's.weblog. [Online]
2008. http://adonisnet.wordpress.com/2008/06/18/metodologias-tradicionales-vs-metodologias-agiles/.
García, Joaquin. 2005. Patrones de diseño, diseño de software orientado a objetos. 2005.
González, Jose Luis Hernández. Instituto Tecnologico de Apisaco. [Online] [Cited: 04 09, 2009.]
http://www.itapizaco.edu.mx/~joseluis/apuntes/estadistica/definiciones%20y%20muestreos.pdf.
Grimpi. 2008. Wordpress. [Online] 11 08, 2008. [Cited: 05 04, 2009.]

http://grimpidev.wordpress.com/2008/11/22/patrones-de-acceso-a-datos-active-record/.
Habasoft. 2005. Habasoft. [Online] 2005. [Cited: 04 08, 2009.]

http://www.havasoft.minaz.cu/hs/Paginas/default.aspx.
Hernandez, Minerva. 2006. Semanario Económico y Financiero de Cuba. [Online] 2006. [Cited: 04 09,
2009.] http://www.opciones.cubaweb.cu/leer.asp?idnuevo=2390.
103
Himmelblau, David. 1938. Fundamentos de la contabilidad. México : s.n., 1938.
IEEE. 1993. Standards Collection: Software Engineering. 1993. IEEE Standard 610.
International, V.P. 2006. Introducción a los sistemas y herramientas CASE. 2006.
2008. Kioskea.net. [Online] 2008. [Cited: 04 08, 2009.] http://es.kioskea.net/contents/strategie/cobit.php3.
Lago, Ramiro. 2007. Patrones de diseño de software. [Online] 2007. [Cited: 04 10, 2009.]
http://www.proactiva-calidad.com/java/patrones/index.html.
Larman, Craig. UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso
unificado. s.l. : Prentice Hall.
López, Jorge Quesada. 2004. La Informática y la Empresa. [Online] 10 2004. [Cited: 04 09, 2009.]
http://www.fec.uh.cu/info3/RECOPILACION.htm.
Martínez, Alejandro and Martínez, Raúl. Guía a Rational Unified Process. Castilla la Mancha : s.n.
Oliver, Mercedes Cervera and Aparicio, Javier Romano. 1990. Contabilidad.tk. [Online] 1990. [Cited:
04 08, 2009.] http://www.contabilidad.tk/prologo-1.htm.
Porem, Pufus. 1930. Accounting Method. Chicago : s.n., 1930.
Pressman, Roger. 1998. Ingeniería de Software. Un enfoque práctico. s.l. : Mc Graw Gill, 1998.
Producción, Equipo de. 2009. Modelo de Desarrollo Orientado a Componentes ERP-Cuba. Ciudad
Habana : s.n., 2009.
RodasXXI. 2002. Rodas XXI Sistema Integral Económico Administrativo. [Online] 2002. [Cited: 04 08,
2009.] http://www.rodasxxi.cu/.
Rumbaugh, James, Jacobson, Ivar and Booch, Grady. 2000. El Lenguaje Unificado de Modelado.
Manual de Referencia. 2000.
SAP, ERP. 2009. SAP España. [Online] 2009. [Cited: 05 28, 2009.]
http://www.sap.com/spain/solutions/business-suite/erp.epx.
Segovia, Daniel. 1999. Prototipos de sistema. [Online] 5 1999. [Cited: 3 3, 2009.]

http://tinpan.fortunecity.com/eltonjohn/914/prototipos.doc. .
104
SICS. 2008. SICS Servicios Informáticos, Consultoria y Sistemas . [Online] 2008. [Cited: 04 09, 2009.]
http://www.sics.cu/productos.aspx.
Siscont5. 2008. Siscont Sistema Contable Financiero. [Online] 2008. [Cited: 04 08, 2009.]
http://www.siscont.com/DESCRIPTIVO%20SISCONT.pdf.
Software, Coliseo. Coliseo Software. [Online] [Cited: 3 3, 2009.]

http://www.coliseosoftware.com.ar/default.asp.
Steve, Burbeck. 1992. Application Programming in Smalltalk-80: How to use Model-View-Controller

(MVC). [Online] 1992. [Cited: 04 10, 2009.] http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html.
Técnicas de Recopilación de Información. [Online] [Cited: 04 09, 2009.]

http://www.mitecnologico.com/Main/TecnicasDeRecopilacionDeInformacion.
Torres, José Luis. 2008. Promoting Community Wordwide. Especicifacion de requisitos en Ingenieria de
Software. [Online] 2008. [Cited: 04 28, 2009.] http://www.uag.mx/ieee/contsep01/requerimientos.htm..
105
 Glosario de Términos
A
Activos: son los bienes y derechos que posee la empresa, de los cuales es posible hacer una
valoración en términos monetarios, los cuales van a conformar el Balance general.
Activos circulantes: constituyen aquel grupo de cuentas que representan bienes o derechos,
susceptibles de convertirse en dinero o de consumirse el próximo ciclo normal de operaciones de la
empresa.
Activos fijos: son los bienes o derechos adquiridos por la empresa y los cuales son de carácter más o
menos permanente, los cuales se adquieren con la intención de utilizarlos en la operaciones normales
de negocio y no de venta.
AJAX: acrónimo de Asynchronous JavaScript And XML es una técnica de desarrollo web para crear
aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los
usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta
forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa
aumentar la interactividad, velocidad y usabilidad en las aplicaciones.
Capital: son las aportaciones que realizan los propietarios de una entidad y aquellos beneficios que se
han obtenido en un período determinado y que no se distribuyen en forma de dividendo, es decir,
representan las obligaciones que tiene la empresa con los propietarios de la misma.
Centro de costo: es un elemento de análisis dentro de un sistema de contabilidad. Puede ser un

Departamento de una empresa, un Vendedor, un Activo (Maquinaria, Equipo, Vehículos), un producto en
proceso de fabricación, entre otros. Cualquier elemento que necesite ser analizado, en cuanto a los
costos que representa para la empresa. Esto se hace enlazando una cuenta o cuentas de costos o
gastos, a los centros a analizar.
Cuentas nominales: Tienen como característica principal que son cuentas temporales, éstas duran
abiertas lo que dura el Ejercicio contable de la empresa, y al finalizar éste, son cerradas y su resultado
es traspasado a la cuenta Capital quien es en definitiva la cuenta que va ser afectada por los beneficios
o pérdida del negocio. Las cuentas nominales se crean en cada ejercicio de la empresa para registrar
106
los ingresos, los costos, gastos, pérdidas y en consecuencia poder determinar los resultados obtenidos
por la empresa en ese ejercicio, por ello se le conoce como cuenta de resultados.
Cuenta orden: permiten controlar en las unidades el presupuesto anual aprobado, el financiamiento
situado o recibido para Gastos corrientes y de Capital, así como el comportamiento de otros hechos
económicos específicos.
Elementos de gasto: Es un concepto económico asociado al gasto que permite la cuantificación de

recursos materiales, laborales y financieros expresados en trabajo vivo y pretérito para un período de la
actividad empresarial. Indican conceptos de gasto según su naturaleza.
Empresa estatal: La empresa estatal es una entidad económica con personalidad jurídica propia, que
constituye el eslabón primario de la economía y, como tal, la base del complejo sistema de relaciones de
la economía nacional.
Empresa presupuestada (o Unidad presupuestada): Son las entidades mediante las cuales el Estado
administra directamente parte de los bienes que integran la propiedad estatal socialista y presta sus
servicios sociales, como la educación y la salud pública y organiza su administración interna. No tiene
personalidad jurídica civil aunque sí son sujetos de derecho económico, laboral y financiero. En ellas,
sus gastos se financian totalmente por el Presupuesto del estado, al cual aportan sus ingresos de
tenerlo.
Entidad: Toda organización administrativa, comercial, económica, productiva y de servicios de carácter

estatal, cooperativa, privada o mixta, residentes en el territorio nacional; así como las organizaciones
sociales y de masas del país.
Gasto: Los gastos son disminuciones brutas de Activos causadas por la entrega de artículos o por la
prestación de un servicio. Los gastos constituyen sacrificios o expiración de Activos, cuando éstos
acaban, sus totales y el patrimonio disminuyen.
107
IDE: un IDE en inglés, Integrated Development Environment es un entorno de programación que ha
sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un
compilador, un depurador y un constructor de interfaz gráfica.
Ingreso: la empresa, en el ejercicio de su actividad presta servicios y bienes al exterior. A cambio de

ellos, percibe dinero o nacen derechos de cobro a su favor, que hará efectivos en las fechas estipuladas.
Se produce un ingreso cuando aumenta el patrimonio empresarial y este incremento no se debe a
nuevas aportaciones de los socios. Los ingresos son los importes ganados por la empresa en virtud de
las transacciones comerciales y otras transacciones financieras.
Inventarios: existencias en almacén ya sean en forma de materiales para la producción (materias

primas) o en forma de mercancías (producto terminado). En dependencia de la forma en que se
presente cada uno será la cuenta a utilizar (Inventarios de materiales o Materia prima, o Inventario de
mercancías).
JavaScript: es un lenguaje de programación interpretado, es decir, que no requiere compilación,

utilizado principalmente en páginas web, con una sintaxis semejante a la del lenguaje Java y el lenguaje
C.
JSON: acrónimo de "JavaScript Object Notation", es un formato ligero para el intercambio de datos.
JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML.
Libro mayor: el Libro mayor constituye un documento obligatorio que debe llevar toda organización, y
en él se agrupan todas las cuentas de Activo, Pasivo, Capital, Ingresos y Gastos. En este libro se hace
un resumen de todas las afectaciones que han tenido cada una de las cuentas, como resultado de las
operaciones de la empresa durante el período contable, estas operaciones han sido previamente
registradas en el Libro Diario y a partir de éste es que se elabora el Libro mayor.
Libro submayor: su objetivo es analizar las subcuentas y análisis de las cuentas que lo requieran
excepto aquellas que son analizadas en Submayores específicos en el resto de los Módulos del sistema,
con la finalidad de obtener todos y cada uno de sus saldos, con vista al cuadre mensual con las cuentas
control del Mayor.
108
O
ORM: El mapeo objeto-relacional u Object Relational Mapping es una técnica de programación para
convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y
el utilizado en una base de datos relacional.
Pasivos: son las fuentes de financiamiento, para llevar a cabo las operaciones es decir son las
obligaciones que tiene la empresa con terceros. Es la clasificación de los recursos de la empresa con
respecto a su procedencia, que pueden ser aportaciones de capital por parte de los propietarios,
recursos ganados por la empresa en su actividad mercantil, o utilización de recursos de terceros que
pueden ser a corto o largo plazo.
Sociedad mercantil: Persona jurídica que se dedica a realizar actos de comercio, con domicilio en el
extranjero. De existir algún domicilio en el territorio nacional, se convertiría en una Sucursal.
Sucursal: establecimiento perteneciente a una sociedad mercantil o a un empresario individual,

radicado en el territorio nacional para realizar operaciones comerciales que le sean autorizadas.
Tasa de cambio: la tasa de cambio de un país, es el valor de cada moneda nacional comparada con
una moneda internacional, se puede definir también como el poder de compra de una moneda respecto
al poder de compra de otra medida en términos monetarios.
XML: por sus siglas en inglés de Extensible Markup Language, es un metalenguaje extensible de
etiquetas que permite definir la gramática de lenguajes específicos.
109

Contabilidad Tesis

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Contabilidad Tesis

Cargado por

Copyright:

Formatos disponibles

Universidad de las Ciencias Informáticas

Título: Análisis y Diseño del Subsistema Contabilidad

Trabajo de Diploma para optar por el título de

Autor(es): Annilié Manresa Bernal.

Rosalina Ibarra González.

Tutor(a): Ing. Aneyvis Hernández Chinea.

Co-tutor(a): Ing. Ileana Centelles Rubiera.

Ciudad de la Habana, Mayo, 2009

 CAPÍTULO 1 Fundamentación teórica. .................................................................................................. 5

1.1 Fundamentación del tema ................................................................................................................... 5

1.1.1 Contabilidad. ..................................................................................................................................... 5

1.1.2 Sistemas contables ........................................................................................................................... 6

1.2 Modelo de desarrollo y herramientas empleadas ............................................................................ 10

1.2.1. Modelo de Desarrollo orientado a componentes ......................................................................... 10

1.2.2. Lenguaje Unificado para Modelado (UML) ................................................................................... 13

1.2.3. BPMN (Notación para Modelar los Procesos de Negocio) ......................................................... 13

1.2.4. Visual Paradigm para UML ............................................................................................................ 14

1.3 Conclusiones parciales ...................................................................................................................... 15

 CAPÍTULO II: Descripción de la solución propuesta........................................................................... 16

2.1 Modelo de Negocio ............................................................................................................................. 16

2.2 Modelo de Negocio basado en procesos. ........................................................................................ 16

2.3 Procesos que tienen lugar en el subsistema Contabilidad general ............................................... 17

2.4 Patrones de Control de flujo empleados........................................................................................... 31

2.5 Mapa de Procesos de negocio .......................................................................................................... 31

2.6 Modelos Conceptuales o de dominio. ............................................................................................... 32

2.7 Requerimientos ................................................................................................................................... 36

2.7.1 Técnicas empleadas para la captura de requisitos...................................................................... 36

2.7.3 Especificaciones de requisitos:...................................................................................................... 39

2.8 Validación de los requisitos ............................................................................................................... 59

2.9 Prototipos de interfaces. .................................................................................................................... 60

2.10 Conclusiones parciales: ..................................................................................................................... 80

 CAPÍTULO III: Construcción y validación de la solución propuesta. ................................................ 81

3.1 Descripción y presentación del Diagrama de componentes: .......................................................... 81

3.2 Patrones de Diseño a emplear en la solución:................................................................................. 82

3.3 Diagrama de Clases del diseño......................................................................................................... 83

3.4 Evaluación del Modelo de diseño propuesto.................................................................................... 97

3.5 Resultados de la evaluación de las métricas ................................................................................... 98

3.6 Conclusiones parciales. ................................................................................................................... 100

 Conclusiones ........................................................................................................................................ 101

 Recomendaciones ................................................................................................................................ 102

 Bibliografía ............................................................................................................................................ 103

 Glosario de Términos ........................................................................................................................... 106

En la búsqueda de estos beneficios, se encuentran en uso actualmente gran diversidad de sistemas

La presente investigación se centrará en la fase inicial de desarrollo de la solución, específicamente en

 Realizar el marco teórico de la investigación.

 Desarrollar el Modelado del Negocio por procesos.

 Identificar y describir los Requisitos funcionales.

 Modelar el Diseño de cada componente definido.

 Buscar información sobre Sistemas contables nacionales y extranjeros para fundamentar la

 Determinar y especificar los requerimientos funcionales.

En el presente trabajo se emplearán los diferentes métodos de investigación:

Para lograr una sustentación más sólida de la investigación el documento se ha estructurado de la

Capítulo 3: Construcción y validación de la solución propuesta. En este capítulo luego de un estudio

1.1 Fundamentación del tema

Con el avance de la tecnología y la informática, se han ideado y materializado, sistemas que

1.1.3 Sistemas contables financieros presentes en entidades cubanas. Tratamiento del

Exact Globe para Windows

El programa VERSAT-Sarasola, sistema cubano de contabilidad, permite enviar información, de forma

Actualmente lo utilizan alrededor de 200 entidades de varias provincias y en lo adelante lo introducirán

Es un sistema multi-empresa y multiusuario creado por CITMATEL para la automatización de la gestión

1.2.1. Modelo de Desarrollo orientado a componentes

Para la exitosa realización de un proyecto de tales magnitudes es necesario establecer modelos