Embed Size (px)
DESCRIPTION
SISTEMA DE GESTIÓN CONTABLE VÍA WEB PARA EL SERVICIO DE OUTSOURCING
Citation preview
Universidad Mayor de San Andrés Facultad de Ciencias Puras y Naturales
Carrera de Informática
PROYECTO DE GRADO
SISTEMA DE GESTIÓN CONTABLE VÍA WEB PARA EL SERVICIO
DE OUTSOURCING
Caso: MAERO CONSULTORA MULTIDISCIPLINARIA S.R.L.
PARA OPTAR AL TITULO DE LICENCIATURA EN INFORMÁTICA
MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS
Postulante: Adán Franklin Torrico Ordoñez.
Tutor: M. Sc. Fátima Dolz de Moreno
Revisor: Lic. Javier Reyes Pacheco
La Paz – Bolivia
2011
DEDICATORIA
Con mucho cariño: A mi madre quien con su paciencia, su amor y su fortaleza me dio un apoyo incondicional en momentos difíciles. A mi tío Abel a quien considero como mi padre, me apoyo en todo momento y me dio fuerzas para seguir adelante.
A mi abuelita Julia, por confiar en mí, darme su cariño y protección todo el tiempo que estuvo con nosotros. A mis seres queridos que con sus bendiciones hicieron posible conseguir llegar a la meta anhelada…
GRACIAS
AGRADECIMIENTOS
Mis agradecimientos a todas las personas que hicieron posible culminar el presente
trabajo de manera satisfactoria.
A mi madre, mis hermanos y mi familia por su amor, confianza y comprensión.
A la Lic. M. Sc. Fátima Dolz de Moreno, quien como Docente Tutor fue la guía del
presente proyecto, por su paciencia, sus consejos, observaciones y por el tiempo
invertido al momento de evaluar el trabajo.
Al Lic. Javier Reyes Pacheco, quien como docente Revisor, me dio su apoyo
incondicional y consejos por lo que pude seguir adelante con el presente proyecto.
Agradecimiento a los Licenciados de la Carrera de Informática, por los
conocimientos transmitidos durante el tiempo de mi formación.
A la institución “MAERO CONSULTORA MULTIDISCIPLINARIA S.R.L.” por
permitirme desarrollar el presente Proyecto de Grado, por guiarme en el desarrollo
del Sistema, el apoyo incondicional que me brindaron y las lecciones valiosas que
recibí.
A todas las personas que me dieron su apoyo y colaboración en todo momento, a
mis compañeros, a mis amigos con quienes compartimos alegrías y tristezas; a Don
Daniel y Don Fernando por la paciencia, amabilidad y disposición que siempre
tuvieron.
Muchas Gracias…
RESUMEN
El presente Proyecto de Grado titulado: ”Sistema de gestión contable vía Web para
el servicio de Outsourcing” desarrollado para la empresa MAERO CONSULTORA
MULTIDISCIPLINARIA S.R.L., muestra el desarrollo del sistema y la documentación
que necesita de acuerdo a las metodologías aplicadas.
En la búsqueda de la optimización de los procesos y la productividad, es requerido
que las empresas se dediquen más a cumplir con su razón de ser, y busquen ayuda
de terceros para suplir las otras necesidades, es por esto que nace
la subcontratación más conocido por "outsourcing", lo cual nos lleva al Outsourcing
Contable, que consiste en el procesamiento, análisis de la información para la
elaboración de estados financieros, y el cumplimiento de aspectos formales de
presentación de los registros contables, con el objetivo de proveer a las direcciones
de la organización información precisa de la gestión para orientar sus decisiones y
estrategias de negocio.
En este trabajo se creó un nuevo sistema de gestión contable, el cual tiene la
singularidad de funcionar vía Web, balancear la carga de procesos entre el cliente y
el servidor, soportar diferentes tipos de empresas con sus respectivas gestiones
contables, permitiendo la centralización de la información, ofrecer a los clientes
accesibilidad en todo momento a su información contable, mejorar el servicio de
Outsourcing Contable y otros.
La gestión del desarrollo de software se realizo con la metodología Scrum que se
basa en el proceso iterativo e incremental utilizado en entornos basados en el
desarrollo ágil, para ello se uso la herramienta TeamTrick permitiendo mejorar el
control y seguimiento del proyecto, además, para una mejor compresión del sistema
se uso la metodología UWE que es un proceso de desarrollo para aplicaciones Web
enfocado sobre el diseño sistemático, la personalización y la generación
semiautomática, de escenarios que guíen el proceso de desarrollo, basado en las
técnicas de UML.
ÍNDICE
CAPITULO I: ............................................................................................................ 1
1. Presentación .......................................................................................................... 1
1.1 Introducción ......................................................................................................... 1
1.2 Antecedentes ...................................................................................................... 2
1.3 Planteamiento y formulación del problema.......................................................... 3
1.3.1 Problemática ............................................................................................ 3
1.3.2 Problema principal ................................................................................... 4
1.4 Objetivos ............................................................................................................. 4
1.4.1 Objetivo principal ..................................................................................... 4
1.4.2 Objetivos secundarios.............................................................................. 5
1.5 Justificación ......................................................................................................... 5
1.5.1 Justificación técnica ................................................................................. 5
1.5.2 Justificación económica ........................................................................... 5
1.5.3 Justificación social ................................................................................... 6
1.6 Metodología e instrumentos de medición ............................................................ 6
1.7 Alcances.............................................................................................................. 6
1.8 Limites ................................................................................................................. 6
1.9 Herramientas ....................................................................................................... 7
CAPITULO II ............................................................................................................ 8
2. MARCO TEÓRICO................................................................................................ 8
2. 1 Contabilidad ...................................................................................................... 8
2.1.1 Objetivo general de la contabilidad .......................................................... 8
2.1.2 Objetivos específicos ............................................................................... 9
2.1.3 Diseños de sistemas contables .............................................................. 9
2.1.4 Activo, Pasivo y Patrimonio ..................................................................... 9
2.1.5 Plan de cuentas ..................................................................................... 10
2.1.6 Libro diario ............................................................................................. 11
2.1.7 Libro mayor ............................................................................................ 11
2.1.8 Balance de comprobación ..................................................................... 11
2.1.9 Balance de general ................................................................................ 12
2.1.10 Estado de resultados ........................................................................... 12
2.1.11 Hoja de trabajo de diez columnas........................................................ 12
2.1.12 Software del libro de compras y ventas (IVA) ...................................... 13
2. 2 Outsourcing ..................................................................................................... 13
2.2.1 Historia................................................................................................... 13
2.2.2 Definición ............................................................................................... 14
2.2.3 Outsourcing Contable ............................................................................ 14
2. 3 Metodología ágil ............................................................................................. 14
2.3.1 ¿Qué es una metodología ágil? ............................................................ 14
2.3.2 La alianza ágil ........................................................................................ 15
2.3.3 Metodologías ágiles vs tradicionales ..................................................... 15
2. 4 Metodología Scrum ........................................................................................ 16
2.4.1 Introducción ........................................................................................... 16
2.4.2 Elementos de Scrum.............................................................................. 17
2. 5 Metodología UWE ........................................................................................... 22
2.5.1 Modelo de casos de uso ........................................................................ 23
2.5.2 Modelo conceptual................................................................................. 24
2.5.3 Modelo navegacional ............................................................................. 24
2.5.4 Modelo de presentación......................................................................... 25
2. 6 Pruebas .......................................................................................................... 26
2.6.1 Test Unitarios......................................................................................... 26
2.6.2 Fallos de seguridad software ................................................................. 27
2.7 Calidad de Software .......................................................................................... 29
2.7.1 Métricas de calidad software ................................................................. 29
2.7.2 Factores de calidad ISO 9126 ............................................................... 29
CAPITULO III ........................................................................................................... 38
3. MARCO APLICATIVO ......................................................................................... 38
3. 1 Introducción ..................................................................................................... 38
3. 2 Recopilación y análisis de requerimientos....................................................... 38
3. 2.1 Recopilación de requerimientos ........................................................... 38
3. 2.2 Análisis de requerimientos ................................................................... 49
3. 3 Planificación y finalización de los Sprints ......................................................... 50
3. 3.1 Primer Sprint ........................................................................................ 50
3. 3.1.1 Modelo Conceptual ................................................................ 52
3. 3.1.2 Modelo Navegacional ............................................................. 55
3. 3.1.3 Modelo Presentacion .............................................................. 58
3.3.2 Segundo Sprint ..................................................................................... 71
3.3.3 Tercer Sprint ......................................................................................... 74
3.3.4 Cuarto Sprint ......................................................................................... 79
CAPITULO IV ............................................................................................................ 86
4. Calidad de Software ............................................................................................ 86
4.1 Pruebas (Test Unitarios) ................................................................................. 86
4.2 Fallos de seguridad software .......................................................................... 87
4.3 Norma ISO/IEC 9126....................................................................................... 88
4.3.1 Funcionalidad ....................................................................................... 88
4.3.2 Usabilidad ............................................................................................. 93
4.3.3 Confiabilidad ......................................................................................... 94
4.3.4 Mantenibilidad ....................................................................................... 95
4.3.5 Costo y tiempo ...................................................................................... 96
CAPITULO V ............................................................................................................. 99
CONCLUSIONES Y RECOMENDACIONES ............................................................ 99
5. 1 Conclusiones .................................................................................................. 99
5. 2 Recomendaciones......................................................................................... 100
5. 3 Bibliografía .................................................................................................... 101
ANEXOS ............................................................................................................... 103
Análisis de situación
DOCUMENTACIÓN
Aval Tutor (Aprobación)
Aval Revisor
Aval Institución
ÍNDICE DE FIGURAS Figura 2.1. Proceso del Sprint .................................................................................. 21
Figura 2.2. Representación de un caso de uso ......................................................... 23
Figura 2.3. Diagrama de Clases................................................................................ 24
Figura 2.4. Ejemplo de un modelo Navegacional ...................................................... 25
Figura 2.5. Ejemplo de un modelo de Presentación .................................................. 26
Figura 3.1. Diagrama de caso de uso “Acceder al sistema” ...................................... 38
Figura 3.2. Diagrama de caso de uso “Administración de Usuarios”......................... 40
Figura 3.3. Diagrama de caso de uso “Administración de las empresas” ................. 41
Figura 3.4. Diagrama de caso de uso “Administración Contable” ............................. 43
Figura 3.5. Diagrama de caso de uso “Administración del libro de compras y ventas” .................................................................................................................................. 45
Figura 3.6. Diagrama de caso de uso “Reportes Contables” .................................... 47
Figura 3.7. Product Backlog (pila del producto)......................................................... 49
Figura 3.8. Planificación del primer Sprint ................................................................. 50
Figura 3.9. Backlog del Primer Sprint ........................................................................ 51
Figura 3.10. Diagrama relacional de la base de datos maestra ................................ 52
Figura 3.11. Diagrama relacional de la gestión de una empresa .............................. 53
Figura 3.12. Modelo Conceptual (Diagrama de clases) ............................................ 54
Figura 3.13. Modelo Conceptual (Diagrama de clases) ............................................ 54
Figura 3.14. Modelo Navegacional del Administrador ............................................... 55
Figura 3.15. Modelo Navegacional del Contador ...................................................... 56
Figura 3.16. Modelo Navegacional del los clientes de MAERO S.R.L. ..................... 57
Figura 3.17. Interfaz de inicio al sistema ................................................................... 58
Figura 3.18. Interfaz de Administración de usuarios ................................................. 59
Figura 3.19. Interfaz de acceso al sistema ................................................................ 59
Figura 3.20. Interfaz de Administración de la gestión................................................ 60
Figura 3.21. Interfaz de Administración de las Empresas ......................................... 60
Figura 3.22. Interfaz de Administración del nivel ....................................................... 61
Figura 3.23. Interfaz del Plan de Cuentas ................................................................. 61
Figura 3.24. Interfaz de los Asientos Contables ........................................................ 62
Figura 3.25. Interfaz del Libro Diario ......................................................................... 62
Figura 3.26. Interfaz del Libro Mayor......................................................................... 63
Figura 3.27. Interfaz de la hoja de Trabajo................................................................ 63
Figura 3.28. Interfaz del Balance de Comprobación ................................................. 63
Figura 3.29. Interfaz del Estado de Resultados......................................................... 64
Figura 3.30. Interfaz del Balance General ................................................................. 65
Figura 3.31. Interfaz del Tipo de cambio del dólar .................................................... 65
Figura 3.32. Interfaz del Proveedor ........................................................................... 66
Figura 3.33. Interfaz del Libro de Compras ............................................................... 66
Figura 3.34. Interfaz del Cliente ................................................................................ 67
Figura 3.35. Interfaz del Libro de Ventas .................................................................. 67
Figura 3.36. Burndown del primer Sprint ................................................................... 68
Figura 3.37. Primera historia de usuario “Creación del modelo y la Base de datos” con sus respectivas actividades ................................................................................ 69
Figura 3.38. Segunda historia de usuario “Creación de los programas de inicio de sistema con sus respectivas tareas” ......................................................................... 70
Figura 3.39. Planificación del Segundo Sprint con sus respectivas historias de usuario ...................................................................................................................... 71
Figura 3.40. Burndown del Segundo Sprint............................................................... 72
Figura 3.41. Tercera historia de usuario “Creación del programa Adm. y de usuarios” con sus respectivas tareas ........................................................................................ 73
Figura 3.42. Cuarta historia de usuario “Creación del programa Adm. de las Empresas y Gestiones” con sus respectivas tereas .................................................. 73
Figura 3.43. Quinta historia de usuario “Creación de la Adm. de Clientes y Proveedores con sus respectivas tareas” ................................................................. 74
Figura 3.44. Planificación del Tercer Sprint con sus respectivas historias de usuario .................................................................................................................................. 75
Figura 3.45. Burndown del Tercer Sprint................................................................... 76
Figura 3.46. Sexta historia de usuario “Creación de Adm. Contable” con su primera tarea “Creación de programas relacionados con el plan de cuentas y asiento ” ....... 76
Figura 3.47 Segunda terea “Creación del Plan de Cuentas” de la Sexta historia de usuario ...................................................................................................................... 77
Figura 3.48. Pantalla del “Plan de Cuentas” ............................................................. 77
Figura 3.49. Tercera tarea “Creación del Registro de Asiento” de la Sexta historia de usuario ...................................................................................................................... 78
Figura 3.50. Cuarta tarea “Creación del Presupuesto” de la Sexta historia de usuario .................................................................................................................................. 78
Figura 3.51. Pantalla del “Registro del Asiento” ........................................................ 78
Figura 3.52. Planificación del Cuarto Sprint con sus respectivas historias de usuario .................................................................................................................................. 79
Figura 3.53. Burndown del Cuarto Sprint ................................................................. 80
Figura 3.54. Séptima historia de usuario “Creación de los reportes contables”, Con su primera tarea “Libro Diario” .................................................................................. 80
Figura 3.55. Reporte del “Libro Diario” ..................................................................... 81
Figura 3.56. Segunda tarea ”Libro Mayor” de la séptima historia de usuario ........... 81
Figura 3.57. Reporte del “Libro Mayor” ..................................................................... 81
Figura 3.58. Tercera tarea “Balance de comprobación” de la séptima historia de usuario ...................................................................................................................... 82
Figura 3.59. Reporte del “Balance de comprobación” ............................................... 82
Figura 3.60. Cuarta tarea “Balance General” de la séptima historia de usuario ....... 83
Figura 3.61. Reporte del “Balance General” ............................................................. 83
Figura 3.62. Quinta tarea “Estado de Resultados” de la séptima historia de usuario .................................................................................................................................. 84
Figura 3.63. Sexta tarea “Hoja de Trabajo” de la séptima historia de usuario........... 84
Figura 3.64. Reporte de la “Hoja de Trabajo” ............................................................ 85
Figura 3.65. Octava historia de usuario “Creación del Libro de Compras y Ventas” con sus respectivas tareas. ....................................................................................... 85
ÍNDICE DE TABLAS
Tabla 2.1. Diferencias entre metodologías agiles y no agiles ................................... 16
Tabla 2.2. Cálculo de Puntos Función....................................................................... 32
Tabla 2.3. Preguntas para el cálculo del Fi ............................................................... 33
Tabla 2.4. Escala de rangos...................................................................................... 33
Tabla 2.5. Constantes según el modo de software ................................................... 36
Tabla 2.6. Atributos para el multiplicador m(X).......................................................... 37
Tabla 3.1. Descripción del caso de uso “Acceder al sistema” ................................... 39
Tabla 3.2. Descripción del caso de uso “Administración de Usuarios” ...................... 41
Tabla 3.3. Descripción del caso de uso “Administración de las empresas”............... 42
Tabla 3.4. Descripción del caso de uso “Administración Contable”........................... 45
Tabla 3.5. Descripción del caso de uso “Administración del Libro de compras y ventas” ...................................................................................................................... 46
Tabla 4.1. Características del dominio de la información .......................................... 90
Tabla 4.2. Resultados de la complejidad................................................................... 91
Tabla 4.3. Valores de ajuste de complejidad basados en respuestas a las preguntas .................................................................................................................................. 92
Tabla 4.4. Escala de valores para la usabilidad ....................................................... 93
Tabla 4.5. Preguntas para hallar la usabilidad .......................................................... 94
Tabla 4.6. Tabla de resultados para la mantenibilidad .............................................. 95
Tabla 4.7. Datos del sistema Orgánico ..................................................................... 96
Tabla 4.8. Tabla de resultados del multiplicador m(X) .............................................. 97
1
CAPITULO I
1 Presentación
1.1 Introducción
Un sistema de información es un conjunto de elementos que interactúan entre sí, con
el fin de apoyar las actividades de una empresa o negocio. Las mismas están siendo
aceptados y adoptados por muchas empresas, debido a las ventajas competitivas
que proporcionan y a la optimización de los procesos en los cuales intervienen.
Actualmente la globalización de mercados obliga a las empresas a modernizar sus
procesos y ser más productivos, para lograr así un buen nivel competitivo dentro del
mercado nacional e internacional. En la búsqueda de la optimización de los procesos
y la productividad, es requerido que las empresas se dediquen más a cumplir con su
razón de ser, y busquen ayuda de terceros para suplir las otras necesidades, es por
esto que nace la subcontratación (más conocido por "outsourcing", el término en
inglés), la cual se define como la gestión o ejecución permanente de una función
empresarial por un proveedor externo de servicios. La empresa subcontratante
deberá transferir parte del control administrativo y operacional a la empresa
subcontratada, de modo que esta pueda realizar su trabajo apartada de la relación
normal de la empresa subcontratante y sus clientes. La subcontratación también
implica un considerable grado de intercambio bidireccional de información,
coordinación y confianza.
De esta manera es que la empresa MAERO CONSULTORA MULTIDISCIPLINARIA
S.R.L. ofrece el servicio de Outsourcing Contable, la cual consiste en el
procesamiento, análisis de la información contable para la elaboración de estados
financieros, y el cumplimiento de aspectos formales de presentación de los registros
contables, con el objetivo de proveer a las direcciones de las organizaciones
información precisa de la gestión para orientar sus decisiones y estrategias de
negocio.
2
Por lo que un Sistema de Gestión Contable vía web para el servicio de Outsourcing,
se constituye como una herramienta importante para el crecimiento, la organización,
y control de la empresa la cual permitirá dar a sus clientes un mejor servicio.
1.2. Antecedentes
Antecedentes de la Institución
MAERO CONSULTORA MULTIDISCIPLINARIA S.R.L. Nace como una iniciativa
emprendedora de un grupo de profesionales el año 2009. Su objetivo es el de
realizar diferentes servicios, entre ellos tenemos: Asesoramiento en consultas
Tributarias, Financieros, diferentes tipos de Auditoria, Outsourcing Contable y otros.
Cuenta con un equipo selecto de profesionales que prestan servicios especializados
a Organizaciones No Gubernamentales, entidades de gobierno, Proyectos con
financiamiento externo del BID, USAID y Banco Mundial, empresas, bancarias, de
seguros, industriales, comerciales y de servicios.
La empresa tiene como misión la de Coadyuvar a la mejora de la gestión, en las
Empresas Privadas, Entidades Públicas, PYMES, y demás negocios; informar y
asesorar a todas las personas emprendedoras interesadas en incursionar en el
mundo de los negocios y la concretización de sus proyectos, aportándoles ideas y
servicios para ello.
El Outsourcing Contable ha aliviado a las empresas de las preocupaciones
relacionadas con esta área, permitiéndoles que se dediquen a realizar actividades
que representen ventajas competitivas para su negocio, es decir a las estrategias
propias del mismo con el fin de obtener mayor eficiencia operacional y mayor
rentabilidad. Las empresas que forman parte de la clientela del servicio de
Outsourcing Contable al no querer hacerse cargo de sus gestiones contables por
diferentes razones, contratan los servicios de MAERO CONSULTORA
MULTIDISCIPLINARIA S.R.L. el cual al contar con un equipo selecto de
3
profesionales, hace posible adoptar, adaptar y ajustar el proceso de Outsoucing de
manera rápida, eficiente, fácil sin problemas ni traumas para su clientela.
Antecedentes del Proyecto
En cuanto a trabajos realizados con anterioridad en la carrera de informática se
pueden citar los siguientes:
“Sistema Contable y Control de Afiliados y pagos de ADEPI (Asociación
Departamental de la pequeña industria)”, Paiva Zapana Maritza Netsi, UMSA 2002
Es un sistema de contabilidad que hace un control administrativo de sus afiliados.
“Sistema de Seguimiento y Control Administrativo Físico y Financiero de proyectos
en ejecución (CSIP)”, Tórres Calzada Esther Pocha, UMSA 2002 Es un sistema
integrado de comunicación, para el control y seguimiento de proyectos en
ejecución.
“Sistema integrado de información administrativo – financiero AADAPAL”, Alex
Adalid Ticona Gutierrez, UMSA 2003, Desarrolla un sistema con diferentes
módulos como ser, presupuestos, contabilidad, almacenes y adquisiciones.
“Sistema de información administrativa contable”, Maydana Lima Juan Jose,
UMSA 2007. Desarrollar e implementar un software de contabilidad para generar y
proporcionar información contable de manera eficiente y oportuna apoyando de
esta forma a una mejor y ágil toma de decisiones.
“Sistema Administrativo Financiero Contable. Caso: DIGITAL NETWORK S.R.L”.
Quispe Aruquipa Freedy, UMSA 2008. El sistema sistematiza los procesos
administrativos del departamento de Tesorería y Contabilidad ofreciendo un
control y seguimiento de las otras áreas relacionadas con el trabajo de la empresa.
1.3 Planteamiento y formulación del problema
1.3.1 Problemática
MAERO CONSULTORA MULTIDISCIPLINARIA S.R.L. en el desenvolvimiento de
sus actividades laborales tiene los siguientes problemas:
4
El sistema actual no permite que el cliente acceda directamente a su información
contable, para la toma de decisiones.
Falta de actualización de la información contable del cliente.
Para hacer la revisión correspondiente de la información, se debe esperar a que la
persona encargada del registro de documentos termine, lo cual hace ineficiente la
revisión del mismo.
No existe un mantenimiento del Sistema Actual.
La información de los clientes se encuentra dispersa.
El sistema actual no permite el crecimiento estratégico de la empresa.
1.3.2 Problema principal
Después de estudiar la situación actual de la empresa con respecto al
funcionamiento del actual sistema, y el manejo de la información se concluye que el
problema principal es:
“La empresa MAERO CONSULTORA MULTIDISCIPLINARIO S.R.L. no cuenta
con Sistema de gestión contable óptimo para el servicio de Outsourcing, que
cumpla con todos las necesidades de la empresa y sus clientes para la toma de
decisiones”.
1.4 Objetivos
1.4.1 Objetivo principal
El objetivo principal del proyecto es:
Diseñar, desarrollar e implementar un Sistema de Gestión Contable vía Web para el
servicio de Outsourcing, el cual manejara la información contable de los clientes, y de
esta manera proporcionar un mejor servicio a sus clientes.
5
1.4.2 Objetivos secundarios
Para la realización del objetivo principal de este trabajo se establecieron los
siguientes objetivos secundarios del Sistema de gestión contable vía web para el
servicio de Outsourcing.
Centralizar la información de los clientes.
Mostrar información actualizada a los clientes
Mejorar el servicio de Outsourcing Contable.
Ofrecer a los clientes una accesibilidad en todo momento a su información
contable.
Desarrollar un Sistema de Gestión Contable capaz de manejar la contabilidad
de diferentes tipos de empresas con sus respectivas gestiones.
Permitir la actualización de la información de forma continua.
Asegurar la integridad, el resguardo de la información.
1.5 Justificaciones
1.5.1 Justificación técnica
PHP y MySQL son conocidas tecnologías de código abierto que resultan muy útiles
para diseñar de forma rápida y eficaz aplicaciones Web dirigidas a bases de datos.
PHP es un potente lenguaje de secuencia de comandos diseñado específicamente
para permitir a los programadores crear aplicaciones Web con distintas prestaciones
de forma rápida. MySQL es una base de datos rápida y fiable que se integra a la
perfección con PHP y que resulta muy adecuada para aplicaciones dinámicas
basadas en Internet.
1.5.2 Justificación económica
La creación del sistema con software libre permitirá a la empresa el ahorro de dinero
en el pago de licencias, las cuales en cuestión de software llegan a ser muy
costosas.
6
La utilización del sistema brindara a la empresa una nueva imagen basada en la
tecnología y un mejor servicio para los clientes.
1.5.3 Justificación social
La implementación del Sistema de Gestión Contable vía Web para el servicio de
Outsourcing permitirá ofrecer a todos los clientes de la MAERO S.R.L. un mejor
servicio con la opción de poder ver toda su información contable actualizada en
cualquier momento para la toma de decisiones.
1.6 Metodología e instrumentos de medición
Para el desarrollo de sistema, la metodología que se utilizará es el SCRUM por ser
una metodología ágil y de esta manera poder incorpora cambios con rapidez y en
cualquier fase del proyecto.
Se utilizaran las métricas del modelo de análisis punto función que pretenden medir
la funcionalidad entregada al usuario independientemente de la tecnología utilizada
para la construcción y explotación del software.
1.7 Alcances
El presente estudio se limita al análisis, diseño, implementación y mantenimiento del
un Sistema de gestión contable vía web enfocado a coadyuvar con el servicio
Outsourcing que ofrece la empresa MAERO CONSULTORA MULTIDISCIPLINARIA
S.R.L.
El sistema proporciona a los clientes información confiable, en tiempo real, de las
actividades desarrolladas en la gestión contable.
1.8 Limites
El sistema solo se limitara al manejo de la información contable y al manejo de los
diferentes roles que existen como: los clientes solo puede ver e imprimir la
7
información contable, el contador encargado se encargar del registro de la
información contable y a ver las transacciones que genere sin acceso a la impresión,
y por último el supervisor tiene las opciones de imprimir, ver las transacciones e
imprimir la información contable.
Para mejorar el servicio de Outsourcing el sistema funcionara en la web, de esta
manera los clientes podrán ver su información contable en todo momento.
1.9 Herramientas
Para el desarrollo del presente proyecto se empleo las siguientes herramientas:
Team Trick, para el manejo de Scrum.
Visio 2007, para la creación de diagramas.
MagicDraw UML con Magic UWE para la creación del modelo navegacional.
Balsamiq Mockups, para la creación del diagrama de presentación
PHP 5.3.1 como lenguaje de programación del lado del servidor.
MYSQL 5.1.41, como gestor de base de datos.
Eclipse Helios, para el desarrollo en PHP
FLASH CS3 como lenguaje de programación del lado del cliente
AMFPHP 1.9 para la vinculación entre Flash y PHP
8
CAPITULO II
2. Marco Teórico
2.1. Contabilidad
La ciencia contable tiene orígenes tan antiguos como antiguos son los negocios,
pues el comerciante o mercader primitivo debió tener necesidad de practicar
anotaciones tal vez rudimentarias de sus negocios, principalmente de las cantidades
y fechas en que debía satisfacer obligaciones o cobrar créditos, de la cantidad y
precio en que compraba sus mercancías, del nombre y dirección de las personas con
quienes comerciaba, etc. Estas anotaciones rudimentarias, libradas al mejor criterio
de los comerciantes han debido evolucionar de acuerdo al crecimiento de los
negocios por el aumento de las poblaciones y de las vías de comunicaciones
convirtiéndose en reglas y procedimientos fijos cuya aparición ha dado origen a la
ciencia misma. [Fernandez, 1979]
El estudio de esta ciencia está íntimamente ligado al estudio de los negocios, sean
estos industriales, comerciales, financieros, de administración, etc., pues es un
poderoso auxiliar de ellos. Una de las tareas de que se ocupa, es la de registrar
todas las operaciones mercantiles que efectúa el comerciante o industrial, lo que
hace que el Contador debiera estar perfectamente compenetrado de la fisonomía y
características del negocio que ocupa sus servicios. Por otra parte, en base a
aquellas anotaciones se preparan estados de situación y resultados económicos los
que, si se interpretan debidamente, podrán modificar el rumbo de la política de los
administradores. [Fernandez, 1979]
2.1.1 Objetivo general de la contabilidad
El objetivo general de la contabilidad es proporcionar información oportuna,
sistémica, confiable y objetiva a la gerencia para una acertada toma de decisiones.
[Terán Gandarillas, 2001]
9
2.1.2 Objetivos específicos
Los objetivo especifico de la contabilidad coadyuva directamente la objetivo general,
y radica en la preparación y emisión de estados financieros o estados contables,
documentos mediante los cuales en forma resumida de acuerdo con normas de
contabilidad y disposiciones legales, se proporciona a los usuarios de la información
contable datos oportunos, verídicos, objetivos y sistemáticos en términos de
unidades monetarias, referidos a la situación patrimonial y financiera de la empresa a
una determinada fecha y como los resultados obtenidos correspondientes a un
determinado tiempo de trabajo. [Terán Gandarillas, 2001]
Para proporcionar esta información deber preparase estados financieros, para tal
efecto, la contabilidad se sirve de determinados medios o instrumentos de gran
importación que son: los registros de diario (Comprobantes de diarios ingreso,
egreso y traspaso), registros de diarios auxiliares, registros de mayor, registros de
mayores auxiliares, documentos (facturas, liquidaciones, planillas de sueldos y
salarios, etc.) balance de comprobación y hoja de trabajo. [Terán Gandarillas, 2001]
2.1.3 Diseño de sistemas contables
La fase inicial realizada en toda empresa al momento de su constitución, labor
cuando el Auditor (Contador Público Autorizado) demuestra su formación académica
no solo en campo contable si no también con otras ciencias relacionadas a esta para
diseñar , implantar, supervisar y controlar un sistema de contabilidad aplicado al giro
especificó de las actividades de una empresa y proyectar el volumen de sus
operaciones, para de esta manera identificar al ente y establecer los tipos de
operaciones que probablemente ocurrirán acorde con los requerimientos
empresariales y disposiciones legales. [Terán Gandarillas, 2001]
2.1.4 Activo, Pasivo y Patrimonio
Activo.- Se define como activo a todos los bienes y valores de propiedad de la
entidad y que están al servicio de la misma con el objetivo de obtener utilidad. Estos
10
bienes tienen mucha probabilidad de generar un beneficio económico y varían de
acuerdo con la naturaleza del negocio. [Ortiz, 2009]
Todo activo tiene un valor de cambio, es decir el propietario de un determinado activo
puede cambiarlo por efectivo o por otro activo, puede utilizarlo para cancelar una
deuda o repartirlo entre los propietarios de la empresa, es decir se lo puede utilizar
para alguna actividad productora de ingresos. El activo es también una de las dos
partes del balance de situación. [Ortiz, 2009]
Pasivo.- Son todas las obligaciones que tiene por pagar la empresa a sus acreedores
y se reflejan en el primer segmento de la segunda parte del balance a una fecha
señalada en el mismo documento. Comprende también las fuentes de financiación
de una entidad, en muchas ocasiones, las empresas deben acogerse al
endeudamiento para poder adquirir activos, es decir obtienen un bien pero a la vez
contraen una deuda, aplicando de esta forma la partida doble. [Ortiz, 2009]
Patrimonio.- Se define patrimonio a los recursos invertidos por el propietario en una
empresa; es igual a los activos totales menos los pasivos. El derecho del
propietario es un derecho residual porque los derechos de los acreedores tienen
prioridad legalmente. Si usted es el propietario de una empresa, tiene derecho
a lo que quede después de cancelar completamente los derechos de los
acreedores. [Ortiz, 2009]
Todo balance de situación comprende dos partes, por un lado tenemos el activo y
por otro lado el pasivo y patrimonio, en consecuencia con estos tres términos se
conforma la ecuación contable de la siguiente manera:
ACTIVO = PASIVO + PATRIMONIO
2.1.5 Plan de cuentas
Un plan contable es la agrupación de un conjunto de cuentas que tiene como objetivo
homogenizar y agrupar hechos y operaciones económico financieras bajo un criterio
definido. Por tanto un plan de cuentas es un listado que contiene todas las cuentas
11
que son necesarias para registrar los hechos contabilizables. [Gonzales Gomes, s.f.]
El Plan de cuentas sirve:
Como estructura básica en la organización y diseño del sistema contable.
Como medio para obtener información.
Para utilizar la misma cuenta frente a hechos similares.
Facilita la confección de los estados contables.
2.1.6 Libro diario
El libro diario es un registro cronológico y ordenado de TODAS las operaciones
comerciales efectuadas por el comerciante, día a día y una tras otra, debiendo
establecerse cuál es el acreedor y quien el deudor [Fernandez, 1979].
2.1.7 Libro mayor
El libro de mayor proporciona información clasificada en forma metódica y sistémica
referente al movimiento de todas y cada una las cuentas apropiadas en el libro diario
mediante la sumatoria de cargos (Debe) y/o en abonos (Haber) para de esta manera
poder determinas sus saldos (deudo o acreedor) en términos de unidades
monetarias. [Terán Gandarillas, 2001]
2.1.8 Balance de comprobación
Se denomina balance de comprobación al estado financiero auxiliar, que presenta
información cuantitativa en términos de unidades monetarias referidas a la situación
de las cuentas que hayan tenido movimiento hasta la fecha de preparación y
emisión.
El objetivo del balance de comprobación es proporcionar oportunamente información
contable en términos de unidades monetarias, referida a la sumatoria de cargos y/o
abonos como también el saldo que corresponde a cada una de las cuentas
apropiadas hasta la fecha de preparación y emisión. [Terán Gandarillas, 2001]
12
2.1.9 Balance general
El balance general, estado de situación o balance de fin de gestión, es un estado
financiero básico, que en forma resumida de acuerdo con normas de contabilidad y
disposiciones legales, proporciona información en términos de unidades monetarias
referías a la situación patrimonial y financiera de una empresa a una determinada
fecha.
El objetivo del balance general es proporcionar información referida a la situación
patrimonial y financiera de una empresa, para la toma de decisiones y control de
estas. [Terán Gandarillas, 2001]
2.1.10 Estado de resultados
El estado de ganancias y pérdidas, estado de ingresos y gastos, estado de
rendimientos, estado de producto o estado de resultados, es un estado financiero
básico, que en forma resumida de acuerdo con normas de contabilidad y
disposiciones legales, proporciona resultados obtenidos en una empresa por un
determinado tiempo de trabajo.
El objetivo del estado de resultados es proporcionar información referida a los
resultados obtenidos. Es decir; la utilidad o pérdida que haya generado un empresa
para la toma de decisiones y control de estas. [Terán Gandarillas, 2001]
2.1.11 Hoja de trabajo de diez columnas
Es uno de los estados Financieros Auxiliares más importantes, pues mediante el es
posible confeccionar el Balance General y Estado de Resulta y conocer la utilidad o
perdida del negocio, antes de asentar definitivamente todos los datos en los libros
legales. Se lo elabora en un estado de diez columnas, las que de izquierda a derecha
y contándolas por juegos de dos en dos. [Fernandez, 1979]
13
2.1.12 Software del libro de compras y ventas (IVA)
Es una aplicación desarrollada para apoyar la presentación de la información
complementaria al Impuesto de Valor Agregado (IVA), que el Servicio de Impuestos
solicita a un grupo de contribuyentes. [Impuestos Nacionales, s. f.]
2.2 Outsourcing
2.2.1 Historia
Si buscamos los inicios del outsourcing, podemos decir que surge desde que el
hombre en sociedad se especializa en ciertas actividades en las cuales destaca para
proveer de ciertos bienes a sus compañeros del grupo o manada. Así los más fuertes
se enfocaron a la caza y protección del grupo, las mujeres a crianza de los hijos y los
menos fuertes a siembra y cosecha.
El Outsourcing como se conoce hoy en día, es una práctica que data desde el inicio
de la era moderna. No es concepto nuevo, ya que muchas compañías competitivas
lo realizaban como una estrategia de negocios. Al inicio de la era post-industrial se
inicia la competencia en los mercados globales.
Después de la segunda guerra mundial, las empresas trataron de concentrar en sí
mismas la mayor cantidad posible de actividades, para no tener que depender de los
proveedores.
Sin embargo, esta estrategia que en principio resultara efectiva, fue haciéndose
obsoleta con el desarrollo de la tecnología, ya que nunca los departamentos de una
empresa podían mantenerse tan actualizados y competitivos como lo hacían las
agencias independientes especializadas en un área, además, su capacidad de
servicio para acompañar la estrategia de crecimiento era insuficiente.
Este concepto comenzó a ganar credibilidad al inicio de la década de los 70’s
enfocado, sobre todo, a las áreas de información tecnológica en las empresas. Las
primeras empresas en implementar modelos de Outsourcing fueron gigantes como
14
EDS, Arthur Andersen, Price Waterhouse y otros. El Outsourcing es un término
creado en 1980 para describir la creciente tendencia de grandes compañías que
estaban transfiriendo sus sistemas de información a proveedores.
2.2.2 Definición
Es considerado como la transferencia de funciones y responsabilidades a un tercer,
lo cual implica una relación estratégica entre ambas partes, que la empresa cliente
entrega un proceso de negocio no estratégico al proveedor proporcionándole
información clave y estratégica de su negocio para que este puede hacer su trabajo.
[Zandweghe,2010]
2.2.3 Outsourcing Contable
En el Outsourcing Contable la empresa que ofrece el servio es encargada y la
responsable de todas aquellas funciones del departamento contable del cliente, lo
cual incluye desde el registro contable de las transacciones efectuados por la
empresa, hasta la elaboración de los estados financieros finales e intermedios que la
compañía requiera, así como la presentación de las declaraciones tributarias del
orden nacional y territorial.
En desarrollo del servicio de Outsourcing Contable la empresa presenta en un
determinado tiempo los Estados Financieros, Balance General, Estado de
Resultados, Estado de resultados analítico, Anexos de cada una de las cuentas e
Informe sobre deficiencias de Control Interno, etc.
2.3 Metodología ágil
2.3.1 ¿Qué es una metodología ágil?
Lo ágil se define como la habilidad de responder de forma versátil al cambio para
maximizar los beneficios. Las metodologías ágiles varían en su forma de responder
al cambio, pero en general comparten las siguientes características:
15
Los individuos y sus interacciones son más importantes que los procesos y las
herramientas.
El software que funciona es más importante que la documentación exhaustiva.
La respuesta al cambio en lugar de aferrarse a un plan.
Los valores y principios compartidos por toda la metodología ágil fueron enunciados
en el “manifiesto ágil”, por la “alianza ágil”. [Citon,2006]
2.3.2 La alianza ágil
En una reunión celebrada en febrero de 2001 en Utha (EEUU), nace el término “ágil”
aplicado al desarrollo de software. En esta reunión participaron un grupo de 17
expertos de la industria del software. Su objetivo fue esbozar los valores y principios
que debían permitir a los equipos desarrollar software rápidamente y respondiendo a
los cambios que pueden surgir a lo largo del proyecto. Se pretendía 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. [Citon,2006]
2.3.3 Metodologías ágiles vs tradicionales
Metodologías Ágiles Metodologías Tradicionales
La planificación del trabajo sólo
comprende el ciclo en el que se está
trabajando (normalmente 30 días).
Trabajo y gestión guiada por un plan
general del proyecto que comprende
todo su ciclo de desarrollo.
Descubrimiento progresivo de
requisitos, e incorporación de cambios
en cualquier iteración del desarrollo.
Conocimiento detallado de los
requisitos antes de comenzar el
diseño del proyecto.
“Refactorización” de código como
modelo de trabajo compatible con el
punto anterior.
“Hacerlo bien a la primera”. Evitar la
re-codificación y el re-trabajo que
supone una pérdida de eficiencia.
16
Comunicación directa entre los
integrantes del equipo (incluidos
cliente y usuarios) prefiriendo la verbal
directa.
Comunicación formal según el plan de
comunicación del proyecto.
Equipos auto-gestionados. Gestión de equipos y personas
centralizada en el gestor del proyecto.
No existe contrato tradicional o al
menos es bastante flexible.
Existe un contrato prefijado.
El cliente es parte del equipo de
desarrollo.
El cliente interactúa con el equipo de
desarrollo mediante reuniones.
Grupos pequeños (hasta 20
integrantes)
y trabajando en el mismo sitio.
Grupos grandes y posiblemente
distribuidos.
Pocos artefactos. Más artefactos.
Pocos roles. Más roles.
Menos énfasis en la arquitectura del
software.
La arquitectura del software es
esencial y se expresa mediante
modelos.
Tabla 2.1: Diferencias entre metodologías agiles y no agiles
Fuente: [Citon,2006]
2.4 Metodología Scrum
2.4.1 Introducción
Scrum es una metodología ágil de gestión de proyectos cuyo objetivo primordial es
elevar al máximo la productividad de un equipo. Reduce al máximo la burocracia y
actividades no orientadas a producir software que funcione y produce resultados en
periodos muy breves de tiempo. Como método, Scrum enfatiza valores y prácticas de
gestión, sin pronunciarse sobre requerimientos, prácticas de desarrollo,
implementación y demás cuestiones técnicas. Más bien delega completamente en el
17
equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo más
productivos posibles. [Citon,2006]
La palabra Scrum procede de la terminología del juego de rugby, donde designa al
acto de preparar el avance del equipo en unidad pasando la pelota a uno y otro
jugador. Igual que el juego, Scrum es adaptable, ágil, auto-organizante y con pocos
tiempos muertos. [Citon,2006]
Scrum fue desarrollado por Jeff Sutherland y elaborado más formalmente por Ken
Schwaber. Poco después Sutherland y Schwaber se unieron para refinar y extender
Scrum. Se la ha llegado a conocer como una herramienta de hiperproductividad.
Schwaber se dio cuenta entonces de que un proceso necesita aceptar el cambio, en
lugar de esperar predictibilidad. Se enfoca en el hecho de que procesos definidos y
repetibles sólo funcionan para atacar problemas definidos y repetibles con gente
definida y repetible en ambientes definidos y repetibles. Toma el cambio como una
forma de entregar al final del desarrollo algo más cercano a la verdadera necesidad
del Cliente. Puede ser aplicado teóricamente a cualquier contexto en donde un
grupo de gente necesita trabajar junta para lograr una meta común. [Citón, 2006]
Se basa en los principios ágiles:
Privilegiar el valor de la gente sobre el valor de los procesos.
Entregar software funcional lo más pronto posible.
Predisposición y respuesta al cambio
Fortalecer la comunicación y la colaboración.
Comunicación verbal directa entre los implicados en el proyecto.
Simplicidad; supresión de artefactos innecesarios en la gestión del proyecto.
2.4.2 Elementos de Scrum
Roles
o Product Owner
o Scrum Mater
18
o Tema (Equipo)
Poda de requerimientos
Product Backlog
o Historias de Usuario
o Story Points
Sprint
o Planificación
o Sprint Backlog
o Scrum
o Builds continuos
o Revisión del Sprint
o Reunión retrospectiva
Valores
o Foco, comunicación, respeto y coraje.
Roles del Scrum
No hay una técnica oficial para coordinar equipos múltiples, pero se han
documentado experiencias de hasta 800 miembros, divididos en Scrums de Scrum,
definiendo un equipo central que se encarga de la coordinación, las pruebas
cruzadas y la rotación de los miembros. [Citon,2006]
Scrum tiene una estructura muy simple. Todas las responsabilidades del proyecto se
reparten en 3 roles:
Product owner (Dueño del producto).- representa a todos los interesados en el
producto final. Es el responsable oficial del proyecto, gestión, control y visibilidad
de la lista de acumulación o lista de retraso del producto (Product Backlog). Toma
las decisiones finales de las tareas asignadas al registro y convierte sus elementos
en rasgos a desarrollar. Sus áreas de responsabilidad son:
o Financiación del proyecto
o Requisitos del sistema
19
o Retorno de inversión del proyecto
o Lanzamiento del proyecto
Scrum Master (Lider del proyecto).- Responsable del proceso Scrum, de cumplir
la meta y resolver los problemas. Así como también, de asegurarse que el
proyecto se lleve a cabo de acuerdo con las prácticas, valores y reglas de Scrum
y que progrese según lo previsto.
Interactúa con el cliente y el equipo. Coordina los encuentros diarios, y se encarga
de eliminar eventuales obstáculos. Debe ser miembro del equipo y trabajar a la
par.
Team (Equipo).- Responsable de transformar el Backlog de la iteración en un
incremento de la funcionalidad del software. Tiene autoridad para reorganizarse y
definir las acciones necesarias o sugerir remoción de impedimentos.
o Auto-gestionado
o Auto-organizado
o Multi-funcional
Poda de requerimientos
La primera actividad es armar una lista exhaustiva de los requerimientos originales
del sistema. Luego se procede a ver qué requerimientos son realmente necesarios,
cuáles pueden posponerse y cuáles eliminarse. Para ello debe identificarse un
representante con capacidad de decisión, priorizar los requerimientos en base a su
importancia y acordar cuáles son los prioritarios para la fecha de entrega.
La poda de requerimientos es una buena práctica implícita en modelos ágiles, se
hace lo que el cliente realmente desea, no más. [Citon,2006]
Historia de Usuario.- Una historia de usuario posee similitudes con un caso de
uso, salvando ciertas distancias. Por hacer una correspondencia entre historias
de usuario y casos de uso, podríamos decir que el titulo de la historia se
corresponde con el del caso de uso tradicional. Sin embargo, la historia no
pretende definir el requisito. [Blé Jurado, Beas, Gutierrez, Reyes, y Mena, 2010].
20
Story Points.- Es una unidad arbitraria pero fija que describe cuanto esfuerzo
requiere una historia de usuario para ser entregada al cliente.
Es arbitraria porque es una medida cuya definición exacta es escogida por el
equipo a implementar las Historias de Usuario. Esto implica que una vez
determinada para un equipo, no se puede aplicar para otros equipos.
En software, esta arbitrariedad es inducida por la naturaleza del proyecto a
implementar (no hay dos proyectos iguales), las capacidades de los miembros de
equipo, las capacidades de equipo (la capacidad combinada del equipo nunca es
la suma de las capacidades individuales) y si las Historias de Usuario actuales
juegan bien con los puntos fuertes del equipo. (Alfaro, 2011).
Product Backlog
Con los requerimientos priorizados y podados armamos el Backlog de Producto. Este
es una forma de registrar y organizar el trabajo pendiente para el producto
(actividades y requerimientos). [Citon,2006]
Es un documento dinámico que incorpora constantemente las necesidades del
sistema. Por lo tanto, nunca llega a ser una lista completa y definitiva. Se mantiene
durante todo el ciclo de vida (hasta la retirada del sistema) y es responsabilidad del
Product Owner. [Citon,2006]
Sprint
Scrum está basado en el control empírico de procesos. Se utiliza cuando la
capacidad de predicción es vaga, la incertidumbre alta o el proceso es demasiado
complejo para ser modelado y definido.
En el enfoque empírico de control de procesos se establecen reglas simples y
se crea una disciplina de inspección frecuente para adaptarse rápidamente a
situaciones imprevistas o problemas.
21
Figura 2.1 Proceso del Sprint.
Planificación .- En esta reunión, tomando como base las prioridades y
necesidades de negocio del Product owner, se determinan cuáles y cómo van a
ser las funcionalidades que se van a incorporar al producto con el próximo
Sprint. Marca el comienzo de cada sprint y no debería durar más de un día.
Sprint Backlog.- El Sprint Backlog es la lista que descompone las funcionalidades
del Product Backlog en las tareas necesarias para construir un incremento: una
parte completa y operativa del producto. El sprint backlog se realiza y actualiza
entre todos los miembros del equipo de proyecto. A lo largo del sprint, se va
asignando a cada tarea la persona que la va a llevar a cabo, y se indica el tiempo
de trabajo que se estima, aún falta para terminarla.
Scrum.- Son reuniones que se hacen normalmente después de la Planificación,
estas reuniones permiten a los equipos discutir su trabajo, enfocándose
especialmente en áreas de solapamiento e integración, asistiendo una persona
asignada de cada equipo. Siguiendo las siguientes cuatro preguntas
o ¿Qué ha hecho tu equipo desde nuestra última reunión?
o ¿Qué hará tu equipo antes que nos volvamos a reunir?
o ¿Hay algo que demora o estorba a tu equipo?
o ¿Estás a punto de poner algo en el camino del otro equipo?
22
Builds continuos.-
o Los programadores desarrollan según el Backlog del Sprint, y al finalizar,
notifican al integrador.
o El integrador toma el código y lo integra con el resto del producto.
o Se compila el software y se prueba “por arriba” el producto, para verificar
que no se haya roto
o Si se encuentran problemas se devuelve al desarrollador.
o Se notifica al equipo que hay una nueva versión “estable” del código para
usar como base.
Revisión del Sprint.- El objetivo de la reunión de revisión es presentar el producto
o porción del producto desarrollada por el equipo a los usuarios. La reunión se
utiliza para detectar inconformidades mayores que se vuelven elementos del
Backlog de Producto y que eventualmente se resuelven en el siguiente
Sprint.
Reunión retrospectiva.- Scrum involucra el concepto de mejora continua a través
de las reuniones de retrospección. Las reuniones buscan detectar los puntos
positivos y negativos del Sprint para generar propuestas de mejora para
futuros Sprints.
Las reuniones de retrospección son el concentrador del aprendizaje organizacional
sobre el Scrum. Los puntos positivos y negativos se registran y se definen ítems de
acción para cada uno. Los ítems de acción definidos se toman en cuenta en los
siguientes Sprints. [Citon,2006]
2.5 Metodología UWE
La metodología UWE (UML – Based Web Engineering) presentado por Koch y sus
colegas, para el desarrollo de aplicaciones web, esta fundad en un entrono Orientado
a Objetos usando para esto la notación “ligera” de UML. UWE proporciona guías
para la construcción de modelos de forma sistemática, enfocándose en
personalización y estudio de casos de uso. Las actividades de modelado principales
23
son el análisis de requerimientos, el diseño conceptual, el diseño de navegación y el
diseño de presentación producen los siguientes modelos: [Koch,2000]
Modelo de Casos de Uso
Modelo Conceptual
Modelo de Navegación
Modelo de Presentación
El lenguaje de Modelo Unificado UML (Unified Modeling Language) es una
herramienta lo suficientemente poderosa para cubrir todos los requerimientos que
surgen cuando se modela un aplicación Web. Además tiene la ventaja de ser un
lenguaje de modelado bien documentado, que es de hecho un estándar industrial.
UML puede ser visto como una familia de leguajes de modelado, más que un
lenguaje simple, si se consideran las extensiones “ligeras”. Por “ligero”, se entiende
que puede ser fácilmente adoptado a otras herramientas de modelado y que no
significa un gran impacto en el intercambio de formatos. Los estereotipos son un
nuevo tipo de elemento de modelados definidos dentro del modelo basado en un tipo
de elementos de un modelo existente.
2.5.1 Modelo de casos de uso
El caso de uso es un documento narrativo que describe la secuencia de eventos de
un actor (agente externo) que utiliza un sistema para completar un proceso. Los
casos de uso son historias o casos de utilización de un sistema; no son exactamente
los requerimientos ni las especificaciones funcionales, sino que ejemplifican e incluye
tácticamente los requerimientos en las historias que narran. [Larman, 1999]
Figura 2.2 Representación de un caso de uso.
24
2.5.2 Modelo Conceptual
Un modelo conceptual explica (a sus creadores) los conceptos significativos en un
dominio del problema: el artefacto más importante a crear durante el análisis
orientado a objetos. [Larman, 1999]
El paso esencial de un análisis o investigación orientado a objetos es descomponer
el problema en conceptos u objetivos individuales: las cosas que sabemos. Un
modelo conceptual es una representación de conceptos en un dominio del problema
en el UML, lo ilustramos con un grupo de diagramas de estructura estática donde no
se define ninguna operación. La designación de un modelo conceptual ofrece la
ventaja de subrayar fuertemente una concentración en los conceptos del domino, no
en las entidades del software. [Larman, 1999]
Figura 2.3 Diagrama de Clases.
2.5.3 Modelo Navegacional
En un sistema para la web es útil saber cómo están enlazadas las páginas. Ello
significa que necesitamos un diagrama conteniendo nodos (nodes) y enlaces (links).
25
¿Pero que es un nodo? Nodos son unidades de navegación y están conectados por
medio de enlaces. Nodos pueden ser representados en diferentes páginas o en una
misma página.
Lo que se quiere con el ejemplo de la figura 2.3 es AddressBook sea nuestra página
principal, tener una lista de contactos, buscador de contactos, poder crear, eliminar y
modificar un contacto. [Web Engineering Group, s.f.]
Figura 2.4 Ejemplo de un modelo Navegacional.
2.5.4 Modelo de presentación
El objetivo es visualizar la organización de la estructura de la aplicación Web de una
forma intuitiva que con el modelo de estructura de navegación. Este paso consiste en
modelar las fases de la presentación mostrando donde se presentaran al usuario los
26
objetos de navegación y los elementos de acceso, por ejemplo en que marco o
ventana se muestra el contenido y que será reemplazado cuando se accione un
enlace.
Figura 2.5 Ejemplo de un modelo de Presentación.
2.6 Pruebas
2.6.1 Test Unitarios
Son los test más importantes, cada test unitario o test unidad (unit test en ingles) es
un paso que andamos en el camino de la implementación del software. Todo test
unitario de ser:
Atómico
Independiente
Inocuo
Rápido
27
Atómico significa que el test prueba la mínima cantidad de funcionalidad posible.
Esto es, probara un solo comportamiento de un método de una clase. El mismo
método puede presentar distintas respuestas ante distintas entradas o distinto
contexto. El test unitario se ocupara exclusivamente de uno de esos
comportamientos, es decir, de un único camino de ejecución.
Independiente significa que un test no pude depender de otros para producir un
resultado satisfactorio. No puede ser parte de una secuencia de tests que se deba
ejecutar en un determinado orden. Debe funcionar siempre igual independientemente
de que se ejecuten otros testo o no.
Inocuo significa que no altera el estado del sistema. Al ejecutarlo una vez, produce
exactamente el mismo resultado que al ejecutarlo veinte veces. No altera la base de
datos, ni envía email ni crea ficheros, ni los borra. es como si no se hubiera
ejecutado.
Rápido porque ejecutamos gran numero de test cada pocos minutos y se ha
demostrado tener que espera unos cuantos segundos cada rato, resulta muy
improductivo. Un sólo test tendría que ejecutarse en una pequeña fracción de
segundo. [Blé Jurado et al. , 2010]
2.6.2 Fallos de seguridad software
SQL Injection.
es una vulnerabilidad informática en el nivel de la validación de las entradas a la
base de datos de una aplicación. El origen es el filtrado incorrecto de las variables
utilizadas en las partes del programa con código SQL. Es, de hecho, un error de una
clase más general de vulnerabilidad que puede ocurrir en cualquier lenguaje de
programación o de script que este incrustado dentro de otro.
La Inyección SQL es un problema de seguridad informática que debe ser tomado en
cuenta por el programador para prevenirlo. Un programa hecho con descuido,
displicencia, o con ignorancia sobre el problema, podrá ser vulnerable y la seguridad
28
del sistema puede quedar ciertamente comprometida. Esto puede suceder tanto en
programas ejecutándose en computadoras de escritorio., como en páginas Web, ya
que estas pueden funcionar mediante programas ejecutándose en el servidor que las
aloja. [Huanca Aliaga, 2011]
HTML Injection
Consiste en hacer una inyección de código HTML en una página, las webs más
vulnerables suelen ser libros de visitas, blogs, foros o cosas por el estilo. Así que es
posible ingresar al buscador google y encontrar páginas vulnerables utilizando las
terminaciones de los urls o contenido. [Huanca Aliaga, 2011]
Escalada de directorios
En cualquier tipo de aplicación es posible que existan medidas de seguridad que
restrinjan los directorios en los cuales un usuario de la misma pueda interactuar,
sobrepasar esas medidas de seguridad, es decir, poder acceder a directorios fuera
del marco de seguridad original, es lo que se conoce como escalada de directorios.
Este error se puede presentar y explotar de muchas maneras. Una forma puede ser
introduciendo los caracteres "../" como parte de una entrada de usuarios relativa a un
fichero que queramos visualizar, descargar o almacenar. Otra forma menos común
es haciendo uso de funciones adicionales las cuales aun perteneciendo a la
aplicación no validen dicha restricción de seguridad. [Huanca Aliaga, 2011]
Errores de mecanismos de Autenticación
Podemos encontrar desde identificación de sesión secuenciales, hasta inexistencia
de mecanismos de autenticación, pasando por un amplio surtido de debilidades
como limitación de longitud de la clave, uso de sistemas de recuperación de
contraseñas ineficientes, por citar algunos.
29
La solución a estos problemas pasa por no cometer los errores vistos con
anterioridad en la codificación del mismo, a la par de diseñar correctamente aquellos
que implementamos. [Huanca Aliaga, 2011]
Errores en el mecanismo de cifrado
Este será el último error que se trate bajo el agrupamos una serie de errores al
implementar sistemas de cifrado. Uso de algoritmos débiles como pueden ser RC4 o
DES Almacenaje de contraseñas en texto plano y no de los hashes md5 o sha1 de
las mismas, incluso sha-256/512 en caso de querer ampliar el espacio de colisiones
Almacenaje de las contraseñas de cifrado dentro de la aplicación. O uso de
algoritmos de cifrado propietario cuya seguridad no ha sido contrastada. [Huanca
Aliaga, 2011]
2.7 Calidad de Software
La calidad de software representa la garantía del correcto funcionamiento, es
necesaria la prueba de software porque representa una revisión final a las
especificaciones del diseño y la codificación.
“La calidad de software es una compleja mezcla de factores que variaran a través de
diferentes aplicaciones y según los clientes que las pidan”. [Pressman, 2003]
La medición de la calidad de software se la realiza a través de las Métricas de
Software, que proporciona una manera cuantitativa de valorar la calidad de los
atributos internos del producto, permitiendo por tanto al ingeniero valorar la calidad
antes de construir el producto.
Las métricas proporcionan la visión interna necesaria para crear modelos efectivos
de análisis y diseño, un código sólido y pruebas minuciosas.
30
2.7.1 Métricas de calidad software
Los requisitos del software son la base de las medidas de calidad. La falta de
concordancia con los requisitos es una falta de calidad, los estándares de la ISO
9126 especificados definen un conjunto de criterios de desarrollo que guían la
manera en que se hace la ingeniería de software.
Existe un conjunto de requisitos implícitos que a menudo no se nombran, tal es el
caso del mantenimiento. Si el software cumple con los requisitos tanto implícitos
como explícitos la calidad del software será confiable.
2.7.2 Factores de calidad ISO 9126
El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos
clave de calidad para el Software. El estándar identifica seis atributos clave de
calidad: Funcionalidad, Confiabilidad, Usabilidad, Eficiencia, Facilidad de
mantenimiento y Portabilidad, estos factores facilitan una valiosa base para medidas
indirectas y con las que se puede determinar la calidad del software.
i. FUNCIONALIDAD
Las métricas de software orientados a la función utilizan una medida de la
funcionalidad entregada, consultas e interfaces externas que proporciona el sistema
para la satisfacción de los requerimientos del usuario.
Como la funcionalidad no se puede medir directamente es necesario derivar
mediante otras medidas directas como el punto función [Pressman, 1998].
Punto función
La métrica punto función (PF’s), es una métrica orientada a la función y sugiere un
acercamiento a la medida de productividad. Los puntos de función se obtienen
utilizando una relación empírica basada en medidas cuantitativas del dominio de
información de software y valorizaciones subjetivas de la complejidad del software.
31
Para determinar la funcionalidad del sistema primero se debe determinar cinco
características del dominio de información. [Sánchez Rodríguez, 1999]
Número de entrada de usuario (NE)
Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la
aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se
cuentan de forma separada
Número salida de usuario(NS)
Se cuenta cada salida que proporciona el usuario información orientad a la
aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de
error, etc. Los elementos de datos particulares dentro de un informe no se cuentan
de forma separada.
Número de peticiones de usuario (NP)
Una petición se define como una entrada interactiva que produce la generación de
alguna respuesta de software inmediata en forma de salida interactiva, se cuenta
cada petición por separado.
Número de archivo(NA)
Se cuanta cada archivo maestro lógico (esto es, un grupo lógico de datos que
puedes ser una parte de una gran base de datos o un archivo independiente).
Número de interfaces externas(NI)
Se cuenta todas las interfaces legibles por la maquina (por ejemplo: archivos de
datos de cinta o disco que se utilizan para transmitir información a otro sistema).
32
Parámetro de medición CuentaSimple Medio Complejo Total NE * 3 4 6
NS * 4 5 7
NP * 3 4 6
NA * 7 10 15
NI * 5 7 10
Cuenta Total
Tabla 2. 2 Cálculo de Puntos Función.
El punto función (PF) se calcula con la siguiente ecuación:
PF = Cuenta Total* (X + Y * SUM Fi)
En donde:
Cuenta _ total: Es la suma de todas las entradas PF obtenidas de la tabla.
X= Nivel de confiabilidad del sistema
Y= Nivel de error igual a 0.01
Fi( i = 1 a 14) : Son valores de ajuste de la complejidad según la respuesta de las
siguientes preguntas:
Nro. Preguntas
1 ¿Requiere el sistema copias de seguridad y de recuperación fiable?
2 ¿Se requiere comunicación de datos?
3 ¿Existen funciones de procesamiento distribuido?
4 ¿Es crítico el rendimiento?
5 ¿Se ejecutara el sistema en un entorno operativo existente y fuertemente
utilizado?
6 ¿Requiere el sistema entrada de datos interactivos?
7 ¿Requiere la entrada de datos interactiva que las transacciones de entrada
33
se lleven
a cabo sobre múltiples pantallas u operaciones?
8 ¿Se utilizan los archivos maestros de la forma interactiva?
9 ¿Son complejas, las salidas, los archivos o las peticiones?
10 ¿Es complejo el procesamiento interno?
11 ¿ Se ha diseñado un código para ser reutilizable?
12 ¿Están incluidas 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?
Tabla 2.3: Preguntas para el cálculo del Fi.
Para obtener el cálculo del factor de ajuste que está dado por: Fi, Grado de influencia
se evalúa en un rango de 0 a 5.
Escala de rangos para las preguntas de la tabla 2.2.
Término Valor
No influenciable 0
Incidencia 1
Moderado 2
Medio 3
Significativo 4
Esencial 5
Tabla 2.4. Escala de rangos.
34
ii. CONFIABILIDAD
Cantidad de tiempo que software está disponible para su uso. Está referido por los
siguientes sub atributos: madurez, tolerancia a fallos y facilidad de recuperación.
Nivel de Madurez. Permite medir la frecuencia de falla por errores en el software.
Tolerancia a fallas. Se refiere a la habilidad de mantener un nivel específico de
funcionamiento en caso de fallas del software o de cometer infracciones de su
interfaz específica.
Recuperación. Se refiere a la capacidad de restablecer el nivel de operación y
recobrar los datos que hayan sido afectados directamente por una falla, así como al
tiempo y el esfuerzo necesarios para lograrlo.
Para la aplicación de la confiabilidad se utilizara la siguiente fórmula:
F(t)= f * e ( -λ / 10 * t)
Dónde:
f: Es la funcionalidad del sistema ya calculado.
-λ: Es la probabilidad de error que pueda tener el sistema.
t: Tiempo que dura una gestión en el Sistema.
Y la probabilidad de que el sistema esté libre de fallos es: P (T>=t) = 1- F(t)
iii. USABILIDAD
Consiste de un conjunto de atributos que permiten evaluar el esfuerzo necesario que
deberá invertir el usuario para utilizar el sistema.
Comprensibilidad. Se refiere al esfuerzo requerido por los usuarios para reconocer la
estructura lógica del sistema y los conceptos relativos a la aplicación del software.
35
Facilidad de Aprender. Establece atributos del software relativos al esfuerzo que los
usuarios deben hacer para aprender a usar la aplicación.
Operabilidad Agrupa los conceptos que evalúan la operación y el control del sistema.
Para realizar el cálculo de usabilidad aplicamos la siguiente fórmula:
FU= [(Σ xi/n) * 100]/N
Dónde:
N: número de la población.
n: número en la Muestra.
iv. MANTENIBILIDAD
Se refiere a los atributos que permiten medir el esfuerzo necesario para realizar
modificaciones al software, ya sea por la corrección de errores o por el incremento de
funcionalidad. Se tienen los siguientes factores:
Capacidad de análisis. Relativo al esfuerzo necesario para diagnosticar las
deficiencias o causas de fallas, o para identificar las partes que deberán ser
modificadas.
Capacidad de modificación. Mide el esfuerzo necesario para modificar aspectos del
software, remover fallas o adaptar el software para que funcione en un ambiente
diferente.
Estabilidad. Permite evaluar los riesgos de efectos inesperados debidos a las
modificaciones realizadas al software.
36
v. Costo y tiempo
Cocomo surgió para medir y calcular el coste y el tiempo de un determinado proyecto
basándose fundamentalmente en las líneas de código y algunas constantes.
[Ferrando, Fito y Yarza, s.f.]
Formulas:
E=A(KL)b * m(X) donde:
E = es el Salario/Mes (Media).
a y b = constantes según el modo (Orgánico, Semilibre o Rígido).
KL= cantidad de líneas de código (En miles)
m(X)= multiplicador que depende de 15 atributos constantes.
MODO a b c d
Orgánico 2.40 1.05 2.50 0.38
Semilibre 3.00 1.12 2.50 0.35
Rígido 3.60 1.20 2.50 0.32
Tabla 2.5. Constantes según el modo del software.
Modo orgánico: Un pequeño grupo de programadores experimentados desarrollan
software en un entorno familiar.
Modo semilibre: Corresponde a un esquema intermedio entre el orgánico y rígido.
Modo rígido: El proyecto tiene fuertes restricciones que el problema a resolver es
único y es difícil basarse en la experiencia.
37
Tabla 2.6: Atributos para el multiplicador m(X).
Personas necesarias por mes:
(MM) = a*(KLb)
Tiempo de desarrollo del proyecto:
(TDEV) = c*(MMd)
Personas necesarias total:
(CosteH) = MM/TDEV
Coste total del proyecto:
(CosteM) = CosteH * E
38
CAPITULO III
3 Marco Aplicativo
3.1 Introducción
El desarrollo del presente proyecto tiene por objetivo crear el Sistema de gestión
contable vía web para el servicio de Outsourcing para la empresa MAERO
CONSULTORA MULTIDISCIPLINARIA S.R.L. utilizando la metodología ágil SCRUM.
3.2 Recopilación y análisis de requerimientos
3.2.1 Recopilación de requerimientos
Una técnica excelente que permite mejorar la comprensión de los requerimientos es
la creación de casos de uso, es decir, descripciones narrativas de los procesos del
dominio.
Sistema
Ingresar a la
página de inicio
Validar datos
«uses»
Administrador del sistema
Contador
Ingresar usuario y
constraseña
Selecion de la
gestion
«uses»
Cliente
Validar acceso de
los usuarios
Figura 3.1: Diagrama de caso de uso “Acceder al sistema”.
Caso de Uso : Acceder al sistema
Actores: Contador, Administrador del sistema y Cliente
Propósito: Acceder al sistema para su respectivo uso.
Resumen: Los actores introducen su usuario y contraseña en respuesta el
sistema le permite el acceso o lo rechaza
Precondiciones: El sistema debe tener almacenado en su base de datos el usuario y
contraseña.
Tipo: Primario, real
Curso norma de eventos
Acción de los actores Respuesta del sistema
1 Ingresa su usuario y contraseña 2 Compara los datos de entrada usuario y
contraseña con los de la base de datos
3 Muestra el usuario en pantalla y una lista de
las gestiones disponibles de la empresa.
4 El usuario accede a la gestión con la
cual desea trabajar.
Cursos alternos
Línea 2 En caso de introducir un usuario y contraseña inexistentes en la base de
datos el sistema. Alerta solicitando que vuelva a intentarlo.
Línea 2 Si el campo usuario o contraseña tienen 5 o menos caracteres. Alerta
pidiendo que estos sean mayores a 5 caracteres.
Tabla 3.1 Descripción del caso de uso “Acceder al sistema”.
39
40
Sistema
Seleccion del Menu
Usuarios
Adicionar Usuario «extends»
Asignacion de
Perfil «extends»
Modificar Usuario
Administrador del sistema
Eliminar Usuario
Figura 3.2: Diagrama de caso de uso “Administración de Usuarios”.
Caso de Uso : Administración de Usuarios
Actores: Administrador del Sistema
Propósito: Administrar los usuarios, privilegios y accesos al sistema.
Resumen: El administrador del sistema puede adicionar, modificar y eliminar
usuarios, además de darle al usuario acceso y privilegios al sistema
Precondiciones: Debe existir un usuario que tenga el perfil de Administrado de sistema.
Tipo: Secundario, esencial
Curso norma de eventos
Acción de los actores Respuesta del sistema
1 Selecciona el menú usuarios 2 Muestra la usuario las opciones de Crear
Usuario y Asignación de Perfil
41
3 El Administrador del sistema
selecciona la opción Crear Usuario
4 El sistema permite crear un nuevo usuario,
modificar los datos del usuario y eliminar un
usuario.
5 El Administrador del sistema
selecciona la opción de Asignación de
Perfil
6 El sistema permite seleccionar un usuario y
asignarle el perfil o los perfiles que tendrá.
Cursos alternos
Línea 4 Si el administrador inserta datos repetidos o datos erróneos. Alerta error
al adicionar o modificar el usuario.
Tabla 3.2 Descripción del caso de uso “Administración de Usuarios”.
Sistema
Seleccionar el
Menu Empresa
«uses» Adicionar Empresa
Administrar Empresa «uses»
Modificar Empresa
Administrar gestion «uses»
Administrador del sistema
«uses»
Crear nueva gestion
Creacion de Backups Modificar gestion
Figura 3.3: Diagrama de caso de uso “Administración de las empresas”.
Caso de Uso : Administración de las empresas
Actores: Administrador del Sistema
Propósito: Administrar la empresa, sus gestiones y sus respectivos backups.
Resumen: El Administrador del sistema puede adicionar, modificar una empresa,
además puede crear nueva gestión partiendo desde cero o crear una
nueva gestión a partir de otra. También permite la opción para crear
backups.
Precondiciones: Debe existir un usuario que tenga el perfil de Administrado de sistema.
Tipo: Primario, real
Curso norma de eventos
Acción de los actores Respuesta del sistema
1 Selecciona el menú Administración de
las empresas
2 Muestra las opciones Administrar Empresa,
Administrar gestión y creación de Backups.
3 El Administrador del sistema
selecciona la opción Administrar
Empresa
4 El sistema permite crear una nueva
empresa y modificar los datos de la empresa.
5 El Administrador del sistema
selecciona la opción de Administrar
gestión
6 El sistema permite crear una nueva gestión
desde cero, crear una nueva gestión
partiendo de una anterior, modificar los datos
de la gestión.
7 El Administrador del sistema
selecciona la opción de Creación de
Backups
8 El sistema crea una backup de la gestión
seleccionada.
Cursos alternos
Línea 4 Si el administrador adicionar o modifica con datos vacios el sistema
muestra una Alerta de que debe de llenar el campo.
Tabla 3.3 Descripción del caso de uso “Administración de las empresas”.
42
Sistema
Administrar tipo
«uses»
«uses»
Adicionar Tipo de
Asiento
Modificar Tipo de
Asiento
«uses»
de Asiento «uses» Verificar si tiene
movimento el tipo de
Eliminar Tipo de
Asiento
«uses» Asiento
Contador
«uses»
Adicionar Nuevo
nivel para las cuentas
Administrar nivel
plan de cuentas
«uses»
«uses»
Modificar Nivel de
las cuentas
Eliminar Nivel de
la cuenta
«uses»
Adicionar Cuenta «uses»
Administracion
Plan de cuentas
«uses»
«uses»
Modificar Cuenta
«uses» Verificar si tiene
movimento la cuenta
Eliminar Cuenta
Adicionar Asiento «uses» Contable
Administracion de los
asientos contables «uses»
Modificar Asiento
Contable
Figura 3.4: Diagrama de caso de uso “Administración Contable”.
43
Caso de Uso : Administración Contable
Actores: Contador
Propósito: Administrar la adición, modificación y eliminación de los datos
necesario para que funcione el sistema contable.
Resumen: Permite al contador la adición, modificación y eliminación del tipo de
asiento (Activo, Pasivo, Patrimonio, etc.), los niveles y la cantidad de
dígitos de cada nivel, la adición, modificación y eliminación de cuentas
contables y el registro de asientos contables.
Precondiciones: El Contador debe definir primero los diferentes tipos de asientos, luego
los niveles con los cuales contara la empresa.
Tipo: Primario, esencial
Curso norma de eventos
Acción de los actores Respuesta del sistema
1 Selección de la administración del tipo
de Asiento
2 El sistema permite la adición, modificación
y eliminación de los tipos de Asientos.
3 Selección de la administración del nivel
plan de cuentas
4 El sistema permite la adición, modificación
y eliminación del nivel de cuentas.
5 Selección de la administración del plan
de cuentas
6 El sistema permite la adición, modificación
y eliminación de las cuentas.
7 Administración de los asientos
contables
8 El sistema permite la adición y modificación
de Asientos contables
Cursos alternos
Línea 2 Si al adicionar se verifica que el código existe se mostrara una alerta: No
se puede adicionar el tipo de asiento, ya existe el código.
Línea 2 Si al eliminar el tipo de asiento tuviera movimiento en los registros
contables entonces se mostrara una alerta: No se puede eliminar el tipo de
Asiento tiene movimiento.
Línea 6 Si al adicionar la cuenta contable existe se mostrara una alerta: No se
44
45
puede adicionar la cuenta contable ya existe.
Línea 6 Si al eliminar la cuenta contable tiene movimiento en los registros
contables entonces se mostrara una alerta: No se puede eliminar la cuenta tiene
movimiento.
Tabla 3.4 Descripción del caso de uso “Administración Contable”
Sistema
Adicionar Clientes
«uses»
Administrar de
clientes
«uses»
«uses»
Modificar Clientes
Eliminar Clientes
Contador
«uses»
Adicionar
Proveedores
Administrar
Proveedores
«uses»
«uses»
Modificar
Proveedores
Eliminar
Proveedores
«uses»
Adicionar registro
Administracion
Libro de ventas
«uses»
«uses»
Modificar registro
Eliminar Registro
«uses»
Adicionar registro
Administracion
Libro de ventas
«uses»
«uses»
Modificar registro
Eliminar Registro
Figura 3.5: Diagrama de caso de uso “Administración del libro de compras y ventas”.
46
Caso de Uso : Administración del libro de compras y ventas
Actores: Contador
Propósito: Administrar la adición, modificación y eliminación de los datos
necesario para que funcionen los libros de compras y ventas.
Resumen: Permite al contador la adición, modificación y eliminación de clientes,
proveedores, libro de compras y libro de ventas.
Precondiciones: El Contador debe introducir al cliente si se desea hacer un registro en
el libro de ventas y debe introducir al proveedor si se desea hacer un
registro en el libro de compras.
Tipo: Primario, esencial
Curso norma de eventos
Acción de los actores Respuesta del sistema
1 Selección de la administración del
Cliente
2 El sistema permite la adición, modificación
y eliminación de los clientes.
3 Selección de la administración
Proveedor
4 El sistema permite la adición, modificación
y eliminación de los proveedores.
5 Selección de la administración del
libro de ventas
6 El sistema permite la adición, modificación
y eliminación del libro de ventas.
7 Seleccione de la administración del
libro de compras
8 El sistema permite la adición, modificación
eliminación del libro de compras
Cursos alternos
Línea 6 No puede existir dos facturas con el mismo número de factura y con
código de autorización iguales, si esto pasa mostrar una alerta.
Línea 8 No puede existir dos facturas con el mismo número de factura y con
código de autorización iguales, si esto pasa mostrar una alerta.
Tabla 3.5 Descripción del caso de uso “Administración del Libro de compras y
ventas”.
47
Sistema
Mostrar Libro
Diario
Mostrar Libro Mayor
Mostrar Hoja de
Trabajo
Contador
Mostrar Balance de
Comprabacion Sumas y Saldos
Cliente
Mostrar Estado de
Resultados
Mostrar Balance
General
Figura 3.6: Diagrama de caso de uso “Reportes Contables”
Caso de Uso : Reportes Contables
Actores: Contador y el Cliente
Propósito: Mostrar los diferentes reportes contables.
Resumen: Genera los diferentes reportes contables que necesitan las empresas
para la toma de decisiones y su respectivo trato con las entidades
fiscalizadoras.
Precondiciones: Se debe tener actualizado todos los Asientos contables hasta la fecha
que se desea mostrar la información.
Tipo: Secundario, esencial
Curso norma de eventos
Acción de los actores Respuesta del sistema
1 Seleccionar la opción mostrar libro
diario y seleccionar el rango de fechas
que se desea ver.
2 El sistema muestra todos los asientos
realizados en el rango de fechas
seleccionado.
3 Seleccionar la opción mostrar libro
mayor y seleccionar el rango de fechas
que se desea ver con su respectiva
cuenta contable.
4 El sistema muestra todos los registros de
una cuenta contable en el rango de fechas
seleccionado.
5 Seleccionar la opción mostrar Hoja de
Trabajo y seleccionar el rango de fechas
que se desea ver.
6 El sistema muestra la hoja de trabajo en el
rango de fechas seleccionado.
7 Seleccionar la opción mostrar balance
de comprobación de sumas y saldos,
luego seleccionar el rango de fechas y el
nivel que se desea ver.
8 El sistema muestra el balance de
comprobación de sumas y saldos en el rango
de fechas y nivel seleccionado.
9 Seleccionar la opción mostrar estado
de resultados y seleccionar el rango de
fechas y el nivel que se desea ver.
10 El sistema muestra estado de resultados
en el rango de fechas y nivel seleccionado.
11 Seleccionar la opción mostrar balance
general y seleccionar el rango de fechas
y nivel que se desea ver
12 El sistema muestra el balance general en
el rango de fechas y nivel seleccionado.
Tabla 3.6 Descripción del caso de uso “Reportes Contables”.
48
49
3.2.2 Análisis de requerimientos
Una vez realizada la recopilación de requerimientos mediante los diagrama de caso
de uso, se especifica lo que se va a realizar en las iteraciones, además de la
prioridades y la estimación de tiempos para el desarrollo del sistema, también es
necesario realizar el Product Backlog que contendrá los requerimientos y
características finales del sistema, para esto se utilizar TeamTrick el cual es una
herramienta de software libre para la gestión del Scrum.
Para el este proyecto se utilizara un story points de 1,2,4,8,16,32,64 y 96 los cuales a
la vez representaran el tiempo que demora cada historia de usuario.
Figura 3.7: Product Backlog (pila del producto).
50
3.3 Planificación y finalización de los Sprints
3.3.1 Primer Sprint
Planificación del Sprint
La duración del Sprint es de 2 semanas que equivale a 10 días hábiles con 8 horas
de trabajo por día, el factor foco para este Sprint es del 80% lo cual nos dice que de
las 8 horas de trabajo al día solo se trabajaran 6 horas y 20. La planificación en el
programa Team Trick es la siguiente.
Figura 3.8: Planificación del primer Sprint.
51
En este primer Sprint se realizo las primeras dos tarea del producto backlog la
“Creación del modelo y la base de datos” y "Creación de los programas de inicio de
sistema" con una estimación de 8 días que equivalen a 64 horas. Lamentablemente
la herramienta no permite hacer una ordenación de las tareas, por esta razón es que
primero aparase la “Creación de los programa de inicio del sistema” y luego la
“Creación de los programas de inicio del sistema”, como se muestra en la figura 3.9.
Figura 3.9: Backlog del Primer Sprint.
52
Sessions
PK sesion FK1
expiracion
data
usuario
ip base
browser
version_browser
plataforma
fechasys
horasys
Empresa
PK id
razon nit
representante
fax
telf1 telf2
celular
pais
depto
zona
ciudad
direccion
website1
website2
Usuarios
PK usuario
FK1
nombre
contrasena
fechatop
supusuario
id_empresa
3.3.1.1 Modelo conceptual
Se creó el diagrama entidad relación para modelar la base de datos y a partir de este
diagrama podemos crear el diagrama de clases. Se crearon dos bases de datos: una
como base de datos maestra, la cual guardara un registro de todas las gestiones
creadas de una determinada empresas, y la otra que contiene todos los datos
contables de una gestión.
Gestion
PK id
FK1
FK2
id_empresa
descrip
gestion
fecha_ini
fecha_fin
dbname
moneda
usuario
fechasys
horasys
Perfiles
PK codigo
Acceso
PK,FK1 cod_usuario
PK,FK2 perfil
descrip
path
FK1 usuario
fechasys
horasys
adicionar
modificar
eliminar
imprimir
usuario
fechasys
horasys
Figura 3.10: Diagrama relacional de la base de datos maestra.
proveedor
PK id
razon nit
autorizacion
telf
celular
pais
depto
domicilio
creditobs
creditosus
usuario
fechasys
horasys
Moneda
PK codigo
descrip
Dolar
PK fecha
ufv
usuario
fechasys
Proveedor_contacto
PK id
FK1
id_proveedor
nombre
telf
celular
cliente
PK id
razon
nit
telf
celular
pais
depto
domicilio
usuario
fechasys
horasys
Cliente_contacto
PK id
FK1
id_cliente
nombre
telf
celular
Presupuesto_det
PK,FK1
PK id_presupuesto
mes
monto
Fig
ura
3.1
1 D
iag
ram
a re
lacio
na
l de
la g
estió
n d
e u
na e
mp
resa
.
53
LibroCompras
PK id
tipofac
poliza
fecha
nit
FK2 proveedor
factura
autorizacion
codigocontrol
importe
exento
ice
neto
iva
flete
FK1 asiento
usuario
fechasys
LibroVentas
PK id
fecha
nit
FK2 cliente
razonsocial
factura
Asiento
PK codigo
cta
mes
FK1 tipo
secuencia
srs
debebs
haberbs
debesus
habersus
glosa
FK2 fecha
usuario
fechasys
horasys
TipoAsiento
PK codigo
descrip
Asientotemplate
PK id
Asiento_det
PK,FK1 cod_asiento
PK,FK2 cuenta
item
debebs
haberbs
debesus
habersus
FK3 cencosto
referencia
CenCostos
PK codigo
descrip
Asientotemplate_det
PK,FK3 id_template
PK,FK2 cuenta
item
referencia
FK1 cencostos
Plancuenta
PK cuenta
FK1 tipocuenta
FK3 nivel
descrip
FK2 tipomov
FK4 moneda
fecha
debebs
haberbs
debesus
habersus
usuario
fechasys
TipoCuenta
PK codigo
descrip
Nivel
PK nivel
digitos
MovCuenta
PK codigo
descrip
Presupuesto
PK id
FK1 cuenta
fecha
FK2 moneda
total
autorizacion
importe
exento
ice
neto
iva
estado
FK1 asiento
descrip
FK1 tipo
cta
srs
glosa
Dolar_det
PK,FK2 moneda
PK,FK1 fecha
compra
venta
54
Empresa +id : int
+razon : string
+nit : double
+representante : string
+fax : int
+telf1 : int
+telf2 : int
+celular : int
+pais : string
+depto : string
+ciudad : string
+zona : string
+direccion : string
+website1 : string
+website2 : string
1 *
Gestion +id : int
+id_empresa : int
+descrip : string
+gestion : int
+fecha_ini : Date
+fecha_fin : Date
+dbname : string
+moneda : string
+usuario : string
+fechasys : Date
+horasys : Long
+cargar()
+adicionar()
+modificar()
+eliminar() +cargar()
+adicionar()
+modificar()
*
Usuarios
-usuario : string
-nombre : string
-contrasena : string
-fechatop : Date
-supusuario : int
-id_empresa : int
+adicionar()
+modificar()
+eliminar()
+cambiar_contrasena()
+login_in()
+login_out()
+validar_datos()
Perfiles
-codigo : string
-descrip : string
-path : string
-usuario : string
-fechasys : Date
-horasys : long
+cargar()
1 1
*
Acceso
* -cod_usuario : string -cod_perfil : string
-adicionar : bool
-modificar : bool
-eliminar : bool
-imprimir : bool
-usuario : string
-fechasys : Date
-horasys : long
+cargar()
+adicionar()
+modificar()
+eliminar()
Figura 3.12: Modelo Conceptual (Diagrama de clases).
Provedores
+id : int
+razon : string
+nit : double
+autorizacion : string
+telf : int
-celular : int
+email : string
+pais : string
+depto : string
+domicilio : string
+credigobs : decimal 1
+creditosus : decimal
LibroCompras
+id : int
+tipofac : int
+poliza : string
+fecha : int
+nit : Double
+proveedor : Date
+factura : int
+autorizacion : string
+codigocontrol : string
+importe : Decimal
+exento : Decimal
-ice : Decimal
-neto : Decimal
Asiento
-codigo : string
-cta : int 1 1
-mes : string
-tipo : string
-secuencia : int
-srs : string
-debebs : Decimal
-haberbs : Decimal
-debesus : Decimal
-habersus : Decimal
-glosa : string
-fecha : Date
Plancuenta
-cuenta : string
-tipocuenta : string
-nivel : int
-descrip : string
-tipomov : string
-moneda : string
-fecha : Date
1 * -debebs : Decimal -haberbs : Decimal
-debesus : Decimal
-habersus : Decimal
+cargar()
TipoCuenta
-codigo : string 1 * -descrip : string
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
1 Nivel
* *
-contactos : object
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
+grabar_contacto()
+imprimir()
-iva : Decimal -flete : Decimal
-asiento : string
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
+verificar()
-cuenta : Plancuenta
+adicionar()
+modificar()
+cargar_datos()
+verificar_totales()
+imprimir()
+validar_datos()
1
+adicionar() +modificar()
+eliminar()
+cargar_datos()
+sumar_cuenta()
+imprimir()
*
1
-nivel : string -digitos : string
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
1
+exportar()
+imprimir()
1
11
TipoAsiento
-codigo : string
-descrip : string
* 1
CenCostos
-codigo : string
-descrip : string
1
Moneda
-codigo : string
-descrip : string
MovCuenta
-codigo : string
-descrip : string
+cargar()
Clientes
+id : int
+razon : string
+nit : double
+telf : int
-celular : int
+email : string
+pais : string
+depto : string
+domicilio : string
-contactos : object
LibroVentas
+id : int
+fecha : int
+nit : Double
+cliente : Date
-razonsocial : string
+factura : int
+autorizacion : string
+importe : Decimal 1
* +exento : Decimal -ice : Decimal
-neto : Decimal
-iva : Decimal
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
1
AsientoTemplate
-id : int
-descrip : string
-tipo : string
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
1
Dolar
-fecha : string
-ufv : string
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
1
Presupuesto
-id : int
-fecha : Date
-moneda : string
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
+grabar_contacto()
+imprimir()
-asiento : string
-estado : char
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
+verificar()
+exportar()
+imprimir()
-cta : string
-srs : string
-glosa : string
-cuenta : Plancuenta
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
-moneda : object
+cargar()
+adicionar()
+modificar()
+cargar_datos()
-total : Decimal
-cuenta : object
+cargar()
+adicionar()
+modificar()
+eliminar()
+cargar_datos()
Figura 3.13: Modelo Conceptual (Diagrama de clases).
55
3.3.1.2 Modelo navegacional
En un sistema para la web es útil saber cómo están enlazadas las páginas por ello es
que utilizamos el modelo navegación. El modelo navegacional es un como un mapa
que nos permite saber por dónde podemos navegar en el sistema para llegar a un
programa o aplicación en concreto.
Figura 3.14: Modelo Navegacional del Administrador.
Figura 3.15: Modelo Navegacional del Contador.
56
Figura 3.16: Modelo Navegacional de los clientes de MAERO.
57
58
3.3.1.3 Modelo de presentación
Este paso consiste en modelar las fases de la presentación, las cuales muestran
donde se presentará al usuario los objetos de navegación y los elementos de acceso,
por ejemplo en la ventana inicio al sistema se mostrara el usuario y contraseña para
entrar al sistema, luego de ingresa este nos permitirá ver las diferentes empresas
con sus respectivas gestiones.
Interfaz de inicio al sistema: La interfaz nos permite entrar al sistema con un
usuario y contraseña creados previamente.
Figura 3.17: Interfaz de inicio al sistema.
59
Interfaz de administración de usuarios: administra las altas, bajas y
modificaciones de los usuarios y a la empresa que tienen acceso.
Figura 3.18: Interfaz de Administración de usuarios.
Interfaz de acceso de usuarios: Permite definir que accesos tiene el usuario,
pudiendo ser este: contador, cliente y/o administrador.
Figura 3.19: Interfaz de inicio al sistema.
60
Interfaz gestión: Administra las diferentes gestiones de las empresas.
Figura 3.20: Interfaz de Administración de la gestión.
Interfaz administración de las empresas: Administra los datos de las empresas.
Figura 3.21: Interfaz de Administración de las Empresas.
61
Interfaz nivel contable: Adiciona, modifica los niveles del plan de cuenta. El cambio
afecta a todas las cuentas.
Figura 3.22: Interfaz de Administración del nivel.
Interfaz plan de cuentas: Administra las altas, bajas y modificaciones de las
cuentas contables.
Figura 3.23: Interfaz del Plan de Cuentas.
62
Interfaz asiento contable: Registro de los asiento contables de una empresa
mostrando el monto en bolivianos y dólares.
Figura 3.24: Interfaz de los Asientos Contables.
Interfaz del libro diario: Muestra todos los asientos contables creados en un
determinado rango de fechas o de un tipo de asiento.
Figura 3.25: Interfaz del Libro Diario.
63
Interfaz libro mayor: muestra todas las transacciones de una cuenta en un rango de
fechas.
Figura 3.26: Interfaz del Libro Mayor.
Interfaz de la hoja de trabajo: Imprime la hoja de trabajo en un rango de fechas.
Figura 3.27: Interfaz de la Hoja de Trabajo.
64
Interfaz balance de comprobación sumas y saldos: Muestra el balance de
comprobación por un rango de fechas.
Figura 3.28: Interfaz del Balance de Comprobación.
Interfaz estado de resultados: Muestra las cuentas de ingreso y egreso.
Figura 3.29: Interfaz del Estado de Resultados.
65
Interfaz balance general: Muestra las cuentas de activo, pasivo y patrimonio.
Figura 3.30: Interfaz del Balance General.
Interfaz tipo de cambio: permite registrar por día la cotización del tipo de dólar.
Figura 3.31: Interfaz del Tipo de cambio del dólar.
66
Interfaz proveedores: Administra las altas, bajas y modificaciones de los
proveedores.
Figura 3.32: Interfaz del Proveedor.
Interfaz del libro de compras: permite registrar las facturas para el descargo a
impuestos internos.
Figura 3.33: Interfaz del Libro de Compras.
67
Interfaz clientes: Administra las altas, bajas y modificaciones de los clientes de la
empresa.
Figura 3.34: Interfaz del Cliente.
Interfaz libro de ventas: Registra las ventas de los clientes para la presentación a
impuestos internos.
Figura 3.35: Interfaz del Libro de Ventas.
68
Finalización del primer Sprint
Se tenía previsto un trabajo de 64 horas, pero el trabajo real duro 80 horas, lo cual es
importante tomar en cuenta para la planificación del siguiente sprint, también
conveniente aumentar un tiempo extra del estimado para solucionar algunos
problemas que pueden aparecer en el diseño o el desarrollo del sistema.
Figura 3.36: Burndown del primer Sprint.
69
Figura 3.37: Primera historia de usuario "Creación del modelo y la Base de datos"
con sus respectivas tereas.
70
Figura 3.38: Segunda historia de usuario "Creación de los programas de inicio de
sistema" con sus respectivas tereas.
71
3.3.2 Segundo Sprint
Planificación del Sprint
Para la planificación de este Sprint se tomo un factor foco del 90%, tomando en
cuenta que el anterior factor foco se tomo de 80% pero el real fue del 94%. La
planificación en el programa Team Trick es la siguiente.
Figura 3.39: Planificación del Segundo Sprint con sus respectivas historias de
usuario.
72
Finalización del segundo Sprint
En este segundo Sprint se realizo las tareas de "Creación del Programa Adm. de
usuarios", "Creación del programa de Adm de las Empresas y gestión" y "Creación
de la Adm. de clientes y proveedores".
Para este Sprint hubieron muchas dificultades sobre todo en el creación de una
empresa y el cambio de gestión de la misma, para el primer caso se debe crear una
base de datos nueva con todas las tablas necesarias para el funcionamiento del
sistema, y para el Cambio de gestión se deben copiar tablas maestra de una
determinada gestión aparte de crear los asientos de apertura automáticamente.
Figura 3.40: Burndown del segundo Sprint.
73
Figura 3.41: Tercera historia de usuario "Creación del programa Adm. y de usuarios"
con sus respectivas tereas.
Figura 3.42: Cuarta historia de usuario "Creación del programa de Adm. de las
Empresas y Gestiones" con sus respectivas tereas.
74
Figura 3.43: Quinta historia de usuario "Creación de la Adm. de Clientes y
Proveedores" con sus respectivas tereas.
3.3.3 Tercer Sprint
Planificación del Sprint
Esta Sprint es el más importante ya que en base a él saldrán todos los reportes
necesarios como: el Libro Mayor, el Balance de Comprobación, la Hoja de Trabajo,
Balance General, etc.
75
Figura 3.44: Planificación del tercer Sprint con sus respectivas historias de usuario.
Finalización del Sprint
Fue un Sprint difícil, la creación del plan de cuentas fue de forma recursiva, el
registro del asiento carga el dólar con su tipo de cambio para generar el asiento
bimonetario, el presupuesto carga por mes de acuerdo a la gestión de inicio de la
empresa.
76
Figura 3.45: Burndown del Tercer Sprint.
Figura 3.46: Sexta historia de usuario "Creación de Adm. Contable" Con su primera
terea "Creación de programas relacionados con el plan de cuentas y asiento".
77
Figura 3.47: Segunda terea "Creación del Plan de Cuentas" de la Sexta historia de
usuario.
Figura 3.48: Pantalla del “Plan de Cuentas”.
78
Figura 3.49: Tercera terea "Creación del Registro de Asientos" de la Sexta historia de
usuario.
Figura 3.50: Cuarta terea "Creación del Presupuesto" de la Sexta historia de usuario.
Figura 3.51: Pantalla del “Registro del Asiento”.
79
3.3.4 Cuarto Sprint
Planificación del Sprint
En este Sprint se realizaran todos los reportes contables necesarios para la empresa
MAERO S.R.L.
Figura 3.52: Planificación del tercer Sprint con sus respectivas historias de usuario.
Finalización del Sprint
Este Sprint se caracterizo por ser uno de los mas trabajos, ya que hacer las
consultas con sus respectivos reportes fue una tarea larga y nos sobrepasamos con
el tiempo del Sprint, se tenía un tiempo de 10 días hábiles con 8 horas de trabajo,
pero esto no fue suficiente y el Sprint se extendió en una semana más que equivale a
80 horas de trabajo
80
Figura 3.53: Burndown del cuarto Sprint.
Figura 3.54: Séptima historia de usuario "Creación de los reportes contables", Con su
primera terea "Libro Diario".
81
Figura 3.55: Reporte del "Libro Diario".
Figura 3.56: Segunda terea "Libro Mayor" de la séptima historia de usuario.
Figura 3.57: Reporte del "Libro Mayor".
82
Figura 3.58: Tercera terea "Balance de comprobación" de la séptima historia de
usuario.
Figura 3.59: Reporte del "Balance de comprobación".
83
Figura 3.60: Cuarta terea "Balance General" de la séptima historia de usuario.
Figura 3.61: Reporte del "Balance General".
84
Figura 3.62: Quinta terea "Estado de Resultados" de la séptima historia de usuario.
Figura 3.63: Reporte "Estado de Resultados"
Figura 3.63: Sexta terea "Hoja de Trabajo" de la séptima historia de usuario.
85
Figura 3.64: Reporte de la "Hoja de Trabajo".
Figura 3.65: Octava historia de usuario "Creación del Libro de Compras y Ventas"
con sus respectivas tareas.
86
CAPITULO IV
4. Calidad de Software
La calidad de software es una preocupación a la que se dedican muchos esfuerzos,
Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo
producir software de la mejor calidad posible, que cumpla y si puede supere las
expectativas de los usuarios.
La calidad de un producto software es el indicador que permite determinar si los
procesos de construcción de software fueron apropiados. Es por esto que debe
indagarse sobre los métodos y técnicas que garantizan calidad en los productos, con
miras a general propuestas concretas para aplicaciones con características
específicas.
4.1 Pruebas (Test Unitarios)
Las pruebas que se hicieron al sistema fueron las pruebas unitarias automatizadas. <?php
class glo_asiento_test{
function asiento_ing_test() {
$db=new db();
$re_db=$db->conec_base();
$c_tools = new glo_tools();
//importamos la clase para hacer el test
$c_tools->importar_clase('../global/glo_test.php');
$c_test=new glo_test();
//importamos la clase que queremos testear, en este caso
glo_asiento.php
$c_tools->importar_clase('../global/glo_asiento.php');
$c_asiento=new glo_asiento();
//creamos el array con los datos de entrada
$obj_asiento=array( 'cta'=>1,
'tipo'=>"ING",
'nrodoc'=>'',
'nroid'=>'',
'tb_nroid'=>'',
'sistema'=>'VEN',
87
//guardamos en asiento
'programa'=>'CONTAB',
'srs'=>'Juan Perez',
'debebs'=>100,
'haberbs'=>100,
'debesus'=>100,
'habersus'=>100,
'glosa'=>'teste glo asiento',
'fecha'=>'2011-01-01',
'tc'=>6.97);
$re_asiento=$c_asiento->asiento_ing($obj_asiento);
//sacamos los datos guardados
$test_asiento=$c_test->carga_db('con_asiento',
array('codigo'=>$re_asiento['codigo']));
//comparamos que los datos guardados sean iguales a los datos de
entrada
foreach($obj_asiento As $key => $dato )
if($dato!=$test_asiento[$key])
$arr_error[]="El campo '$key', entrada='$dato' y
BD='$test_asiento[$key]'";
if(count($arr_error) && is_array($arr_error)) return $arr_error;
else
}
}
?>
return 'No existen errores';
En el cual el resultado fue:
Error en la comparación, el campo 'nroid', con dato de entrada ='' y BD='0'
Cambiando en el código fuente 'nroid'=>'', por 'nroid'=>'0', se soluciona el
problema y nos da como resultado:
"No Existen errores de comparación"
4.2 Fallos de seguridad software
SQL Injection.- Para evitar este fallo de seguridad se utilizo la función
mysql_real_escape_string(), la cual escapa caracteres especiales en la cadena no
escapada, teniendo en cuenta un conjunto de caracteres actual de la conexión para
que sea seguro usarla en mysql_query(). Si se van a insertar datos binarios, esta
función debe ser usada.
88
Esta función antepone backslashes a los siguientes caracteres: \x00, \n, \r, \, ',
" y \x1a.
HTML Injection.- Como se utilizo la tecnología Flash para el lenguaje de
programación del cliente y al ser este compilado, evita las inyecciones de código.
Escalada de directorios.- En este caso se deshabilito la opción de poder ver los
directorios del servidor.
Errores de mecanismos de Autenticación.- Para evitar este fallo se creó una clase
para la encriptación de los passwords, cantidad mínima de caracteres para los
mismos, a los tres intentos fallidos el programa se cierra con lo cual el usuario debe
refrescar la página.
Errores en el mecanismo de cifrado.- Para el mecanismos de cifrado se utilizó md5
y algunos mecanismos adiciones de encriptación.
4.3 Norma ISO/IEC 9126
ISO 9126 es un estándar internacional para la evaluación del Software. el estándar
está dividido en cuatro partes: modelo de calidad, métricas externas, métricas
internas y calidad en las métricas de uso.
4.3.1 Funcionalidad
Para medir el tamaño del software propuesto se utilizara la métrica de Punto
Función, este método pretende medir la funcionalidad entregada al usuario,
independientemente de la tecnología utilizando para la construcción y explotación del
software, y también ser útil en cualquiera de las fases del software, desde el diseño
inicial hasta la explotación y mantenimiento.
Características del dominio de la información:
PARAMETRO DESCRIPCION NUMERO
Número de entradas
Ubicación 1
Adm. de Usuarios 1
Acceso de usuarios 1
Nueva Gestión 1
Adm. de Empresas 1
Registro de datos 4
Nivel de cuentas 1
Impuestos 1
Plan de cuentas 1
Asiento 1
Presupuesto 1
Dólar 1
Clientes 1
Proveedores 1
Libro de compras 1
Libro de ventas 1
Número de salidas de
Usuario
Ubicación 1
Adm. de usuarios 1
Acceso de usuarios 1
Registro de datos 4
Nivel de cuentas 2
Impuestos 1
Plan de cuentas 1
Asiento 3
Reportes 7
89
Presupuesto 2
Dólar 1
Clientes 2
Proveedores 1
Libro de compras 1
Libro de ventas 1
Número de peticiones
de usuario
Adm. de usuario 1
Backup 1
Nueva gestión 1
Nivel de cuentas 1
Ajustar Plan Cuentas 1
Libro Diario 1
Libro Mayor 1
Hoja de Trabajo 1
Balance de comprobación 1
Estado de Resultados 1
Balance de general 1
Libro de compras 1
Libro de ventas 1
Número de Archivos
Tablas de la Base de Datos 48
Número de Interfaces
Externas
Disco Duro 1
CD 1
USB 1
Tabla 4.1: Características del dominio de la información
90
91
En el caso del sistema se cuenta con los siguientes datos:
Número de Entradas de usuario=19
Número de Salidas de Usuario=29
Número de Peticiones de Usuario=13
Número de Archivos= 48
Número de Interfaces Externas=3
La siguiente tabla se utiliza para determinar el valor de complejidad:
PARAMETRO CANTIDAD COMPLEJIDAD PF
Simple Media Alta
Número de Entradas de usuario 19 3 4 6 114
Número de Salidas de Usuario 29 4 5 7 203
Número de Peticiones de Usuario 13 3 4 6 78
Número de Archivos 48 7 10 15 480
Número de Interfaces Externas 3 5 7 10 15
Total 890
Tabla 4.2: Resultados de la complejidad.
Ahora se obtiene los valores de ajuste de complejidad basados en las respuestas a
las preguntas: valores de ajuste de complejidad
Nro. Preguntas Valor
1 ¿Requiere el sistema copias de seguridad y de recuperación fiable? 4
2 ¿Se requiere comunicación de datos? 0
3 ¿Existen funciones de procesamiento distribuido? 0
92
4 ¿Es crítico el rendimiento? 4
5 ¿Se ejecutara el sistema en un entorno operativo existente y
fuertemente utilizado?
4
6 ¿Requiere el sistema entrada de datos interactivos? 3
7 ¿Requiere la entrada de datos interactiva que las transacciones de
entrada se lleven a cabo sobre múltiples pantallas u operaciones?
2
8 ¿Se utilizan los archivos maestros de la forma interactiva? 3
9 ¿Son complejas, las salidas, los archivos o las peticiones? 2
10 ¿Es complejo el procesamiento interno? 3
11 ¿Se ha diseñado un código para ser reutilizable? 5
12 ¿Están incluidas en el diseño la conversión y la instalación? 2
13 ¿Se ha diseñado el sistema para soportar múltiples instalaciones en
diferentes organizaciones?
0
14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser
fácilmente utilizada por el usuario?
5
Total 37
Tabla 4.3: Valores de ajuste de complejidad basados en respuestas a las preguntas.
Cada una de las preguntas anteriores es respondida usando una escala con rangos
desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial).
Reemplazando los valores hallados en la siguiente fórmula:
PF=cuenta total * [0.65 + 0.01 * ∑(Fi)]
PF= 890*[0.65 + 0.01 * 37]
PF= 890*1.02
PF= 907.8
93
Para el punto función máximo:
PF máximo= 907.8 * [0.65 + 0.01 * 37]
PF máximo= 925.956
Funcionalidad= (907.8/925.956)*100
Funcionalidad= 98.04 %
4.3.2 Usabilidad
Para calcular la usabilidad del sistema realizamos una encuesta a los usuarios de la
siguiente manera:
ESCALA VALOR
Muy buena 5
Buena 4
Regular 3
Malo 2
Pésimo 1
Tabla 4.4: Escala de valores para la usabilidad.
NRO PREGUNTA EVALUACION
1 ¿El sistema es fácil de utilizar? 5
2 ¿Puedes parar el programa y salir de él en cualquier
momento?
5
3 ¿El sistema facilita el trabajo que usted realiza? 5
4 ¿Se ha satisfecho todos los requerimientos
establecidos?
5
5 ¿Cómo considera los formularios que elabora el
sistema?
4
94
6 ¿El sistema tiene la seguridad necesaria? 5
7 ¿Cómo considera el ingreso de datos al sistema? 5
8 ¿La generación de resultados le ayuda al proceso
de toma de decisiones?
4
Total 38
Tabla 4.5: Preguntas para hallar la usabilidad. Calculamos la facilidad de uso, tomando en cuenta que el Nro. de preguntas son 8 y
la encuesta se realizo a 5 personas
FU = [(Σ xi/n) * 100]/N
FU = [(38/8) * 100]/5
FU = 95
La facilidad de Uso del Sistema es de 95 %.
4.3.3 Confiabilidad
La confiabilidad del software es el tiempo que está disponible para su uso; se utiliza
la siguiente fórmula que calcula la confiabilidad del sistema:
F (t)= f * e ( -λ / 10 * t)
Donde:
f: Es la funcionalidad del sistema ya calculado: 0,98039.
λ: Es la probabilidad de error que pueda tener el sistema: 0,03 (3 %).
t: Tiempo que dura una gestión en el Sistema: 12 meses.
F(t)= 0.9804*e(-3/10*12)
95
F(t)=0.9801*0.02732372
F(t)=0.02678818
La probabilidad de que ocurran fallas en el sistema es de 2.7% entonces la
probabilidad de que el sistema esté libre de fallos es:
P(T>=t) = 1-F(t)
P(T>=t) = 1-0.02678818 = 0.97321182
P(T>=t) = 97%
4.3.4 Mantenibilidad
Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir
en un sistema software, en este sentido se usará el índice de madurez:
IMS = [Mt - (Fe + Fa + Fd)] / Mt
Donde:
Tipo Descripción Nro.
Mt: Número de módulos en la versión actual 35
Fe: Número de módulos en la versión actual que se han cambiado 5
Fa: Número de módulos en la versión actual que se han añadido 3
Fd: Número de módulos en la versión anterior que se han borrado en la
versión actual
0
Tabla 4.6: Tabla de resultados para la mantenibilidad.
Reemplazando en:
IMS = [Mt - (Fe + Fa + Fd)] / Mt
96
IMS = [35 - (5+3+0)] / 35 = 0,77
IMS = 0,77
Se concluye que el sistema tiene un Índice de Madurez del 77 % al momento de
realizar el mantenimiento.
4.3.5 Costo y tiempo
Líneas de código=3986
Es un sistema Orgánico.
MODO a b c d
Orgánico 2.40 1.05 2.50 0.38
Tabla 4.7: Datos del sistema Orgánico.
El multiplicador es:
Atributos Valor
Fiabilidad Nominal 1
Tamaño de Base de datos Bajo 0.94
Complejidad Bajo 0.85
Restricciones de tiempo de ejecución Nominal 1
Restricciones de memoria virtual Nominal 1
Volatilidad de la maquina virtual Bajo 0.87
Tiempo de respuesta Alto 1.07
Capacidad de análisis Nominal 1
Experiencia en la aplicación Bajo 1.13
Calidad de los programadores Nominal 1
Experiencia en la maquina virtual Bajo 1.17
Experiencia en el lenguaje Alto 0.95
97
Técnicas actualizadas de programación Nominal 1
Utilización de herramientas de software Nominal 1
Restricciones de tiempo de desarrollo Bajo 1.08
Total 1.008931022
Tabla 4.: Tabla de resultados del multiplicador m(X).
m(X)=1*0.94*0.85*0.87*1.07*1.13*1.17*0.95*1.08*1000=3026
Por la formula tenemos
E=A(KL)b * m(X)
E= 2.4 (3.986)1.05*1.008931022*1000
E=10342.77 Bs/Mes
Personas necesarias por mes:
(MM) = a*(KLb)
(MM) = 2.4*(3.986)1.05
(MM) = 10.2512 Personas/mes
Tiempo de desarrollo del proyecto:
(TDEV) = c*(MMd)
(TDEV) = 2.5*(10.25120.38)
(TDEV) = 6.05389 Meses
98
Personas necesarias total:
(CosteH) = MM/TDEV
(CosteH) = 10.2512/6.05389
(CosteH) = 1.6933
Coste total del proyecto: (CosteM) =
CosteH * E (CosteM) =
1.6933*10342.77 (CosteM) =
17482.93 Bs
99
CAPITULO V
5 Conclusiones y recomendaciones
5.1 Conclusiones
Al haber concluido con el Sistema de gestión contable vía web para el servicio de
Outsourcing se ha alcanzado a realizar en su totalidad los objetivos planteados en
el presente Proyecto de Grado, por lo tanto se puede dar las siguientes conclusiones:
El sistema permite la centralización de la información de los clientes
Gracias a que el sistema se encuentra en la web los clientes y contadores
pueden acceder a la información en todo momento, de esta manera se logro
mejorar el servicio de Outsourcing contable y permitir actualizaciones de forma
continua.
El sistema permite manejar la información contable de diferentes empresas.
Se logro asegurar la integridad de la información gracias a la base de datos
Mysql con las tablas Innodb, y se resguarda gracias a la seguridad con la que
cuenta.
Otros objetivos alcanzados:
Se construyo un pequeño framework el cual facilito de gran medida el
desarrollo de software.
La programación en PHP y FLASH mediante AMFPHP, crear un código fuente
mas entendible, amigable y legible al poder separar el lenguaje del servidor y
cliente.
La utilización de la herramienta Team Trick permite ver el avance del proyecto
en base a la planificación realizada, pudiendo de esta manera hacer ajustes
en su debido tiempo gracias al Burndown.
100
Utilizar las metodologías Scrum y Uwe para el desarrollo de software fue muy
bueno ya que Scrum nos dio la forma de trabajo y Uwe los artefactos para
entender el software.
Por tanto se concluye que el Sistema de gestión contable vía web para el servicio
de Outsourcing, para la empresa MAERO CONSULTORA MULTIDISCIPLINARIA
S.R.L., cumple con los objetivos planteados al iniciar el trabajo.
5.2 Recomendaciones
Se hace las siguientes recomendaciones:
La herramienta Team Trick fue suficiente para el desarrollo de software, pero
esta herramienta se puede mejorar teniendo un control directo con los
programas, para poder saber las modificaciones de los mismos.
Se puede considerar el desarrollo de diferentes módulos que tienen relación
con la parte contable para su integración como: Ventas - Facturación,
Inventarios, Activos fijos, Recursos humanos, Importación - Exportación,
Contabilidad de Costos, etc.
101
5.3 BIBLIOGRAFÍA
Alfaro, D. (2011,mayo) Estimación Agil con Story Points. Prontitud. Consultada el 29
de junio de 2011, de http://prontitud.com/2011/05/22/estimacion-agil-story-points/
Blé Jurado, C., Beas, J. M., Gutierrez, J., Reyes, F., y Mena G. (2010) Diseño Agil
con TDD (1ra Ed). España: Safe Creative.
Citón, M. L. (2006) Método agil Scrum aplicado al desarrollo de un software de
trazabilidad.Mendoza, Tesis de maestría. Universidad de Mendoza, Argentina
Ferrando, E., Fito, A., y Yarza, D. (s.f.) COCOMO II. Valencia, España: Florida
Universitaria.
Larman, C. (1999) UML y Patrones, Introducción al Análisis y Diseño Orientado a
Objetos (1ra Ed). Mexico: Printice Hall
Fernandez, E. (1979) Contabilidad comercial (9na Ed).La Paz, Bolivia: Gisbert & CIA.
S.A.
Gonzales Gomes, J. I. (s. f.) El Plan General de Contabilidad. Normalización
Contable. Diccionario Contable.
Huanca Aliaga, H. B. (2011) Elaboración de métricas para evaluar la seguridad del
software durante su desarrollo. La Paz, Bolivia: Tesis de Grado Universidad Mayor
de San Andrés
Impuestos Nacionales (s. f.) Glosario. Consultada el 3 de agosto de 2011, de
http://www.impuestos.gob.bo/index.php?option=com_content&view
=article&id=251:s&catid=135:glosario-tributario
Ortiz, E (2009) “Contabilidad computarizada. Introducción, generalidades y
definiciones” Consultada el 3 de agosto de 2011 de http://www.mailxmail.com/curso-
102
contabilidad-computarizada-introduccion-generalidades-definiciones/activo-pasivo-
patrimonio-ecuacion-contable-sus-variaciones-ilustracion
Sánchez Rodríguez, F. (1999) Medida del Tamaño Funcional de Aplicaciones
Software. Universidad de Castilla - La Mancha
Terán Gandarillas, G.J. (2001) Temas de Contabilidad básica. Cochabamba, Bolivia:
Editorial Educacion y cultura.
Web Engineering Group (s.f.) UWE-UML based Web Engineering. Consultada el 11
de agosto de 2011 de http://uwe.pst.ifi.lmu.de/index.html
Zandweghe, H. (2010) La tercerizacion de actividades como herramienta competitiva.
Ensayo sobre outsourcing.
ANEXOS
103
104
PROYECTO DE GRADO
SISTEMA DE GESTIÓN CONTABLE VÍA WEB PARA EL SERVICIO
DE OUTSOURCING
1. ANÁLISIS DE SITUACIÓN
1.1 Organización
MAERO CONSULTORA MULTIDISCIPLINARIA S.R.L.
1.2 Ubicación
Ciudad de La Paz, zona Miraflores entre Av. Pasoskanki y Av. Brasil.
1.3 Descripción
La empresa tiene como misión la de "Coadyuvar a la mejora de la gestión, en las
Empresas Privadas, Entidades Públicas, PYMES, y demás negocios; informar y
asesorar a todas las personas emprendedoras interesadas en incursionar en el
mundo de los negocios y la concretización de sus proyectos, aportándoles ideas y
tecnología para ello.
Apoyar académicamente al profesional Contable, al Administrador de Empresas y
todo aquel interesado en el tema; así como a aquellos que aún se encuentran en la
etapa del Estudio Universitario".
Las empresas que forman parte de la clientela del servicio de Outsourcing Contable
al no querer hacerse cargo de sus gestiones contables por diferentes razones,
contratan los servicios de MAERO CONSULTORA MULTIDISCIPLINARIA S.R.L. el
cual se encarga de: diseño, manejo del plan de cuentas, procesamiento de las
transacciones contables, preparación de estados financieros, elaboración y
presentación de las declaraciones mensuales tributarias, elaboración y presentación
de la declaración anual del impuesto a la renta, supervisión de la contabilidad,
asesoramiento en la aplicación de normas contables y tributarias, y otros.
105
Actualmente cuenta con un sistema para el servicio de Outsourcing él cual en un
principio fue suficiente, pero en el transcurso del tiempo no llego a cubrir todas las
necesidades de la empresa.
1.4 Organigrama
SOCIOS
ADMINISTRACIÓN SERVICIOS
AUX. CONTABLE
MENSAJERO
AUDITORIA
OUTSORSING
CONTABILIDAD
RR. HH.
Supervisor
OTROS Contador Encargado
IMPUESTOS
LEGAL
CONSULTORÍAS
1.5 Análisis FODA:
FORTALEZAS
1 Cuenta con un equipo humano y técnico altamente preparado en el
manejo de la información contable.
2 Tiene una buena relación con sus clientes en el servicio de Outsourcing
106
Contable.
3 Cuenta con un supervisor para la revisión de la información contable.
4 A fin de satisfacer los requerimientos de sus clientes tiene alianzas
estratégicas con consultores independientes.
5 Tienen bajos costos operativos por lo cual pueden ofrecer un buen servicio
a bajos costos.
DEBILIDADES
1 La empresa con tiene presencia ni reputación en el mercado.
2 Si bien cuenta con equipo selecto de profesionales el mismo es reducido
para las distintas demandas de los clientes.
3 Su flujo de de fondos es bajo en comparación con la competencia ya que
son una empresa nueva.
4 El sistema que actual no permite que el cliente acceda directamente a su
información contable, para la toma de decisiones.
5 Para hacer la revisión correspondiente de la información se debe esperar a
que la persona encargada del registro de documentos termine, lo cual
hace ineficiente la revisión del mismo.
6 No existe un mantenimiento del Sistema Actual.
7 La información de los clientes se encuentra dispersa en diferentes lugares.
8 Falta de organización en algunos aspectos de la Información que se
maneja.
9 El sistema actual no permite el crecimiento estratégico de la empresa.
10 Obsolescencia del sistema actual.
OPORTUNIDADES
1 Su sector de negocios está en expansión lo cual trae muchas
oportunidades.
107
2 El gobierno quiere estimular a los productores locales para expandir sus
productos.
3 Mejorar el sistema actual por uno que se encuentre entre las expectativas
de la empresa y sus clientes.
AMENAZAS
1 Los desarrollos futuros en tecnología cambian en el mercado más allá de
la habilidad para adaptarse.
2 Un pequeño cambio en el enfoque de su competidor puede destruir
cualquier posición conseguida en el mercado
3 Son vulnerables de que las empresas que pueden formar parte de la
clientela no se encuentren a gusto con su actual propuesta de servicios y
se vayan con la competencia.
Habiendo caracterizado
2. MARCO LÓGICO
2.1 Identificación del problema
Después de estudiar la situación actual de la empresa con respecto al
funcionamiento del actual sistema, y el manejo de la información se concluye que el
problema principal es:
“La empresa MAERO CONSULTORA MULTIDISCIPLINARIO S.R.L. no cuenta
con Sistema de gestión contable óptimo actual, el cual cumpla con todos las
necesidades de la empresa y sus clientes para la toma de decisiones”.
2.2 Análisis de involucrados
Par realizar el análisis de involucrados se procedió a estudiar la estructura funcional
a nivel del personal que se encarga del servicio de Outsourcing.
108
a) Se lograron identificar 4 categorías de involucrados que participan
activamente en el servicio de Outsorucing Contable.
Socios
Supervisor
Contador Encargado
Cliente
b) Se identifico los intereses, actitudes, motivaciones, limitaciones de cada uno
de los grupos estudiados.
GRUPOS
INTERESES
PROBLEMAS
PERCIBIDOS
RECURSOS
MANDATOS
Socios Brindar un
mejor servicio
de Outsourcing
Contable a sus
clientes.
Centralizar la
información de
los clientes.
Dispersión de la
información contable
de los clientes y la
obsolescencia del
sistema actual.
Desarrollo de un
nuevos sistema
hecho a medida que
se adapte a las
exigencias de la
empresa.
Supervisor Monitorear el
trabajo del
Contador
Encargado.
Para hacer la revisión
correspondiente de la
información se debe
esperar a que la
persona encargada
En el desarrollo de
sistema de debe
tomar en cuenta la
opción de ser
multiusuario.
Elaboración de
informes
contables.
del registro de
documentos termine,
lo cual hace
ineficiente la revisión
del mismo.
Contador
Encargado
Insertar
registros
contable
Para hacer un registro
contable se debe
esperar a que el
supervisor termine de
elaborar sus informes
contables.
En el desarrollo de
sistema de debe
tomar en cuenta la
opción de ser
multiusuario.
Clientes Calidad del
servicio de
Outsourcing.
No disponer de su
información contable
actualizada.
La empresa MAERO
se debe de encargar
de brindar a sus
clientes la
información contable
actualizada.
109
