UNIVERSIDAD UNIVERSIDAD MAYOR DE SAN ANDRES

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO
“SISTEMA WEB DE CONTABILIDAD
ACORDE A LAS NORMAS INTERNACIONALES DE INFORMACIÓN
FINANCIERA (N.I.I.F.)
CASO: CARRERA CONTADURÍA PÚBLICA
UNIVERSIDAD PÚBLICA DE EL ALTO”

PARA OPTAR EL TITULO DE LICENCIATURA EN INFORMÁTICA

MENCIÓN: INGENIERIA DE SISTEMAS INFORMÁTICOS

POSTULANTE: GABRIEL SEGALES CONDORI

TUTOR: Lic. GERMAN HUANCA TICONA
REVISOR: Lic. ALDO VALDEZ ALVARADO

LA PAZ - BOLIVIA
2011
DEDICATORIA

Dedico este trabajo a dios por su generosidad y

misericordia, por darme lo necesario para ser feliz, en
especial a mi madre Lidia por darme la vida, por su
esfuerzo y su paciencia, a mi padre Prudencio por
brindarme su apoyo sus concejos y experiencia y a mis
hermanos quienes me apoyaron siempre.
AGRADECIMIENTOS

Primeramente quiero agradecer a dios y a mis queridos

padres y hermanos quienes me brindaron su apoyo su
paciencia y sus concejos, también quiero expresar mis
agradecimientos a mi Universidad Mayor de San Andrés,
a mi querida Carrera de Informática, a mis docentes
quienes compartieron sus conocimientos y experiencias
con mi persona y a mis compañeros quienes me
apoyaron en mis estudios.
 ÍNDICE

Descripción Pag.
CAPÍTULO I
1.1. PRESENTACIÓN .................................................................................................1
1.2. ANTECEDENTES ................................................................................................ 2
1.2.1. Antecedentes Institucionales..........................................................................2
1.2.2. Antecedentes del sistema ..............................................................................2
1.3. DEFINICIÓN DEL PROBLEMA ............................................................................3
1.3.1. PROBLEMA CENTRAL .................................................................................3
1.3.2. PROBLEMAS SECUNDARIOS ......................................................................3
1.4. JUSTIFICACIÓN DEL TEMA ...............................................................................4
1.4.1. ECONÓMICA .................................................................................................4
1.4.2. SOCIAL..........................................................................................................5
1.4.3. TÉCNICO .......................................................................................................5
1.5. OBJETIVO ...........................................................................................................5
1.5.1. OBJETIVO GENERAL ...................................................................................5
1.5.2. OBJETIVOS ESPECÍFICOS ..........................................................................5
1.6. LÍMITES ...............................................................................................................6
1.7. ALCANCES ..........................................................................................................7
1.7.1. TEMPORAL ...................................................................................................7
1.7.2. ESPACIAL .....................................................................................................7
1.8. APORTES ............................................................................................................7
1.9. METODOLOGÍA ..................................................................................................7

CAPÍTULO II
2.1. BASES TEÓRICAS .............................................................................................. 8
2.1.1. INGENIERIA DE SOFTWARE .......................................................................8
[Link]. GESTION DE PROYECTOS ....................................................................9
[Link]. REQUERIMIENTOS ................................................................................9
[Link]. ANALISIS Y DISEÑO ...............................................................................9
 [Link]. IMPLEMENTACIÓN ...............................................................................10
[Link]. PRUEBAS .............................................................................................. 10
[Link]. MÉTRICAS DEL SOFTWARE................................................................ 11
[Link]. METODOLOGÍAS DE DESARROLLO DE SOFTWARE ........................11
2.1.2. INGENIERIA WEB .......................................................................................13
[Link]. INTRODUCCIÓN A LA INGENIERIA WEB ............................................13
[Link]. ÁREAS A LA INGENIERÍA WEB............................................................ 14
2.1.3. WEBML........................................................................................................16
2.1.4. METODOLOGÍAS, MÉTODOS, TECNOLOGÍAS, LENGUAJES Y
HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DEL PROYECTO ............16
[Link]. METODOLOGÍAS AGILES ....................................................................16
[Link]. PROGRAMACIÓN EXTREMA (XP – EXTREMME PROGRAMMING) ...18
[Link]. C#.NET ..................................................................................................24
[Link]. SQL SERVER ........................................................................................25
2.2. BASES CONCEPTUALES .................................................................................25
2.2.1. CONTABILIDAD .......................................................................................... 25
2.2.2. NOMENCLATURA DE CUENTAS ............................................................... 26
2.2.3. CICLO DE LA CONTABILIDAD ...................................................................27
[Link]. Balance general al principio del periodo reportado .................................27
[Link]. Proceso de análisis de las transacciones y registro en el diario .............28
[Link]. Pase del libro diario al libro mayor .........................................................28
[Link]. Elaboración del balance de comprobación no ajustado .......................... 28
[Link]. Analizar los ajustes y las correcciones, registrarlos en el diario y
transferirlos al mayor ............................................................................................. 29
[Link]. Elaboración de un balance de prueba ajustado......................................29
[Link]. Elaboración de los estados financieros ..................................................29
[Link]. Cierre de libros .......................................................................................29
2.2.4. MARCO CONCEPTUAL PARA LA PREPARACIÓN Y PRESENTACIÓN DE
ESTADOS FINANCIEROS ....................................................................................29
[Link]. Introducción ........................................................................................... 29
[Link]. Objetivos de los estados financieros ......................................................31
 [Link]. Situación financiera, desempeño y cambios en la posición financiera ....32
[Link]. Hipótesis fundamentales ........................................................................33
[Link]. Características cualitativas de los estados financieros ........................... 33
[Link]. Restricciones a la información relevante y fiable ....................................35
[Link]. Elementos de los estados financieros ....................................................36
[Link]. Situación financiera ................................................................................37
[Link]. Desempeño............................................................................................ 37
[Link]. Ajustes por mantenimiento de capital ...................................................38
[Link]. Medición de los elementos de los estados financieros .........................39
2.2.5. PROPIEDADES, PLANTA Y EQUIPO .........................................................40
[Link]. Definiciones ........................................................................................... 41
[Link]. Reconocimiento .....................................................................................42
[Link]. Medición en el momento del reconocimiento..........................................43
[Link]. Componentes del costo..........................................................................43
[Link]. Medición posterior al reconocimiento .....................................................44
[Link]. Depreciación .......................................................................................... 46
[Link]. Importe depreciable y periodo de depreciación ......................................47
[Link]. Método de depreciación .........................................................................49
[Link]. Deterioro de valor...................................................................................50
[Link]. Compensación por deterioro de valor...................................................50
[Link]. Bajas en cuentas..................................................................................51
[Link]. Información a relevar ...........................................................................52
2.2.6. ACTIVOS INTANGIBLES .............................................................................54
[Link]. Definición ............................................................................................... 54
[Link]. Identificabilidad ......................................................................................54
[Link]. Beneficios económicos futuros ............................................................... 55
[Link]. Reconocimientos y medición ..................................................................55
[Link]. Vida útil ..................................................................................................56
[Link]. Periodo y método de amortización .........................................................57
[Link]. Activos Intangibles con vida útil indefinidas ............................................57
3.1. XP Y WEBML ...................................................................................................59
CAPÍTULO III
3.2. EXPLORACION .................................................................................................60
3.2.1. HISTORIAS DE USUARIO...........................................................................60
3.2.2. HERRAMIENTAS ........................................................................................61
3.3. PLANIFICACIÓN DE LAS ENTREGAS .............................................................. 61
3.3.1. ESTIMACIONES DE ESFUERZOS ............................................................. 65
3.3.2. Primera Iteración: .........................................................................................71
3.3.3. Segunda Iteración: .......................................................................................72
3.3.4. Tercera Iteración: .........................................................................................73
3.3.5. Cuarta Iteración: .......................................................................................... 74
3.4. ITERACIONES ...................................................................................................74
3.4.1. PRIMERA ITERACIÓN ................................................................................75
[Link]. Gestión de usuarios ...............................................................................76
[Link]. Apertura de una Gestión ........................................................................79
[Link]. Introducción del Plan de Cuentas ........................................................... 81
[Link]. Introducción de los Tipos de Cambio .....................................................83
[Link]. Introducción de las UFV's ......................................................................84
3.4.2. SEGUNDA ITERACIÓN ..................................................................................85
[Link]. Introducción de Comprobante ................................................................ 87
[Link]. Modificación de Comprobante ................................................................ 89
[Link]. Eliminación de Comprobante .................................................................91
[Link]. Pago de Sueldos y Salarios ...................................................................93
3.4.3. TERCERA ITERACIÓN ...............................................................................95
[Link]. Generación de Reportes ........................................................................96
[Link]. Re-expresiones y actualizaciones .......................................................... 98
[Link]. Depreciaciones de Activos Fijos............................................................. 99
[Link]. Amortizaciones de Activos Intangibles ................................................. 101
3.4.4. CUARTA ITERACIÓN ................................................................................ 102
[Link]. Presentación de Estados Financieros .................................................. 104
[Link]. Cierre de Gestión ................................................................................. 105
 [Link]. Obtención de Copias de Respaldo (Backups) ...................................... 106
[Link]. Resumen de la contabilización ............................................................. 107
3.5. PRODUCCIÓN................................................................................................. 108
3.5.1. Interfaz de acceso ...................................................................................... 108
3.5.2. Interfaz de gestión de usuarios .................................................................. 109
3.5.3. Interfaz de apertura de gestión .................................................................. 109
3.5.4. Introducción de plan de cuentas ................................................................ 110
3.5.5. Introducción de los Tipos de Cambio ......................................................... 110
3.5.6. Introducción de las UFV's .......................................................................... 111
3.5.7. Introducción de Comprobante .................................................................... 111
3.5.9. Eliminación de Comprobante ..................................................................... 112
3.5.10. Generación de Reportes .......................................................................... 113
3.5.11. Re-expresiones y actualizaciones ............................................................ 113
3.5.12. Depreciaciones de Activos Fijos .............................................................. 114
3.5.13. Presentación de Estados Financieros ...................................................... 114
3.5.15. Resumen de la contabilización ................................................................. 115
3.6. MANTENIMIENTO ........................................................................................... 116
3.7. MUERTE DEL PROYECTO ............................................................................. 116
3.8. CALIDAD DEL SOFTWARE............................................................................. 116
3.9.1. FUNCIONALIDAD ...................................................................................... 116
3.9.2. SATISFACCIÓN DEL USUARIO ............................................................... 119
3.9.3. PORTABILIDAD......................................................................................... 121
3.9.4. CONFIABILIDAD ....................................................................................... 121
3.9.3. PORTABILIDAD......................................................................................... 121
3.10. CONTRIBUCIÓN DEL SISTEMA SCANIIF .................................................... 124

CAPITULO IV
4.1. CONCLUCIONES Y RECOMENDACIONES ................................................... 126
BIBLIOGRAFÍA ....................................................................................................... 127
ANEXOS ................................................................................................................. 128
 ÍNDICE DE FIGURAS

Descripción Pag.
Figura 2.1. Proyecto Xtreme Programming .............................................................. 22
Figura 2.2. Coste del cambio de la ingeniería del software tradicional ..................... 23
Figura 2.3. Coste del cambio en XP ......................................................................... 23
Figura 2.4. Modelo de Comprobantes de Diario ....................................................... 28
Figura 2.5. Ciclo Contable ........................................................................................ 30
Figura 3.1. XP y WEBML ........................................................................................ 59
Figura 3.2. Planificación de Entregas (Iteración 1) .................................................. 63
Figura 3.3. Planificación de Entregas (Iteración 2) ................................................... 63
Figura 3.4. Planificación de Entregas (Iteración 3) ................................................... 64
Figura 3.5. Planificación de Entregas (Iteración 4) ................................................... 64
Figura 3.6. Diagrama Entidad Relación (Iteración 1) ................................................ 75
Figura 3.7. Historia de usuario – Gestión de usuarios .............................................. 76
Figura 3.8. Diagrama de hipertextos – Gestión de usuarios ..................................... 79
Figura 3.9. Historia de usuario – Apertura de una gestión ........................................ 79
Figura 3.10. Diagrama de hipertextos – Apertura de Gestión ................................... 80
Figura 3.11. Historia de usuario – Introducción del Plan de Cuentas........................ 81
Figura 3.12. Diagrama de hipertextos – Introducción plan de cuentas ..................... 82
Figura 3.13. Historia de usuario – Introducción de los Tipos de Cambio .................. 83
Figura 3.14. Diagrama de hipertextos – Introducción plan de cuentas .................... 84
Figura 3.15. Historia de usuario – Introducción de las UFV`s ................................... 84
Figura 3.16. Diagrama de hipertextos – Introducción ufv’s ....................................... 85
Figura 3.17. Diagrama Entidad Relación (Iteración 2) .............................................. 86
Figura 3.18. Historia de usuario – Introducción de Comprobantes ........................... 87
Figura 3.19. Diagrama de hipertextos – Introducción comprobante .......................... 88
Figura 3.20. Historia de usuario – Modificación de Comprobante ............................. 89
Figura 3.21. Diagrama de hipertextos – Modificación comprobante ......................... 90
Figura 3.22. Historia de usuario – Eliminación de Comprobante .............................. 91
Figura 3.23. Diagrama de hipertextos – Eliminación comprobante ........................... 92
Figura 3.24. Historia de usuario – Pago de sueldos y salarios ................................. 93
Figura 3.25. Diagrama de hipertextos – Pago de sueldos y salarios ........................ 94
Figura 3.26. Diagrama Entidad Relación (Iteración 3) .............................................. 95
Figura 3.27. Historia de usuario – Generación de reportes ...................................... 96
Figura 3.28. Diagrama de hipertextos – Generación de reportes ............................ 97
Figura 3.29. Historia de usuario – Re-expresión y actualizaciones ........................... 98
Figura 3.30. Historia de usuario – Depreciación de Activos fijos .............................. 99
Figura 3.31. Diagrama de hipertextos – Depreciación activos fijos ......................... 100
Figura 3.32. Historia de usuario – Amortizaciones de activos intangibles ............... 100
Figura 3.33. Diagrama de hipertextos –Amortización de activos intangibles .......... 101
Figura 3.34. Diagrama Entidad Relación (Iteración 4) ............................................ 102
Figura 3.35. Historia de usuario – presentación de estados financieros ................. 104
Figura 3.36. Historia de usuario – Cierre de gestión ............................................... 105
Figura 3.37. Historia de usuario – Obtención de copias de respaldo ...................... 106
Figura 3.38. Historia de usuario – Resumen de la contabilidad .............................. 107
Figura 3.39. Producción – Interfaz de acceso ....................................................... 108
Figura 3.40. Producción – Gestión de usuario ........................................................ 109
Figura 3.41. Producción – Apertura de Gestión ...................................................... 109
Figura 3.42. Producción – Introducción plan de cuentas ........................................ 110
Figura 3.43. Producción – Introducción tipo de cambio .......................................... 110
Figura 3.44. Producción – Introducción UFV`s ....................................................... 111
Figura 3.45. Producción – Introducción comprobante ............................................ 111
Figura 3.46. Producción – Modificación comprobante ............................................ 112
Figura 3.47. Producción – Eliminación comprobante .............................................. 112
Figura 3.48. Producción – Generación de reportes ................................................ 113
Figura 3.49. Producción – Depreciación Activos fijos ............................................. 113
Figura 3.50. Producción – Presentación de estados financieros ............................ 114
Figura 3.51. Producción – Resumen de la contabilidad .......................................... 114
Figura 4.1. Modelo del Sistema .............................................................................. 122
Figura 4.2. Diagrama de Bloques ........................................................................... 122
 ÍNDICE DE TABLAS

Descripción Pag.
Tabla 2.1. Diferencias entre metodologías Agiles y no agiles ................................... 17
Tabla 2.1. Nomenclatura de Cuentas ....................................................................... 27
Tabla 3.1. Planteamiento de Historias de Usuario .................................................... 60
Tabla 3.2. Numero de Iteraciones de Historias de Usuario ....................................... 62
Tabla 3.3. Planificación de Entregas (Resumen) ...................................................... 65
Tabla 3.4. Estimación de esfuerzos – Gestión de usuarios ...................................... 66
Tabla 3.5. Estimación de esfuerzos – Apertura de gestión ...................................... 66
Tabla 3.6. Estimación de esfuerzos – Introducción de plan de cuentas .................... 66
Tabla 3.7. Estimación de esfuerzos – Introducción de tipos de cambio .................... 67
Tabla 3.8. Estimación de esfuerzos – Introducción de UFV`s ................................... 67
Tabla 3.9. Estimación de esfuerzos – Introducción de Comprobante........................ 67
Tabla 3.10. Estimación de esfuerzos – Modificación de comprobantes .................... 68
Tabla 3.11. Estimación de esfuerzos – Eliminación de comprobante........................ 68
Tabla 3.12. Estimación de esfuerzos – Pago de Sueldos y Salarios ......................... 68
Tabla 3.13. Estimación de esfuerzos – Generación de reportes ............................... 69
Tabla 3.14. Estimación de esfuerzos – Reexpresiones y actualizaciones ................. 69
Tabla 3.15. Estimación de esfuerzos – Depreciación de Activos Fijos ...................... 69
Tabla 3.16. Estimación de esfuerzos – Amortización de Activos Intangibles ............ 70
Tabla 3.17. Estimación de esfuerzos – Presentación de Estados Financieros ......... 70
Tabla 3.18. Estimación de esfuerzos – Cierre de gestión ......................................... 70
Tabla 3.19. Estimación de esfuerzos – Obtención de copias de respaldo ................ 71
Tabla 3.20. Estimación de esfuerzos – Resumen de la contabilización .................... 71
Tabla 3.21. Historias de Usuario – Primera Iteración ................................................ 72
Tabla 3.22. Historias de Usuario – Segunda Iteración .............................................. 73
Tabla 3.23. Historias de Usuario – Tercera Iteración ................................................ 73
Tabla 3.24. Historias de Usuario – Cuarta Iteración .................................................. 74
Tabla 3.25. Perfiles de acceso por usuario ............................................................... 77
Tabla 3.26. Depreciaciones de activos fijos ............................................................ 100
Tabla 4.1. Factor de ponderación ........................................................................... 116
Tabla 4.2. Factor de ponderación ........................................................................... 118
Tabla 4.3. Factor de ponderación ........................................................................... 119
Tabla 4.4. Factor de ponderación ........................................................................... 121
Tabla 4.5. Evaluación para cuestionario FU ........................................................... 121
Tabla 4.6. Confiabilidad de los subsistemas ........................................................... 123
 CAPITULO I

MARCO REFERENCIAL

1.1. PRESENTACIÓN

Vivimos en una era considerada por muchos autores como la Sociedad de la

Información, especialmente en el sector empresarial es patente, a todos los niveles
empresariales, la implantación de la informática como ayuda a la gestión empresarial
y, por supuesto, en el ámbito de la información contable. Hoy en día, es difícilmente
concebible un negocio cuya contabilidad no sea gestionada por lo menos en parte
por medios informáticos. Aún cuando la informática ha inundado todos los espectros
empresariales, el tratamiento de la contabilidad difiere bastante según se considere
el tamaño y complejidad de la organización. De este modo, el mayor tamaño, suele
llevar aparejado un sistema de información a medida, no estandarizado, que abarca
toda la gestión de la empresa. En cambio, las empresas con un menor tamaño,
suelen satisfacer sus necesidades a través de paquetes informáticos estandarizados
de los muchos que existen en el mercado.

El pasado año 2010 fueron aprobadas las Normas Internaciones de Información

Financiera (NIIF) por los que se regula el Nuevo Plan General de Contabilidad,
vigente a partir del 1 de Enero de 2012, fecha en la que todas las entidades deberán
adaptar su contabilidad a las nuevas normativas, dichas normas contables
constituyen los Estándares Internacionales o normas internacionales en el desarrollo
de la actividad contable y suponen un manual Contable, ya que en ellas se
establecen los lineamientos para llevar la Contabilidad de la forma como es
aceptable en el mundo, por lo cual la carrera de Contaduría Pública de la Universidad
Pública de El Alto se han visto en la necesidad de contar con un nuevo sistema
Informático Contable a partir de las NIIF.

1
1.2. ANTECEDENTES
1.2.1. Antecedentes Institucionales

El conocimiento y el manejo de información relevante en las Organizaciones

constituyen la materia prima fundamental de todos los procesos decisorios, sean
éstos gerenciales u operativos. Desde esta perspectiva, las organizaciones obtienen,
almacenan y procesan gran cantidad de datos que convierten en información útil
para un mejor cumplimiento de las metas propuestas. Así, las personas actúan,
operan y toman decisiones constantemente, utilizando y emitiendo información
diversa. Estas tareas han cambiado notablemente en los últimos tiempos. Los
constantes cambios mundiales, la globalización de los mercados, la introducción y
utilización de nuevas tecnologías y, en consecuencia, el creciente desarrollo de la
información, etc. requiere, entre otras cosas la codificación precisa de dicha
información. En lo que se refiere específicamente a los aspectos contables es
necesario comprender la complejidad de las operaciones financieras, la cambiante
dinámica de las normas contables y productivas, la globalización de los negocios y
manejar los nuevos software específicos de contabilidad.

1.2.2. Antecedentes del sistema

Hoy en día existen diversos tipos de sistemas contables utilizadas por las distintas
organizaciones en Bolivia, pero, estos sistemas están basados en las antiguas
normas de contabilidad bolivianas, por tanto no cumplen con las expectativas de la
institución, como por ejemplo:

Titulo: Orión Ver.4.6

Año: 2009
Institución: ORION SRL

Titulo: Mónica Ver. 8.0

Año: 2010
Institución: MONICA

2
1.3. DEFINICIÓN DEL PROBLEMA

1.3.1. PROBLEMA CENTRAL

¿De qué manera la contabilidad de la institución seria automatizada y ajustada a las

normas internacionales de información financiera (NIIF)?

1.3.2. PROBLEMAS SECUNDARIOS

• En la institución, existe la necesidad de exponer en los estados financieros de

forma automatizada con propósitos generales, información financiera confiable,
uniforme, transparente y comparable, siendo necesario que se asegure a los
múltiples usuarios de la información financiera, su presentación razonable y con
calidad, coadyuvando de este modo a la propagación de las expectativas externas
para realizar inversiones, actividades productivas y comerciales en el país.

• Los problemas que se presentan es la contabilización de los activos, la

determinación de su importe en libros y los cargos por depreciación y perdidas por
deterioro que deben reconocerse con relación a los mismos.

• No se cuenta con la automatización del tratamiento contable de las propiedades

de inversión y las exigencias de revelación de información correspondiente.

• La entidad requiere que se reconozca un activo intangible si, y sólo si, se cumplen
ciertos criterios.

• No se utiliza una sistema apropiado para el reconocimiento y la medición de las

provisiones, pasivos contingentes y activos contingentes, así como que se revele
la información complementaria suficiente, por medio de las notas, como para
permitir a los usuarios comprender la naturaleza, calendario del vencimiento e
importes, de las anteriores partidas.

• El cálculo de los impuestos a pagar se realizan manualmente.

3
1.4. JUSTIFICACIÓN DEL TEMA.

Debido a la necesidad de la actualización, integración, información que tiene la

entidad se hace necesario el desarrollo de un sistema Informático contable acordes a
las nuevas normas de información financiera, que permitirá a todos los usuarios
(docentes, estudiantes y administrativos de la carrera Contaduría Pública) estar
actualizados así de esta manera se dará cumplimiento a la normativa, desarrollar un
proceso dinámico en la información económica, financiera y tomar decisiones
acertadas, ya que dicha tarea se realizaba con sistemas informáticos basados en
antiguas normas Bolivianas

1.4.1. ECONÓMICA.

El Sistemas de Contabilidad Acordes a las NIIF permitirá minimizar los gastos y

optimizar tiempos en la parte administrativa de la carrera, ya que los sistemas
utilizados actualmente cuentas con varios errores y para la corrección de dichos
errores se incurre en varios gastos

1.4.2. SOCIAL.

El Sistemas de Contabilidad Acordes a las NIIF coadyuvará al aprendizaje,

actualización y en un mejor entendimiento de docentes, estudiantes y administrativos
de la Carrera de Contaduría Pública de la aplicación de estas nuevas normas
recientemente aprobadas

1.4.3. TÉCNICO.

En el diseño del Sistema de Contabilidad Acorde a las NIIF ofrecerá garantías

técnicas de seguridad e integridad de la información, también permitirá la emisión de
la información contable de forma oportuna y confiable para una mejor toma de
decisiones se emplearan me herramientas y metodologías actuales, ya que son
necesarias e imprescindibles

4
1.5. OBJETIVO

1.5.1. OBJETIVO GENERAL

Desarrollar e implementar un Sistema Web Contable acorde a las Normas

Internacionales de Información Financiera (NIIF) para la carrera de Contaduría
Pública de la Universidad Pública de El Alto.

1.5.2. OBJETIVOS ESPECÍFICOS

• Analizar la administración financiera de la Institución.

• Analizar el marco de conceptos de las Normas Internacionales de Información

Financiera.

• Abstraer y relacionar el marco de conceptos con el diseño del Sistema de

Contabilidad.

• Analizar las características y requerimientos para el desarrollo e implantación

del Sistema de Contabilidad.

• Implementar un modulo que permita presentar los estados financieros de

acuerdo al formato que indica la norma 1 de las NIIF.

• Implementar un modulo para el tratamiento contable de propiedades, planta y

equipo, de forma que los usuarios de los estados financieros puedan conocer
la información acerca de la inversión que la entidad tiene en sus propiedades,
planta y equipo, así como los cambios que se hayan producido en dicha
inversión.

• Automatizar el tratamiento contable de las propiedades de inversión y las

exigencias de revelación de información correspondiente.

• Implementar el modulo que se reconozca un activo intangible si, y sólo si, se

cumplen ciertos criterios.

5
 • Implementar el modulo apropiado para el reconocimiento y la medición de las
provisiones, pasivos contingentes y activos contingentes, así como que se
revele la información complementaria suficiente, por medio de las notas, como
para permitir a los usuarios comprender la naturaleza, calendario del
vencimiento e importes, de las anteriores partidas.

• Automatizar el cálculo de los impuestos a pagar de acuerdo a los datos

económicos dictados por la entidad correspondiente.

1.6. LÍMITES Y ALCANCES

1.6.1. LIMITES

• El Sistemas de Contabilidad no será capaz de realizar actualizaciones ni

pronósticos los índices económicos como las (Plan de Cuentas, UFV’s, Tipos
de Cambios), ya que estos datos son otorgados por las entidades
correspondientes.

• El Sistema de Contabilidad no será capaz de identificar transacciones

erróneas (Montos de la transacción), ya que esto necesita de un análisis
previo de un personal a cargo

1.6.2. ALCANCES

[Link]. Temporal

El sistema a desarrollar esta orientado a todos los docentes, administrativos y

estudiantes de la Carrera de Contaduría Pública de la Universidad Pública de El Alto
y el tiempo que tomará para desarrollar el sistema

[Link]. Espacial

El Desarrollo del Sistema será a partir del mes de junio y se estima concluir a fines
del mes de noviembre del 2011 (6 meses).

6
1.7. APORTES

• El Sistema web Contable estará Acordes a las Normas Internacionales de

Información financiera.

• La formulación de conceptos contables a partir de las Normas Internacionales

de Información Financiera.

• La aplicación de las Normas Internacionales de Información Financiera y

aplicación de elementos informáticos para el diseño del Sistema Contable.

• La utilización de una metodología ágil (XP) y un lenguaje de modelado

(WEBML) para el desarrollo del sistema Contable acordes a las NIIF.

1.8. METODOLOGÍA

Para el desarrollo del presente trabajo de investigación se hará uso del método
científico exploratorio, pues se necesita una manera sistemática, controlada,
empírica y crítica para llevarla a cabo, también porque la mayoría de las ideas
iníciales de la investigación es vaga e imprecisa y además porque es necesario
transformar los planteamientos inicial es en forma más precisa y estructurada.

En la parte del análisis y desarrollo del sistema de hará uso de la metodología ágil
(XP), y para el modelado se utilizara WEBML.

En cuanto a herramientas para la implementación se empleara el lenguaje de

programación php, como Gestor de base de datos se hará uso de MySql Server y
como servidor Web se hará uso de apache.

7
 CAPITULO II

MARCO CONCETUAL

2.1. BASES TEÓRICAS

2.1.1. INGENIERIA DE SOFTWARE

Es el área del conocimiento que se encarga de estudiar todos los aspectos que
alcanzan al desarrollo de sistemas informáticos, entre ellos: ciclo de vida, análisis de
requisitos, diseño, documentación, pruebas, calidad, seguridad, análisis de costos,
etc.

[Link]. GESTION DE PROYECTOS

Consiste en gestionar el desarrollo de un producto dentro de determinados plazos

y bajo los límites financieros. Lo anterior requiere capacidad para administrar
personal, una estructura administrativa definida, inclusión de procesos
administrativos, procesos de desarrollo y programas de mejoramiento continuo. El
objetivo de la gestión de proyectos consiste en mantener un equilibrio entre el costo,
la capacidad, la calidad.

[Link]. REQUERIMIENTOS

“La obtención de los requerimientos correctos es un proceso difícil. Consiste en la

interacción cuidadosa con quienes tienen intereses en la aplicación”. Para desarrollar
un software, generalmente en las primeras iteraciones se debe tener claridad en las
funcionalidades que va a ofrecer, que utilidades va a brindar a la comunidad de
usuarios. La etapa de requerimientos consiste en capturar con los implicados del
software que necesidades (procesos deficientes) de la compañía o entorno
determinado va a cubrir, que debe hacer el sistema (requerimientos funcionales),
cómo lo debe hacer (requerimientos no funcionales), que riesgos y que restricciones
existen. Esta etapa suele realizarse con entrevistas directas entre el analista y el
implicado del sistema (dueño del negocio, empleado del negocio, etc.), sin embargo

8
pueden utilizarse otros métodos para obtener dicha información. La mayor parte de
los defectos encontrados en un software se deben a errores en esta etapa y
generalmente los errores que de aquí nacen suelen ser los más costosos de corregir.
Un software puede estar muy bien diseñado e, implementado, pero si no le es útil a
la empresa o al cliente su usabilidad se verá afectada. [Erik J, 2003].

[Link]. ANALISIS Y DISEÑO

Las actividades a desarrollar en estas etapas dependen de la metodología de

desarrollo de software que se utilice. James A. Senn en su libro Análisis y Diseño de
Sistemas de Información, hace referencia al análisis y diseño como: “El proceso de
examinar una situación en la empresa con la intención de mejorarla mediante nuevos
procedimientos”. En el libro Análisis y Diseño de Sistemas de Kendall y Kendall, dice
que: “El análisis y diseño de sistemas sirve para analizar, diseñar y fomentar mejoras
en la operación de la empresa, lo cual puede realizarse mediante el uso de sistemas
de información computarizados”. Básicamente el análisis consiste en analizar los
requerimientos obtenidos en la etapa anterior mediante la elaboración de unos
artefactos que permiten especificar la funcionalidad y la arquitectura del sistema,
algunas metodologías utilizan los diagramas de modelado que ofrece UML (Unified
Modeling Language) como los casos de uso, los diagramas de clases, entre otros. El
diseño consiste en retocar o refinar los artefactos hechos en el análisis, es decir,
llevar a un nivel superior (aumentar el detalle) la arquitectura, de forma que los
requerimientos estén expresados en términos cercanos a la implementación. Algunas
veces en la etapa de diseño se corrigen errores que vienen desde la etapa de
requerimientos. Generalmente se realizan en esta etapa los modelos de las
interfaces gráficas.

[Link]. IMPLEMENTACIÓN

La implementación consiste en transformar los resultados del diseño en realidad

(producto de software), en esta etapa se escoge -aunque generalmente se determina
en etapas previas- un lenguaje de programación y se comienza a escribir las
instrucciones necesarias para que el sistema realice las tareas que se han

9
identificado en las etapas anteriores. “La implementación se refiere a la
programación. El propósito de la implementación es satisfacer los requerimientos de
la manera que especifica el diseño”.

[Link]. PRUEBAS

Las pruebas consisten en realizar una serie de “ataques” al sistema. Después de

desarrollar una aplicación o módulo de programación se debe validar cada una de las
posibles situaciones que ocurran entre el usuario y el software. Las pruebas
muestran la presencia de los defectos del sistema; los coloca al descubierto.

[Link]. MÉTRICAS DEL SOFTWARE

Son un conjunto de técnicas que permiten medir varios aspectos del proceso de
desarrollo de un sistema de información. Se utilizan para conocer con exactitud
variables como cantidad de trabajo realizado, tiempo que toma realizar el trabajo,
tasa de defectos, entre otras. Las métricas de software son fundamentales para el
aseguramiento de la calidad en los procesos de desarrollo.

[Link]. METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Son un conjunto de procedimientos, técnicas, herramientas y un soporte

documental que ayuda al equipo desarrollador a crear un nuevo producto de
software. A continuación se mencionan algunas:

a) Cascada

Esta metodología no soporta el desarrollo iterativo-incremental. Se utiliza en los

proyectos donde se conocen exactamente todos los requerimientos. Consiste en
pasar por cada una de las etapas (requerimientos, análisis, diseño, implementación,
pruebas) de desarrollo, pero no al mismo tiempo, sólo cuando definitivamente
termine la etapa de requerimientos puede seguir a la de análisis y sucede de igual
forma para el resto de las etapas. Soporta muy poca retroalimentación y genera
documentación excesiva. Un requerimiento no capturado que es detectado en la

10
etapa de diseño puede ser fatal para la vida del proyecto. Actualmente es una
metodología de desarrollo poco utilizada.

b) Proceso Unificado (UP - Unified Software Development Process)

Esta metodología de desarrollo define quién debe hacer qué, cuándo y cómo debe
hacerlo. Es un marco de trabajo genérico que puede especializarse. Está basada en
componentes interconectados por interfaces. Se apoya en UML para el modelado del
sistema y es dirigida por los casos de uso, se centra en la arquitectura y es iterativa e
incremental. Fue creada por: Grady Booch, Jim Rumbaugh e Ivar Jacobson, los
creadores de UML. Contempla cuatro fases:

Inicio, en la cual se define el ámbito del proyecto.

Elaboración, donde se define el plan del proyecto, las especificaciones

funcionales y la arquitectura base.

Construcción, consiste en construir el producto.

Transición, que es la instalación del sistema en la comunidad de usuarios finales.

Contiene dentro de estas fases unas disciplinas que en el desarrollo del proyecto se
vuelven dinámicas.

Las disciplinas son: modelado del negocio, requerimientos, análisis y diseño,

implementación, pruebas, despliegues, configuración y cambios en el proyecto,
administración del proyecto, ambiente de desarrollo.
[[Link]

c) Programación Extrema (XP – eXtremme Programming)

En esta metodología se trabaja con parejas de programadores expertos. Se

realizan pruebas todo el tiempo, esto con el fin de garantizar que se esté escribiendo
el código correctamente. Es utilizada cuando la cultura de la compañía permite
experimentación. Trabaja con equipos pequeños, pero estos equipos deben tener
alta experiencia en desarrollo. Los requerimientos cambian frecuentemente pues no

11
existe un diseño detallado, puede que sólo se fundamenten en los casos de uso de
UML. [[Link]

d) Metodología de Diseño de Hipermedia Orientada a Objetos (OODHM –

Object Oriented Design Methodology)

Es una metodología de desarrollo de software orientado a la Web, fue creada por

D. Schwabe, G. Rossi y S.D.J. Barbosa. La novedad de esta metodología es que
contempla los paradigmas de la orientación a objetos en el proceso de producción de
aplicaciones hipermedias (Imágenes, sonido, vídeo, entre otras). Incluye 4 fases:
diseño conceptual, diseño navegacional, diseño de interfaces abstractas e
implementación.

2.1.2. INGENIERIA WEB

La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y

cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta
calidad en la World Wide Web.

La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web

está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando
a la información en las diferentes áreas en que se presenta ha hecho que las
personas tiendan a realizar todas sus actividades por esta vía.

Desde que esto empezó a suceder el Internet se volvió más que una diversión y
empezó a ser tomado más en serio, ya que el aumento de publicaciones y de
informaciones hizo que la Web se volviera como un desafío para los (Ingeniería del
software) ingenieros del software, a raíz de esto se crearon enfoques disciplinados,
sistemáticos y metodologías donde tuvieron en cuenta aspectos específicos de este
nuevo medio.

[Link]. INTRODUCCIÓN A LA INGENIERIA WEB

Uno de los aspectos más tenidos en cuenta, en el desarrollo de sitios web es sin
duda alguna el diseño gráfico y la organización estructural del contenido. En la

12
actualidad la web está sufriendo grandes cambios, que han obligado a expertos en el
tema a utilizar herramientas y técnicas basadas en la ingeniería del software, para
poder garantizar el buen funcionamiento y administración de los sitios web.

Para garantizar el buen funcionamiento y mantenimiento de los sitios web, este

debe contar con ciertos atributos y características que en conjunto forman un
concepto muy importante, para alcanzar el éxito en cualquier organización,
herramienta, y todo aquello que se pueda considerar como servicio. Dicho concepto
es la calidad, que con atributos como, usabilidad, navegabilidad, seguridad,
mantenibilidad, entre otros, hace posible por un lado la eficiencia del artefacto web y
por ende la satisfacción del usuario final.

Pero para tener artefactos de calidad, a esa misma se le debe planificar,

programar y controlar, es decir la calidad no podrá ser agregada a un artefacto web o
a cualquier otro producto, al final del proceso de desarrollo, si no que se deberá
implementar durante todo el ciclo de vida del desarrollo. Para finalizar el resultado de
un proceso de calidad, podría arrojar recomendaciones para introducir mejoras, y la
decisión final podría consistir en lanzar una nueva versión del sitio web o en
modificar algunos atributos ausentes o pobremente diseñados. Cabe destacar que la
ingeniería de la web hace una diferencia entre un webSite y un aplicativo, ya que la
ingeniería de la web no se dedica a la construcción de sitios web si no a la
construcción de aplicativos web, la principal característica que los distingue
(aplicativos de sitios web) es que los sitios web son sitios en la web en donde se
publica contenido generalmente estático o un muy bajo nivel de interactividad con el
usuario, mientras que los aplicativos son lugares con alto contenido de interactividad
y funcionalidades que bien podrían ser de un software convencional, el aplicativo
web más sencillo seria uno que contenga formularios y subiendo de nivel
encontramos los que realizas conexión con bases de datos remotas, y
administradores de contenidos entre otras.

Entonces la ingeniería de la Web es la aplicación de metodologías sistemáticas,

disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de
aplicaciones de alta calidad en la World Wide Web. En este sentido, la ingeniería de

13
la Web hace referencia a las metodologías, técnicas y herramientas que se utilizan
en el desarrollo de aplicaciones Web complejas y de gran dimensión en las que se
apoya la evaluación, diseño, desarrollo, implementación y evolución de dichas
aplicaciones. [Pressman. 2006].

[Link]. ÁREAS A LA INGENIERÍA WEB

El desarrollo de aplicaciones Web posee determinadas características que lo

hacen diferente del desarrollo de aplicaciones o software tradicional y sistemas de
información. La ingeniería de la Web es multidisciplinar y aglutina contribuciones de
diferentes áreas: arquitectura de la información, ingeniería de hipermedia/hipertexto,
ingeniería de requisitos, diseño de interfaz de usuario, usabilidad, diseño gráfico y de
presentación, diseño y análisis de sistemas, ingeniería de software, ingeniería de
datos, indexado y recuperación de información, testeo, modelado y simulación,
despliegue de aplicaciones, operación de sistemas y gestión de proyectos.

La ingeniería de la Web no es un clon o subconjunto de la ingeniería de software

aunque ambas incluyen desarrollo de software y programación, pues a pesar de que
la ingeniería de la Web utiliza principios de ingeniería de software, incluye nuevos
enfoques, metodologías, herramientas, técnicas, guías y patrones para cubrir los
requisitos únicos de las aplicaciones web. Sin embargo el termino de ingeniería de la
web ha sido un término muy controvertido especialmente para profesionales en
disciplinas tales como la ingeniería del software ya que no la consideran como un
campo dentro de la ingeniería.

Los principales aspectos de la ingeniería de la Web incluyen, entre otros, los

siguientes temas:

• Diseño de procesos de negocio para aplicaciones web.

• Herramientas CASE para aplicaciones web.

• Generación de código para aplicaciones web.

• Desarrollo web colaborativo.

• Modelado conceptual de aplicaciones web.

14
 • Diseño de Modelos de datos para sistemas de información web.

• Ingeniería web empírica.

• Entornos de desarrollo de aplicaciones web integrados.

• Herramientas de autor para contenido multimedia.

• Pruebas de rendimiento de aplicaciones basadas en web.

• Personalización y adaptación de aplicaciones web.

• Herramientas y métodos de prototipado.

• Control de calidad y pruebas de sistemas.

• Ingeniería de requisitos para aplicaciones web.

• Aplicaciones para la Web Semántica.

• Factorías de software para la web.

• Métodos, herramientas y automatización de pruebas para aplicaciones web.

• Aplicaciones web móviles y ubícuas.

• Usabilidad de aplicaciones web.

• Accesibilidad para la web.

• Metodologías de diseño web.

• Formación en ingeniería de la web.

• Diseño de interfaces de usuario.

• Métricas para la web, estimación de costes y medición.

• Gestión de proyectos web y gestión de riesgos.

• Desarrollo y despliegue de servicios web.

2.1.3. WEBML

WebML (Web Modeling Language) es una notación visual para el diseño de

aplicaciones Web complejas que usan datos intensivamente. Provee

15
especificaciones gráficas formales para un proceso de diseño completo que puede
ser asistido por herramientas de diseño visuales.

Disponen de una herramienta CASE que facilita la creación de páginas web en

jsp. WebRatio.

También existe una extensión del módulo de navegación de UML propuesto por
Jim Conallen, para el manejo de proyectos de aplicaciones web.

2.1.4. METODOLOGÍAS, MÉTODOS, TECNOLOGÍAS, LENGUAJES Y

HERRAMIENTAS UTILIZADAS EN EL DESARROLLO DEL PROYECTO

[Link]. METODOLOGÍAS AGILES

El objetivo de las metodologías ágiles es esbozar los valores y principios que

deberían permitir a los equipos de desarrollo, desarrollar software rápidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretende
ofrecer una alternativa a los procesos de desarrollo de software tradicionales.
Caracterizados por ser rígidos y dirigidos por la documentación que se genera en
cada una de las actividades desarrolladas. Varias de las denominadas metodologías
ágiles están siendo utilizadas con éxito en proyectos reales, pero les faltaba una
mayor difusión y reconocimiento.

Antes de mostrar la metodología eXtreme Programming, mostraremos las

principales diferencias respecto a las metodologías tradicionales (no ágiles):

Metodologías Agiles Metodologías Tradicionales

Basadas en normas provenientes de
Basadas en heurísticas provenientes de
estándares seguidos por el entorno
prácticas de producción de código.
de desarrollo.
Especialmente preparados para
Cierra resistencia a los cambios.
cambios durante el proyecto.
Impuestas internamente (por el equipo
Impuestas externamente.
de desarrollo)

16
 Proceso menos controlado, con pocos Proceso mucho más controlado, con
principios. numerosas políticas/normas.
No existe contrato tradicional o al
Existe un contrato prefijado.
menos es bastante flexible.
El cliente es parte del equipo de El Cliente interactúa con el equipo de
desarrollo. desarrollo mediante reuniones.
Grupos pequeños (<10 integrantes) y Grupos grandes y posiblemente
trabajando en el mismo sitio. distribuidos.
Pocos artefactos. Más artefactos.
Pocos roles Más roles.
Menos énfasis en la arquitectura del La arquitectura del software es esencial
software y se expresa mediante modelos.
Tabla 2.1. Diferencias entre metodologías Agiles y no agiles
[Letelier, 2004]

[Link]. PROGRAMACIÓN EXTREMA (XP – EXTREMME PROGRAMMING)

XP [Beck, 2004] es una metodología ágil centrada en potenciar las relaciones

interpersonales como clave para el éxito en desarrollo de software, promoviendo el
trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y
propiciando un buen clima de trabajo.

XP se basa en realimentación continua entre el diente y el equipo de desarrollo,

comunicación fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo técnico.

A continuación se detallan las características esenciales de XP organizadas en los

tres apartados siguientes: historias de usuario, roles, proceso y prácticas.

17
 a) Historias de Usuario

Las historias de usuario son la técnica utilizada en XP para especificar los

requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe
brevemente las características que el sistema debe poseer, sean requisitos
funcionales o no funcionales. El tratamiento de las historias de usuario es muy
dinámico y flexible, en cualquier momento historias de usuario pueden romperse,
reemplazarse por otras más específicas o generales, añadirse nuevas o ser
modificadas. Cada historia de usuario es lo suficientemente comprensible y
delimitada para que los programadores puedan implementarla en unas semanas
[Jefries, 2001].

Respecto de la información contenida en la historia de usuario, existen varias

plantillas sugeridas pero no existe un consenso al respecto. En muchos casos sólo
se propone utilizar un nombre y una descripción [Wake, 2002] o sólo una descripción
[Jefries, 2001], más quizás una estimación de esfuerzo en días [Newk:ifk, 2(01). Beck
en su libro [Beck, 2004] presenta un ejemplo de ficha (customer story and task card)
en la cual se reconocen los siguientes contenidos: fecha, tipo de actividad (nueva,
corrección, mejora), prueba funcional, número de historia, prioridad técnica y del
diente, referencia a otra historia previa, riesgo, estimación técnica, descripción, notas
y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios. No
hay que preocuparse, si en un principio, no se identifican todas las historias de
usuario. Al comienzo de cada iteración estarán registrados los cambios en las
historias de usuario y según eso se planificará la siguiente iteración.

Las historias de usuario son descompuestas en tareas de programación y

asignadas a los programadores para ser implementadas durante una iteración.

Como sugiere Kent Beck, XP lleva un conjunto de técnicas y principios de sentido

común a niveles extremos, entre los que podemos destacar:

• El código será revisado continuamente.

18
 • Se harán pruebas todo el tiempo no sólo de cada nueva clase (pruebas
unitarias) sino que también los clientes comprobarán que el proyecto va
satisfaciendo los requisitos (pruebas funcionales).

• Las pruebas de integración se efectuarán siempre. antes de añadir cualquier

nueva clase al proyecto, o después de modificar alguna existente (integración
continua).

• Se rediseñará todo el tiempo (refactoring) dejando el código siempre en el

estado más simple posible.

• Las iteraciones serán radicalmente más cortas de lo que es usual en otros

métodos, de manera que nos podamos beneficiar de la retroalimentación tan a
menudo como sea posible.

b) Proceso XP

Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a

implementar basado en la habilidad del equipo para medir la funcionalidad que puede
entregar a través del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los
siguientes pasos [Jefries, 2001]:

1. El cliente define el valor de negocio a imptementar.

2. El programador estima el esfuerzo necesario para su implementación.

3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las

restricciones de tiempo.

4. El programador construye ese valor de negocio.

5. Vuelve al paso 1.

En todas las iteraciones de este ciclo, tanto el cliente como el programador

aprenden.

19
 El ciclo de vida ideal de XPconsiste de seis fases [Beck, 2004): Exploración,
Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y
Muerte del Proyecto.

A continuación se describen cada una de ellas:

Fase I. Exploración

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de interés para la primera entrega del producto. Al mismo tiempo el equipo de
desarrollo se familiariza con las herramientas, tecnologías y prácticas que se
utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la
arquitectura del sistema construyendo un prototipo. La fase de exploración toma de
pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan
los programadores con la tecnología.

Fase II. Planificación de la Entrega

En esta fase el cliente establece la prioridad de cada historia de usuario, y

correspondientemente, los programadores realizan una estimación del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera
entrega y se determina un cronograma en conjunto con el cliente. Una entrega
debería obtenerse en no más de tres meses. Esta fase dura unos pocos días.

Las estimaciones de esfuerzo asociado a la implementación de las historias la

establecen los programadores utilizando como medida el punto. Un punto, equivale a
una semana ideal de programación. Las historias generalmente valen de 1a 3
puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la -Velocidad"
de desarrollo, establecida en puntos por iteración, basándose principalmente en la
suma de puntos correspondientes a las historias de usuario que fueron terminadas
en la última iteración. La planificación se puede realizar basándose en el tiempo o el
alcance. La velocidad del proyecto es utilizada para establecer cuántas historias se
pueden implementar antes de una fecha determinada o cuánto tiempo tomará
implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número

20
de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se
pueden completar. Al planificar según alcance del sistema, se divide la suma de
puntos de las historias de usuario seleccionadas entre la velocidad del proyecto,
obteniendo el número de iteraciones necesarias para su implementación.

Fase III. Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El
Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la
primera iteración se puede intentar establecer una arquitectura del sistema que
pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las
historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre
es posible ya que es el diente quien decide qué historias se implementarán en cada
iteración (para maximizar el valor de negocio). Al final de la última iteración el
sistema estará listo para entrar en producción.

Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la
Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de
aceptación no superadas en la iteración anterior y tareas no terminadas en la
iteración anterior. Todo el trabajo de la iteración es expresado en tareas de
programación, cada una de ellas es asignada a un programador como responsable,
pero llevadas a cabo por parejas de programadores. Wake (Wake, 2002] proporciona
algunas guías útiles para realizar la planificación de la entrega y de cada iteración.

Fase IV. Producción

La fase de producción requiere de pruebas adicionales y revisiones de

rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo
tiempo, se deben tomar decisiones sobre la inclusión de nuevas características ea la
versión actual, debido a cambios durante esta fase.

Es posible que se rebaje el tiempo que torna cada iteración, de tres a una
semana. Las ideas que han sido propuestas y las sugerencias son documentadas
para su posterior implementación (por ejemplo, durante la fase de mantenimiento).

21
Fase V. Mantenimiento

Mientras la primera versión se encuentra en producción, el proyecto XP debe

mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas
iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De
esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema
en producción. La fase de mantenimiento puede requerir nuevo personal dentro del
equipo y cambios en su estructura.

Fase VI. Muerte del proyecto

Esta fase del proyecto se presenta- el momento que el cliente no tiene más
historias que concluir en el sistema. Esto implica que se satisfagan las necesidades
del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se
genera la documentación final del sistema y no se realizan más cambios en la
arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los
beneficios esperados por el cliente o cuando no existe el presupuesto necesario para
mantenerlo.

A continuación se muestra el ciclo de un proyecto con eXtreme Programming:

Figura 2.1. Proyecto Xtreme Programming

[Wake, 2002]

22
 c) Coste del Cambio

Siempre ha sido una verdad universal el hecho de que el coste del cambio en el
desarrollo de un proyecto se incrementa exponencialmente en el tiempo, como lo
indica la Figura 10.3:

REQUISITOS ANÁLISIS DISEÑO IMPLEMENTACIÓN PRUEAS PRODUCCIÓN

Figura 2.2. Coste del cambio de la ingenieria del software tradicional
[Kent, 2004]

Lo que XP propugna es que esta curva ha perdido validez y que con una
combinación de buenas prácticas de programación y tecnología es posible lograr que
la curva sea la contraria como se refleja en la Figura 10.4:

REQUISITOS ANÁLISIS DISEÑO IMPLEMENTACIÓN PRUEAS PRODUCCIÓN

Figura 2.3. Coste del cambio en XP

[Kent, 2004]

23
[Link]. PHP

PHP es un acrónimo recursivo que significa PHP Hypertext Pre-

processor (inicialmente PHP Tools, o, Personal Home Page Tools). Fue creado
originalmente por Rasmus Lerdorf en 1994; sin embargo la implementación principal
de PHP es producida ahora por The PHP Group y sirve como el estándar de facto
para PHP al no haber una especificación formal. Publicado bajo la PHP License, la
Free Software Foundation considera esta licencia como software libre.

Puede ser desplegado en la mayoría de los servidores web y en casi todos los
sistemas operativos y plataformas sin costo alguno. El lenguaje PHP se encuentra
instalado en más de 20 millones de sitios web y en un millón de servidores, el
número de sitios en PHP ha compartido algo de su preponderante sitio con otros
nuevos lenguajes no tan poderosos desde agosto de 2005. Este mismo sitio web de
Wikipedia está desarrollado en PHP. Es también el módulo Apache más popular
entre las computadoras que utilizan Apache como servidor web.

[Link]. MySQL

MySQL es un sistema de gestión de bases de

datos relacional, multihilo y multiusuario con más de seis millones de
instalaciones.1MySQL AB —desde enero de 2008 una subsidiaria de Sun
Microsystems y ésta a su vez de Oracle Corporation desde abril de 2009— desarrolla
MySQL como software libre en un esquema de licenciamiento dual.

Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta
licencia, pero para aquellas empresas que quieran incorporarlo en
productos privativos deben comprar a la empresa una licencia específica que les
permita este uso. Está desarrollado en su mayor parte en ANSI C.

Al contrario de proyectos como Apache, donde el software es desarrollado por

una comunidad pública y los derechos de autor del código están en poder del autor
individual, MySQL es patrocinado por una empresa privada, que posee el copyright
de la mayor parte del código.

24
 Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado.
Además de la venta de licencias privativas, la compañía ofrece soporte y servicios.
Para sus operaciones contratan trabajadores alrededor del mundo que colaboran
vía Internet. MySQL AB fue fundado por David Axmark, Allan Larsson y Michael
Widenius.

[Link]. Apache

El servidor HTTP Apache es un servidor web HTTP de código abierto, para

plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que
implementa el protocolo HTTP/1.12 y la noción de sitio virtual. Cuando comenzó su
desarrollo en 1995 se basó inicialmente en código del popular NCSA HTTPd 1.3,
pero más tarde fue reescrito por completo. Su nombre se debe a que Behelendorf
quería que tuviese la connotación de algo que es firme y enérgico pero no agresivo, y
la tribu Apache fue la última en rendirse al que pronto se convertiría en gobierno de
EEUU, y en esos momentos la preocupación de su grupo era que llegasen las
empresas y "civilizasen" el paisaje que habían creado los primeros ingenieros de
internet. Además Apache consistía solamente en un conjunto de parches a aplicar al
servidor de NCSA. Era, en inglés, a patchy server (un servidor "parcheado").

El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de

la Apache Software Foundation.

Apache presenta entre otras características altamente configurables, bases de

datos de autenticación y negociado de contenido, pero fue criticado por la falta de
una interfaz gráfica que ayude en su configuración.

Apache tiene amplia aceptación en la red: desde 1996, Apache, es el servidor

HTTP más usado. Alcanzó su máxima cuota de mercado en 2005 siendo el servidor
empleado en el 70% de los sitios web en el mundo, sin embargo ha sufrido un
descenso en su cuota de mercado en los últimos años. (Estadísticas históricas y de
uso diario proporcionadas por Netcraft).

25
2.2. BASES CONCEPTUALES

2.2.1. CONTABILIDAD

Contabilidad es una técnica, de las Ciencias Sociales, que se encarga de estudiar,

medir y analizar el patrimonio de las empresas y de los individuos, con el fin de servir
en la toma de decisiones y control, presentando la información, previamente
registrada, de manera sistemática y útil para las distintas partes interesadas. Posee
además una técnica que produce sistemáticamente y estructuradamente información
cuantitativa y valiosa, expresada en unidades monetarias acerca de las
transacciones que efectúan las Entidades económicas y de ciertos eventos
económicos identificables y cuantificables que la afectan, con la finalidad de facilitarla
a los diversos públicos interesados.

También se puede definir como el sistema que mide la actividad en los negocios y
procesa dicha medición en informes y estados financieros para comunicar resultados
y hallazgos a los encargados de tomar las decisiones. [Vargas, 2007].

2.2.2. NOMENCLATURA DE CUENTAS

La nomenclatura de cuentas es un catálogo o lista de cuentas, clasificadas de

acuerdo con una codificación. Este listado se clasifica según las áreas del balance y
de resultado:

• ACTIVO

• PASIVO

• PATRIMONIO

• INGRESO

• EGRESO

El siguiente esquema ilustra el formato de una nomenclatura para una

organización sencilla:

26
 CODIGO CUENTA POSICIÓN CONTABLE
1 ACTIVO GRUPO
11 ACTIVO CORRIENTE RUBRO
1101 DISPONIBLE TITULO
110101 CAJA CUENTA
11010101 CAJA M/N SUB-CUENTA
11010102 CAJA M/E SUB-CUENTA
110102 BANCO CUENTA
11010201 BANCO M/N SUB-CUENTA
11010202 BANCO M/E SUB-CUENTA
2 PASIVO GRUPO
3 PATRIMONIO GRUPO
4 INGRESO GRUPO
5 EGRESO GRUPO
Tabla 2.2. Nomenclatura de Cuentas
[Funes, 2008]

2.2.3. CICLO DE LA CONTABILIDAD

El ciclo contable, es el conjunto de pasos o fases de la contabilidad que se repiten

en cada período contable, durante la vida de un negocio. Se inicia con el registro de
las transacciones, continúa con la labor de pase de las cantidades registradas del
diario al libro mayor, la elaboración del balance de comprobación, la hoja de trabajo,
los estados financieros, la contabilización en el libro diario de los asientos de ajuste,
su traspaso a las cuentas del libro mayor y, finalmente el balance de comprobación
posterior al cierre.

Es importante destacar que el ciclo contable se refiere al proceso de registros que

va desde el registro inicial de las transacciones hasta los estados financieros finales.
Además de registrar las transacciones explícitas conforme van ocurriendo, el ciclo
contable incluye los ajustes para las transacciones implícitas. Es importante
reconocer cómo los ajustes para las transacciones implícitas en el período anterior
pueden afectar la contabilidad adecuadamente en el período actual para las
transacciones explícitas relativas. Por ejemplo, si se han acumulado salarios al final
del período anterior, la primera nómina del periodo actual eliminará esa cuenta por
pagar. El pasar a un nuevo período contable se facilita cerrando los libros, que es un

27
procedimiento de oficina que transfiere los saldos de ingresos y gastos a la utilidad
acumulada, y prepara los libros para el comienzo de un nuevo ciclo contable.

Sin embargo, no solamente cerrar los libros y preparar los estados financieros
completa el ciclo contable, los auditores con frecuencia revisan los estados antes que
estos se revelen al público. Una auditoría le agrega credibilidad a los estados
financieros. Las cuentas ayudan a organizar el pensamiento y a descubrir las
cantidades desconocidas. La idea clave es la de llenar las cuentas relativas con
todos los cargos, abonos y saldos conocidos, y luego resolver para encontrar las
cantidades desconocidas. [Funes, 2008].

[Link]. Balance general al principio del periodo reportado

Consiste en el inicio del ciclo contable con los saldos de las cuentas del balance
de comprobación y del mayor general del período anterior.

[Link]. Proceso de análisis de las transacciones y registro en el diario

Consiste en el análisis de cada una de las transacciones para proceder a su

registro en el diario.

ORGANIZACIÓN
NIT:
COMPROBANTE DE DIARIO
Fecha: Nº
Concepto:
Forma de pago:
CODIGO DETALLE PARCIAL DEBE HABER

TOTALES
Son:………………………………………………………… 00/100
C.I.:…………………………………………………………
Preparado por:………………………………………………………………………
Autorizado por:…………………………………………………………………

Figura 2.4. Modelo de Comprobantes de Diario

[Funes, 2008]

28
[Link]. Pase del libro diario al libro mayor

Consiste en registrar en las cuentas del libro mayor los cargos y créditos de los
asientos consignados en el diario.

[Link]. Elaboración del balance de comprobación no ajustado o una hoja de

trabajo

Consiste en determinar los saldos de las cuentas del libro mayor y en comprobar
la exactitud de los registros. Con la hoja de trabajo se reubican los efectos de los
ajustes, antes de registrarlos en las cuentas; transferir los saldos de las cuentas al
balance general o al estado de resultados, procediendo por último a determinar y
comprobar la utilidad o pérdida.

[Link]. Analizar los ajustes y las correcciones, registrarlos en el diario y

transferirlos al mayor

Consiste en registrar en el libro diario los asientos de ajuste, con base en la

información contenida en la hoja de trabajo, en sus columnas de ajustes; se procede
luego a pasar dichos ajustes al libro mayor, para que las cuentas muestren saldos
correctos y actualizados.

[Link]. Elaboración de un balance de prueba ajustado

Consiste en la elaboración de un balance de prueba después de realizar los

ajustes correspondientes al periodo.

[Link]. Elaboración de los estados financieros

Consiste en reagrupar la información proporcionada por la hoja de trabajo y en

elaborar un balance general y un estado de resultados.

[Link]. Cierre de libros

Consiste en contabilizar en el libro diario los asientos para cerrar las cuentas
temporales de capital, procediendo luego a pasar dichos asientos al libro mayor,
transfiriendo la utilidad o pérdida neta a la cuenta de capital. Los saldos finales en el

29
balance general se convierten en los saldos iniciales para el período siguiente.
[Funes, 2008]

BALANCE GENERAL AL PRINCIPIO DEL PERIODO

REPORTADO

PROCESO DE ANÁLISIS DE LAS

TRANSACCIONES Y REGISTRO EN EL DIARIO

PASE DEL LIBRO DIARIO AL LIBRO MAYOR

ELABORACIÓN DEL BALANCE DE

COMPROBACIÓN NO AJUSTADO

ANALIZAR LOS AJUSTES Y LAS CORRECCIONES,

REGISTRARLOS EN EL DIARIO Y MAYOR

ELABORACIÓN DE UN BALANCE DE PRUEBA

AJUSTADO

ELABORACIÓN DE LOS ESTADOS FINANCIEROS

CIERRE DE LIBROS

Figura 2.5. Ciclo Contable

[Vargas M., 2006]

2.2.4. MARCO CONCEPTUAL PARA LA PREPARACIÓN Y PRESENTACIÓN DE

ESTADOS FINANCIEROS

30
[Link]. Introducción

Muchas entidades, en el mundo entero, preparan y presentan estados financieros

para usuarios externos. Aunque tales estados financieros pueden parecer similares
entre un país y otro, existen en ellos diferencias causadas probablemente por una
amplia variedad de circunstancias sociales, económicas y legales
; así como porque
en los diferentes países se tienen en mente las necesidades de distintos usuarios de
los estados financieros al establecer la normativa contable nacional.

En base a lo anteriormente expuesto es que el Consejo Técnico Nacional de

Auditoria y Contabilidad (CTNAC) del Colegio de Auditores o Contadores Públicos de
Bolivia considera que los estados financieros elaborados para tal propósito cubren
las necesidades comunes de la mayoría de los usuarios. Esto es porque casi todos
los usuarios toman decisiones económicas, como ser las siguientes:

a) Decidir si comprar, mantener o vender inversiones financieras de capital.

b) Evaluar el comportamiento o la actuación de los administradores.
c) Evaluar la capacidad de la entidad para satisfacer los pagos y suministrar
otros beneficios a sus empleados.
d) Evaluar la seguridad de los fondos prestados a la empresa.
e) Determinar políticas impositivas.
f) Determinar las ganancias distribuibles y los dividendos.
g) Preparar y usar las estadísticas de la renta nacional 1.
h) Regular las actividades de las entidades.

El Consejo Técnico Nacional de Auditoria y Contabilidad del Colegio de Auditores

o Contadores Públicos de Bolivia, reconoce que el gobierno, puede fijar requisitos
diferentes o adicionales para sus propios intereses. Sin embargo estos requisitos
contables no deben afectar a los estados financieros emitidos para beneficio de otros
usuarios, a menos que satisfagan también las necesidades de esos otros usuarios.

Generalmente, los estados financieros se elaboran de acuerdo a un modelo

contable basado en el costo histórico recuperable, así como el concepto de
mantenimiento de capital financiero en términos nominales. Si se tiene el objetivo de

31
proveer información útil para la toma decisiones económicas, otro tipo de modelos y
conceptos contables pueden ser más apropiados. El Marco Conceptual de Bolivia en
convergencia con el Marco Conceptual de las IASB ha sido desarrollado de manera
que pueda aplicarse a una variada gama de modelos contables, como de conceptos
de capital y de mantenimiento de capital.

[Link]. Objetivos de los estados financieros

El objetivo de los estados financieros es suministrar información acerca de la

situación financiera, desempeño y cambios en la posición financiera.

Los estados financieros preparados con este propósito cubren las necesidades
comunes de muchos usuarios.

Los estados financieros también muestran los resultados de la administración

llevada a cabo por la gerencia, o dan cuenta de la responsabilidad en la gestión de
los recursos confiados a la misma.

[Link]. Situación financiera, desempeño y cambios en la posición financiera

Las decisiones económicas, que toman los usuarios de los estados financieros,
requieren una evaluación de la capacidad que la entidad tiene de generar efectivo u
otros recursos equivalentes al efectivo para la misma, así como la proyección
temporal y la certeza de tal generación de liquidez. En último extremo, es esta
capacidad la que determina, por ejemplo, la posibilidad que tiene la entidad para
pagar a sus empleados y proveedores, satisfacer los pagos de intereses, reembolsar
los préstamos y proceder a distribuir ganancias a los propietarios. Los usuarios
pueden evaluar mejor esta capacidad para generar efectivo, si se les suministra
información que haga hincapié en la situación financiera, desempeño y cambios en la
posición financiera de la empresa.

La situación financiera de una entidad se ve afectada por los recursos económicos

que controla, por su estructura financiera, por su liquidez y solvencia, así como por la
capacidad para adaptarse a los cambios habidos en el medio ambiente en el que
opera. La información acerca de los recursos económicos controlados por la

32
empresa, y de su capacidad en el pasado para modificar tales recursos, es útil al
evaluar la posibilidad que la entidad tiene para generar efectivo y demás
equivalentes al efectivo en el futuro.

La información acerca del desempeño de una empresa, y en particular sobre su

rendimiento, se necesita para evaluar cambios potenciales en los recursos
económicos, que es probable puedan ser controlados en el futuro.

La información acerca de los cambios en la posición financiera de una entidad es

útil para evaluar sus actividades de financiación, inversión y operación, en el periodo
que cubre la información financiera.

La información acerca de la situación financiera es suministrada

fundamentalmente por el balance. La información acerca de la actividad es
suministrada fundamentalmente por el estado o cuenta de resultados. La información
acerca de los flujos de fondos es suministrada fundamentalmente por el estado de
cambios en la posición financiera.

Las partes que componen los estados financieros están interrelacionadas porque
reflejan diferentes aspectos de las mismas transacciones u otros sucesos acaecidos
a la empresa.

[Link]. Hipótesis fundamentales

a) Base de acumulación (o devengo)

Con el fin de cumplir sus objetivos, los estados financieros se preparan sobre la
base de la acumulación o del devengo contable. Según esta base, los efectos de las
transacciones y demás sucesos se reconocen cuando ocurren (y no cuando se
recibe o paga dinero u otro equivalente al efectivo), asimismo se registran en los
libros contables y se informa sobre ellos en los estados financieros de los periodos
con los cuales se relacionan.

33
 b) Negocio en marcha

Los estados financieros se preparan normalmente sobre la base de que la entidad

está en funcionamiento, y continuará sus actividades de operación dentro del futuro
previsible. Por lo tanto, se asume que la entidad no tiene intención ni necesidad de
liquidar o cortar de forma importante la escala de sus operaciones. Si tal intención o
necesidad existiera, los estados financieros pueden tener que prepararse sobre una
base diferente y, si así fuera, se revelará información sobre la base utilizada en ellos.

[Link]. Características cualitativas de los estados financieros

Las características cualitativas son los atributos que hacen útil, para los usuarios,
la información suministrada en los estados financieros. Las cuatro principales
características cualitativas son comprensibilidad, relevancia, fiabilidad y
comparabilidad.

a) Comprensibilidad

Una cualidad esencial de la información suministrada en los estados financieros

es que sea fácilmente comprensible para los usuarios.

b) Relevancia

Para ser útil, la información debe ser relevante de cara a las necesidades de toma
de decisiones por parte de los usuarios.

Frecuentemente, la información acerca de la situación financiera y la actividad

pasada se usa como base para predecir la situación financiera y la actividad futura,
así como otros asuntos en los que los usuarios están directamente interesados, tales
como pago de dividendos y salarios, evolución de las cotizaciones o capacidad de la
entidad para satisfacer las deudas al vencimiento.

c) Importancia de la materialidad

34
 La relevancia de la información está afectada por su naturaleza e importancia
relativa. En algunos casos la naturaleza de la información, por sí misma, es capaz de
determinar su relevancia.

d) Fiabilidad

Para ser útil, la información debe también ser fiable. La información posee la
cualidad de fiabilidad cuando está libre de error material y de sesgo o prejuicio, y los
usuarios pueden confiar en que es la imagen fiel de lo que pretende representar, o
de lo que puede esperarse razonablemente que represente.

e) Representación fiel

Para ser fiable, la información debe representar fielmente las transacciones y

demás sucesos que pretende representar, o que se puede esperar razonablemente
que represente. Así, por ejemplo, un balance debe representar fielmente las
transacciones y demás sucesos que han dado como resultado los activos, pasivos y
patrimonio neto de la entidad en la fecha de la información, siempre que cumplan los
requisitos para su reconocimiento.

f) La esencia sobre la forma

Si la información sirve para representar fielmente las transacciones y demás

sucesos que se pretenden reflejar, es necesario que éstos se contabilicen y
presenten de acuerdo con su esencia y realidad económica, y no meramente según
su forma legal.

g) Neutralidad

Para ser fiable, la información contenida en los estados financieros debe ser
neutral, es decir, libre de sesgo o prejuicio. Los estados financieros no son neutrales
si, por la manera de captar o presentar la información, influyen en la toma de una
decisión o en la formación de un juicio, a fin de conseguir un resultado o desenlace
predeterminado.

35
 h) Prudencia

No obstante, los elaboradores de estados financieros tienen que enfrentarse con

las incertidumbres que, inevitablemente, rodean muchos acontecimientos y
circunstancias, tales como la recuperabilidad de los saldos dudosos, la vida útil
probable de las propiedades, planta y equipo o el número de reclamaciones por
garantía postventa que pueda recibir la empresa.

i) Integridad

Para ser fiable, la información en los estados financieros debe ser completa dentro
de los límites de la importancia relativa y el costo. Una omisión puede causar que la
información sea falsa o equívoca, y por tanto no fiable y deficiente en términos de
relevancia.

[Link]. Restricciones a la información relevante y fiable

a) Oportunidad

Si hay un retraso indebido en la presentación de la información, ésta puede perder

su relevancia. La gerencia puede necesitar sopesar los méritos relativos de la
presentación a tiempo frente al suministro de información fiable. A menudo, para
suministrar información a tiempo es necesario presentarla antes de que todos los
aspectos de una determinada transacción u otro suceso sean conocidos,
perjudicando así su fiabilidad.

b) Equilibrio entre costo y beneficio

El equilibrio entre costo y beneficio es una profunda restricción, más que una
característica cualitativa. Los beneficios derivados de la información deben exceder a
los costos de suministrarla. Sin embargo, la evaluación de beneficios y costos es,
sustancialmente, un proceso de juicios de valor. Es más, los costos no son
soportados necesariamente por quienes disfrutan de los beneficios.

36
 c) Equilibrio entre características cualitativas

En la práctica, es a menudo necesario un equilibrio o contrapeso entre

características cualitativas. Generalmente, el objeto es conseguir un equilibrio
apropiado entre tales características, en orden a cumplir el objetivo de los estados
financieros. La importancia relativa de cada característica en cada caso particular es
una cuestión de juicio profesional.

[Link]. Elementos de los estados financieros

Los estados financieros reflejan los efectos financieros de las transacciones y

otros sucesos, agrupándolos en grandes categorías, de acuerdo con sus
características económicas. Estas grandes categorías son los elementos de los
estados financieros. Los elementos relacionados directamente con la medida de la
situación financiera en el balance son los activos, los pasivos y el patrimonio neto.
Los elementos directamente relacionados con la medida del desempeño en el estado
de resultados son los ingresos y los gastos. Puesto que el estado de cambios en la
posición financiera utiliza, generalmente, elementos del estado de resultados y
cambios en los elementos del balance, este Marco Conceptual no identifica ningún
elemento exclusivo de tal estado financiero.

[Link]. Situación financiera

Los elementos relacionados directamente con la medida de la situación financiera

son los activos, los pasivos y el patrimonio neto. Se definen como sigue:

Un activo es un recurso controlado por la entidad como resultado de sucesos

pasados, del que la entidad espera obtener, en el futuro, beneficios económicos.

Un pasivo es una obligación presente de la empresa, surgida a raíz de sucesos

pasados, al vencimiento de la cual, y para cancelarla, la entidad espera
desprenderse de recursos que incorporan beneficios económicos.

Patrimonio neto es la parte residual de los activos de la empresa, una vez

deducidos todos sus pasivos.

37
 Las definiciones de activo, pasivo y patrimonio neto, identifican sus características
esenciales, pero no pretenden especificar las condiciones a cumplir para que tales
elementos se reconozcan en el balance. Por tanto, ciertas partidas pueden caber en
las definiciones, pero no se reconocerán como activos o pasivos en el balance,
porque no cumplen las condiciones para su reconocimiento.

Los balances generales elaborados de acuerdo con las actuales Normas

Internacionales de Contabilidad, pueden incluir partidas que no satisfagan las
definiciones de activo o de pasivo, y que no se muestren tampoco en el patrimonio
neto. Sin embargo, las respectivas definiciones, serán la base para la revisión futura
de las actuales Normas Internacionales de Contabilidad, así como de la formulación
de otras posteriores.

[Link]. Desempeño

La cifra del resultado es a menudo usada como una medida del desempeño en la
actividad de la empresa, o bien es la base de otras evaluaciones, tales como el
rendimiento de las inversiones o las ganancias por acción. Los elementos
relacionados directamente con la medida del resultado son los ingresos y los gastos.
El reconocimiento y medida de los ingresos y gastos, y por tanto del resultado,
dependen en parte de los conceptos de capital y mantenimiento del capital usado por
la entidad al elaborar los estados financieros.

A continuación se definen los elementos denominados ingresos y gastos:

Ingresos son los incrementos en los beneficios económicos, producidos a lo largo

del periodo contable, en forma de entradas o incrementos de valor de los activos, o
bien como decrementos de las obligaciones, que dan como resultado aumentos del
patrimonio neto, y no están relacionados con las aportaciones de los propietarios a
este patrimonio.

Gastos son los decrementos en los beneficios económicos, producidos a lo largo

del periodo contable, en forma de salidas o disminuciones del valor de los activos, o
bien de nacimiento o aumento de los pasivos, que dan como resultado decrementos

38
en el patrimonio neto, y no están relacionados con las distribuciones realizadas a los
propietarios de este patrimonio.

Las definiciones de ingresos y gastos identifican sus características esenciales,

pero no pretenden especificar las condiciones a cumplir para que tales elementos se
reconozcan en el estado de resultados.

Los ingresos y gastos pueden presentarse de diferentes formas, en el estado de

resultados, al objeto de suministrar información relevante para la toma de decisiones
económicas. Por ejemplo, es una práctica común distinguir entre aquéllas partidas de
ingresos y gastos que surgen en el curso de las actividades ordinarias de la entidad y
aquellas otras que no.

[Link]. Ajustes por mantenimiento de capital

La revaluación o re expresión del valor de los activos y pasivos da lugar a

incrementos o decrementos en el patrimonio neto. Aún cuando tales incrementos y
decrementos cumplan la definición de ingresos y gastos, respectivamente, no son
incluidos, dentro del estado de resultados, bajo ciertos conceptos de mantenimiento
del capital.

[Link]. Medición de los elementos de los estados financieros

Medición es el proceso de determinación de los importes monetarios por los que

se reconocen y llevan contablemente los elementos de los estados financieros, para
su inclusión en el balance y el estado de resultados. Para realizarla es necesaria la
selección de una base o método particular de medición.

En los estados financieros se emplean diferentes bases de medición, con

diferentes grados y en distintas combinaciones entre ellas. Tales bases o métodos
son los siguientes:

a) Costo histórico. Los activos se registran por el importe de efectivo y otras

partidas pagadas, o por el valor razonable de la contrapartida entregada a
cambio en el momento de la adquisición. Los pasivos se registran por el valor del

39
 producto recibido a cambio de incurrir en la deuda o, en algunas circunstancias
(por ejemplo en el caso de los impuestos), por las cantidades de efectivo y otras
partidas equivalentes que se espera pagar para satisfacer la correspondiente
deuda, en el curso normal de la operación.

b) Costo corriente. Los activos se llevan contablemente por el importe de efectivo y

otras partidas equivalentes al efectivo, que debería pagarse si se adquiriese en la
actualidad el mismo activo u otro equivalente. Los pasivos se llevan
contablemente por el importe sin descontar de efectivo u otras partidas
equivalentes al efectivo que se precisaría para liquidar el pasivo en el momento
presente.

c) Valor realizable (o de liquidación). Los activos se llevan contablemente por el

importe de efectivo y otras partidas equivalentes al efectivo que podrían ser
obtenidos, en el momento presente, por la venta no forzada de los mismos. Los
pasivos se llevan por sus valores de liquidación, esto es, los importes sin
descontar de efectivo u otros equivalentes al efectivo, que se espera puedan
cancelar las deudas, en el curso normal de la operación.

d) Valor presente. Los activos se llevan contablemente al valor presente,

descontando las entradas netas de efectivo que se espera genere la partida en el
curso normal de la operación. Los pasivos se llevan por el valor presente,
descontando las salidas netas de efectivo que se espera necesitar para pagar las
deudas, en el curso normal de la operación.

La base o método de medición más comúnmente utilizado por las entidades, al

preparar sus estados financieros, es el costo histórico.

2.2.5. PROPIEDADES, PLANTA Y EQUIPO

El objetivo de la norma es prescribir el tratamiento contable de propiedades,

planta y equipo, de forma que los usuarios de los estados financieros puedan
conocer la información acerca de la inversión que la entidad tiene en sus
propiedades, planta y equipo, así como los cambios que se hayan producido en

40
dicha inversión. Los principales problemas que presenta el reconocimiento contable
de propiedades, planta y equipo son la contabilización de los activos, la
determinación de su importe en libros y los cargos por depreciación y pérdidas por
deterioro que deben reconocerse con relación a los mismos.

Esta Norma debe ser aplicada en la contabilización de los elementos de

propiedades, planta y equipo, salvo cuando otra Norma exija o permita un
tratamiento contable diferente.

Esta Norma no será de aplicación a:

a) Las propiedades, planta y equipo clasificadas como mantenidas para la venta.

b) Los activos biológicos relacionados con la actividad.

c) El reconocimiento y medición de activos para exploración y evaluación.

d) Las inversiones en derechos mineros, exploración y extracción de minerales,

petróleo, gas natural y otros recursos no renovables similares.

Otras Normas pueden obligar a reconocer un determinado elemento de

propiedades, planta y equipo de acuerdo con un tratamiento diferente al exigido en
esta Norma. [3]

[Link]. Definiciones

Los términos siguientes se usan, en la norma, con los significados que a

continuación se especifica:

Importe en libros, es el importe por el que se reconoce un activo, una vez

deducidas la depreciación acumulada y las pérdidas por deterioro del valor
acumuladas.

Costo, es el importe de efectivo o equivalentes al efectivo pagados, o bien el valor

razonable de la otra contraprestación entregada, para adquirir un activo en el
momento de su adquisición o construcción o, cuando fuere aplicable, el importe que

41
se atribuye a ese activo cuando se lo reconoce inicialmente de acuerdo con los
requerimientos específicos de otros NIIF.

Importe depreciable, es el costo de un activo, u otro importe que lo haya

sustituido, menos su valor residual.

Depreciación, es la distribución sistemática del importe depreciable de un activo a

lo largo de su vida útil.

Valor específico para una entidad, es el valor presente de los flujos de efectivo
que la entidad espera obtener del uso continuado de un activo y de su disposición al
término de su vida útil, o bien de los desembolsos que espera realizar para cancelar
un pasivo.

Valor razonable, es el importe por el cual un activo podría ser intercambiado entre
partes interesadas y debidamente informadas, en una transacción realizada en
condiciones de independencia mutua.

Una pérdida por deterioro, es el exceso del importe en libros de un activo sobre su
importe recuperable.

Las propiedades, planta y equipo, son los activos tangibles que:

Posee una entidad para su uso en la producción o suministro de bienes y

servicios, para arrendarlos a terceros o para propósitos administrativos.

Se esperan usar durante más de un periodo.

Importe recuperable, es el mayor entre el valor razonable menos los costos de

venta de un activo y su valor en uso.

El valor residual, de un activo es el importe estimado que la entidad podría

obtener actualmente por la disposición del elemento, después de deducir los costos
estimados por tal disposición, si el activo ya hubiera alcanzado la antigüedad y las
demás condiciones esperadas al término de su vida útil.

42
 Vida útil es, el periodo durante el cual se espera utilizar el activo por parte de la
entidad.

El número de unidades de producción o similares que se espera obtener del

mismo por parte de una entidad.

[Link]. Reconocimiento

Un elemento de propiedades, planta y equipo se reconocerá como activo si, y sólo si:

a) Sea probable que la entidad obtenga los beneficios económicos futuros

derivados del mismo.

b) El costo del elemento puede medirse con fiabilidad.

Las piezas de repuesto y el equipo auxiliar se registran habitualmente como

inventarios, y se reconocen en el resultado del periodo cuando se consumen. [4]

a) Costos iniciales

Algunos elementos de propiedades, planta y equipo pueden ser adquiridos por

razones de seguridad o de índole medioambiental. Aunque la adquisición de ese tipo
de propiedades, planta y equipo no incremente los beneficios económicos que
proporcionan las partidas de propiedades, planta y equipo existentes, puede ser
necesaria para que la entidad logre obtener los beneficios económicos derivados del
resto de los activos. Dichos elementos de propiedades, planta y equipo cumplen las
condiciones para su reconocimiento como activos porque permiten a la entidad
obtener beneficios económicos adicionales del resto de sus activos, respecto a los
que hubiera obtenido si no los hubiera adquirido.

b) Costos posteriores

La entidad no reconocerá, en el importe en libros de un elemento de propiedades,

planta y equipo, los costos derivados del mantenimiento diario del elemento. Tales
costos se reconocerán en el resultado cuando se incurra en ellos. Los costos del
mantenimiento diario son principalmente los costos de mano de obra y los

43
consumibles, que pueden incluir el costo de pequeños componentes. El objetivo de
estos desembolsos se describe a menudo como “reparaciones y conservación” del
elemento de propiedades, planta y equipo.

[Link]. Medición en el momento del reconocimiento

Un elemento de propiedades, planta y equipo, que cumpla las condiciones para

ser reconocido como un activo, se medirá por su costo.

[Link]. Componentes del costo

El costo de los elementos de propiedades, planta y equipo comprende:

a) Su precio de adquisición, incluidos los aranceles de importación y los impuestos

indirectos no recuperables que recaigan sobre la adquisición, después de deducir
cualquier descuento o rebaja del precio.

b) Todos los costos directamente atribuibles a la ubicación del activo en el lugar y

en las condiciones necesarias para que pueda operar de la forma prevista por la
gerencia.

c) La estimación inicial de los costos de desmantelamiento y retiro del elemento, así

como la rehabilitación del lugar sobre el que se asienta, la obligación en que
incurre una entidad cuando adquiere el elemento o como consecuencia de haber
utilizado dicho elemento durante un determinado periodo, con propósitos
distintos al de producción de inventarios durante tal periodo.

[Link]. Medición posterior al reconocimiento

La entidad elegirá como política contable el modelo de revaluación, y aplicará esa

política a todos los elementos que compongan una clase de propiedades, planta y
equipo.

44
 a) Modelo de costo

Con posterioridad a su reconocimiento como activo, un elemento de propiedades,

planta y equipo se registrará por su costo menos la depreciación acumulada y el
importe acumulado de las pérdidas por deterioro del valor.

b) Modelo revaluación

Con posterioridad a su reconocimiento como activo, un elemento de propiedades,

planta y equipo cuyo valor razonable pueda medirse con fiabilidad, se contabilizará
por su valor revaluado, que es su valor razonable, en el momento de la revaluación,
menos la depreciación acumulada y el importe acumulado de las pérdidas por
deterioro de valor que haya sufrido. Las revaluaciones se harán con suficiente
regularidad, para asegurar que el importe en libros, en todo momento, no difiera
significativamente del que podría determinarse utilizando el valor razonable al final
del periodo sobre el que se informa.

Cuando se revalúe un elemento de propiedades, planta y equipo, la depreciación

acumulada en la fecha de la revaluación puede ser tratada de cualquiera de las
siguientes maneras:

• Reexpresada proporcionalmente al cambio en el importe en libros bruto del

activo, de manera que el importe en libros del mismo después de la
revaluación sea igual a su importe revaluado. Este método se utiliza a menudo
cuando se revalúa el activo por medio de la aplicación de un índice para
determinar su costo de reposición depreciado.

• Eliminada contra el importe en libros bruto del activo, de manera que lo que se
reexpresa es el importe neto resultante, hasta alcanzar el importe revaluado
del activo. Este método se utiliza habitualmente en edificios.

La cuantía del ajuste en la depreciación acumulada, que surge de la reexpresión o

eliminación anterior, forma parte del incremento o disminución del importe en
libros del activo, que se contabilizará.

45
Si se revalúa un elemento de propiedades, planta y equipo, se revaluarán también
todos los elementos que pertenezcan a la misma clase de activos.

Una clase de elementos pertenecientes a propiedades, planta y equipo es un

conjunto de activos de similar naturaleza y uso en las operaciones de una
entidad. Los siguientes son ejemplos de clases separadas:

• Terrenos;

• Terrenos y edificios;

• Maquinaria;

• Buques;

• Aeronaves;

• Vehículos de motor;

• Mobiliario y enseres y

• Equipo de oficina.
Los elementos pertenecientes a una clase, de las que componen las propiedades,
planta y equipo, se revaluarán simultáneamente con el fin de evitar revaluaciones
selectivas, y para evitar la inclusión en los estados financieros de partidas que serían
una mezcla de costos y valores referidos a diferentes fechas. No obstante, cada
clase de activos puede ser revaluada de forma periódica, siempre que la revaluación
de esa clase se realice en un intervalo corto de tiempo y que los valores se
mantengan constantemente actualizados.

Si se incrementa el importe en libros de un activo como consecuencia de una

revaluación, este aumento se reconocerá directamente en otro resultado integral y se
acumulará en el patrimonio, bajo el encabezamiento de superávit de revaluación. Sin
embargo, el incremento se reconocerá en el resultado del periodo en la medida en
que sea una reversión de un decremento por una revaluación del mismo activo
reconocido anteriormente en el resultado del periodo.

Los efectos de la revaluación de propiedades, planta y equipo, sobre los

impuestos sobre las ganancias, si los hubiere, se contabilizarán y revelarán.

46
[Link]. Depreciación

Se depreciará de forma separada cada parte de un elemento de propiedades,

planta y equipo que tenga un costo significativo con relación al costo total del
elemento.

Una entidad distribuirá el importe inicialmente reconocido con respecto a una

partida de propiedades, planta y equipo entre sus partes significativas y depreciará
de forma separada cada una de estas partes. Por ejemplo, podría ser adecuado
depreciar por separado la estructura y los motores de un avión, tanto si se tiene en
propiedad como si se tiene en arrendamiento financiero. De forma análoga, si una
entidad adquiere propiedades, planta y equipo sujeto a un arrendamiento operativo
en el que es el arrendador, puede ser adecuado depreciar por separado los importes
reflejados en el costo de esa partida que sean atribuibles a las condiciones
favorables o desfavorables del arrendamiento con respecto a las condiciones de
mercado.

La entidad podrá elegir por depreciar de forma separada las partes que
compongan un elemento y no tengan un costo significativo con relación al costo total
del mismo.

El cargo por depreciación de cada periodo se reconocerá en el resultado del

periodo, salvo que se haya incluido en el importe en libros de otro activo.

El cargo por depreciación de un periodo se reconocerá habitualmente en el

resultado del mismo. Sin embargo, en ocasiones los beneficios económicos futuros
incorporados a un activo se incorporan a la producción de otros activos. En este
caso, el cargo por depreciación formará parte del costo del otro activo y se incluirá en
su importe en libros. Por ejemplo, la depreciación de una instalación y equipo de
manufactura se incluirá en los costos de transformación de los inventarios. De forma
similar, la depreciación de las propiedades, planta y equipo utilizada para actividades
de desarrollo podrá incluirse en el costo de un activo intangible reconocido de
acuerdo con la NIC 38 Activos Intangibles.

47
[Link]. Importe depreciable y periodo de depreciación

El importe depreciable de un activo se distribuirá de forma sistemática a lo largo

de su vida útil.

El valor residual y la vida útil de un activo se revisarán, como mínimo, al término

de cada periodo anual y, si las expectativas difirieren de las estimaciones previas, los
cambios se contabilizarán como un cambio en una estimación contable, de acuerdo
con la NIC 8 Políticas Contables, Cambios en las Estimaciones Contables y Errores.

La depreciación se contabilizará incluso si el valor razonable del activo excede a

su importe en libros, siempre y cuando el valor residual del activo no supere al
importe en libros del mismo. Las operaciones de reparación y mantenimiento de un
activo no evitan realizar la depreciación.

El importe depreciable de un activo se determina después de deducir su valor

residual. En la práctica, el valor residual de un activo a menudo es insignificante, y
por tanto irrelevante en el cálculo del importe depreciable.

El valor residual de un activo podría aumentar hasta igualar o superar el importe

en libros del activo. Si esto sucediese, el cargo por depreciación del activo será nulo,
a menos que y hasta que ese valor residual disminuya posteriormente y se haga
menor que el importe en libros del activo.

Los beneficios económicos futuros incorporados a un activo, se consumen, por

parte de la entidad, principalmente a través de su utilización. No obstante, otros
factores, tales como la obsolescencia técnica o comercial y el deterioro natural
producido por la falta de utilización del bien, producen a menudo una disminución en
la cuantía de los beneficios económicos que cabría esperar de la utilización del
activo. Consecuentemente, para determinar la vida útil del elemento de propiedades,
planta y equipo, se tendrán en cuenta todos los factores siguientes:

a) La utilización prevista del activo. El uso se evalúa por referencia a la

capacidad o al producto físico que se espere del mismo.

48
 b) El desgaste físico esperado, que dependerá de factores operativos tales como
el número de turnos de trabajo en los que se utilizará el activo, el programa de
reparaciones y mantenimiento, y el grado de cuidado y conservación mientras
el activo no está siendo utilizado.

c) La obsolescencia técnica o comercial procedente de los cambios o mejoras en

la producción, o de los cambios en la demanda del mercado de los productos
o servicios que se obtienen con el activo.

d) Los límites legales o restricciones similares sobre el uso del activo, tales como
las fechas de caducidad de los contratos de arrendamiento relacionados.

La vida útil de un activo se definirá en términos de la utilidad que se espere que

aporte a la entidad. La política de gestión de activos llevada a cabo por la entidad
podría implicar la disposición de los activos después de un periodo específico de
utilización, o tras haber consumido una cierta proporción de los beneficios
económicos incorporados a los mismos.

Los terrenos y los edificios son activos separados, y se contabilizarán por

separado, incluso si han sido adquiridos de forma conjunta. Con algunas
excepciones, tales como minas, canteras y vertederos, los terrenos tienen una vida
ilimitada y por tanto no se deprecian. Los edificios tienen una vida limitada y, por
tanto, son activos depreciables. Un incremento en el valor de los terrenos en los que
se asienta un edificio no afectará a la determinación del importe depreciable del
edificio.

Si el costo de un terreno incluye los costos de desmantelamiento, traslado y

rehabilitación, la porción que corresponda a la rehabilitación del terreno se
depreciará a lo largo del periodo en el que se obtengan los beneficios por haber
incurrido en esos costos.

49
[Link]. Método de depreciación

El método de depreciación utilizado reflejará el patrón con arreglo al cual se

espera que sean consumidos, por parte de la entidad, los beneficios económicos
futuros del activo.

El método de depreciación aplicado a un activo se revisará, como mínimo, al

término de cada periodo anual y, si hubiera habido un cambio significativo en el
patrón esperado de consumo de los beneficios económicos futuros incorporados al
activo, se cambiará para reflejar el nuevo patrón. Dicho cambio se contabilizará como
un cambio en una estimación contable.

Pueden utilizarse diversos métodos de depreciación para distribuir el importe

depreciable de un activo de forma sistemática a lo largo de su vida útil. Entre los
mismos se incluyen el método lineal, el método de depreciación decreciente y el
método de las unidades de producción. La depreciación lineal dará lugar a un cargo
constante a lo largo de la vida útil del activo, siempre que su valor residual no
cambie. El método de depreciación decreciente en función del saldo del elemento
dará lugar a un cargo que irá disminuyendo a lo largo de su vida útil. El método de
las unidades de producción dará lugar a un cargo basado en la utilización o
producción esperada. La entidad elegirá el método que más fielmente refleje el
patrón esperado de consumo de los beneficios económicos futuros incorporados al
activo. Dicho método se aplicará uniformemente en todos los periodos, a menos que
se haya producido un cambio en el patrón esperado de consumo de dichos
beneficios económicos futuros.

[Link]. Deterioro de valor

Para determinar si un elemento de propiedades, planta y equipo ha visto

deteriorado su valor,. En dicha Norma se explica cómo debe proceder la entidad para
la revisión del importe en libros de sus activos, cómo ha de determinar el importe
recuperable de un activo y cuándo debe proceder a reconocer, o en su caso, revertir,
las pérdidas por deterioro del valor.

50
[Link]. Compensación por deterioro de valor

Las compensaciones procedentes de terceros, por elementos de propiedades,

planta y equipo que hayan experimentado un deterioro del valor, se hayan perdido o
se hayan abandonado, se incluirán en el resultado del periodo cuando tales
compensaciones sean exigibles.

El deterioro del valor o las pérdidas de los elementos de propiedades, planta y

equipo son hechos separables de las reclamaciones de pagos o compensaciones de
terceros, así como de cualquier compra posterior o construcción de activos que
reemplacen a los citados elementos, y por ello se contabilizarán de forma separada,
procediendo de la manera siguiente:

a) El deterioro del valor de los elementos de propiedades, planta y equipo se

reconocerá según la NIC 36;

b) La baja en cuentas de los elementos de propiedades, planta y equipo retirados

o de los que se haya dispuesto por otra vía se contabilizará según lo
establecido en esta Norma;

c) La compensación de terceros por elementos de propiedades, planta y equipo

que hubieran visto deteriorado su valor, se hubieran perdido o se hubieran
abandonado se incluirá en la determinación del resultado del periodo, en el
momento en que la compensación sea exigible; y

d) El costo de los elementos de propiedades, planta y equipo rehabilitados,

adquiridos o construidos para reemplazar los perdidos o deteriorados se
determinará de acuerdo con esta Norma.

[Link]. Bajas en cuentas

El importe en libros de un elemento de propiedades, planta y equipo se dará de

baja en cuentas:

a) Por su disposición.

51
 b) Cuando no se espere obtener beneficios económicos futuros por su uso o
disposición.

La pérdida o ganancia surgida al dar de baja un elemento de propiedades, planta

y equipo se incluirá en el resultado del periodo cuando la partida sea dada de baja en
cuentas. Las ganancias no se clasificarán como ingresos de actividades ordinarias.

A Sin embargo, una entidad que, en el curso de sus actividades ordinarias, venda
rutinariamente elementos de propiedades, planta y equipo que se mantenían para
arrendar a terceros, transferirá esos activos a los inventarios por su importe en libros
cuando dejen de ser arrendados y se clasifiquen como mantenidos para la venta. El
importe obtenido por la venta de esos activos se reconocerá como ingreso de
actividades ordinarias.

La disposición de un elemento de propiedades, planta y equipo puede llevarse a

cabo de diversas maneras (por ejemplo mediante la venta, realizando sobre la misma
un contrato de arrendamiento financiero o por donación). Para determinar la fecha en
que se ha dispuesto de una partida, una entidad aplicará los criterios establecidos en
la NIC 18 para el reconocimiento de ingresos de actividades ordinarias por ventas de
bienes.

La entidad reconociera dentro del importe en libros de un elemento de

propiedades, planta y equipo el costo derivado de la sustitución de una parte del
elemento, entonces dará de baja el importe en libros de la parte sustituida, con
independencia de si esta parte se hubiera amortizado de forma separada. Si no fuera
practicable para la entidad determinar el importe en libros del elemento sustituido,
podrá utilizar el costo de la sustitución como indicativo de cuál era el costo del
elemento sustituido en el momento en el que fue adquirido o construido.

La pérdida o ganancia derivada de la baja en cuentas de un elemento de

propiedades, planta y equipo, se determinará como la diferencia entre el importe neto
que, en su caso, se obtenga por la disposición y el importe en libros del elemento.

52
 La contrapartida a cobrar por la disposición de un elemento de propiedades,
planta y equipo, se reconocerá inicialmente por su valor razonable. Si se aplazase el
pago a recibir por el elemento, la contrapartida recibida se reconocerá inicialmente al
precio equivalente de contado. La diferencia entre el importe nominal de la
contrapartida y el precio equivalente de contado se reconocerá como un ingreso por
intereses, de forma que refleje el rendimiento efectivo derivado de la cuenta por
cobrar.

[Link]. Información a relevar

En los estados financieros se revelará, con respecto a cada una de las clases de
propiedades, planta y equipo, la siguiente información:

a) Las bases de medición utilizadas para determinar el importe en libros bruto.

b) Los métodos de depreciación utilizados.

c) Las vidas útiles o las tasas de depreciación utilizadas.

d) El importe en libros bruto y la depreciación acumulada (junto con el importe

acumulado de las pérdidas por deterioro de valor), tanto al principio como al
final de cada periodo.

Una conciliación entre los valores en libros al principio y al final del periodo,
mostrando:

a) Las adiciones;

b) Los activos clasificados como mantenidos para la venta o incluidos en un

grupo de activos para su disposición que haya sido clasificado como
mantenido para la venta, así como otras disposiciones;

c) Las adquisiciones realizadas mediante combinaciones de negocios;

d) Los incrementos o disminuciones, resultantes de las revaluaciones, así como

las pérdidas por deterioro del valor reconocidas, o revertidas en otro resultado
integral.

53
 e) Las pérdidas por deterioro del valor reconocidas en el resultado del periodo.

f) Las pérdidas por deterioro de valor que hayan revertido, y hayan sido
reconocidas en el resultado del periodo.

g) La depreciación.

h) Las diferencias netas de cambio surgidas en la conversión de estados

financieros desde la moneda funcional a una moneda de presentación
diferente, incluyendo también las diferencias de conversión de un operación
en el extranjero a la moneda de presentación de la entidad que informa.

i) Otros cambios.

En los estados financieros se revelará también:

a) La existencia y los importes correspondientes a las restricciones de titularidad,

así como las propiedades, planta y equipo que están afectos como garantía al
cumplimiento de obligaciones.

b) El importe de los desembolsos reconocidos en el importe en libros, en los

casos de elementos de propiedades, planta y equipo en curso de
construcción.

c) El importe de los compromisos de adquisición de propiedades, planta y

equipo.

d) Si no se ha revelado de forma separada en el estado del resultado integral, el

importe de compensaciones de terceros que se incluyen en el resultado del
periodo por elementos de propiedades, planta y equipo cuyo valor se hubiera
deteriorado, perdido o entregado.

La entidad revelará información sobre las partidas de propiedades, planta y equipo

que hayan sufrido pérdidas por deterioro del valor.

54
2.2.6. ACTIVOS INTANGIBLES

[Link]. Definición

Con frecuencia, las entidades emplean recursos, o incurren en pasivos, para la

adquisición, desarrollo, mantenimiento o mejora de recursos intangibles tales como el
conocimiento científico o tecnológico, el diseño e implementación de nuevos
procesos o nuevos sistemas, las licencias o concesiones, la propiedad intelectual, los
conocimientos comerciales o marcas (incluyendo denominaciones comerciales y
derechos editoriales).

[Link]. Identificabilidad

La definición de un activo intangible requiere que éste sea identificable para

poderlo distinguir de la plusvalía. La plusvalía reconocida en una combinación de
negocios es un activo que representa los beneficios económicos futuros que surgen
de otros activos adquiridos en una combinación de negocios que no están
identificados individualmente y reconocidos de forma separada.

Un activo es identificable si:

a) Es separable, es decir, es susceptible de ser separado o escindido de la entidad

y vendido, transferido, dado en explotación, arrendado o intercambiado, ya sea
individualmente o junto con un contrato, activo identificable o pasivo con los que
guarde relación, independientemente de que la entidad tenga la intención de
llevar a cabo la separación; o

b) Surge de derechos contractuales o de otros derechos legales, con independencia

de que esos derechos sean transferibles o separables de la entidad o de otros
derechos u obligaciones.

[Link]. Beneficios económicos futuros

Entre los beneficios económicos futuros procedentes de un activo intangible se

incluyen los ingresos de actividades ordinarias procedentes de la venta de productos

55
o servicios, los ahorros de costo y otros rendimientos diferentes que se deriven del
uso del activo por parte de la entidad.

[Link]. Reconocimientos y medición

El reconocimiento de una partida como activo intangible exige, para la entidad,

demostrar que el elemento en cuestión cumple:

a) La definición de activo intangible.

b) Los criterios para su reconocimiento

Un activo intangible se reconocerá si, y sólo si:

a) Es probable que los beneficios económicos futuros que se han atribuido al mismo
fluyan a la entidad.

b) El costo del activo puede ser medido de forma fiable.

Este requerimiento se aplicará a los costos soportados inicialmente, para adquirir

o generar internamente un activo intangible, y para aquéllos en los que se haya
incurrido posteriormente para añadir, sustituir partes del mismo o realizar su
mantenimiento.

[Link]. Vida útil

Una entidad evaluará si la vida útil de un activo intangible es finita o indefinida y, si

es finita, evaluará la duración o el número de unidades productivas u otras similares
que constituyan su vida útil. La entidad considerará que un activo intangible tiene una
vida útil indefinida cuando, sobre la base de un análisis de todos los factores
relevantes, no exista un límite previsible al periodo a lo largo del cual el activo se
espera que el activo genere entradas de flujos netos de efectivo para la entidad.

La contabilización de un activo intangible se basa en su vida útil. Un activo

intangible con una vida útil finita se amortiza, mientras que un activo intangible con
una vida útil indefinida no se amortiza.

56
 Para determinar la vida útil de un activo intangible, es preciso considerar muchos
factores, entre los que figuran:

a) La utilización esperada del activo por parte de la entidad, así como si el elemento
podría ser gestionado de forma eficiente por otro equipo directivo distinto;

b) Los ciclos típicos de vida del producto, así como la información pública disponible
sobre estimaciones de la vida útil, para tipos similares de activos que tengan una
utilización parecida;

c) La incidencia de la obsolescencia técnica, tecnológica, comercial o de otro tipo;

d) La estabilidad de la industria en la que opere el activo, así como los cambios en

la demanda de mercado para los productos o servicios fabricados con el activo
en cuestión;

e) Las actuaciones esperadas de los competidores, ya sean actuales o potenciales;

f) El nivel de los desembolsos por mantenimiento necesarios para conseguir los

beneficios económicos esperados del activo, así como la capacidad y voluntad
de la entidad para alcanzar ese nivel;

g) El periodo en que se controle el activo, si estuviera limitado, así como los límites,
ya sean legales o de otro tipo, sobre el uso del elemento, tales como las fechas
de caducidad de los arrendamientos relacionados con él; y

h) Si la vida útil del activo depende de las vidas útiles de otros activos poseídos por
la entidad.

[Link]. Periodo y método de amortización

El importe depreciable de un activo intangible con una vida útil finita, se distribuirá
sobre una base sistemática a lo largo de su vida útil. La amortización comenzará
cuando el activo esté disponible para su utilización, es decir, cuando se encuentre en
la ubicación y condiciones necesarias para que pueda operar de la forma prevista por
la gerencia. La amortización cesará en la fecha más temprana entre aquélla en que

57
el activo se clasifique como mantenido para la venta (o incluido en un grupo de
activos para su disposición que se haya clasificado como mantenido para la venta), y
la fecha en que se produzca la baja en cuentas del mismo. El método de
amortización utilizado reflejará el patrón de consumo esperado, por parte de la
entidad, de los beneficios económicos futuros derivados del activo. Si este patrón no
pudiera ser determinado de forma fiable, se adoptará el método lineal de
amortización. El cargo por amortización de cada período se reconocerá en el
resultado del periodo, a menos que otra Norma permita o exija que dicho importe se
incluya en el importe en libros de otro activo.

[Link]. Activos Intangibles con vida útil indefinidas

Los activos intangibles con una vida útil indefinida no se amortizarán.

La entidad comprobará si un activo intangible con una vida útil indefinida ha

experimentado una pérdida por deterioro del valor comparando su importe
recuperable con su importe en libros

a) Anualmente.

b) En cualquier momento en el que exista un indicio de que el activo puede haber

deteriorado su valor.

58
 CAPÍTULO III
APLICACIÓN DE EXTREME PROGRAMMING EN EL DISEÑO E
IMPLEMENTACIÓN DEL SISTEMA (SCANIIF)
3.1. XP Y WEBML

La aplicación del lenguaje de modelado web (WebML) en la metodología Extreme

Programming (XP) se puede observar en la siguiente figura:

Figura 3.1. XP y WEBML

[Fuente: Elavoración Propia]

59
3.2. EXPLORACION

El objetivo de la fase de Exploración es definir las historias de usuarios, las cuales

son realizadas a partir de reuniones llevadas a cabo con el personal de la institución
involucrado en el desarrollo del sistema SCANIIF. Asimismo, se definen las
herramientas y la plataforma tecnológica con la que se trabajará.

3.2.1. HISTORIAS DE USUARIO

Como resultado de la fase de Exploración se definieron las siguientes historias de

usuario:

Numero Planteamiento de las Historias de Usuario

1 Introducción de Usuarios al Sistema
2 Apertura de una Gestión
3 Introducción del Plan de Cuentas
4 Introducción de los Tipos de Cambio
5 Introducción de las UFV's
6 Introducción de Comprobante
7 Modificación de Comprobante
8 Eliminación de Comprobante
9 Pago de Sueldos y Salarios
10 Generación de Reportes
11 Re-expresiones y actualizaciones
12 Depreciaciones de Activos Fijos
13 Amortizaciones de Activos Intangibles
14 Cierre de Gestión
15 Obtención de Copias de Respaldo (Backups)
16 Resumen de la contabilización
Tabla 3.1. Planteamiento de Historias de Usuario
[Fuente: Elavoración Propia]

60
 Dentro del formulario de historias de usuarios, existe un campo específico de
nombre Riesgo de Desarrollo, dicho término está asociado con la dificultad que
representa el desarrollo de esa historia.

3.2.2. HERRAMIENTAS

Para el desarrollo del presente proyecto se utilizarán las siguientes herramientas:

• c#.NET.

• SQL SERVER.

La elección de las herramientas mencionadas fue realizada tomando en cuenta

los siguientes aspectos.

• Por políticas de seguridad y por el volumen de datos la Universidad Pública de

El Alto utiliza como gestor de base de datos SQL SERVER.

• La Universidad cuenta con equipos recomendables para la utilización de estos

sistemas.

3.3. PLANIFICACIÓN DE LAS ENTREGAS

En esta fase del proyecto se establecerán prioridades para cada una de las
historias, así como la estimación del esfuerzo necesario para el cumplimiento de
cada una de ellas, con el fin de determinar el cronograma de entregas.

La estimación del esfuerzo asociado a la implementación de las historias de

usuario se establece utilizando como medida el punto. Un punto, equivale a una
semana ideal de programación. Las historias de usuario generalmente valen de 1 a 3
puntos.

La planificación de las entregas fue realizada tomando en cuenta el tiempo y el

alcance de la entrega de las historias de usuario. Como se muestra en la Tabla 12.1
se llegó a definir las iteraciones y las historias de usuarios a ser entregadas en éstas:

61
 Numero Historias de Usuario Iteración designada
1 Gestión de usuarios 1
2 Apertura de una Gestión 1
3 Introducción del Plan de Cuentas 1
4 Introducción de los Tipos de Cambio 1
5 Introducción de las UFV's 1
6 Introducción de Comprobante 2
7 Modificación de Conprobante 2
8 Eliminación de Comprobante 2
9 Pago de Sueldos y Salarios 2
10 Generación de Reportes 3
11 Reexpreciones y actualizaciones 3
12 Depreciaciones de Activos Fijos 3
13 Amortizaciones de Activos Intangibles 3
14 Presentación de Estados Financieros 4
15 Cierre de Gestión 4
16 Obtencion de Copias de Respaldo (Backups) 4
17 Resumen de la contabilización 4
Tabla 3.2. Numero de Iteraciones de Historias de Usuario
[Fuente: Elavoración Propia]

Partiendo de las historias de usuario anteriores se realiza una planificación en

cuatro iteraciones basados en el tiempo y procurando agrupar la funcionalidad
relacionada en la misma iteración.

En las figuras siguientes se pueden observar el tiempo estimado de entrega. Sin

embargo, las fechas pueden variar de acuerdo a nuevos requerimientos que existan
por parte de los usuarios.

62
Figura 3.2. Planificación de Entregas (Iteración 1)
[Fuente: Elavoración Propia]

Figura 3.3. Planificación de Entregas (Iteración 2)

[Fuente: Elavoración Propia]

63
Figura 3.4. Planificación de Entregas (Iteración 3)
[Fuente: Elavoración Propia]

Figura 3.5. Planificación de Entregas (Iteración 4)

[Fuente: Elavoración Propia]

64
 En resumen el tiempo estimado para el desarrollo del sistema se muestra en el
siguiente cuadro:

2da sem 4ta sem 2ta sem 4ta sem

Historias de Usuario
octubre octubre noviembre noviembre

Gestión de usuarios X

Apertura de una Gestión X

Introducción del Plan de Cuentas X

Introducción de los Tipos de Cambio X

Introducción de las UFV's X

Introducción de Comprobante X

Modificación de Comprobante X

Eliminación de Comprobante X

Pago de Sueldos y Salarios X

Generación de Reportes X

Reexpreciones y actualizaciones X

Depreciaciones de Activos Fijos X

Amortizaciones de Activos Intangibles X

Presentación de Estados Financieros X

Cierre de Gestión X
Obtención de Copias de Respaldo
X
(Backups)
Resumen de la contabilización X
Tabla 3.3. Planificación de Entregas (Resumen)
[Fuente: Elavoración Propia]

3.3.1. ESTIMACIONES DE ESFUERZOS

Las estimaciones de esfuerzo se realizaron sobre los releases relacionadas con

las historias de usuarios.

65
 a) Gestión de usuarios

En la Tabla 3.4. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Gestión de usuarios 2
Asignación de permisos 1
Tabla 3.4. Estimación de esfuerzos – Gestión de usuarios
[Fuente: Elavoración Propia]

b) Apertura de una Gestión

En la Tabla 3.5. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Apertura de una gestión 1
Tabla 3.5. Estimación de esfuerzos – Apertura de gestión
[Fuente: Elavoración Propia]

c) Introducción del Plan de Cuentas

En la Tabla 3.6. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Introducción de plan de cuentas 1.5
Codificación del plan de cuentas 1.5
Tabla 3.6. Estimación de esfuerzos – Introducción de plan de cuentas
[Fuente: Elavoración Propia]

66
 d) Introducción de los Tipos de Cambio

En la Tabla 3.7. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Introducción de Tipos de cambio 2
Validación de tipos de cambio 1
Tabla 3.7. Estimación de esfuerzos – Introducción de tipos de cambio
[Fuente: Elavoración Propia]

e) Introducción de las UFV's

En la Tabla 3.8. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Introducción de UFV`s 2
Validación de UFV´s 1
Tabla 3.8. Estimación de esfuerzos – Introducción de UFV`s
[Fuente: Elavoración Propia]

f) Introducción de Comprobante

En la Tabla 3.9. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Introducción de Comprobante 1
Comprobación doble partida 1
Tabla 3.9. Estimación de esfuerzos – Introducción de Comprobante
[Fuente: Elavoración Propia]

67
 g) Modificación de Comprobante

En la Tabla 3.10. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Modificación de Comprobante 1
Reorganización de comprobantes 1
Tabla 3.10. Estimación de esfuerzos – Modificación de comprobantes
[Fuente: Elavoración Propia]

h) Eliminación de Comprobante

En la Tabla 3.11. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Eliminación de comprobante 2
Renuneración 1
Tabla 3.11. Estimación de esfuerzos – Eliminación de comprobante
[Fuente: Elavoración Propia]

i) Pago de Sueldos y Salarios

En la Tabla 3.12. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Pago de Sueldos y Salarios 2
Elaboración de reportes de planillas 1
Tabla 3.12. Estimación de esfuerzos – Pago de Sueldos y Salarios
[Fuente: Elavoración Propia]

68
 j) Generación de Reportes

En la Tabla 3.13. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Generación de reportes 2
Tabla 3.13. Estimación de esfuerzos – Generación de reportes
[Fuente: Elavoración Propia]

k) Re-expresiones y actualizaciones

En la Tabla 3.14. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Reexpresiones y Actualizaciones 1
Generación de asientos de ajuste 1
Tabla 3.14. Estimación de esfuerzos – Reexpresiones y actualizaciones
[Fuente: Elavoración Propia]

l) Depreciación de Activos Fijos

En la Tabla 3.15. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Depreciación de Activos Fijos 1
Generación de asientos de ajuste 1
Tabla 3.15. Estimación de esfuerzos – Depreciación de Activos Fijos
[Fuente: Elavoración Propia]

69
 m) Amortización de Activos Intangibles

En la Tabla 3.16. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Amortización de Activos Intangibles 1
Generación de asientos de ajuste 1
Tabla 3.16. Estimación de esfuerzos – Amortización de Activos Intangibles
[Fuente: Elavoración Propia]

n) Presentación de Estados Financieros

En la Tabla 3.17. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Presentación de Estados Financieros 2
Tabla 3.17. Estimación de esfuerzos – Presentación de Estados Financieros
[Fuente: Elavoración Propia]

o) Cierre de Gestión

En la Tabla 3.18. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Cierre de gestión 2
Generación de asientos de cierre 1
Tabla 3.18. Estimación de esfuerzos – Cierre de gestión
[Fuente: Elavoración Propia]

70
 p) Obtención de Copias de Respaldo (Backups)

En la Tabla 3.19. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Obtención de Copias de respaldo 1
Tabla 3.19. Estimación de esfuerzos – Obtención de copias de respaldo
[Fuente: Elavoración Propia]

q) Resumen de la contabilización

En la Tabla 3.20. se muestra la estimación de esfuerzo correspondiente a este

punto.

Historias de Usuario Punto (esfuerzo)

Resumen de la contabilización 1
Tabla 3.20. Estimación de esfuerzos – Resumen de la contabilización
[Fuente: Elavoración Propia]

3.3.2. Primera Iteración:

En esta primera iteración se creará un prototipo con el que se comprobará la

adecuación de la tecnología escogida y se intentará crear la mayor parte de la base
de la arquitectura del sistema.

Principalmente se entregarán los procedimientos para importar la información de

las bases de datos proporcionadas por los clientes. Asimismo, se desarrollarán los
procedimientos necesarios para realizar la Gestión de los parámetros para los datos
iniciales del sistema. No se implementará muy extensa, tan sólo un mínimo para
tener cuanto antes una versión demo para poder mostrar los avances en el desarrollo
del proyecto a los usuarios finales.

71
 Con relación al tiempo estimado para el desarrollo de las historias de usuario,
existe una demora debida principalmente a la curva de aprendizaje de la tecnología
usada.

Historias de Usuario Punto (Esfuerzo)

Gestión de usuarios 2
Apertura de una Gestión 1
Introducción del Plan de Cuentas 1,5
Introducción de los Tipos de Cambio 2
Introducción de las UFV's 2
Estimación inicial 3
Real 4
Tabla 3.21. Historias de Usuario – Primera Iteración
[Fuente: Elavoración Propia]

3.3.3. Segunda Iteración:

En esta iteración se pretende entregar un programa con las funcionalidades

propias del cliente principal así como de los clientes de temporada. En esta fase
también de se pretende comenzar con las funcionalidades básicas relacionadas a la
introducción, modificación y eliminación de los comprobantes de ingreso, egreso y/o
traspaso.

Cumpliendo de esta manera los requerimientos expresados en las historias de

usuarios. En la segunda iteración, se tiene un mayor conocimiento de las
herramientas utilizadas. Sin embargo, algunas historias de usuarios fueron
modificadas luego de mostrar las pantallas iniciales del prototipo y expresar la forma
de trabajo que se tendrá, las cuales se detallan en las historias respectivas.

Con relación a la estimación de tiempo definida, existió una pequeña variación

debido al nuevo requerimiento presentado por el usuario.

72
 Historias de Usuario Punto (Esfuerzo)
Introducción de Comprobante 1
Modificación de Conprobante 1
Eliminación de Comprobante 2
Pago de Sueldos y Salarios 2
Generación de la planilla tributaria 1,5
Estimación inicial 4
Real 3
Tabla 3.22. Historias de Usuario – Segunda Iteración
[Fuente: Elavoración Propia]

3.3.4. Tercera Iteración:

En esta tercera iteración, se añadirán las funcionalidades principales del sistema:

Generación de Reportes. También se realizará una integración parcial de los
pequeños desarrollos realizados hasta el momento, debido a que los procedimientos
desarrollados en esta iteración tienen estrecha relación con los desarrollados en las
otras iteraciones.

En esta iteración se pretende entregar el programa con casi todas las

funcionalidades completas así como los ajustes correspondientes de la segunda
iteración. A pesar de problemas surgidos en esta etapa con relación a la
funcionalidad del sistema y los requerimientos de los usuarios, no ha existido demora
con relación a fa estimación inicial, lo que indica que se ha sobre estimado el
esfuerzo de las historias de usuario.

Historias de Usuario Punto (Esfuerzo)

Generación de Reportes 2
Reexpreciones y actualizaciones 1
Depreciaciones de Activos Fijos 1
Amortizaciones de Activos Intangibles 1
Estimación inicial 4
Real 3
Tabla 3.23. Historias de Usuario – Tercera Iteración

73
3.3.5. Cuarta Iteración:

La cuarta iteración conllevará la finalización del sistema tras la implementación de

las historias correspondientes a la obtención y generación de distintos tipos de
reportes, la comparación entre gestiones. Siendo esta la última iteración se pretende
entregar el producto acabado con todas las funcionalidades propuestas por el cliente.

De acuerdo a la estimación inicial, las historias de usuarios estaban

sobreestimadas, de manera que existió tiempo para realizar mejoras en las interfaces
gráficas de usuarios, tomando en cuenta el criterio de los usuarios.

Historias de Usuario Punto (Esfuerzo)

Presentación de Estados Financieros 2
Cierre de Gestión 2
Obtencion de Copias de Respaldo (Backups) 1
Resumen de la contabilización 1
Estimación inicial 5
Real 4
Tabla 3.24. Historias de Usuario – Cuarta Iteración
[Fuente: Elavoración Propia]

3.4. ITERACIONES

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El
Plan de Entrega está compuesto por iteraciones de no más de cuatro semanas. En la
primera iteración se puede intentar establecer una arquitectura del sistema que
pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las
historias que fuercen la creación de esta arquitectura, sin embargo, se puede variar
con el fin de maximizar el valor de negocio. Al final de la última iteración el sistema
estará listo para entrar en producción.

Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la
Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de
aceptación no superadas en la iteración anterior y tareas no terminadas en la
iteración anterior.

74
 3.4.1. PRIMERA ITERACIÓN

En esta iteración se contempla la realización del prototipo que además de servir

1
N:1
PERMI N
S1:N
OS1
para evaluar la tecnología también establecerá la arquitectura base del sistema.

UFV
I
1:NNS
1:NN:
TI U
NC I
C1:NAM1:B1IO
TIPO1:N
Las historias de usuario a abordar en esta iteración se pueden ver en la Tabla
3.21. Tomando en cuenta los diagramas de WebML el modelo de datos en relación a
f l peri codigo p
las historias de usuario de la iteración 1 es el siguiente:
tc valor
permi_permiso
ufv_anno
tc_anno
ufv_mes
ufv_dia
inst_anno c
inst_nro_patrc
permi_codigo
inst_ciudad
inst_nit
tc_mes inst_telefono
inst_direccio
ufv_codigo
p
c

p
inst_razon_s
p inst_codigo tc_dia
tc_codigo

Figura 3.6. Diagrama Entidad Relación (Iteración 1)

[Fuente: Elavoración Propia]

75
[Link]. Gestión de usuarios

Historia de Usuario
Usuario: Administrador del sistema, Jefe del depto. de
Número: 1
contabilidad

Nombre historia: Gestión de usuarios

Prioridad en negocio: Media Riesgo en desarrollo: Baja

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Gabriel Segales Condori

Descripción:

Llevaremos el alta, baja y modificación de los datos relacionados con los usuarios
del sistema.

Y se dará los permisos correspondientes a cada usuario.

Observaciones:

Los usuarios habilitados accederán al sistema con un nombre de usuario y una

contraseña.

Figura 3.7. Historia de usuario – Gestión de usuarios

[Fuente: Elavoración Propia]

Para comenzar con el desarrollo, es necesario conocer los usuarios que

administraran con el sistema. Dada la estructura jerárquica existente dentro de la
institución, se deben definir cuatro tipos de usuarios, los cuales se detallan a
continuación:

• Jefe del departamento de contabilidad

• Administrador del sistema.

• Contador General.

• Auxiliar contable.

76
 En base al análisis de la estructura de la Base de Datos se definirán los atributos
o permisos que tendrán cada uno de los usuarios, Las opciones a las que tendrá
cada usuario se detallan en la tabla siguiente:

Jefe del depto.

Contador Auxiliar
Opciones de sistema/Acceso por usuario De Administrador
General contable
contabilidad

Registro de comprobantes x x x
Modificación de comprobante x x x
Eliminación de comprobante x x
Visualización de comprobante x x x x
Impresión de comprobante x x x x
Resumen de la contabilidad x x x
Libro diario x x x x
Libro mayor x x x x
Registro alfanumérico y numero de
x x x x
orden
Estados financieros x x x
Editar plan de cuentas x x
Asignar cuentas a usuarios x x
Códigos fijos contables x x x
Tipo de Cambio x x x x
UFV`s x x x x
Nuevo Usuario x x
Acceso a usuario x x
Respaldos de la información x x
Recuperación de información x x
Mantenimiento de índices x x
Editar datos de la empresa x
Planilla de sueldos x x x
Re-expresiones y actualizaciones x x x
Cierre de gestión x x
Tabla 3.25. Perfiles de acceso por usuario
[Fuente: Elavoración Propia]

Y los comandos respectivos para verificar que la introducción de usuarios al

sistema fue satisfactoria. Aplicando conceptos relacionados con la ISO 15408, se
identificaron los requerimientos de seguridad que debe tener el proyecto. A
continuación se detalla el Perfil de Protección (Protection Profile) o PP:

77
 • Acceso restringido de usuarios al sistema.

• Control de acceso mediante autenticación de usuarios.

• Acceso de usuarios de acuerdo a perfiles de acceso.

• Base de datos encriptado, dentro del sistema SCANIIF.

Los Objetivos de Seguridad definidos para los PP, se detallan a continuación:

• El sistema será utilizado sólo por personal del área de Contabilidad, el

acceso de los usuarios será definido con las respectivas gerencias. Cada
usuario deberá acceder al sistema mediante la introducción de su User y
su Password.

• La autenticación de usuarios es controlada mediante el uso de password

por cada User ID, las características de las contraseñas obedecen a
estándares internacionales de seguridad.

• El acceso de los usuarios autenticados en el sistema obedece a los

perfiles de acceso definidos en la Tabla 12.25.

La aplicación de la ISO 15408 en el sistema SCANIIF, es un tanto restringida dada

las características operativas de éste.

Para efectos de funcionalidad, el sistema debe permitir emitir mensajes visuales

indicando si el proceso de adición de usuarios y la asignación de permisos fue
óptimo o no. Además el sistema internamente debe revisar si la base con la que se
está trabajando no produzca errores a otros usuarios.

La presente iteración también sirvió para definir ciertos niveles de seguridad en el

sistema, como ser la posibilidad de que la información almacenada en la base de
datos no sea de acceso a otro tipo de usuarios, Esto con el objetivo de que no se
produzcan errores en la manipulación de la información, esta nueva funcionalidad del
sistema se produjo como un nuevo requerimiento hecho sobre la historia de usuario
número 1.

78
 Tomando en cuenta el modelo de datos en relación a la historias 1 de usuario de
la iteración 1, el modelo del diseño es el siguiente:

Login

Figura 3.8. Diagrama de hipertextos – Gestión de usuarios

[Fuente: Elavoración Propia]

[Link]. Apertura de una Gestión

Historia de Usuario

Número: 2 Usuario: Contador General

Nombre historia: Apertura de una gestión

Prioridad en negocio: Media Riesgo en desarrollo: Media

Puntos estimados: 1 Iteración asignada: 1

Programador responsable: Paco Valverde

Descripción:Llevaremos el alta, baja y modificación de los datos relacionados con

una determinada gestión o periodo fiscal.

Observaciones: Una gestión es un periodo fiscal, este puede ser de enero-

diciembre, abril-marzo, julio-junio, octubre-septiembre.

Figura 3.9. Historia de usuario – Apertura de una gestión

[Fuente: Elavoración Propia]

79
 El desarrollo de la apertura de una gestión fue realizado tomando en cuenta los
tipos de organizaciones o los tipos de sociedades que existen en nuestro país puesto
que cada sociedad debe presentar sus estados financieros en un determinado
periodo. Por lo que el sistema permitirá elegir el periodo de la contabilidad, a partir
del cual se generaran los reportes adecuados a la gestión.

Como resultado del desarrollo de esta historia de usuario, el sistema emitirá un

reporte con todos los datos de la entidad considerados el cierre de gestión y el tipo
de institución.

Tomando en cuenta el modelo de datos en relación a la historias 2 de usuario de

la iteración 1, el modelo del diseño es el siguiente:

Institucion

Figura 3.10. Diagrama de hipertextos – Apertura de Gestión

[Fuente: Elavoración Propia]

80
[Link]. Introducción del Plan de Cuentas

Historia de Usuario

Número: 3 Usuario: Contador General

Nombre historia: Introducción del Plan de Cuentas

Prioridad en negocio: Media Riesgo en desarrollo: Baja

Puntos estimados: 1.5 Iteración asignada: 1

Programador responsable: Gabriel Segales Condori

Descripción:

Llevaremos el alta, baja y modificación de los datos relacionados con el plan de

cuentas de la institución.

Observaciones:

Esto solo se lleva a cabo al iniciar la gestión.

Figura 3.11. Historia de usuario – Introducción del Plan de Cuentas

[Fuente: Elavoración Propia]

El desarrollo de introducción del plan de cuentas fue realizado tomando en cuenta

los tipos de organizaciones o los tipos de instituciones que existen en nuestro país
puesto que cada tipo de institución cuenta con un propio plan de cuentas, para esto
se introdujo en la base de datos un plan de cuantas de base para cada tipo de
instituciones, también se tomo en cuenta las NIIF, puesto que menciona a grandes
rasgos como debe de estas compuesto un plan de cuentas.

Como resultado del desarrollo de esta historia de usuario, el sistema emitirá un

panel donde contara con 3 botones para la adición, modificación y eliminación de una
cuenta ya sea esta de grupo, capítulos, cuenta o subcuenta, también se contara con
un motor de búsqueda para realizar la búsqueda de una cuenta en especifico ya sea
por el nombre o por el código de la cuenta, también se contara con el reporte
correspondiente del plan de cuentas elaborado por el usuario.

81
 Tomando en cuenta el modelo de datos en relación a la historias 3 de usuario de
la iteración 1, el modelo del diseño es el siguiente:

user

usuario

Figura 3.12. Diagrama de hipertextos – Introducción plan de cuentas

[Fuente: Elavoración Propia]

82
[Link]. Introducción de los Tipos de Cambio

Historia de Usuario

Número: 4 Usuario: Contador general, Auxiliar contable

Nombre historia: Introducción de Tipos de Cambio

Prioridad en negocio: Baja Riesgo en desarrollo: Baja

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Gabriel Segales Condori

Descripción:

Antes de comenzar con las transacciones se debe introducir los tipos de cambio a la
fecha.

Observaciones:

Los tipos de cambio están dados por el banco central de Bolivia diariamente.

Figura 3.13. Historia de usuario – Introducción de los Tipos de Cambio

[Fuente: Elavoración Propia]

La introducción de tipos de cambio al sistema en necesario pues se necesita al

momento de introducir las transacciones y al momento de realizar los asientos de
ajuste, para las reexpreción o actualización de las cuentas en moneda extranjera.

Como resultado del desarrollo el sistema emitirá un panel con una tabla tipo matriz
donde se podrá introducir todos los tipos de cambio de las distintas fechas, también
se contara con la posibilidad de importar datos desde un archivo en excel en formato
.csv, para el llenado de los tipos de cambio de las gestiones pasadas, y por último el
sistema emitirá un reporte por gestión de los tipos de cambio introducidos.

Tomando en cuenta el modelo de datos en relación a la historias 4 de usuario de

la iteración 1, el modelo del diseño es el siguiente:

83
 user

usuario

Figura 3.14. Diagrama de hipertextos – Introducción plan de cuentas

[Fuente: Elavoración Propia]

[Link]. Introducción de las UFV's

Historia de Usuario

Número: 5 Usuario: Contador general, Auxiliar contable

Nombre historia: Introducción de las UFV`s

Prioridad en negocio: Media Riesgo en desarrollo: Media

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Gabriel Segales Condori

Descripción:Antes de comenzar con las transacciones se debe introducir las UFV`s

a la fecha.

Observaciones:

Las UFV’s están dados por el banco central de Bolivia diariamente.

Figura 3.15. Historia de usuario – Introducción de las UFV`s

[Fuente: Elavoración Propia]

84
 Al igual de los tipos de cambio la introducción de las UFV’s al sistema es
importante puesto que la norma 6 indica que se debe realizar los asientos de ajuste,
para las reexpreción o actualización de las cuentas de activos no monetarios como
por ejemplo: los activos Fijos, los Activos Intangibles, las cuentas de capital, etc.

Como resultado del desarrollo el sistema emitirá un panel con una tabla tipo matriz
donde se podrá introducir todos valores de las UFV’s de las distintas fechas, también
se contara con la posibilidad de importar datos desde un archivo en Excel en formato
.csv, para el llenado de los UFV`s de las gestiones pasadas, y por último el sistema
emitirá un reporte por gestión de los UFV`s introducidos.

Tomando en cuenta el modelo de datos en relación a la historias 5 de usuario de

la iteración 1, el modelo del diseño es el siguiente:

user

usuario

Figura 3.16. Diagrama de hipertextos – Introducción ufv’s

[Fuente: Elavoración Propia]

3.4.2. SEGUNDA ITERACIÓN

En esta segunda iteración se contempla la realización del modulo de introducción,

modificación y eliminación de comprobantes ya sean estos de ingreso, egreso o
traspaso.

85
86
[Fuente: Elavoración Propia]
Figura 3.17. Diagrama Entidad Relación (Iteración 2)
comp_codigo
comp_tipo
comp_fecha
tc_codigo
tc_codigo comp_codigo
ufv_codigo suel_codigo
emp_codigo
tc_dia comp_monedainst_codigo suel_descuento
comp_fuente
inst_razon_social
cta_codigo suel_bono1
ufv_codigo
comp_pagado
inst_direccion cta_codigo suel_bono2
tc_mes comp_nro
ufv_dia inst_telefono
cta_nombre suel_bono3
comp_glosainst_nit emp_codigo
suel_retencion1
permi_codigo
ufv_mes
tc_anno inst_ciudad
cta_tipo
user_codigo peri_codigo
emp_ap_paterno
suel_retencion2
inst_nro_patronal amp_ap_materno
inst_codigo cta_moneda suel_retencion3
ufv_annoinst_anno
permi_permiso peri _fecha_inicial emp_nombre
tc_valor suel_total
ecarmpg__codifechag_onac
us er _c odi go
us er _nom br e
us er _ap_pat er no
us er _ap_m at er no
user_codigo
tipo_user_codigo us er
us er
us er
us er

_c i
_m ai l
_di r
_us er
_pas w
t i po_us er
or

el inal
ufv_valorperi_codigo pericta_ni_fevcha_f
us er
ec c i on
d
_c odi go

comp_codigo
ecarmpg__catfecheagor_iniag
peri_fecha_cierre
tipo_user_nombre
tc moneda
1:N
1:N
I
UFV
PERMI
N:1
1:N N
S1:N S TI
N:1 1:
U C1:
OS1P:1ERIOD N1:
1:N
TIPO 1:1
USUARIO
IO
P LN
A
USUARIctOa presupuesto
N_N:1:1
TIPO_C1:OAMPMRN:OBN1IAOCM1NP_E:TANS1:N
C1
UE NTA S 1: N carg_sueldobasico
carcargg suelcodidgomio n
las historias de usuario de la iteración 2 es el siguiente:
Tomando en cuenta los diagramas de WebML el modelo de datos en relación a
CARGO
Las historias de usuario a abordar en esta iteración se pueden ver en la Tabla

ESUEMLPDLOA_DOA 3.22.
[Link]. Introducción de Comprobante

Historia de Usuario

Número: 6 Usuario: Contador General, Auxiliar contable

Nombre historia: Introducción de Comprobante

Prioridad en negocio: Alta Riesgo en desarrollo: Baja

Puntos estimados: 1 Iteración asignada: 2

Programador responsable: Gabriel Segales Condori

Descripción:

Cuando se produce un movimiento dentro de la institución (Ej. Pago de sueldos y

salarios) se procede a registrar dicha transacción tomando en cuenta la
documentación para respaldar dicha transacción realizada.

Observaciones:

Figura 3.18. Historia de usuario – Introducción de Comprobantes

[Fuente: Elavoración Propia]

Una vez que el sistema SCANIIF realiza la introducción de los datos necesarios
para la apertura de la contabilidad, éste debe permitir introducir las transacciones,
asientos contables tomando en cuentas el plan de cuentas de la institución
introducidos anteriormente. Esta tarea es de mucha importancia desde el punto de
vista operativo para el contador, ya que es necesario para la generación de estados
financieros.

Como resultado se obtuvo un panel con diferentes cajas de texto en las cuales se
muestran o se introducen datos como por ejemplo: el tipo de comprobante, la fecha,
el número de comprobante, las cuentas a utilizar, la glosa, etc. También se cuenta
con botones para la búsqueda de cuentas, para la adición de campos y para el
almacenamiento de la transacción.

87
 Esta segunda iteración también sirvió para establecer el tipo de moneda con la
que se trabajara es el boliviano según uno de los principios de contabilidad (moneda
constante).

Tomando en cuenta el modelo de datos en relación a la historias 6 de usuario de

la iteración 2, el modelo del diseño es el siguiente:

user

usuario

Figura 3.19. Diagrama de hipertextos – Introducción comprobante

[Fuente: Elavoración Propia]

88
[Link]. Modificación de Comprobante

Historia de Usuario

Número: 7 Usuario: Contador General, Auxiliar contable

Nombre historia: Modificación de un comprobante

Prioridad en negocio: Alta Riesgo en desarrollo: Baja

Puntos estimados: 1 Iteración asignada: 2

Programador responsable: Gabriel Segales Condori

Descripción:

Accede a la base de datos y busca un comprobante según la fecha o el número de

comprobante y una vez encontrado se muestra para luego ser modificado por el
usuario autorizado.

Observaciones:

Figura 3.20. Historia de usuario – Modificación de Comprobante

[Fuente: Elavoración Propia]

El sistema SCANIIF, también permitirá la modificación de comprobantes. El

contador como cualquier ser humano puede cometer algún error al momento de
introducir un comprobante de ingreso, de egreso o de traspaso, y por motivos de
seguridad cada vez que se produzca una modificación esta información se
almacenara en una base de datos, para luego ser presentado en el resumen de la
contabilidad para evitar irregularidades dentro la institución.

Una vez que se produzca la modificación debe realizar las correcciones

pertinentes como por ejemplo la reorganización del los comprobantes, puesto que
todos los comprobantes deben de estar ordenados cronológicamente.
Posteriormente se debe realizar las correcciones en los libros mayores y en la hoja
de trabajo.

89
 Como resultado del desarrollo se obtuvo una ventana donde contiene varias cajas
de texto para realizar la búsqueda del comprobante a modificar, y con varios botones
para aceptar o rechazar la modificación del comprobante.

Tomando en cuenta el modelo de datos en relación a la historias 7 de usuario de

la iteración 2, el modelo del diseño es el siguiente:

user

usuario

Figura 3.21. Diagrama de hipertextos – Modificación comprobante

[Fuente: Elavoración Propia]

90
[Link]. Eliminación de Comprobante

Historia de Usuario

Número: 8 Usuario: Contador General, Auxiliar contable

Nombre historia: Eliminación de un comprobante

Prioridad en negocio: Alta Riesgo en desarrollo: Alta

Puntos estimados: 2 Iteración asignada: 2

Programador responsable: Gabriel Segales Condori

Descripción:Se busca en base de datos un determinado comprobante, si existe se

muestra una ventana con los datos correspondientes al usuario con dos opciones
“eliminar” y “cancelar” y él podrá elegir una opción.

Observaciones:

Figura 3.22. Historia de usuario – Eliminación de Comprobante

[Fuente: Elavoración Propia]

Al igual que la anterior historia de usuario el sistema SCANIIF debe permitir la

eliminación de comprobantes de ingreso, egreso o traspaso erróneos. y por motivos
de seguridad cada vez que se produzca la eliminación de un comprobante esta
información se almacenara en una base de datos, para luego ser presentado en el
resumen de la contabilidad para evitar irregularidades dentro la institución.

Luego de realizar la eliminación de un comprobante el sistema debe realizar las

correcciones pertinentes como por ejemplo la remuneración del los comprobantes,
puesto que todos los comprobantes deben de estar ordenados cronológicamente.
Posteriormente se debe realizar las correcciones en los libros mayores y en la hoja
de trabajo.

Como resultado del desarrollo se obtuvo una ventana donde contiene varias cajas
de texto para realizar la búsqueda del comprobante a eliminar, y con varios botones
para aceptar o rechazar la eliminación del comprobante.

91
 En esta segunda iteración ya se tiene un conocimiento más detallado de la
plataforma y de la estructura que tendrá el sistema, con relación a los tiempos
estimados estos no se vieron afectados.

Tomando en cuenta el modelo de datos en relación a la historias 8 de usuario de

la iteración 2, el modelo del diseño es el siguiente:

user

usuario

Figura 3.23. Diagrama de hipertextos – Eliminación comprobante

[Fuente: Elavoración Propia]

92
[Link]. Pago de Sueldos y Salarios

Historia de Usuario

Número: 9 Usuario: Contador general

Nombre historia: Pago de sueldos y salarios

Prioridad en negocio: Riesgo en desarrollo:

Baja Baja

Puntos estimados: 2 Iteración asignada: 2

Programador responsable: Gabriel Segales Condori

Descripción:

Mensualmente se procede al pago de los sueldos y salarios a los trabajadores de la

institución.

Para ello se deben tomar en cuenta los distintos descuentos de ley a los sueldos
tomando en cuenta los datos introducidos al iniciar la gestión o periodo fiscal.

El sistema realizara los comprobantes necesarios de forma automática.

Observaciones:

Para llevar a cabo estas operaciones se debe tomar en cuenta distintos factores
como por ejemplo: el salario mínimo de Bolivia, el sueldo básico de los empleados,
etc.

Figura 3.24. Historia de usuario – Pago de sueldos y salarios

[Fuente: Elavoración Propia]

Realizando el análisis del pago de sueldos y salarios y de las operaciones que se

deben realizar al momento de registrar, se tomó en cuenta trabajar con bases de
datos temporales, la cuales son eliminadas luego de procesar la información
necesaria para obtener las planillas de sueldos y salarios, la planilla de aportes
patronales y la planilla tributaria.

Para la preparación de este modulo se tiene que tomar en cuenta los siguiente: el
sueldo mínimo nacional actual, la alícuota vigente de los impuestos, las retenciones

93
correspondientes al trabajador (bonos, aportes afp`s, aguinaldos, indemnizaciones,
etc), el número de trabajadores, los cargos y el sueldo básico del trabajador, una vez
teniendo estos datos se procede a la realización de la transacción correspondiente.

Como resultado del desarrollo se obtuvo una ventana donde se introducen los
datos anteriormente citados y luego los botones para la generación de los asientos
correspondientes.

Tomando en cuenta el modelo de datos en relación a la historias 9 de usuario de

la iteración 2, el modelo del diseño es el siguiente:

user

usuario

Figura 3.25. Diagrama de hipertextos – Pago de sueldos y salarios

[Fuente: Elavoración Propia]

94
95
[Fuente: Elavoración Propia]
Figura 3.26. Diagrama Entidad Relación (Iteración 3)
act_codigo
act_nombre
comp_codigo
comp_tipo
act_categoria
comp_fecha
act_tipotc_codigo
tc_codigo comp_codigo
ufv_codigo suel_codigo
act_vidautil
comp_moneda emp_codigo
tc_dia inst_codigo suel_descuento
comp_fuente
cta_codigo inst_razon_social
cta_codigo suel_bono1
ufv_codigo
comp_pagadoinst_direccion
cta_codigo suel_bono2
tc_mes
act_valoractual inst_telefono
ufv_dia comp_nro cta_nombre suel_bono3
comp_glosa inst_nit emp_codigo
suel_retencion1
act_revalorizacion
permi_codigo inst_ciudad
cta_tipo
ufv_mesuser_codigo may_codigo
tc_anno emp_ap_paterno
suel_retencion2
inst_nro_patronal amp_ap_materno
inst_codigo cta_codigo
act_depreciacion cta_moneda suel_retencion3
ufv_anno
permi_permiso inst_anno emp_nombre
may_debe suel_total
tc_valor peri_codigo ecarmpg__codifechag_onac
us er _c odi go
ufv_valor may_haber
us er
us er
us er

_nom br
_ap_pat er
e
_ap_m at er

cta_nivel
us er _c i

no
no
us er _m ai l
us er _di rec c i on

act_reexpresion
user_codigo
tipo_us er_c odigous er
us er
_us er
_pas w
peri_codigo
t i po_us er
or d
_c odi go

comp_codigo
peri_fecha_inicial
ecarmpg__catfecheagor_iniag
tipo_us er_nombre
may_saldo carg_sueldobasico
tc moneda peri_fecha_final

TIPOA_CN:1:N
CT[Link]N
1:N
1:N
1:N
TIPO 1:1
INSN:1
UFV1:N
PERMI
N:1 S
USUARIO
TI UC1:IPOLAN_1:C1UENTA1S 1:N
OS
1:N
USUARI1:1 L IB RO M A Y OR
Octa PprEeRsupuestIODO o
N
1: ccarargg csuelodigdoomin

AOIMVPMRN:1:N:1OBN1I:AO:NCN1M1P:_ETNA1S :N
las historias de usuario de la iteración 3 es el siguiente:
3.23. Tomando en cuenta los diagramas de WebML el modelo de datos en relación a
Las historias de usuario a abordar en esta iteración se pueden ver en la Tabla

CARGO
sistema SCANIIF.
En esta tercera iteración se contempla la realización de los procesos centrales del

ESUEMLPDLOA_DOA
3.4.3. TERCERA ITERACIÓN
 [Link]. Generación de Reportes

Historia de Usuario
Usuario: Jefe de depto. de contabilidad, Contador General,
Número: 10
Auxiliar contable

Nombre historia: Generación de reportes

Prioridad en negocio: Media Riesgo en desarrollo: Baja

Puntos estimados: 2 Iteración asignada: 3

Programador responsable: Gabriel Segales Condori

Descripción:

El usuario podrá verificar constantemente los reportes de: libro diario,

comprobantes, libro mayor, balance de Sumas y saldo, Estado de situación
financiera, estado de desempeño.

Cuando se muestre el reporte, este mostrara opciones de impresión y configuración.

Observaciones:

Los reportes presentados estarán se prepararan bajo las Normas Internacionales de

Información Financiera.

Figura 3.27. Historia de usuario – Generación de reportes

[Fuente: Elavoración Propia]

La obtención de reportes es el resultado que emite el sistema SCANIIF. Los

reportes que se emitirán son: Visualización de los comprobantes de ingreso, egreso,
traspaso ordenados cronológicamente, los libros mayores en detalle con una cuenta
o con varias cuentas en una hoja, el libro diario, el resumen de comprobantes, la hoja
de sumas y saldos.

La obtención de estos reportes es resultado de la introducción de las

transacciones o asientos contables durante toda una gestión y como resultado se
mostrara en pantalla el reporte correspondiente con la opción de impresión.

96
 Tomando en cuenta el modelo de datos en relación a la historias 10 de usuario de
la iteración 3, el modelo del diseño es el siguiente:

user

usuario

Figura 3.28. Diagrama de hipertextos – Generacion de reportes

[Fuente: Elavoración Propia]

97
 [Link]. Re-expresiones y actualizaciones

Historia de Usuario

Número: 11 Usuario: Contador general, Auxiliar Contable

Nombre historia: Reexpresiones y actualizaciones

Prioridad en negocio: Riesgo en desarrollo:

Media Baja

Puntos estimados: 1 Iteración asignada: 3

Programador responsable: Gabriel Segales Condori

Descripción:

Mensualmente o diariamente de llevan a cabo las reexpresiones y actualizaciones

de los activos corrientes, activos fijos, etc. de la institución.

El sistema realizara los comprobantes necesarios de forma automática tomando en

cuenta los datos introducidos al iniciar la gestión o el periodo fiscal.

Observaciones:

Para llevar a cabo estas reexpresiones y actualizaciones se toma en cuenta el tipo

de cambio y las UFV’s. según indica las NIIF (Planta y equipo)

Figura 3.29. Historia de usuario – Re-expresión y actualizaciones

[Fuente: Elavoración Propia]

El proceso de re-expresiones y/o actualizaciones según las Normas

Internacionales de Información Financiera (NIIF) se las debe realizar a todos los
activos no monetarios según las UFV`s cada fin de mes o cuando asi lo requiera.
Para el desarrollo de ésta historia de usuario se tomo como base las UFV`s
Introducidas al iniciar una gestión, las operaciones realizadas para la re-expresión o
actualización es la siguiente:

98
 Como resultado se generaran los asientos de ajuste correspondientes, se
mostrara un mensaje con la realización de la operación.

Tomando en cuenta el modelo de datos en relación a la historias 11 de usuario de

la iteración 3, el modelo del diseño es el siguiente:

[Link]. Depreciaciones de Activos Fijos

Historia de Usuario

Número: 12 Usuario: Contador general, Auxiliar Contable

Nombre historia: Depreciaciones de activos fijos

Prioridad en negocio: Riesgo en desarrollo:

Baja Baja

Puntos estimados: 1 Iteración asignada: 3

Programador responsable:

Descripción:

Mensualmente o diariamente de llevan a cabo las depreciaciones de activos fijos de

la institución.

El sistema realizara los comprobantes necesarios de forma automática tomando en

cuenta los datos introducidos al iniciar la gestión o el periodo fiscal.

Observaciones:

Para llevar a cabo estas depreciaciones se toma en cuenta los años de vida útil de
un activo.

Según indica las NIIF (Planta y equipo)

Figura 3.30. Historia de usuario – Depreciación de Activos fijos

[Fuente: Elavoración Propia]

El proceso de depreciación de activos fijos según la Normas Internacionales de

Información Financiera (NIIF) se las debe realizar cada mes o cada año según el tipo
de entidad y según la vida útil del activo fijo mostrado a continuación:

99
 COEFICIENTE
BIENES VIDA UTIL
[%]
Edificaciones 40 2,50
Muebles y enseres de oficina 10 10,00
Maquinaria en general 8 12,50
Equipo e Instalaciones 8 12,50
Barcos lanchas en general 10 10,00
Vehículos automotores 5 20,00
Aviones 5 20,00
Maquinarias de construcción 5 20,00
Maquinarias agrícolas 4 25,00
Animales de trabajo 4 25,00
Herramientas en general 4 25,00
Equipos de computación 4 25,00
Viviendas para el personal 20 5,00
Silos almacenes y galpones 20 5,00
Tinglados y cobertizos de madera 5 20,00
Tinglados y cobertizos de metal 10 10,00
Instalaciones de electricidad 10 10,00
Tabla 12.26. Depreciaciones de activos fijos
[Fuente: Elavoración Propia]

Como resultado del desarrollo se generan los asientos correspondientes a las

depreciaciones. Tomando en cuenta el modelo de datos en relación a la historias 12
de usuario de la iteración 3, el modelo del diseño es el siguiente:

user

usuario

Figura 3.31. Diagrama de hipertextos – Depreciacion activos fijos

[Fuente: Elavoración Propia]

100
 [Link]. Amortizaciones de Activos Intangibles

Historia de Usuario

Número: 13 Usuario: Contador general, Auxiliar Contable

Nombre historia: Amortizaciones de activos intangibles

Prioridad en negocio: Riesgo en desarrollo:

Baja Baja

Puntos estimados: 1 Iteración asignada: 3

Programador responsable: Gabriel Segales Condori

Descripción:

Mensualmente o diariamente de llevan a cabo las depreciaciones de activos

intangibles de la institución.

El sistema realizara los comprobantes necesarios de forma automática tomando en

cuenta los datos introducidos al iniciar la gestión o el periodo fiscal.

Observaciones: Para llevar a cabo estas depreciaciones se toma en cuenta los

años probables de de vida útil de un activo intangible.

Según indica las NIIF (Activos Intangibles)

Figura 3.32. Historia de usuario – Amortizaciones de activos intangibles

[Fuente: Elavoración Propia]

Al igual de la depreciación de activos fijos se debe proceder a las amortizaciones

de activos intangibles, el proceso de amortización de activos intangibles según la
Normas Internacionales de Información Financiera (NIIF) se las debe realizar cada
mes o cada año según el tipo de entidad y según la vida útil estimada del activo
intangible como por ejemplo: los derechos de autos se pueden amortizar en cuatro
años.

Tomando en cuenta el modelo de datos en relación a la historias 13 de usuario de

la iteración 3, el modelo del diseño es el siguiente:

101
 user

usuario

Figura 3.33. Diagrama de hipertextos –Amortizacion de activos intangibles

[Fuente: Elavoración Propia]

3.4.4. CUARTA ITERACIÓN

Esta última iteración concluirá el sistema con la implementación de la

funcionalidad relacionada con la obtención de estados financieros, el cierre de
gestión, la obtención de copias de respaldo y el resumen de la contabilidad.

Las historias de usuario a abordar en esta iteración se pueden ver en la Tabla

3.24.

Tomando en cuenta los diagramas de WebML el modelo de datos en relación a

las historias de usuario de la iteración 4 es el siguiente:

102
103
[Fuente: Elavoración Propia]
Figura 3.34. Diagrama Entidad Relación (Iteración 4)
act_codigo
comp_codigo
comp_tipo
act_nombre comp_codigo
comp_fecha
act_categoria
tc_codigo
ufv_codigo cta_codigo
act_tiporesu_codigo
comp_moneda
tc_codigo
resu_fecha
act_vidautil cta_codigo suel_codigo
comp_fuentecta_nombre emp_codigo
tc_dia resu_numcomp
comp_pagado
cta_codigo may_codigo suel_descuento
resu_nummodifi
ufv_codigo _t i
comp_nro ctctaa_codipo go suel_bono1
act_valoractual
tc_mes inst_codigo suel_bono2
ufv_dia resu_numelimina
comp_glosainst_razon_social suel_bono3
inst_direccion
may_debe emp_codigo
act_revalorizacioninst_telefono
resu_numcompin
user_codigo cta_moneda suel_retencion1
eeff_codigo
permi_codigo
ufv_mes
tc_anno inst_nit peri_codigo
eeff_tipo

emp_ap_paterno
suel_retencion2
eeff_fecha
inst_ciudad
resu_numcompeg
inst_codigo may_haber eeff_moneda
amp_ap_materno
may_saldo
inst_nro_patronal eeff_totalactivo
act_depreciacion
ufv_anno
permi_permiso eeff_totalpasivo
eeff_totalpatri

suel_retencion3
emp_nombre
inst_anno
cta_nivel
resu_numcomptr eeff_totalingreso
eeff_totalegreso
tc_valor suel_total
peri_codigo ecarmpg__codifechag_onac
us er _c odi go
us er _nom br e
us er _ap_pat er no
us er _ap_m at er no
us er _c i

ufv_valor us er

act_reexpresionmay_saldo
us er
us er
us er

_m ai l
_di rec c i on
_us er
_pas w

user_codigo peri_codigo
tipo_user_codigo t i po_us er
or d
_c odi go

comp_codigo
peri_fecha_inicial
ecarmpg__catfecheagor_iniag
PERMI
N:1
1:N 1:N
UFVAN:CT1:OIMVN:PRO1NBA1CNOMTP:_ENA1S
tipo_user_nombre
tc moneda
1:N
1:N
SIN N:1
1:N
TIPO 1:1 1:N peri fecha final

TIPO_1:RCESAU1:MNEBN_1NOCPLA_1NUE:TA1S 1:N
N:
1: LIB
N RO
1 M A:Y OR
1 1: N
OSTI UCIEcOtSaTAprNDeOsupFuIeNsAtoC N1:
USUARIO
USUARI1:1
OPERIODO
carg_sueldobasico
carcargg suelcodidgomio n
CARGO
ESUEMLPDLOA_DOA
 [Link]. Presentación de Estados Financieros

Historia de Usuario

Número:14 Usuario: Contador General

Nombre historia: Presentación de Estados Financieros

Prioridad en negocio: Media Riesgo en desarrollo: Baja

Puntos estimados: 2 Iteración asignada: 4

Programador responsable: Gabriel Segales Condori

Descripción:

Se presenta un reporte de los estados financieros:

• Estado de Situacion Financiera

• Estado de Desempeño

Observaciones:

Figura 3.35. Historia de usuario – presentación de estados financieros

[Fuente: Elavoración Propia]

El objetivo principal del desarrollo del sistema es la presentación de Estados

Financieros, la Norma de Contabilidad 1 mencionada en el marco conceptual
menciona que los dos estados financieros más importantes son: Estado de Situación
Financiera, el Estado de Desempeño, y también menciona como y cuando se debe
preparar dichos estados y cuáles deben ser las operación a seguir y los elementos
que debe tener cada uno de los EEFF. Tomando en cuenta el desarrollo de todas las
anteriores historias de usuario se desarrollo el modulo de presentación de estados
financieros.

La presentación de estados financieros fue trabajada sobre las tablas resultantes

de todo el proceso y como resultado se tiene los reportes de los Estados Financieros
según las NIIF, con la opción de impresión y configuración.

104
 Tomando en cuenta el modelo de datos en relación a la historias 14 de usuario de
la iteración 4, el modelo del diseño es el siguiente:

[Link]. Cierre de Gestión

Historia de Usuario

Número: 15 Usuario: Contador General

Nombre historia: Cierre de gestión

Prioridad en negocio: Media Riesgo en desarrollo: Baja

Puntos estimados: 2 Iteración asignada: 4

Programador responsable: Gabriel Segales Condori

Descripción:

Cuando finalice una gestión se debe proceder a registrar los comprobantes de

ajustes que sean necesarios. Estos comprobantes el sistema los debe realizar de
forma automática tomando en cuenta los datos introducidos al iniciar la gestión.

Observaciones:

Una gestión es un periodo fiscal, este puede ser de enero-diciembre, abril-marzo,

julio-junio, octubre-septiembre

Figura 3.36. Historia de usuario – Cierre de gestión

[Fuente: Elavoración Propia]

El cierre de gestión fue trabajada sobre los resultados de la tabla de estados

financieros y el periodo o gestión de la institución

Como resultado del desarrollo se genero los asientos correspondientes y se

almaceno en la base de datos para la apertura de la siguiente gestión y se muestra
una ventana con el mensaje “cierre de gestión realizada satisfactoriamente”.

Tomando en cuenta el modelo de datos en relación a la historias 15 de usuario de

la iteración 4, el modelo del diseño es el siguiente:

105
 [Link]. Obtención de Copias de Respaldo (Backups)

Historia de Usuario

Número: 16 Usuario: Contador General, jefe del depto. de contabilidad

Nombre historia: Obtención de copias de respaldo

Prioridad en negocio: Baja Riesgo en desarrollo: Baja

Puntos estimados: 1 Iteración asignada: 4

Programador responsable:

Descripción:

Al finalizar una gestión o cuando sea necesario el usuario necesita realizar una
copia de seguridad (backup) de toda la información, transacciones realizadas en
ese determinado tiempo.

Observaciones:

Figura 3.37. Historia de usuario – Obtención de copias de respaldo

[Fuente: Elavoración Propia]

Para poder facilitar el trabajo de los usuarios del sistema SCANIIF, se desarrollo la
facilidad de exportar los resultados a un archivo comprimido como una copia de
respaldo, para luego este pueda ser almacenado de manera segura o para su
posterior restauración de la base de datos.

Tomando en cuenta el modelo de datos en relación a la historias 16 de usuario de

la iteración 4, el modelo del diseño es el siguiente:

106
 [Link]. Resumen de la contabilización

Historia de Usuario

Número:17 Usuario: Contador General

Nombre historia: Resumen de la contabilidad

Prioridad en negocio: Media Riesgo en desarrollo: Baja

Puntos estimados: 1 Iteración asignada: 4

Programador responsable: Gabriel Segales Condori

Descripción: Se presenta un resumen de todas las operaciones realizadas en un

determinado tiempo: resumen de comprobantes de egreso, ingreso, traspaso,
comprobantes eliminados, comprobantes modificados.

Observaciones:

Figura 3.38. Historia de usuario – Resumen de la contabilidad

[Fuente: Elavoración Propia]

Para poder facilitar el visualizar de mejor forma es necesario un resumen de toda

la gestión del sistema SCANIIF, se desarrollo un modulo que permite generar un
reporte de toda la contabilidad realizada en la gestión como ser: el número de
comprobantes introducidos, el número de comprobantes modificados, el número de
comprobantes eliminados, los saldos de cada cuenta.

Tomando en cuenta el modelo de datos en relación a la historias 17 de usuario de

la iteración 4, el modelo del diseño es el siguiente:

107
3.5. PRODUCCIÓN

La fase de producción requiere pruebas adicionales y revisiones de rendimiento

antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se
deben tomar decisiones sobre inclusión de nuevas características a la versión actual,
debido a cambios durante esta fase.

A continuación se detallan algunas de las interfaces de usuario det sistema

SCANIIF:

3.5.1. Interfaz de acceso

Figura 3.39. Producción – Interfaz de acceso

108
3.5.2. Interfaz de gestión de usuarios

Figura 3.40. Producción – Gestión de usuario

3.5.3. Interfaz de apertura de gestión

Figura 3.41. Producción – Apertura de Gestión

109
3.5.4. Introducción de plan de cuentas

Figura 3.42. Producción – Introducción plan de cuentas

3.5.5. Introducción de los Tipos de Cambio

Figura 3.43. Producción – Introducción tipo de cambio

110
3.5.6. Introducción de las UFV's

Figura 3.44. Producción – Introducción UFV`s

3.5.7. Introducción de Comprobante

Figura 3.45. Producción – Introducción comprobante

111
3.5.8. Modificación de Comprobante

Figura 3.46. Producción – Modificación comprobante

3.5.9. Eliminación de Comprobante

Figura 3.47. Producción – Eliminación comprobante

112
3.5.10. Generación de Reportes

Figura 3.48. Producción – Generación de reportes

3.5.11. Depreciaciones de Activos Fijos

Figura 3.49. Producción – Depreciación Activos fijos

113
3.5.12. Presentación de Estados Financieros

Figura 3.50. Producción – Presentación de estados financieros

3.5.13. Resumen de la contabilización

Figura 3.51. Producción – Resumen de la contabilidad

114
3.6. MANTENIMIENTO

Una vez entregada la primera versión del sistema SCANIIF, se procedió a

modificar la calidad de las interfaces de usuario, y cubriendo una nueva historia de
usuarios. En este caso en las cuatro iteraciones se cubrieron la totalidad de historias
de usuario, sin que se presente alguna nueva.

3.7. MUERTE DEL PROYECTO

Esta fase del proyecto se presenta el momento que el cliente no tiene más
historias que concluir en el sistema. Esto implica que se satisfagan las necesidades
del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se
.generó la documentación final del sistema y no se realizan más cambios en la
arquitectura, el manual del usuario se encuentra en el.

3.8. CALIDAD DEL SOFTWARE

La calidad de software se define como la ausencia de errores de funcionamiento,

la adecuación a las necesidades del usuario, y el alcance de un desempeño
apropiado (tiempo, volumen, espacio), además del cumplimiento de los estándares
[Pressman, 2001] La calidad de software proporciona una indicación de cómo se
ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy
a medir para que mi sistema se adapte a los requisitos que me pide el cliente.

3.9.1. FUNCIONALIDAD

Es una medida indirecta del software y del proceso por el cual se desarrolla se
centran en la funcionalidad o utilidad del programa.

Los puntos de función que obtienen utilizando una función empírica basando en
medidas cuantitativas del dominio de información del software y valoraciones
subjetivos de la complejidad del software.

Los puntos de función se calculan rellenando la tabla como se muestra en la

siguiente figura:

115
 FACTOR DE PONDERACIÓN
Parametro de medicion Cuenta Simple Medio Complejo
Num. de entradas de usuario 3 4 6 =
Num. De salidas de usuario 4 5 7 =
Num. De peticiones de usuario 3 4 6 =
Numero de archivos 7 10 15 =
Numero de interfaces externas 5 7 10 =
Cuenta total
Tabla 4.1. Factor de ponderacion
[Fuente: Pressman, 2006]

Se determinan 5 características del ámbito de la información y los cálculos

aparecen en la posición apropiada de la tabla. Los valores del ámbito de información
están definidos de la siguiente manera.

• Números de entrada de usuario: se cuenta cada entrada del usuario que

proporcione al software diferentes datos orientados a la aplicación. Las
entradas deben ser distinguidas de las peticiones que se contabilizan por
separado.

• Número de salida del usuario: se encuentra cada salida que proporciona la

usuario información orientada a la aplicación. En este contexto las salidas se
refieren a informes, pantalla, mensajes de error. Los elementos de datos
individuales dentro de un informe se encuentran por separado.

• Números de peticiones al usuario: una petición esta definida como una

entrada interactiva que resulta de la generación de algún tipo de respuesta en
forma de salida interactiva. Se cuenta cada petición por separado.

• Número de archivos: se cuenta cada archivo maestro lógico, o sea una

agrupación lógica de datos que puede ser una parte en una gran base de
datos o un archivo independiente.

• Numero de interfaces externas: se cuentan todas las interfaces legibles por la

maquina por ejemplo: archivos de datos, en cinta o discos que son utilizados
para transmitir información a otro sistema.

116
 Cuando han sido recogidos los datos anteriores se asocian el valor de
complejidad a cada cuenta. Las organizaciones que utilizan métodos de puntos de
función desarrollan criterios para determinar si una entrada es denominada simple,
media o compleja. No obstante la determinación de la complejidad es algo subjetivo.

Para calcular los puntos de función se utiliza la siguiente relación.

PF = CUENTA_TOTAL· [0.65 + 0.01 • SUM(fi)]

Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la

tabla anterior de la figura 4.24.

Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad

basados en las respuestas a del siguiente cuestionario.

Evaluar cada factor en escala O a 5.

0 1 2 3 4 5
No tiene Ayudaría Es Es una
No afecta Sería Útil
relevancia medianamente necesario prioridad

F¡ :

1) ¿Requiere el sistema copias de seguridad y recuperación fiable?

2) ¿Se requiere comunicación de datos?

3) ¿Existen funciones de procesamiento distribuido?

4) ¿Es crítico el rendimiento?

5) ¿Será ejecutado el sistema en un entorno operativo existente y

frecuentemente utilizado?

6) ¿Requiere el sistema entrada de datos interactivo?

7) ¿Requiere la entrada de datos interactivo que las transiciones de entrada se

lleven a cabo sobre múltiples o variadas operaciones?

117
 8) ¿Se actualizan los archivos maestros en forma interactiva?

9) ¿son complejas las entradas, las salidas, los archivos o peticiones?

10) ¿es complejo el procesamiento interno?

11) ¿Se ha diseñado el código para ser reutilizable?

12) ¿Se han incluido en el diseño la conversión y la instalación?

13) ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes

organizaciones?

14) ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente
utilizada por el usuario?

Los valores constantes de la ecuación anterior y los factores de peso aplicados en

las encuestas de los ámbitos de información han sido determinados empíricamente.
Debe tenerse en cuenta que los puntos de característica y los puntos de función
representan lo mismo. "funcionalidad o utilidad" en forma de software.

Aplicando lo explicado al presente trabajo tenemos lo siguiente:

FACTOR DE
TOTALES
PESO
Parámetro de medición M1 M2 M3 M4 M5 S M C T1 T2 T3 T4 T5 T
Num. de entradas de usuario 2 3 2 3 2 3 4 6 8 12 8 12 8 48
Num. De salidas de usuario 3 7 5 7 3 4 5 7 15 35 25 35 21 131
Num. De peticiones de usuario - 3 - 3 4 3 4 6 - 12 - 12 16 40
Numero de archivos 3 3 3 4 - 7 10 15 30 30 30 40 - 130
Numero de interfaces externas - - - - 4 5 7 10 - - - - 48 28
Cuenta total 377
Tabla 4.2. Factor de ponderacion
[Fuente: Elavoración Propia]

Donde M1 es el modulo de archivo, M2 modulo de control de actas, M3 modulo

registro de personal, M4 modulo de evaluación de desempeño y M5 modulo de
reportes. 377 es la sumatoria de los resultados de los 5 módulos debido a eso se
divide por los cinco módulos utilizados siendo este resultado igual a 75.4

118
 Para el cálculo de la SUM (F¡) hacemos:

Fi FACTORES CALIFICACION VALOR

1 ¿Requiere el sistema copias de seguridad y recuperación fiable? En prioridad 5
2 ¿Se requiere comunicación de datos? Es necesario 4
3 ¿Existen funciones de procesamiento distribuido? Es necesario 4
4 ¿Es crítico el rendimiento? No afecta 1

¿Será ejecutado el sistema en un entorno operativo existente Ayudaría

5 5
y frecuentemente utilizado? medianamente
6 ¿Requiere el sistema entrada de datos interactivo? No afecta 4

7 ¿Requiere la entrada de datos interactivo que las transiciones Es necesario 1

de entrada se lleven a cabo sobre múltiples o variadas operaciones?
8 ¿Se actualizan los archivos maestros en forma interactiva? Es necesario 4
Ayudaría
9 2
¿son complejas las entradas, las salidas, los archivos o peticiones? medianamente
10 ¿es complejo el procesamiento interno? Seria útil 2
11 ¿Se ha diseñado el código para ser reutilizable? Es necesario 4
Ayudaría
12 3
¿Se han incluido en el diseño la conversión y la instalación? medianamente

13 ¿Se ha diseñado el sistema para soportar múltiples instalaciones Es necesario 4

en diferentes organizaciones?

14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser Es prioridad 5
fácilmente utilizada por el usuario?
48
Tabla 4.3. Factor de ponderacion
[Fuente: Elavoración Propia]

Ahora tenemos que:

PF = CUENTA _ TOTAL * [0.65 + 0.01 * SUM (fi))

PF = 75.4 * (0.65 + 0.01 * 48)

PF=75.4*(1.11)

PF = 83.694

Entonces decimos que el sistema tiene una funcionalidad del 83 %

3.9.2. SATISFACIÓN DEL USUARIO

La satisfacción del usuario es un factor que solo se la puede medir indirectamente

y está relacionado con el intento de cuantificar "lo amigable que puede ser el
software con el usuario", para ello cual se ha hecho uso de un cuestionario para

119
facilitar la evaluación de la facilidad de uso (FU) de sistema, basado en una escala
de evaluación.

ESCALA VALOR
Muy Buena 5
Bueno 4
Malo 3
Pésimo 2
Tabla 4.4. Factor de ponderacion
[Fuente: Elavoración Propia]

Se ha considerado el siguiente cuestionario, con el siguiente contenido:

PREGUNTA EVALUACIÓN
1 ¿Se ha satisfecho todos los requerimientos establecidos? 4
2 ¿Le resulta difícil recordar las órdenes y aprender las operaciones básicas? 4
3 ¿Considera usted que es una herramienta útil? 5
4 ¿Presenta la suficiente ayuda durante el tiempo que accede al sistema? 4
5 ¿Cómo considera el formato de las salidas que genera el sistema? 3
6 ¿El sistema tiene la seguridad necesaria? 3
7 ¿Los reportes que representa son lo suficientemente representativos? 4
¿La generación de estadísticas y proyecciones le ayuda al proceso de toma de
8
decisiones? 4
9 ¿Cómo le parece el tiempo de ejecución de tareas? 3
TOTAL 34
Tabla 4.5. Evaluación para cuestionario FU
[Fuente: Elavoración Propia]

En base al cuestionaría, se calcula la facilidad de uso:

FU = [(SUM x, /n)*100] /5]

Donde:

FU = [(34/9)*100] /5]

FU = 75.5555 %; La facilidad de Uso es buena

120
3.9.3. PORTABILIDAD

Se define como el esfuerzo necesario para transferir el programa de un entorno

(hardware/software) a otro entorno diferente.

Es importante tomar en cuenta la plataforma, el hardware y los datos. Para el

presente podemos hacer el siguiente análisis:

1. La plataforma: Al ser un sistema que se construye en el lenguaje php la

plataforma es indistinta, por lo que es soportado por plataformas LlNUX o
WINDOWS.

2. El hardware: Este sistema no usa demasiados recursos que puedan exigir

mucho, en cuanto a hardware se refiere, por lo que el cambio de hardware no
afectaría en gran medida.

3. Los datos: Se uso el motor de base de datos MySQL, en este motor existe
muchas facilidades para realizar la migración de los datos a cualquier otro
motor de base de datos o exportar a otros formatos como hojas electrónicas o
procesadores de datos.

3.9.1. CONFIABILIDAD

La confiabilidad es una de las métricas más importantes, cuya definición se

encuentra en términos estadísticos como la probabilidad de operación libre de fallos
del sistema en un entorno determinado y durante un tiempo especifico.

El análisis de confiabilidad de los sistemas se lo realiza en base al modelo del

sistema figura siguiente, donde se observa las interconexiones de los subsistemas.

121
 REGISTRO DE
DATOS

Figura 4.1. Modelo del Sistema

[Fuente: Elavoración Propia]

La formalización del modelo del sistema se realiza mediante funciones de

transferencia; analizando el sistema con este enfoque obtenemos la función de
transferencia etiquetando cada subsistema como se muestra en la figura 3.

.
Figura 4.2. Diagrama de Bloques
[Fuente: Elavoración Propia]

Cada uno de los G¡ representa la función de transferencia de los subsistemas y de

acuerdo a las interconexiones entre los mismos, la confiabilidad se obtiene y observa
en la tabla, considerando la ecuación:

122
 G(t) λ P(t) e^(-λP(t))
G1(t) 0,1 0,3 0,97
G2(t) 0,4 0,3 0,88
G3(t) 0,2 0,3 0,94
G4(t) 0,4 0,3 0,88
G5(t) 0,4 0,3 0,88
G6(t) 0,1 0,3 0,97
Tabla 4.6. Confiabilidad de los subsistemas
[Fuente: Elavoración Propia]

Considerando los valores encontrados en la tabla 4.9, se tiene los siguientes

resultados de acuerdo a las ecuaciones

G¡(t) = G1(t) * G2(t) * ... * Gn(t)

G¡(t) = 1 - [1 - G1(t)] * [1 - G2(t)] *.... * [1 - Gn(t)]

Para los subsistemas en paralelo

Ga(t) = 1 - (1 - G2) * (1 - G3) * (1 - Gb)

Ga(t) = 1 - (0,12) * (0,06) * (0,225)
Ga(t) = 1 - 0,00162
Ga(t) = 0,99

Para los subsistemas en serie

Gb(t) = G4*G5
Gb(t) = 0.88 * 0.88
Gb(t) = 0,774
Gf(t) = G1 *Ga* G6
Gf(t) = 0,97 * 0,99 * 0,97
Gf(t) = 0,9314

Por lo tanto el grado de confiabilidad del sistema de Administración de Información

de la Unidad de Nutrición y alimentación Complementaria Escolar es de 93%, dando
a entender que el 93% de las veces funciona libre de fallos y un 7% de las veces el
sistema pasara por errores que no llegaran a ocasionar grandes problemas en el
funcionamiento total del sistema.

123
3.10. CONTRIBUCIÓN DEL SISTEMA SCANIIF

La contribución del desarrollo del sistema SIAC, se refleja en los siguientes

aspectos:

• Los Estados Financieros es tareas más importante del Sistema SCANIIF,

debido a que esta se centra n las Normas Internacionales de Información
Financiera, Por otro lado mediante el uso del sistema SCANIIF se garantiza
que el proceso de contabilización es realizado de manera automática
reduciendo considerablemente los errores que se generaban con la ejecución
de Técnicas de Contabilidad, en el proceso mencionado.

Además se debe considerar que el sistema SCANIIF se adecúa a cualquier

cambio ylo modificación que pueda realizarse a la normativa emitida por el
Concejo Técnico Nacional (CTNAC), relacionada con el proceso de
contabilidad.

• La aplicación de la metodología eXtreme Programming hace posible que los

usuarios participen continuamente en el proceso de desarrollo del sistema
SCANIIF. Desde la generación de las historias de usuarios hasta la entrega de
los últimos productos en cada iteración se garantiza la conformidad del usuario
con el sistema SCANIIF.

• El proceso de testing permite evaluar constantemente la calidad garantizando

de ésta forma el correcto funcionamiento del sistema.

• La entrega de los productos en cada iteración, permite al usuario final revisar y

dar su opinión con relación a las interfaces gráficas, los resultados del
proceso. De esta manera los cambios se van realizando conforme se realizan
ras entregas reduciendo el tiempo de corrección ylo modificación una vez
terminado el sistema.

• La aplicación del lenguaje de modelado WebML sobre el proyecto de

desarrollo de un Sistema, permite facilitar el desarrollo del mismo, puesto que
es un lenguaje orientado a datos al igual que la metodología XP.

124
• La seguridad del sistema en cuanto a acceso restringido, se tomó en cuenta
mediante la aplicación de ciertos aspectos relacionados con la norma ISO
15408.

Se realizaron las pruebas en cada iteración con los usuarios respectivos para
poder obtener su aceptación con relación al funcionamiento del sistema, lo
cual está reflejado en las historias de usuarios con la firma del usuario en
señal de conformidad.

125
4. CONCLUCIONES Y RECOMENDACIONES

Una vez finalizado el desarrollo del Sistema Web Contable Acorde a las Normas
Internacionales de Información Financiera (SCANIIF), mediante la aplicación de la
metodología propuesta, es posible formular las siguientes conclusiones:

• El objetivo general del proyecto, el cual es: "Diseñar un sistema web contable
acorde a las normas internacionales de información financiera en una
Universidad Pública de El Alto, que facilite fa tarea de contabilización y
presentación de estados financieros”, ha sido alcanzado mediante el uso de la
Metodología eXtreme Programming.

• El desarrollo de prototipo de sistema web contable, ha sido alcanzado con el

desarrollo del sistema SCANIIF lo cual puede ser verificado a través de las
historias de usuario firmadas por los usuarios finales en señal de conformidad.
Adicionalmente, la implementación del sistema SCANIIF logrará reducir el
tiempo y dinero invertidos.

• Como se muestra en el Anexo 11, el sistema SCANIIF automatiza los

procesos de contabilización. solicitando al usuario sólo la introducción del
comprobante a partir del cual se genera todo el ciclo de la contabilidad.
Posteriormente el sistema SCANIIF Matiza el análisis de la base de datos de
la contabilidad y emite los resultados (excepciones). A diferencia de fa
situación actual, el usuario no tiene que realizar mayor análisis ni operaciones
con la base de datos proporcionada.

• Se recomienda que se use el Sistema SCANIIF, como base para un sistema

integral de contabilidad. El cual cubra nuevos requerimientos que en el trabajo de
las empresas dedicadas a la contabilidad, dedicadas al rubro Financiero.
Asimismo, se recomienda que para trabajos futuros con las mismas
características, se proceda a utilizar otro lenguaje de programación, como' ser
Java, debido a su enfoque orientado a objetos y dadas las herramientas de
acceso gratuito para aplicar métricas de calidad al código.

126
BIBLIOGRAFIA

[1] NIIF. “Normas Internacionales de Información Financiera”. 2010

CTNAC.“Consejo Técnico Nacional de Auditoria y contabilidad”.2010
[2] NIC. “Normas Internacionales de Contabilidad”
CTNAC.“Consejo Técnico Nacional de Auditoria y contabilidad”.2010
[3] Pressman, R. “Ingeniería de Software – Un enfoque Practico”. 2005
5ta. EDICION
[4] Resolución Nº 04/2010
CTNAC.“Consejo Técnico Nacional de Auditoria y contabilidad”.2010
[5] Resolución Nº 05/2010
CTNAC. “Consejo Técnico Nacional de Auditoria y contabilidad”.2010
[6] Resolución Nº 06/2010
CTNAC. “Consejo Técnico Nacional de Auditoria y contabilidad”.2010
[7] Sampieri, R. “Metodología de la Investigación”. 2006
México
[8] J, R. “Tesis de Grado-Sistema de contabilidad”. 2006
Bolivia
[9] Galvis J, “Implementacion de un sistema web”. 2009
San José de Vutuca
[10] Colegio de Auditores de Bolivia
[Link]
20 de Mayo, 2011
[11] Colegio de Contadores de Bolivia
[Link]
14 de Mayo, 2011
[12] Desarrollo Web
[Link]
24 de septiembre, 2011
[13] Monografias
[Link]
25 de septiembre, 2011

127
ANEXOS

128
 CONSEJOTÉCNICONACIONATDEAUDITORIAY CONTABITIDAD
RESOLUCION
NOOLIaOO9
NORMASDECONTABILIDAD
Y AUDITORIA
VISTO:
Elproceso
de convergencia
a Normas
Internacionales
de contabilidad
y Auditoría
en Bolivia.
CONSIDERANDO:
Que,actualmente en Bolivia,
comoen todostospaíses del mundo,existela necesidad
de exponer
en los estadosfinancieroscon propósitos
generales,informaciónfinancieraconfiabte,
unifórme,
transparentey ,ssnlparable,siendonecesarioque se asegurea los múltiplesusuáriosde la
informaciónfinancieracon presentaciónrazonabley calida?,coadyuvando de este modoa la
propagación de las-expectativasexternaspara realizarinversione's,
actividadesproductivas
y
en el país.
comerciales

Que,el Colegiode Auditores

o Contadores Públicosde Bolivia(CAUB), ha suscritoun Convenio de
CooperaciónTécnicacon el BancoInteramericano de Desariollo (titO), denominado '.proyecto
ATN/MT-10078-BO Convergenciaa Normas Internacionales
de Contábilid'ad y Auditoría", proyecto
conel quese pretende contribuir
a que la informaciónfinancierade lasempresas queoperanen
Bolivia.
Siendoqueel objetivodel Proyecto es quelosprofesionalesy usuarios contábles'del país,
apliquennormascontablesy de auditoríaacordesa la normativainternacional (Noimas
Internacionales
de InformaciónFinanciera- NIIFy Normas Internacionales deAuditoría - Ñfnl.
Que,el mencionado Proyectose estructuraen tres componentes, siendoel Componente 1:
"Adecuaciónnormativaconlasnormasinternacionales', queestablece un plande convLrgencia de
lasnormas bolivianas
conlasnormasinternacionales (NIIF- NIA).Lasnüevas normas bolivianas
de contabilidady auditoríadesarrolladas en convergencia a las normasinternacionales,
reemplazarána las actualescatorce(14) normascontables y cinco(5) normasde auditoria
vigentes
en Bolivia.
Que,en el marcode ejecución del Proyectoy de acuerdo a lo establecido
en el Convenio suscrito
f conel BID,se ha constituidoel ComitéEjecutivo del Proyecto (CEP),conformado por el Comité
EjecutivoNacional del CAUBy los representantesde losnueveColegios Departamentales, Comité
quesiruede apoyoy coordinación en el proceso de discusión y consensode los borraáores de
normas,y queha aprobado la ResoluciónCEPNo01/2009, queestablece un criteriouniformey de
consenso de la profesión
contable , parael desarrollo
boliviana y aprobación
de lasnuevasnormas

[t bolivianas
en convergencia
tantode contabilidad
formato,estructura,
conlasnormasinternacionales,
y auditoríaque se desarrollen
contenidoy esenciade lasnormas
criterioqueestablece
en el marcodel Proyecto,
internacionales.
quelasnormas
mantendrán el

i,V
,
Que,se ha creadoel ComitéInterinstitucional,
Empresarios
Control
Privados
Socialde Empresas,
SantaCruz,Facultad
Seruicio
de Contaduría
de Impuestos
Pública
conformado
de Bolivia,CámaraNacional
por el CTNAC,
de Comercio,
Nacionales,
Cámara
de la Universidad
Confederación
de
Autoridadde Fiscalización
y
y Comercio
de Industria de
Autónoma "Gabrieliené Moreno,,
Asociación
Boliviana
de Firmasde Auditoríay Coordinacióndel Proyectoo Representantedel
-Cgmité EjFcutivoNacionaldel C^ltR. Fl Comité Tntcrinstifircinnal,
tiene comn firnrión rev¡sarlos
ProlongaciónÑuflo de ChavezN" 865 Calle Batallón ColoradosN" 162
Edif. Montecarlo P. 2 . Of 3A Edif. Batattón Colorados p. 2 . Of 202
F\IIf|!iliól:,::,::í'r:3e-12s8 retr/Fax
rs;t¡tz+i-ostt
Santa Cruz - Bolivia www. au d i to res co n tad o res bo liv i a. org
 orradoresde normas a nivelnacionaly
canalizadosa travésdel ConsejoTécnicoNacionalde Auditoríay Contabilidad, previoa su
aprobación final por parte del CAUBy de la autoridadcompetente del [Link] Comité
Interinstitucional
en su reuniónde fecha12 de noviembrede 2009,realizadaen la ciudadde La
Paz,aprobósu Reglamento Internoy plande trabajo,determinandoque en susdos próximas
reuniones aprobaráo rechazará los borradores
de normasdebidamente consensuados a nivel
nacional.

Que,comopartedel Componente 1: "Adecuación normativacon las normasinternacionales"

los
consultoresexpertosen normasde contabilidad y auditoríahan desarrollado, en estricto
cumplimiento a la Resolución0U2009del CEP,dieciséis(16) borradoresde normasde
contabilidad,
inclüyendoel MarcoConceptual y dieciséis
(16) borradoresde normasde auditoría,
incluyendoel Marcode Referencia; borradoresque han sido revisados y ajustadospor las
respectivas
Comisionesde Estudioy por el Consejoen Plenodel [Link] conformidad a los
Estatutosdel CAUBy al Reglamento Internodel CTNAC,los borradores de normasse han
circularizado y actoresinvolucrados
a todoslossectores en el proceso parasus
de convergencia,
pronunciamientos
respectivos técnicosconsusobservacionesy recomendaciones.

Que,cumplidos los plazosestablecidosen el ReglamentoInternodel CTNAC parael procesode

consenso, y habiéndose considerado y sugerencias
las obseruaciones recibidasde lasdiferentes
Institucionesconsultadas por partede lasComisiones de Estudiorespectivasy por el Consejo
en
Plenodel CTNAC. El CTNAC mediantecomunicación oficial,pusoen consideración del Comité
Interinstitucional
los dieciséis(16) borradores de normasde contabilidad,incluyendo el Marco
Conceptual y dieciséis(16)borradores de normasde auditoría,incluyendo
el Marcode Referencia,
consensuados a nivelnacíonalparasu revisióny aprobación.

Que,el ComitéInterinstitucional, de fechas21 de noviembre

en susreuniones y 4 de diciembrede
2009,realizadasen la ciudadde SantaCruz,consideró y aprobópor unanimidad las primeras
(16)normas
dieciséis de contabilidad, el MarcoConceptual
incluyendo y dieciséis(16)normas de
incluyendo
auditoría, el Marcode Referencia,consensuadasa nivelnacional,
lascualestendránla
mismanumeración, formatoy esenciade las normasinternacionales y en su denominación
solamente seleseliminarála palabra y desusiglaseeliminará
"Internacional" la letra"I".
f Que,habiéndose contodoel proceso
concluido porel Reglamento
establecido InternodelCTNAC,
I parala elaboración,
revisióny aprobaciónde una"Norma"y de conformidad al Artículo47 del
+ Estatutodel CAUB,que establece
discutir, promover
elaborar,
serhomologadasporel Consejo
que el CTNAC
y proponernormas
Nacional
es el órganotécnicofacultadoparaanalizar,
y auditoría,
de contabilidad
delCAUB.
lasmismas quedeben

PORTANTO:

EtcoNsEJorÉcNrco NACToNAL DEAuDrroRÍA Y CoNTABTLTDAD (CTNAC)del CAU4

Internoy en usode susfacultades
consu Reglamento
de conformidad porlosEstatutos
otorgadas
delColegio
deAuditores Públicos
o Contadores de -
Bolivia CAUB.

ProlongacíónÑuflo de ChovezN" 865 Calle Batallón ColoradosN' I62

Edif. Montecarlo P. 2 . Of 3A Edif, Batallón ColoradosP. 2 'Of. 202
Telf/Fax:(59I -3) 339-l 257' 339-1258 Telf/Fax:(59I -2) 244-03I I
E-mail: ctnac@cotas,[Link] La Paz - Bolivia
SantaCruz - Bolivia [Link] [Link]
 PRIMERO
Aprobarlas siguientes (16) Normasde Contabilidad,
dieciséis incluyendo y
el MarcoConceptual
(16) Normasde Auditoría,
dieciséis incluyendo las mismasquetendrán
el Marcode Referencia,
vigenciay aplicación
en todo el territorionacional
como"NormasGeneralmente Aceptadas"
en
y cuyodetalleesel siguiente:
Bolivia,

Normasde Contabilidad (NC)

Marcoconceptual parala preparación y presentaciónde losestados financieros
NC 1 Presentación deestados financieros
NC 2 Inventario$'
NC 7 Estados de flujosde efectivo
NC 8 Políticas
contables, cambios en lasestimaciones contablesy errores
NC10 Hechos ocurridos después de la fechadelbalance
NC16 Propiedad,plantay equipo
NC17 Arrendamientos
NC18 Ingresosde actividades ordinarias
NC21 Efectosde lasvariaciones en lastasasdecambiode la moneda extranjera
NC23 Costosporpréstamos
NC29 Información financieraen economías hiperinflacionarias
NC37 Provisiones,activoscontingentes y pasivoscontingentes
NC41 Agricultura
NIF5 Activos
nocorrientes mantenidos parala ventay operacionesdiscontinuadas
NIF7 Instrumentos financieros:
Información a revelar
Normasde AuditoríalNAl
Marcode referenciaparatrabajosparaatestiguar
y principios
NA200 Objetivo generales quegobiernan unaauditoria
de estados financieros
NA210 Términosde lostrabajosde auditoria
de calidadparaauditorias
NA220 Control de información financiera
histórica
NA230 Documentación de auditoria
NA240 Responsabilidaddelauditorde considerar el fraudeen unaauditoria de estadosfinancieros
NA250 Consideración
de leyesreglamentos en unaauditoria de estados financieros
NA260 Comunicación de asuntosde auditoríia con los encargados del gobiernocorporativo
NA300 Planeación
de unaauditoría de estadosfinancieros
NA315 Entendimientode la entidady su entornoy evaluación de los riesgosde representación
de importancia
errónea relativa
NA320Importanciarelativade la auditoría
NA330Procedimientosdelauditoren respuesta a losriesgos evaluados
NA402Consideracionesde auditoríarelativas
a entidades queutilizanorganizacionesde servicio
NA500Evidencia
de auditoría
NA501Evidencia
de auditoría-Consideracionesadicionales parapartidasespecíficas
NA505Confirmacionessiguientes externas

ProlongaciónÑuflo de ChávezN' 865 Calle Batallón ColoradosN" 162

Edif. Montecarlo P. 2 . Of. 3A Edif. Batallón Colorados P. 2 . Of 202
Telf/Fax:(591-3) 339-I 257 . 339-I 258 Telf/Fax:(59I -2) 244-03I I
E -mail: ctnac@[Link] La Paz - Bolivia
Sanfa Cruz - Bolivia [Link] torescontadoresboIivi [Link]
 E SEGUNDO
todoslospronunciamientos
Abrogar quefuerancontrarios
técnicos en la presente
a losaprobados
Resol
ución,específicamente
las siguientesnormasnacionales:

Normas de Contabilidad
NCNo1 Principios de contabilidadgeneralmente aceptados
NCNo2 Tratamientocontablede hechosposteriores al cierredel ejercicio
NCNo3 Estados financierosa monedaconstante(ajustepor inflación)
NCNo4 Revalorización técnicade activosfrjos
NCNo5 Principios de contabilidadparala industriaminera
NCNo6 Tratarilíento contablesde lasdiferencias de cambio
NCNo7 Valuación de inversionespermanentes
NCNoI Consolidaciónde estadosfinancieros
NCNo9 Normade contabilidad parala industriapetrolera
NCNo10 Tratamientocontablede losarrendamientos
NCNo11 Informaciónesencialrequeridaparaunaadecuada exposición de losestadosfinancieros
NCNo12 Tratamientocontablede operaciones en monedaextranjeracuandocoexistenmás de un tipo
de cambio
NCNo13 Cambioscontablesy su exposición
NCNo14 Políticas
contablessu exposición y revelación

Normas de Auditoría
NANo I NormasBásicasde Auditoríade Estados financieros
NANo 2 Normasrelativasa la emisiónde dictámenes
NA NO 3 Planificación
delTrabajodeAuditoría
NA NO 4 NormaRelativaa la emisión conpropósitos
de informes tributarios
NA NO 5 Documentos delAuditor

TERCERO
Aprobarla adopciónen Boliviade las NORMASINTERNACIONALES DE INFORITIACIóN
FINANCIERA - NIIF (IFRS por su siglaen inglés),emitidaspor El Consejode Normas
Internacionales de Contabilidad (IASB por su sigla en inglés) y las NORMAS
INTERNACIONATES DE AUDITORIA- NIA (ISA por su siglaen inglés)emitidaspor la
FederaciónInternacionalde Contadorcs(IFACpor su siglaen inglés),parasu aplicación

II únicamente
locales
en ausencia
sobreasuntos

APROBACTóN:
de pronunciamientos
determinados.
del paíso reglamentaciones
técnicosespecfficos

y contabilidad
Estasnormastécnicasde auditoría fueronaprobadas por el Consejo en Plenodel

4n
Consejo
TécnicoNacional y
de Auditoría Contabilidad
en su reuniónordinariadel díaviernes4 de
diciembre
de 2009,conel votofavorabledetodossusmiembros:

Presidente: [Link]ércerosFernández
Vi
I
Vicepresidente: [Link]
Secretario:
Arias
[Link]éEdwinNatuschMelqar
ProlongaciónÑuflo de ChávezN'865 Calle Batallón ColoradosN' 162
Edif. Montecarlo P. 2 . Of 3A Edif. Batallón Colorados P. 2 . Of. 202
Telf/Fax:(59I -3) 339-I 25 7' 339-I 258 Telf/Fax:(59I -2) 244-03I I
E-mail: ctnac@cotas. [Link] La Paz - Bolivia
Santa Cruz - Bolivia [Link] oresconÍadoresboliv [Link]
 [Link]
Lic.VíctorWilfredoChugarZubieta

VIGENCIA:
Estospronunciamientos técnicostendránvigenciaa partirdel 1 de enerode 20LL,losmismosque
debenser homologados por el ConsejoNacionaldel [Link] su aplicación
anticipada.
Si
unaentidadaplicaseestasnormascontablesen un períodoanterior,revelaráestehecho;asícomo,
si un auditoro firmade auditoriaaplicaseestasnormasde auditoriade formaanticipada, deben
tomar las previsionesque implicanutilizarestasnormasen los compromisos asumidosy en el
alcancede su trabajo.

Es dado en la sala de reunionesdel ConsejoTécnicoNacionalde Auditoríay Contabilidad del

Colegiode Auditoreso ContadoresPúblicosde Bolivia,en la ciudadde SantaCruzde la Sierra,a
loscuatrodíasdel mesde diciembredelañodosmil nueve.

|
.--.-".. - l.-r-
¡ l-
" , íf..
i l l
-j¡JI '':';'
'[lcJosé
EdfinrNatusch
Melgar
SECRETARIOGENERAL PRESIDENTE

ProlongaciónÑuflo de ChávezN'865 CalleBatallónColoradosN'162

Edif. Montecarlo P. 2 . Of. 3A Edif. Batallón ColoradosP. 2 . Of. 202
Telf/Fax:(591-3) 339-I 257 . 339-1258 TelfFar. (591-2)244-0311
E-mail: cfnac@.[Link] La Paz - Bolivia
SantaCruz - Folivia wwry,.auditorescontadoresboIivi [Link]
 COTDGIOIID AUIIITONDSO CONTAIIONDS
pÚntICOS DD BOTIYIA. CAUB
JuníorcnR.S.Ne209343 DEg DEJuLtoos l99l
PERsoNALrDno

coLEGroDEAUDTToRES
o coNTADones púelrcos DEBoLtvrA
comrÉ EJEcurvo NAcToNAL
REsoLUctóNNocrNAc oazoag
ASOCTADO 21-12-2009
A:

NóRññAüDE ¡NFORifiAcÉNFiNAi¡eiERA- i'¡iFüNCLUYENiáS NORi¡iASDE

coNTABtLtDAD- NC)BOL|VIANAS,EN CONVERGENCIA CONLAS NORMAS
INTERNACIONALES DE INFORi,IACION FINANCIERAS(NllF)

VISTOS:
El trabajode las Comisionesde Estudiodel GonsejoTécnicoNacionalde Auditoríay Contabilidad
y
el proceso de Convergenciaa Normes Internacionales
de y
Contabiiiüaü Aiiditoríaen Boiiüa.

IFAC CONSIDERANDO:
Que, de conformidadal Artículo47 del EstatutoOrgánicodel CAUB,el ConsejoTécnicoNacional
de Auditoriay Contabilidad(CTNAC)es el órganotécnicoespecializado de la profesióncontable,
para analizar,díscutir,elaborary proponerrecomendaciones y decisionesrelativasa resoluciones,
. reglamentos,interpretaciones y normasde auditoríay contabilidad,acordesa los lineamientos
L establecidospor ios organismosinternacionales,
cielos cuaieses miembroei Colegiode Auditores
o ContadoresPúblicosde Bolivia.
CI L E A
Que, ei Coiegiode At¡diioreso ConiadoresPúbliessde Boiivia(CAUB),suseribiéun Conveniode
CooperaciónTécnicaoon el Banoo Interamericano de Desanollo(BlD), denominado"Proyecto
ATN/MT-1007&BO, Convergencia a NormasIntemacionales de Contabilidady Auditoría",para el
desarrollode Normasde Información Financiera(incluyelae Normasde Contabilidad) y de Normas

tl
de Auditoríaen Bolivia,que permitanexponeren los estadosfinancieroscon propósitosgenerales,
informaciónfinancieraconfiable,uniforme,transparentey comparableque asegurea los múltiples
usueriosde la informaciónfinenciere,una presentaciónrezonabley de celided,que incentivey
posibiliterealizarinversionesy ac'tividadesproductivasy comercialesen nuestropaís.
Atc
Qce, en el marco Cel Proyectode Qonverganeia a NormasInbmacionalesde eentabilidady
Auditoría,el CTNACen coordinación los
con colegiosdepartamentales y el Comitélnterinstitucional
por
conformado instituciones públicasy privadas relacionadas
con la profesióncontable,ha venido
desarrollando, analizandoy consensuando las nuevasNormasde Información Financieray Normas

CB
CPB
de Auditoríaen Boliüa,en convergencia conlas NormasInternacionales.

Que, el GonsejoTécnicoNacionalde Auditoriay Contabilidad,en su reuniónde fecha (X de

diciembrede 2009,luegode habercumplidocontodoslos procedimientosestablecidos
en nuestros
estatutosy reglamentos,con el voto favorablede todos sus miembrosdel Consejoen Pleno,
medianteResoluciónNo 01/2009,aprobó dieciséis (16) Normas de Información Financiera
(incluyen las Normas rie Gontabiiidad y el Marco Gonceptuai para ia Preparación y
Presentación de Estados Financieros), desanolladasen convergenciacon las l{ormas
Internacionalesde InformaciónFinanciera(NllF).

Que, las dieciséis (16) Normas de Información Financiera (incluyen las Normas de
Gontabilidad y el Marco Conceptual para la Preparacion y Presentación de Estados
Finaneierosi, de confonnidad a nuestros estaiutos, f¡¡er-orrco¡'rsideiadas,aprriiradas y
homologadasen el Segundo Consejo Nacional Ordinario2009 del Colegio de Auditores o
ContadoresPúblicosde Bolivia,realizadoen la ciudadSucreel dfa 19de diciembrede 2009.

[Link]
Corazón No16l . Telf:(591-4) 6480949 . Fax:(591-4) 6462915.
[Link]
CalleBgtallón # [Link]ón
Colorados Colorados P,2 . 0f. 202. Telf/Fax:
(591-212M-0311. [Link]
Prolongación # 865. [Link]
ÑuflodeChávez P,2 . Dpto,3A. Telf/Fax: (591-3) . ggg-tZ5g
339-12áZ . [Link]
E-mail:caub@cotas,[Link] . [Link]
 O O I N G I OD D A U D I T O N D SO COITTADORDS
P Ú N L I O O SD D B O T I V I A . C A U B
JuniorcnR.S.Ne209343 oe 9 oe JuLroDEl99l
PERsoNALrDlo

PORTANTO:
El Comité EjecutivoNacionaldel Colegio de Auditoreso ContadoresPúblicosde Bolivia,de
conformidadcon ei reglamentointernodei eonsejoTécnacoNacionalde Auditoriay Contabiiidaci,
y
ASOCTADO por
A: en usode lasfacuftadesotorgadas losestatutosdel CAUB.

KtsüUtsLVE:

ARTICULOPRIMERO.-
Promulgar y publicar las dieciséis (16) Normas de InformaciónFinanciera(incluyen las
Normas de Contabilidad y ei ñiarco Gonceptual para ia Preparación y Presentación de
Estados Financieros),aprobadaspor el ConsejoTécnicoNacionalde Audítoríay Contabilidad,
medianteResoluciónNo0112009, de fechaM de diciembrede 2009y homologadas porel Consejo
NacionaldeiCAijB,en su reunióncieiechai9 de de
ciiciembre 2009,
cuyodetaiie
es ei siguiente:
IFAC
. Marcoconceptualparala preparación y presentaciónde los estadosfinancieros
. Normade informaciónfinancieraNo5 (NlF-s);Activosno conientesmantenidosparala ventay
operaciones discontinuadas
r o Normade informaciónfinancieraNo7 (NlF-7):Instrumentos financieros:Informacióna revelar
h oNormade contabilidad No1 (NC 1): Presentación de estadosfinancieros
. Normade contabilidadNo2 (NC2): lnventarios
CILEA . Normade contabilidadNo7 (NC7): Estadosde flujosde efectivo
. Normade contabilidadNo8 (NC8): Políticascontables, cambiosen lasestimaciones contables
y enores
o Normade contabilidadNo10 (NC 10):Hechosocunidosdespuésde la fechadel balance
. Normade contabilidadNo16 (NC16):Propiedad, plantay equipo

tl
Atc
. Normade contabilidad
c Normade contabilidad
. Normade contabilidad

. Normade contabilidad
o Normade contabilidad
No17 (NC 17):Anendamientos
No18 (NC18):Ingresosde actividades
No21 (NC21):Efectosde lasvariaciones
monedaextranjera
No23 (NC23):Costospor préstamos
ordinarias
en lastasasde cambiode la

No29 (NC29): lnfonnaciónftnancieraen economlashiperinflacionarias

. Normade contabilidadNo37 (NC37):Provisiones, activoscontingentes y pasivoscontingentes
. Normade contabilidadNo41 (NC41):Agricultura

CB
CP B
ARTICULOSEGUNDO..
Disponerla vigenciade las dieciséis(16) Normasde fnformaciónFinanciera(incluyenlas Normas
de Contabilidady el MarcoConceptualparala Preparación y Presentación de EstadosFinancieros)
mencionacias, en ios periociosanuaiesque comien@na partirciel ciía üi cie enero cie 20ii,
teniendocomo alcancede aplicación,en todo el territorionacional,para todos los profesionales
vinculadoscon la profesióncontabley de auditoría,tomandopor lo tanto la categoríade "Normas
Generaimente Aee$adaí en [Link] una enüdadapiieasede foma áñiie¡pada csies ñoimes,
revelaráestehecho.

ARTICULCTERCERO.-
Abrogartodoslos pronunciamientostécnicosque fuerancontrariosa los aprobadosen la presente
específicamentelas siguientesnormasde contabilidadnacionales:
Resolucién,

Nomlas de Gontabilidadabrooadas
generalmente
NC N' I Principiosde contabilidad aceptados
[Link]
Corazón No16l . Telf:(591
-4)6480949 . Fax:(591 5 . Sucre- Bolivia
-4)646291
GaffeBatallón # 162. [Link]ón
Colorados Colorados P.2 . Of.202,felflFax: , LaPaz-Bolivia
(591-21244-031'l
ProlongaciónÑuflodeChávez#[Link],[Link]/Fax:(59,|-3)[Link]
E-mail:
caub@[Link] . [Link]
 C O I D G I O D N A U I I I T O R N SO O O I T T A I I O R D S
p Ú n T I C O S I D DB O I I Y I A . O A U B
Juníorcl R.S.Ne209348 DEg DEJulro DEl99l
PERsoNALrDlo

NC N'2 Tratamiento contablede hechosposteriores al cierredelejercicio

NC N" 3 Estados financierosa moneda constante (ajuste por inflaciÓn)
Ne N'+ Revaiorización técnicacieactivosfijos
ASOCTADONC N" 5 Príncípios de contabiÍídadparafa industriaminera
A:
NC N" 6 Tratamientocontablesde las diferenciasde cambio
NC N'7 Valuación de inversionespermanentes
NC N'I Consolidación de estadosfinancieros
NC N" I Normade contabilidad parala industriapetrolera
NC i.i" 10Tratamientoeontabiede ios anendamientos
NC N" 11 Información esencialrequeridaparaunaadecuadaexposiciónde los estadosfinancieros
NC N" 12 Tratamientocontablede operaciones en monedaextranjeracuandocoexistenmás de un tipo
¡a ^ámtni^
ug vgttlgtv

NC N" 13Cambioscontables y su exposición

IFAC NC N" 14 Políticascontables y revelación
su exposiciÓn

ARNCULOCUARTO.-
Aprobar la adopción en Bolivia de tas NORilAS INTERNACIONALES DE INFORilAGóN
_ FTNANGTERA - NllF (IFRS por su sigfa en ingfés), emitidas Bor El Gone€-lqde Ncrnnas
t para su aplicaciónúnicamenteen
Internacionatesde Gontabilidad(IASB por su siglaen ingrlés),
ausenciade pronunciamientos técnicosespecíficosdel país o reglamentaciones locales sobre
CILEA asuntosdeterminados.

Es dado en la sala de reunionesdel Comité EjecutivoNacionaldel Colegio de Auditoreso

ContadoresPúblicosde Boliüa,en la ciudadde Sucre,a los veintiúndías mes de diciembredel
año dosmii nueve.

ll
Arc
r\r
ñ,r\
u. r{"}5lio
*¿ [Link]
SECRETARIO
GENERAL PRES¡DENTE

CBCPB

[Link]
CorazónN0161. Telf:(591-4) . Fax:(591-4)
6480949 Sucre- Bolivia
6462915.
CaffeBgtallónColorados#[Link]ónColoradosP.2.0f,[Link]/Fax:(591-2)244-03'11,LaPaz
ProlongaciónÑuflodeChávez#[Link]/Fax:(591-3)[Link]
E-mail:
caub@[Link] . [Link]