UNIVERSIDAD MAYOR DE SAN ANDRÉS FACULTAD DE CIENCIAS PURAS Y NATURALES CARRERA DE INFORMATICA
PROYECTO DE GRADO “
SISTEMA DE INFORMACION WEB PARA EL
SEGUIMIENTO Y CONTROL DE ACTIVOS FIJOS: FUNDACION LA PAZ”
PARA OPTAR AL TÍTULO DE LICENCIATURA LICENCIATURA EN INFORMÁTICA MENCION: INGENIERÍA DE SISTEMAS INFORMÁTICOS Postulante :
Enrique Richard Conde Canaviri
Tutor
:
Lic. Roberto Vargas Blacutt
Revisor
:
Lic. Ramiro Flores Rojas LA PAZ – BOLIVIA 2009
DEDICATORIA Dedicado a DIOS por regalarme una vida llena de satisfacciones, felicidad y por estar siempre a mi lado dando fortaleza para seguir adelante en todo momento. A mis padres, Victor Basilio Conde Aruquipa y Maria Canaviri de Conde por todo el amor, la entrega, el apoyo incondicional y la paciencia que tuvieron para conmigo y la formación que me dieron para luchar en la vida. A mis hermanas, Martha y Brenda por su comprensión y constante apoyo en todo momento de nuestras vidas. Y a toda mi familia.
DEDICATORIA Dedicado a DIOS por regalarme una vida llena de satisfacciones, felicidad y por estar siempre a mi lado dando fortaleza para seguir adelante en todo momento. A mis padres, Victor Basilio Conde Aruquipa y Maria Canaviri de Conde por todo el amor, la entrega, el apoyo incondicional y la paciencia que tuvieron para conmigo y la formación que me dieron para luchar en la vida. A mis hermanas, Martha y Brenda por su comprensión y constante apoyo en todo momento de nuestras vidas. Y a toda mi familia.
AGRADECIMIENTOS Deseo expresar mi agradecimiento en primer lugar a Dios por darme la vida, por ser el Padre más tierno, amoroso y comprensivo conmigo y por permitirme concluir esta etapa de mi vida donde termino un ciclo y comienzo otro. A mi docente tutor Lic. Roberto Vargas Blacutt, por darme la confianza necesaria para poder concluir con el presente proyecto de grado, el apoyo y la guía en todo momento. A mi docente revisor revisor Lic. Ramiro Ramiro Flores Flores Rojas, por la la amistad, amistad, colaboración, orientación y sugerencias que me condujeron a la finalización del proyecto de grado. Al encargado de la Unidad de Activos Fijos de la Fundación La Paz, Sr. Jaime Zamudio por su colaboración, confianza y la oportunidad de desarrollar el presente proyecto en dicha institución. A Sonia Tintaya Paredes quien fue la persona que estuvo siempre a mi lado y me acompaño en todo momento m omento y en circunstancias muy difíciles. A todos mis amigos y amigas que en el transcurso de mi vida universitaria tuve a bien compartir con ellos, en especial a Alejandro Chiri Aguirre, Waldo Amaru Estrada, Gladys Vargas y Eddy Churani Coronel.
¡¡¡Muchas Gracias!!!
RESUMEN La Fundación La Paz es una institución privada, sin fines de lucro y de solidaridad que nace en el año 1971 como Fundación San Gabriel, la misma está dedicada a promover y fortalecer movimientos sociales, mediante procesos de organización, participación y prestación de servicios orientados a mejorar las condiciones y calidad de vida de la población. Focaliza su acción en mujeres niños y niñas por su acentuada situación de pobreza, exclusión y discriminación. El presente proyecto de grado titulado: “Sistema de Información Web para el Seguimiento y Control de Activos Fijos: Fundación La Paz”, propone mejorar la administración de los Activos Fijos de la fundación, aprovechando el potencial de comunicación que proporciona Internet. El control que se le da en la Unidad de Activos Fijos no es el apropiado, ya que estos procesos (incorporación del Activo Fijo, asignación, reasignación, depreciaciones, revalorización y baja) se los realiza de forma semi-automatizada. En este proyecto se realizo un análisis previo y con el mismo se realizó el diseño de cada uno de los procesos, utilizando como metodología de desarrollo de software el “Proceso Unificado de Desarrollo de Software (RUP)”, que permite modelar el comportamiento que va a tener el sistema, también se hará uso del “Lenguaje Unificado de Modelado (UML)”, el cual modelará cada uno de los procesos. A partir de
esta situación se procede a desarrollar las aplicaciones del producto final. En la etapa de implementación se hace uso del preprocesador de hipertexto (PHP), que juntamente con Apache y MySQL hacen que la aplicación construida pueda ser accedida desde cualquier computador con ayuda del navegador, sin mucha complicación. De esta manera el personal de la fundación puede acceder al sistema para hacer uso en su totalidad o tan solo para la consulta de los activos fijos asignados, de acuerdo a los privilegios otorgados. Durante la construcción del software se realizaron entrega de prototipos a los usuarios finales, producto de las iteraciones de la metodología utilizada, con ello se obtuvo la funcionalidad del sistema incrementalmente y la facilidad operacional de la misma, satisfaciendo los requerimientos y expectativas de los usuarios.
ÍNDICE CAPÍTULO I
MARCO INTRODUCTORIO
1.1 1.2 1.3 1.4 1.5
Introducción Antecedentes Planteamiento del Problema Justificación Objetivos 1.5.1 Objetivo General 1.5.2 Objetivos Específicos 1.6 Limites y Alcances 1.6.1 Limites 1.6.2 Alcances 1.7 Importancia del Estudio (Aportes) 1.8 Metodología y Herramientas
CAPÍTULO II
1 2 5 6 7 7 7 7 7 8 10 11
MARCO TEÓRICO
2.1 Marco Conceptual 2.1.1 Activos Fijos o Bienes De Uso 2.1.1.1 Clasificación de Los Activos Fijos 2.1.2 Codificación de Activos Fijos 2.1.3 Depreciación de Activos Fijos 2.1.4 Método de Depreciación 2.1.4.1 Método de Línea Recta 2.1.5 Revalorización Técnica de Activos Fijos 2.1.6 Baja de Activos Fijos 2.2 Metodologías para el Desarrollo de Software 2.2.1 Ingeniería de Software Orientada a Objetos
12 12 12 13 14 14 14 15 15 16 16
2.2.1.1 Conceptos y principios Orientados a Objeto 2.2.1.2 Análisis Orientado a Objetos (AOO) 2.2.1.3 Diseño Orientado a Objetos (DOO) 2.2.2 Lenguaje Unificado de Modelado 2.2.2.1 Descripción de los Diagramas 2.2.3 Proceso Unificado de Desarrollo de Software (RUP) 2.2.3.1 Características esenciales del RUP 2.2.3.2 Fases dentro de un Ciclo 2.2.3.3 Flujos de Trabajo Fundamentales 2.2.4 Diseño de la Base de Datos Relacional 2.2.5 Herramientas de Desarrollo de Software 2.2.5.1 Servidor Web Apache 2.2.5.2 MySQL 2.2.5.3 Lenguaje De Programación PHP 2.3 Calidad De Software 2.3.1 Métricas de Calidad Del Software 2.3.2 Factores de Calidad ISO 9126 2.3.3 Funcionalidad 2.3.4 Usabilidad 2.3.5 Facilidad de Mantenimiento 2.3.6 Portabilidad
17 19 20 21 23 30 30 33 35 39 40 40 41 42 43 43 44 45 47 48 49
CAPÍTULO III
MARCO APLICATIVO
3.1 Plan de desarrollo del sistema 3.2 Fase de inicio 3.2.1 Modelado del negocio 3.2.1.1 Identificación de Procesos del Negocio 3.2.1.2 Identificación de Actores del Negocio 3.2.1.3 Definición de Casos de Uso del Negocio 3.2.1.4 Definición del diagrama de casos de uso del Negocio 3.2.1.5 Diagrama de actividades 3.2.1.6 Modelo de objetos 3.2.2 Modelado de requisitos 3.2.2.1 Requisitos funcionales 3.2.2.2 Requisitos no funcionales 3.2.2.3 Modelo conceptual 3.3 Fase de Elaboración 3.3.1 Modelo de casos de uso 3.3.1.1 Actores del Sistema 3.3.1.2 Definición de los casos de uso Esenciales 3.3.1.3 Definición del diagrama de Casos de Uso Esencial 3.3.1.4 Descripción de los Casos de Uso Esenciales 3.3.2 Modelo de Diseño 3.3.2.1 Definición de Diagramas de Secuencia 3.3.2.2 Definición del Diagrama de Estados 3.3.2.3 Definición de Diagramas de Colaboración 3.3.2.4 Definición del Diagrama de Clases 3.3.2.5 Transformación del Modelo OO al Modelo E-R 3.3.3 Modelo de Despliegue del Sistema 3.3.3.1 Definición del Diagrama de Componentes 3.3.3.2 Definición del Diagrama de Despliegue 3.4 Fase de Construcción 3.4.1 Implementación de Interfaces 3.5 Fase de Transición
50 53 53 53 53 54 55 56 60 62 62 62 63 64 64 64 64 65 66 73 73 75 76 79 80 81 81 82 82 83 84
CAPÍTULO IV
CALIDAD Y PRUEBAS
4.1 Calidad de Software 4.1.1 Introducción 4.1.2 Funcionalidad 4.1.3 Facilidad de Mantenimiento 4.1.4 Portabilidad 4.1.5 Usabilidad 4.2 Pruebas 4.2.1 Casos de Prueba 4.2.2 Pruebas de Caja Blanca 4.2.3 Pruebas de Caja Negra
CAPÍTULO V
CONCLUSIONES Y RECOMENDACIONES
5.1 Conclusiones 5.2 Recomendaciones
BIBLIOGRAFIA ANEXOS
88 88 88 91 91 92 94 94 95 99
100 101
INDICE DE FIGURAS Figura 2.1 Figura 2.2 Figura 2.3 Figura 2.4 Figura 2.5 Figura 2.6 Figura 2.7 Figura 2.8 Figura 2.9 Figura 2.10 Figura 2.11 Figura 2.12 Figura 2.13 Figura 2.14 Figura 2.15 Figura 2.16 Figura 2.17 Figura 2.18 Figura 2.19 Figura 3.1 Figura 3.2 Figura 3.2 Figura 3.3 Figura 3.3 Figura 3.4 Figura 3.5 Figura 3.6 Figura 3.7 Figura 3.8 Figura 3.9 Figura 3.10 Figura 3.11
Clasificación y Representación en la Posición Financiera Codificación de Activo Fijo existente Codificación de Activo Fijo del sistema Representación Gráfica de una Clase Orientada a Objetos Jerarquía de Clases Evolución de UML Diagramas, partes de un modelo Diagrama de casos de uso Diagrama de clases Estereotipos de clases estándar de UML Diagrama de Estados Diagrama de Actividades Diagrama de Secuencia Diagrama de Colaboración Diagrama de Componentes Diagrama de Despliegue Proceso de desarrollo de software Descripción del Proceso Unificado Modelado del diagrama E-R a partir de un diagrama de clases Modelos de Casos de Uso del Negocio Diagrama de Actividades Recepcionar pedido de Activo Fijo Diagrama de Actividades Comprar Activo Fijo Diagrama de Actividades Asignar Activo Fijo Diagrama de Actividades Revaluó de Activo Fijo Diagrama de Actividades Baja de Activo Fijo Diagrama de Actividades Reasignación de Activo Fijo Modelo de Objeto del Caso de Uso Recepcionar Pedido de AF Modelo de Objeto del Caso de Uso Comprar Activo Fijo Modelo de Objeto del Caso de Uso Asignar Activo Fijo Modelo de Objeto del Caso de Uso Revaluó de Activo Fijo Modelo de Objeto del Caso de Uso Baja de Activo Fijo Modelo de Objeto del Caso de Uso Reasignación de Activo Fijo
12 13 13 17 19 22 24 24 25 26 26 27 28 28 29 29 30 33 40 56 57 57 58 58 59 59 60 60 61 61 61 61
Figura 3.12 Figura 3.13 Figura 3.14 Figura 3.15 Figura 3.16 Figura 3.17 Figura 3.18 Figura 3.19 Figura 3.20 Figura 3.21 Figura 3.22 Figura 3.23 Figura 3.24 Figura 3.25 Figura 3.26 Figura 3.27 Figura 3.28 Figura 3.29 Figura 3.30 Figura 3.31 Figura 4.1 Figura 4.2 Figura 4.3 Figura 4.4 Figura 4.5
Modelo Conceptual asociado al Control y Seguimiento de AF Diagrama de Casos de Uso del Sistema SISCAFW Diagrama de Secuencia Registrar Activo Fijo Diagrama de Secuencia Cálculo de Actualización y Depreciación Diagrama de Secuencia Baja de Activo Fijo Diagrama de Secuencia Registrar Tipo de Cambio Diagrama de Secuencia Revaluó Activo Fijo Diagrama de Estados del Sistema SISCAFW Diagrama de Colaboración Registrar Activo Fijo Diagrama de Colaboración Cálculo de Actualización y Depreciación Diagrama de Colaboración Baja de Activo Fijo Diagrama de Colaboración Registro de Tipo de Cambio Diagrama de Colaboración Revaluó de Activo Fijo Diagrama de Clases Diagrama Entidad Relación Diagrama de Componentes del sistema SISCAFW Diagrama de Despliegue del sistema SISCAFW Interface de Ingreso al Sistema. Interface del Menú Principal de Encargado de la Unidad de AF Interface de Registro de Activo Fijo Caso de Prueba Registrar Activo Fijo Caso de Prueba Registrar Activo Fijo Diagrama de Flujo Registro de Activos Fijos. Grafo de Flujo Registro de Activos Fijos Grafo de Flujo Simplificado de Activos Fijos
63 66 73 73 74 74 74 75 76 77 77 78 78 79 80 81 82 83 83 84 94 95 96 97 97
INDICE DE TABLAS Tabla 1.1 Tabla 2.1 Tabla 2.2 Tabla 3.1 Tabla 3.2 Tabla 3.3 Tabla 3.4 Tabla 3.5 Tabla 3.6 Tabla 3.7 Tabla 3.8 Tabla 3.9 Tabla 3.10 Tabla 4.1 Tabla 4.2 Tabla 4.3 Tabla 4.4 Tabla 4.5 Tabla 4.6
Proyectos Similares Calculo de puntos de función. Preguntas para hallar el valor de ajuste Tiempos estimados en las fases de RUP Fases e Hitos del desarrollo de software Artefactos de las distintas disciplinas que comprende RUP Definición de Requisitos Funcionales del Sistema Descripción Caso de Uso Registrar Activo Fijo Descripción Caso de Uso Registrar Tipo de Cambio Descripción Caso de Uso Actualizar y Depreciar Activo Fijo Descripción Caso de Uso Revaluó Activo Fijo Descripción Caso de Uso Baja de Activo Fijo Descripción Caso de Uso Generar Reportes Cuenta total de entradas y salidas Parámetros de Medición Valores de ajuste de la complejidad Ajuste de complejidad del punto función Descripción de la escala de evaluación Ajuste de Preguntas
4 45 47 51 51 52 62 67 68 69 70 71 72 88 88 89 89 92 92
CAPITULO I MARCO INTRODUCTORIO
CAPÍTULO I MARCO INTRODUCTORIO 1.1 INTRODUCCIÓN El software, es una herramienta muy importante, pues es un transformador de información; produce, gestiona, adquiere, modifica y muestra la información que así se requiera. En consecuencia las instituciones deben hacer uso de los recursos tecnológicos existentes para no quedarse relegadas en sus actividades. Por ello deben obtener de la tecnología informática el mayor beneficio y con ello lograr proyectarse al futuro. Ejemplo claro la red internet y los sistemas basados en Web1 de las cuales mayor número de instituciones (públicas y privadas) puedan disponer, teniendo una gran variedad de contenido y funcionalidad, por lo cual precisan contar con el activo más importante como es la información y todas las características que esta debe tener para una buena toma de decisiones, como ser precisa, oportuna y fiable. La utilización de un navegador2, permite visualizar la información que contiene una página web. Toda institución para llevar a cabo sus actividades, requiere de la utilización de ciertos bienes denominados activos. A los activos que se utilizan en el desarrollo de sus actividades administrativas, con la finalidad de que cumplan una función, se les denomina “Activos Fijos”. Es de resaltar que una de las principales
características de esos activos, es la de ser permanentes en la institución, hasta que dichos bienes dejen de ser útiles por el paso del tiempo y debido a la depreciación3. La “Fundación La Paz” es una institución privada, sin fines de lucro y de
solidaridad de fomento y promoción de la participación de la población, la misma que cuenta con subprogramas ubicados en distintos sectores de la ciudad de La 1
Web: son sistemas que utilizan la Internet para su ejecución. Navegador: aplicación en donde se pueden visualizar páginas web. 3 Depreciación: Es la pérdida del valor que sufre un bien de uso a través del tiempo por el servicio que presta, por inclemencias climatológicas u obsolescencia. 2
Paz, es responsable del área de Promoción de la Mujer y el área Socioeducativa, es en esta última es en la que la Unidad de Activos Fijos se encarga de administrar las actividades y procedimientos relativos al ingreso, asignación, registro, salvaguarda, mantenimiento, depreciación y control de los Activos Fijos. Esta administración se la realiza de manera semi-automatizada, es decir se tiene registros de los activos fijos en hojas electrónicas, lo que ocasiona retraso en la emisión de informes y no existe una administración adecuada en la gestión de los activos fijos. El Sistema de Información Web, que se ha desarrollado tiene como objetivo principal el seguimiento y control de los activos fijos del Área Socio Educativa de la Fundación La Paz, lo cual contempla: la incorporación, asignación, revaluó, baja, reasignación, depreciación y actualización de activos fijos. En el capítulo I, se describe los antecedentes y la problemática actual que atraviesa el Área Socio Educativa de la Fundación La Paz, asimismo se especifica tanto el problema principal y los objetivos trazados en la elaboración del presente proyecto, descripción del alcance y los límites que se tendrá. En el capítulo II, se especifica las herramientas y conceptos que se utilizan para el desarrollo de la implementación del proyecto. En el capítulo III, se orienta al análisis y diseño del sistema, considerando los requerimientos definidos por la Institución. En el capítulo IV, se describen las pruebas realizadas y se aplica métricas de calidad al sistema. Finalmente en el capítulo V, se detallan las conclusiones y recomendaciones del proyecto.
1.2 ANTECEDENTES La “ Fundación La Paz” es una institución privada, sin fines de lucro y de
solidaridad que nace en el año 1971 como Fundación San Gabriel, con programas
de carácter asistencial, cambiando su enfoque progresivamente hacia la consolidación de una institución de fomento y promoción de la participación de la población. La Fundación La Paz, cuya misión, está dedicada a promover y fortalecer movimientos sociales, mediante procesos de organización, participación y prestación de servicios orientados a mejorar las condiciones y calidad de vida de la población. Focaliza su acción en mujeres niños y niñas por su acentuada situación de pobreza, exclusión y discriminación. La estructura orgánica de la Fundación se detalla en el Anexo A. La Unidad de Activos Fijos, es la que administra la información sobre los activos que se utilizan en el desarrollo de las actividades administrativas dentro de cada uno de los subprogramas correspondientes a cada unidad del Área Socio Educativa. Los procesos que realiza son: Recepción de Activos Fijos. Asignación de los Activos Fijos. Codificación y Clasificación de los Activos Fijos. Registro e Incorporación de Activos Fijos. Reasignación de Activos Fijos. Baja de los Activos Fijos. Depreciación y Actualización de Activos Fijos. Revaluó de los Activos Fijos.
La codificación de cada activo fijo se realiza de acuerdo a la unidad, programa, subprograma, rubro, sub rubro y el correspondiente número correlativo al que pertenece, una vez realizada la donación o adquisición del mismo. Está codificación la realiza el encargado de la Unidad de Activos Fijos, el cual hace uso
de una etiqueta para identificar al activo fijo al momento de su incorporación en un subprograma. La forma en la que se lleva actualmente la gestión y control de activos fijos es semi-automatizada e inadecuada, puesto que solo cuenta con un registro de activos fijos en una planilla electrónica (Excel), el mismo que responde a limitadas tareas para la obtención de información y la cual es susceptible a tener errores debido al excesivo volumen de información. Los proyectos similares se detallan en la tabla 1.1 Tabla 1.1: Proyectos Similares Sistema
Descripción
“Sistema de Control de Activos Fijos”,[Quispe Patana Johnny, 2006]
“Control y Seguimiento de Activos Fijos”,[Canchillo Sanga Mario,
2006]
Sistema de Información de Activos “Fijos y Almacenes”,[Silva Choque
Martha, 2003]
Proyecto de Grado que administra y controla los activos fijos de la Honorable Alcaldía Municipal de Jesús de Machaca. Proyecto de grado para controlar el registro, asignación, depreciación, bajas y revalorización de los activos fijos de las misiones del servicio exterior del Ministerio de Relaciones Exteriores y Cultos. Se plantea el desarrollo de un sistema de información moderno que proporcione a los encargados de la administración de activos fijos información adecuada en el momento preciso.
Fuente: Elaboración Propia.
1.3 PLANTEAMIENTO DEL PROBLEMA Durante el proceso de recopilación de información juntamente con la colaboración del Área Socioeducativa se realizo un estudio general de los problemas existentes y los nuevos requerimientos que surgieron a consecuencia de esta investigación. Se ha llegado a establecer que no se cuenta con un sistema automatizado que permita clasificar los bienes utilizados para el desarrollo de las actividades administrativas (activos fijos). Después de analizar los síntomas, causas y diagnosticar el problema, se ha podido identificar, deficiencias en el actual manejo y disposición de activos fijos y otros problemas asociados: Inadecuado manejo de la información, debido a que esta se encuentra registrada en una hoja electrónica, la misma que no cuenta con la debida seguridad. Dificultad en el procedimiento para obtener información del registro de los responsables de los Activos Fijos, por el excesivo volumen de información. La Unidad de Activos Fijos no cuenta con información adecuada concerniente a: los bienes de uso de un determinado subprograma y de los financiadores. No se cuenta con un historial de los Activos Fijos durante sus años de vida útil. Ausencia de información en tiempo real y oportuna de la actualización – depreciación y revaluó técnico de los Activos fijos. Inadecuada asignación del código para un determinado Activo Fijo. Dificultad en el procedimiento para obtener información de los Activos Fijos, debido a que la misma está centralizada y no se encuentra disponible en todo momento para los coordinadores y/o funcionarios de programa y subprograma respectivamente.
Información incompleta en el registro del Activo Fijo en el momento de su incorporación. Demora en la obtención de reportes. No existe el registro de los activos fijos dados de baja. Comunicación inadecuada de los diferentes subprogramas hacia la Unidad de Activos Fijos, respecto de la solicitud, incorporación y baja de Activos Fijos. En consecuencia la formulación del problema es la siguiente: ¿El Sistema de Información Web para el Control y Seguimiento de Activos Fijos: Fundación La Paz, permitirá la administración de manera eficiente y eficaz de los Activos Fijos?
1.4 JUSTIFICACIÓN La Fundación La Paz dispone de recursos computacionales, servidor de páginas y conexión a internet, disponible este último en los subprogramas. Estos recursos no son utilizados adecuadamente en consideración al seguimiento y control de activos fijos, porque las actividades y tareas que realizan al respecto son semi automatizadas. Por tanto existen las condiciones tecnológicas para poder desarrollar el nuevo proyecto, así los recursos computacionales de la Fundación tendrán un adecuado uso para la administración de los activos fijos. Con el desarrollo de este proyecto, el encargado de la Unidad de Activos Fijos, coordinador de programa y el personal de la fundación podrán realizar una mejor administración de los activos fijos del Área Socioeducativa.
1.5 OBJETIVOS 1.5.1 Objetivo General Desarrollar e implementar el sistema de información web para el seguimiento y control de activos fijos del Área Socioeducativa perteneciente a la Fundación La Paz, para tener un eficiente seguimiento y control de los bienes de uso.
1.5.2 Objetivos Específicos Controlar y validar el ingreso de usuarios autorizados. Realizar un control adecuado de los registros de incorporación, asignación, reasignación, actualización-depreciación, revaluó, baja de los Activos Fijos. Elaborar una base de datos para el registro, actualización, eliminación y consulta de la información concerniente a la gestión de Activos Fijos. Realizar el cálculo de la actualización y depreciación de los Activos Fijos. Elaborar el revaluó técnico de los Activos Fijos. Generar de manera automática el código del Activo Fijo a ser incorporado, de acuerdo a ciertas características, como ser: la ubicación del bien, al rubro y sub rubro al cual pertenece. Mejorar la rapidez y confiabilidad al momento de obtener reportes. Diseñar y desarrollar las interfaces que faciliten la operabilidad del sistema.
1.6 LIMITES Y ALCANCES 1.6.1 Limites El presente trabajo proporciona.
Información referente al seguimiento y control de los Bienes de Uso Tangibles y no así los intangibles. Información referente a los Activos Fijo del área Socioeducativa, es decir se obtendrá información de las unidades, programas y subprogramas correspondientes a esta área. Es restringido a cinco tipos de usuarios, Encargado de la Unidad de Activos Fijos, Administrador del Sistema, Director de Área Socioeducativa, Coordinador de Programa y funcionario de Sub Programa. Los usuarios no implicados solo podrán acceder a la página inicial de presentación de la fundación.
1.6.2 Alcances El presente proyecto, sistema de información web para el control y seguimiento de activos fijos de la Fundación La Paz, contempla los siguientes módulos:
Módulo de Administración: Este modulo constara de los siguientes submódulos Institución, se realizara la administración de la información concerniente a: Área. Unidad. Programa. Subprograma. Persona Responsable del Activo Fijo. Usuario. Clasificador Rubro: Se registra en este modulo los grupos contables de acuerdo al anexo del artículo 22 del decreto supremo 24051(reglamento del impuesto a las Utilidades), y los correspondientes sub rubros.
Organismo financiador: Se registra que tipo de organización sea extranjera o nacional financia la adquisición del Activo Fijo. Cambio de moneda (tipo de cambio): En este modulo se registra el tipo de cambio de moneda en Dólares Estadounidenses.
Módulo de Procesos: Este modulo constara de los siguientes sub-módulos Control del movimiento físico: Incorporación de nuevos Activos Fijos (AF): Se registran las nuevas adquisiciones codificados y clasificados por el rubro que corresponde. Asignación de AF: Se realiza el registro de la asignación al responsable del AF. Reasignación de AF. Baja de AF. Control del movimiento económico: Revaluó Técnico de AF. Actualización y depreciación de AF.
Modulo de Consultas y Reportes: Este módulo constara de los siguientes sub módulos Listado de AF por rubros. Listado de AF por sub rubros. Listado de AF por sub programas. Listado de la Asignación de AF, por responsable o por rubro o por subprograma.
Cantidad de AF por programa. Depreciación y actualización de AF. Listado de AF dados de baja. Revaluó técnico de AF.
Modulo de Herramientas: Este módulo contará con los siguientes sub-módulos Cambio de contraseña o password, para los usuarios del sistema. Ventanas para, notificaciones de incorporación, solicitud, baja de activos, para la respectiva actualización y depreciación de los activos fijos. También para el registro del tipo de cambio diario. Creación de respaldos de información de la base de datos del sistema de información web. Con este sistema de información vía web, se lograra disminuir la demora en los diferentes procesos de obtención de información y brindar información actualizada de la depreciación, bajas, reevaluó, ubicación física, asignación a responsables, y consecuentemente éste desempeña un papel importante en el proceso de evolución del Área Socioeducativa de la Fundación La Paz en cuanto al mejoramiento de su trabajo para el beneficio de la institución. También él sistema solucionara problemas de comunicación y falta de coordinación entre los subprogramas involucrados del Área Socioeducativa. Se tendrá informes de acuerdo a los requerimientos del usuario, el acceso a la información de los Activos Fijos será más completo.
1.7 IMPORTANCIA DEL ESTUDIO (APORTES) El sistema que se implementara tendrá las características necesarias para proveer información de todo lo concerniente a la administración de Activos Fijos, consecuentemente desempeña un papel importante en el proceso de evolución
del Área Socioeducativa de la Fundación La Paz, en cuanto al mejoramiento de su trabajo para beneficio de la institución misma y nuestro país. En consideración a la información necesaria acerca de los activos fijos se tomara en cuenta que estos no solo se componen de un solo elemento sino de varios; en el instante del registro del activo fijo, como un ejemplo especifico, un equipo de computación el cual por poseer más de un componente no solo requiere de un rubro llamado “Equipo de Computación”, sino también de sub rubros como ser: Microprocesador,
Memoria, disco duro, entre otros. Ya que si el equipo de computación requiere cambiar algún componente o simplemente mejorarlo o darlo de baja, este tenga una mejor administración del mismo con respecto al seguimiento y control de este Activo Fijo.
1.8 METODOLOGÍA Y HERRAMIENTAS Para el desarrollo del proyecto se usa una metodología orientada a objetos, específicamente la metodología RUP (Rational Unified Process) por ser un proceso de desarrollo de software configurable que se adapta a los proyectos de variado tamaño y complejidad, y por ajustarse a los requerimientos de este proyecto. Para el modelado del análisis y diseño del sistema se realizara con UML (Unified Modeling Language), ya que permite modelar, construir y documentar los elementos que forman parte del sistema. En la etapa de desarrollo se utilizara las siguientes herramientas: Plataforma del sistema operativo Windows o Linux. Como lenguajes de programación sea hará uso de JavaSript para el desarrollo de interfaces de usuario mejoradas y páginas web dinámicas, además de hacer uso de PHP el mismo que está diseñado especialmente para desarrollo web y puede ser incrustado dentro de código HTML. Como sistema gestor de Base de Datos se utilizara MySQL.
CAPITULO II MARCO TEORICO
CAPÍTULO II MARCO TEÓRICO 2.1 MARCO CONCEPTUAL 2.1.1 Activos Fijos o Bienes de Uso Son aquellos bienes tangibles que se utilizan en la actividad de la empresa, que tengan una vida útil y que no estén destinados a la venta, tales como: Terrenos, edificios, muebles y enseres, vehículos, maquinaria y equipo, herramientas y equipos de computación. Los bienes de uso (activos fijos) a diferencia de los activos corrientes, no entran en la rotación comercial o industrial del negocio por su naturaleza constituyen inversiones de carácter permanente que se encuentran al servicio de la empresa.
2.1.1.1 Clasificación de los Activos Fijos Los activos fijos en forma general se clasifican en dos grandes grupos: Figura 2.1: Clasificación y Representación en la Posición Financiera No Sujetos a Depreciación
Terrenos
Sujetos a Depreciación
Edificios Muebles y Enseres Maquinaria y Equipo Vehículos Equipo de Computación etc.
Recurso Naturales Sujetos a Agotamiento
No Renovables
Pozos Petrolíferos Fondos Mineros Canteras, etc.
Renovables
Bosques madereros Agricultura Arboricultura
TANGIBLES
Sujetos a Amortización
Patentes Derechos de Autor Concesiones Mejoras en arrendamiento, etc.
No Sujetos a Amortización
Marcas de Fabrica Crédito Mercantil
INTANGIBLES
Fuente: [FUNES, 2003]
2.1.2 Codificación de Activos Fijos Para realizar el control adecuado de los activos fijos se hace necesario usar una codificación particular, que es la siguiente: Nombre de la institución, Área, Unidad, Programa, Sub programa, Rubro y un número correlativo. Esta codificación permite ver e identificar la ubicación, el destino del bien, discriminando claramente un bien del otro, facilitando el recuento físico f ísico periódico. Por ejemplo, un mueble que pertenece al programa “Wawauta” correspondiente al sub programa “Valle Pacasa” su codificación será:
Figura 2.2: Codificación de Activo Fijo existente UNIDAD DE ATENCION AREA SOCIO EDUCATIVA INSTITUCION FUNDACION LA PAZ
FLP-ASE-UA-WAW-VP-MU-0001 PROGRAMA WAWAUTA SUBPROGRAMA: VALLE PACASA RUBRO: MUEBLES Y EQUIPO DE OFICINA NÚMERO CORRELATIVO
Fuente: [FLP, 2006] Una vez que se le asigna el código anteriormente descrito, el paso siguiente es colocar o pegar un sticker sobre el activo fijo, esta operación es realizada por el encargado de Unidad de Activos Fijos de la fundación. En consideración a los requerimientos obtenidos, los mismos que se detallan en el capítulo III, la nueva codificación del activo fijo se detalla a continuación: Figura 2.3: Codificación de Activo Fijo del sistema UNIDAD AREA SOCIO EDUCATIVA INSTITUCION FUNDACION LA PAZ
FLP-ASE-UU-WW-XX-YY-ZZ-0001 PROGRAMA SUBPROGRAMA RUBRO SUB RUBRO NÚMERO CORRELATIVO
Fuente: Elaboración Propia
2.1.3 Depreciación de Activos Fijos (Bienes de Uso) Es la pérdida de valor que sufre el bien de uso a través del tiempo por el servicio que presta, su manipulación y otros. La depreciación se estima por su vida útil y su valor residual, se entiende por vida útil el lapso de vida que tiene un activo en años. El importe de la depreciación no debe deducirse directamente del costo del activo, si no debe acreditarse a una cuenta complementaria como: “depreciación acumulada”, por dos razones que se indican a continuación:
La depreciación contribuye una perdida estimada del valor de un bien de uso (activo fijo) tangible y su importe no es exacto, si no aproximado. Es el costo del activo menos la depreciación acumulada, de esta manera el valor que refleja el Balance General o Posición Financiera es el valor neto del activo a una determinada fecha.
2.1.4 Método de Depreciación (Línea Recta) En el presente proyecto para la depreciación de activos fijos utilizó el método de depreciación de línea recta. recta.
2.1.4.1 Método de línea recta La depreciación en línea recta supone que el bien de uso se desgasta por igual durante cada periodo. Este método se usa con frecuencia por ser sencillo y fácil de calcular. Este método se basa conforme a la disposición contenida en el primer párrafo del Artículo 22° del Decreto Supremo 24051, ver Anexo B. B. Entonces se tiene la siguiente ecuación:
Donde: Fa = Fa = Factor de actualización. tc i i = Tipo de cambio inicial tc f f = Tipo de cambio final. Va = Valor actualizado. D = D = Depreciación. AVU= Años de Vida Útil.
2.1.5 Revalorización Técnica de Activos Fijos Es un procedimiento reconocido contablemente, a través del cual los peritos independientes asignan nuevos valores o determinan justiprecios a estos mas los correspondientes años de vida útil residual en función al estado de conservación. Los activos fijos de la revalorización técnica de activos fijos son: Asignar nuevos valores a los bienes. Asignar años de vida útil residual. Cumplir con disposiciones legales y normas contables.
2.1.6 Baja de Activos Fijos Se denomina baja de bienes de uso o retiro de estos por encontrarse en condiciones no aptas para prestar servicio útil a una empresa. Se puede originar tal situación, por inclemencias climatológicas, por siniestros, por hurto, por robo, por obsolescencia o por haber cumplido con su vida útil. Además, se deberá seguir el siguiente procedimiento:
Cumplir con lo estipulado en el Artículo 23 del Decreto Supremo No. 24051. Actualizar valores hasta la fecha cuando se realiza la baja. Efectuar cálculos de la depreciación y su registro hasta la fecha cuando se realiza la baja, tomando en cuenta si es revaluado o no. Determinar el valor residual para efectuar cuenta de gasto cuando no se recupere o caso contrario cuenta de activo (por cobrar) si existe la posibilidad de recuperación. Preceder a la preparación de registro contable. Para ver las características de la administración de Activos Fijos, las mismas se encuentran descritas en el Decreto Supremo No. 29190, dirigirse al Anexo C.
2.2 METODOLOGIAS PARA EL DESARROLLO DE SOFTWARE 2.2.1 Ingeniería de Software Orientada a Objetos La ingeniería de software orientada a objetos (ISOO) tiene como principal protagonista al objeto, pero, una forma de describirlo en términos sencillos seria: “El mundo en el cual vivimos está rodeado de objetos. Estos objetos están presentes en la naturaleza, en las entidades hechas por el hombre, en los negocios y en los productos que usamos” [PRESS , 2005]. Una de las virtudes de estos objetos es que pueden ser clasificados, descritos, organizados, manipulados y creados. De ahí es que nace la Visión Orientada a Objetos para el desarrollo de sistemas informáticos basados en objetos, utilizando para ello una abstracción del entorno mismo. Este paradigma tubo como inicios los finales de los años 60’s en los que se
escucho por primera vez. Pero tuvieron que pasar 20 años para que en la década de los 90’s llegue a ser ampliamente difundida y usada en el entorno. Cabe
mencionar que la aparición de nuevas herramientas de desarrollo ayudo a este propósito, como por ejemplo: C++, Eiffel, SmalTalk, C#, Java y en los últimos años a PHP.
2.2.1.1 Conceptos y Principios Orientados a Objetos Para una mejor comprensión de la ingeniería orientada a objetos se presenta los siguientes conceptos y principios básicos: Clases y Objetos, un modelo de software orientado a objetos debe mostrar abstracciones y procedimientos que conducen a una modularidad eficaz. Una clase es un concepto Orientado a Objetos (O.O.) que encapsula las abstracciones de los datos y procedimientos que requieren para describir el contenido y comportamiento de alguna entidad del mundo real. Figura 2.4: Representación Gráfica de una Clase Orientada a Objetos.
Fuente: [JACOB, 2000] Una clase está formada de atributos y operaciones. Los atributos son descripciones de los datos que definen a la clase, mientras que las operaciones son abstracciones procedimentales capaces de manipular los atributos. La única forma de alcanzar a los atributos es a través de las operaciones definidas en la clase, por tanto, la clase encapsula los atributos. Entonces una clase es una descripción generalizada que describe a una colección de objetos similares. Por definición todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulación de los datos. Atributo, es una propiedad o característica que está asociado a una clase u objeto con un nombre y que describen a la clase u objeto de alguna manera. Un atributo puede tomar un valor por defecto definido por un
dominio, por ejemplo en el caso de un objeto de tipo físico los atributos posibles serian: forma, peso, color, tipo de material, etc. Los posibles valores por defecto para el atributo peso llegarían a ser: 1 Kg o 200 grs, esto según se defina en la necesidad del objeto. Operaciones, que también son llamados métodos o servicios, no son más que algoritmos específicos capaces de manipular los datos representados como una colección de atributos. Una operación tiene un nombre específico y parámetros que son definidos. Las operaciones representan el comportamiento de los objetos y son invocadas a través de mensajes. Mensajes, son el media mediante el cual los objetos interactúan entre sí. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor, este comportamiento se ejecuta al realizarse una operación. Encapsulamiento, una de las características de las clases y objetos es que encapsulan los atributos y operaciones definidas, llegando a actuar como una caja negra cuya estructura interna permanece oculta, tanto para el usuario como para así también para otras clases, llegándose a obtener los siguientes beneficios: o
o
o
Los detalles de la implementación de los datos y algoritmos están ocultos para el mundo exterior, lo cual reduce los efectos colaterales al efectuarse los cambios. La estructura de los datos y las operaciones que las manipulan están unidas en una sola entidad llamada clase. Esto facilita la reutilización de componentes. Las interfaces entre objetos están simplificadas, un objeto que envía un mensaje no tiene que preocuparse por los detalles de la estructura de los datos internos del objeto receptor.
Polimorfismo, es una característica que reduce en gran medida el esfuerzo para extender un sistema y consiste en operaciones o métodos con un
mismo nombre que actúan de manera distinta, generalmente la única diferencia entre ellos es el paso de parámetros o argumentos. Herencia, es una de las diferencias entre los sistemas convencionales y los sistemas orientados a objetos. No es más que la especialización de una clase a partir de otra definida de forma general, esto quiere decir que una Clase X (hija) con atributos y operaciones propios puede heredar los atributos y operaciones de una Clase Y (padre) y cualquier cambio que ocurra en esta ultima llegara a afectar a la clase hija. Figura 2.5: Jerarquía de Clases.
Fuente: [PRESS, 2005] 2.2.1.2 Análisis Orientado a Objetos (AOO) Se puede definir al AOO como el proceso que se utiliza para modelar el dominio del problema identificando y especificando un conjunto de objetos semánticos que interactúan y se comportan de acuerdo a los requisitos del sistema. El AOO se fundamenta en un conjunto de cinco principios básicos: Modelar el dominio de la información. Describir la función del modulo. Representar el comportamiento del modelo. Dividir el modelo para mostrar más detalles.
Observar que los modelos iníciales representan la esencia del problema mientras que los últimos aportan detalles de la implementación. El propósito del AOO es definir todas las clases, además de las relaciones y comportamientos asociados a ellas, que son relevantes al problema a ser resuelto. Para cumplirlo se deben ejecutar las siguientes tareas: Los requisitos básicos del usuario deben comunicarse entre el cliente y el ingeniero del software. Identificar las clases, definiendo los atributos y los métodos. Especificar una jerarquía de clases. Representar las relaciones, conexiones, objeto a objeto. Modelar el comportamiento del objeto. Repetir iterativamente las tareas 1 a la 5 hasta completar el modelo.
2.2.1.3 Diseño Orientado a Objetos (DOO) El diseño orientado a objetos (DOO) transforma el producto obtenido en la anterior etapa o sea el modelo de análisis en un modelo de diseño que sirve como un anteproyecto para la construcción de software. A diferencia de los métodos convencionales de diseño del software, el DOO constituye un tipo de diseño que logra un cierto número de diferentes niveles de modularidad. Los componentes principales del sistema están organizados en módulos denominados subsistemas. El DOO debe describir la organización de datos específicos, de atributos y los detalles procedimentales de las operaciones individuales. Esta representación fragmentada de datos y algoritmos de un sistema orientado a objetos colaboran a una modularidad general. La naturaleza única del DOO descansa en su capacidad para apoyarse en cuatro conceptos importantes del diseño clásico del software:
Abstracción , consiste en ignorar aquellos aspectos del problema en
estudio que no son relevantes para centrarse en aquellos que sí son importantes Ocultación de la información , este concepto está íntimamente asociado al
encapsulamiento en donde los datos y las operaciones se unen en un paquete. Independencia funcional , en cual se busca de los módulos u operaciones
sean capaces de realizar o especializarse en una tarea en particular Modularidad , esto concepto permite la reutilización y facilita la verificación
y depuración de los mismos. Los objetos son módulos naturales ya que corresponden a una representación lógica de la realidad. Para los sistemas orientados a objetos es posible definir un diseño en pirámide con las siguientes cuatro capas: Subsistema . Contiene una representación de cada uno de los subsistemas
que le permiten al software conseguir los requisitos definidos por el cliente e implementar la infraestructura técnica que los soporta. Clases y objetos . Contiene las jerarquías de clases que permiten crear el
sistema utilizando generalizaciones y especializaciones mejor definidas incrementalmente. También contiene representaciones de diseño para cada objeto. Mensajes . Contiene los detalles que permiten a cada objeto comunicarse
con sus colaboradores. Establece las interfaces externas e internas para el sistema. Responsabilidades . Contiene las estructuras de datos y el diseño
algorítmico para todos los atributos y operaciones de cada objeto.
2.2.2 Lenguaje Unificado de Modelado El Lenguaje Unificado de Modelado comúnmente conocido como UML, es un lenguaje de modelado visual que se usa para especificar, construir, visualizar y
documentar los artefactos de un sistema de software orientado a objetos (OO). Se usa para entender, diseñar, configurar, mantener y controlar la información sobre tales sistemas. Está pensado para usarse con todos los métodos de desarrollo, etapas de ciclo de vida, dominios de aplicación y medios. El Lenguaje Unificado de Modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas actuales en un acercamiento estándar. Figura 2.6: Evolución de UML.
Fuente: [BOOCH, 1999] UML fue desarrollado en un esfuerzo para simplificar y consolidar el gran número de métodos de desarrollo orientado a objetos que hasta ese momento había ya surgido. Es así que partir del año 1994, Grady Booch y Jim Rumbaugh creador de OMT se unen en una empresa común, Rational Software Corporation, y comienzan a unificar sus dos métodos. Un año más tarde, en octubre de 1995, aparece 0.8, la que se considera como la primera versión del UML. A finales de ese mismo año, Ivan Jacobson, creador de la Ingeniería de Software Orientado a Objetos -OOSE (Object Oriented Software Engineer) se añade al grupo.
UML se quiere convertir en un lenguaje estándar con el que es posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo. Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las perspectivas entre diferentes tipos de sistemas no sólo software, sino también en el ámbito de los negocios, al aclarar las fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos de la metodología OO.
2.2.2.1 Descripción de los diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. Un diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés. Es aquí donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software . El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos. Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de enlaces entre los diferentes modelos.
Varios modelos aportan diferentes vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes. Así, UML recomienda la utilización de nueve diagramas, para representar las distintas vistas de un sistema. Estos diagramas de UML se presentan en la figura 2.6 y se describen a continuación: Figura 2.7: Diagramas, partes de un modelo
Fuente: [RUEDA, 2006] Diagrama de Casos de Uso : modela la funcionalidad del sistema
agrupándola en descripciones de acciones ejecutadas por un sistema para obtener un resultado, también muestra un conjunto de casos de uso, actores y sus relaciones. Figura 2.8: Diagrama de casos de uso
Fuente: [BOOCH, 1999]
Diagrama de Clases : muestra las clases (descripciones de objetos que
comparten características comunes) que componen el sistema y cómo se relacionan entre sí. Figura 2.9: Diagrama de clases
Fuente: [FOWLER, 1999]
Diagrama de Objetos: muestra una serie de objetos (instancias de las
Cada una de las clases de entidad, interfaz y control, aislaran los cambios al comportamiento (estereotipos estandarizados en UML) y a la información que representan, como se puede observar en la figura 2.9: clases) y sus relaciones.
Figura 2.10: Estereotipos de clases estándar de UML
Fuente: [BOOCH, 1999] Diagramas
de
Comportamiento :
dentro de estos diagramas se
encuentran:
o
Diagrama de Estados: modela el comportamiento del sistema de acuerdo con eventos.
Figura 2.11: Diagrama de Estados
Fuente: [LARMAN, 1999] o
Diagrama de Actividades: simplifica el Diagrama de Estados modelando el comportamiento mediante flujos de actividades. También se pueden utilizar caminos verticales para mostrar los responsables de cada actividad.
Figura 2.12: Diagrama de Actividades
Fuente: [FOWLER, 1999]
o
Diagramas de Interacción: Estos diagramas a su vez se dividen en 2 tipos de diagramas, según la interacción que enfatizan:
Diagrama de Secuencia : enfatiza la interacción entre los
objetos y los mensajes que intercambian entre sí junto con el orden temporal de los mismos.
Figura 2.13: Diagrama de Secuencia
Fuente: [BOOCH, 1999]
igualmente, muestra la interacción entre los objetos resaltando la organización estructural de los objetos en lugar del orden de los mensajes intercambiados.
Diagrama
de
Colaboración :
Figura 2.14: Diagrama de Colaboración
Fuente: [BOOCH, 1999] Diagramas de implementación o
Diagrama de Componentes : muestra la organización y las
dependencias entre un conjunto de componentes.
Figura 2.15: Diagrama de Componentes
Fuente: [BOOCH, 1999]
o
Diagrama de Despliegue : muestra los dispositivos que se
encuentran en un sistema y su distribución en el mismo. Figura 2.16: Diagrama de Despliegue
Fuente: [BOOCH, 1999]
2.2.3 Proceso Unificado de Desarrollo de Software (RUP) El Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software (ver Figura 2.16). Figura 2.17: Proceso de desarrollo de software
Fuente: [JACOB, 2000] El Proceso Unificado está basado en componentes , utiliza el Lenguaje de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. El Proceso Unificado se resumen en tres fases clave; dirigidos por casos de uso, centrado en la arquitectura, e iterativo e incremental. Esto es lo que hace único al Proceso Unificado. El Proceso Unificado es más que un simple proceso; es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyectos.
2.2.3.1 Características Esenciales del RUP El proceso Unificado se base en los siguientes aspectos característicos: El proceso unificado está dirigido por casos de uso
Un caso de uso es un fragmento de funcionalidad que proporciona al usuario un resultado importante . Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad total del sistema. La especificación funcional contesta a la pregunta: ¿Qué debe hacer el
sistema para cada usuario? Sin embargo, los casos de uso no son solo una herramienta para especificar los requisitos de un sistema. También guían su diseño, implementación y prueba: esto es, guían el proceso de desarrollo . El proceso unificado está centrado en la arquitectura
La arquitectura es un sistema software en el que se describe diferentes vistas del sistema en construcción. El concepto de la arquitectura software incluye los aspectos estáticos y dinámicos más significativos . Como la plataforma en la que tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema gestión de base de datos, protocolos para comunicaciones en red), los bloques de construcción reutilizables de que se dispone (por ejemplo: un marco de trabajo para interfaces gráficas de usuario), consideraciones de implantación, sistemas heredados y requisitos no funcionales (por ejemplo, rendimiento y fiabilidad). La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado. ¿Cómo se relacionan los casos de uso y la arquitectura? Cada producto tiene tanto una función como una forma. Estas dos fuerzas deben equilibrarse para poder obtener un producto con éxito. Es esta la situación, la función correspondiente a los casos de uso y la forma de la arquitectura. Debe haber la iteración entre los casos de uso y la arquitectura. Los arquitectos moldean el sistema para darle una forma . Es esta forma, la arquitectura, la que debe diseñarse para permitir que el sistema evolucione, no solo en el desarrollo inicial, sino también a lo largo de las futuras generaciones. Para encontrar, esa forma los arquitectos deben trabajar sobre la comprensión general de las funciones claves del sistema. Estos casos de uso claves pueden suponer solamente 5 y 10 por ciento de todos los casos de uso, pero son los significativos, los que constituyen las funciones fundamentales del sistema.
Proceso unificado es iterativo e incremental
El desarrollo de un software comercial supone un gran esfuerzo que puede durar entre varios meses hasta posiblemente un año o más. Es práctico dividir el trabajo en partes más pequeñas o mini-proyectos . Cada mini-proyecto es una iteración que resulta en un incremento . Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos al crecimiento del producto. Para cada efectividad máxima, las iteraciones deben estar controladas ; esto es, deben seleccionarse y ejecutarse de forma planificada. Esto es por lo que son mini-proyectos. La iteración trata: un conjunto de casos de uso y los riesgos más importantes. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la iteración. Al ser mini-proyectos, comienzan con los casos de uso y continúan a través de desarrollo subsiguiente Análisis, Diseño, Implementación y Prueba, que termina convirtiéndose en código ejecutable los casos de uso que se desarrollan en la iteración, véase Figura 2.17, por supuesto un incremento no necesariamente es aditivo. Especialmente en las primeras fases del ciclo de vida, los desarrolladores van a tener que reemplazar un diseño superficial por uno detallado o sofisticado. En las fases posteriores los incrementos son típicamente aditivos. En cada iteración los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño mediante componentes y verifican que los componentes satisfacen los casos de uso. Si una iteración cumple con sus objetivos-como suele suceder- el desarrollo continúa con la siguiente iteración. Cuando una iteración no cumple con los objetivos, los desarrolladores deben revisar sus decisiones previas y probar con un nuevo enfoque.
2.2.3.2 Fases Dentro de un Ciclo El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema, cada ciclo concluye con una versión del producto para los clientes. Cada ciclo se desarrolla a lo largo del tiempo. Este tiempo a su vez, se divide en cuatro fases, como se muestra en la Figura 2.5., a través de una secuencia de modelos, los implicados visualizan lo que está sucediendo en estas fases. Dentro de cada fase, los directores y desarrolladores pueden descomponer adicionalmente el trabajo – en iteraciones con sus incrementos resultantes. Cada fase termina con un hito . Cada hito se termina por la disponibilidad de un conjunto de artefactos; es decir ciertos modelos o documentos han sido desarrollados hasta alcanzar un estado predefinido. Figura 2.18: Descripción del Proceso Unificado
Fuente: [JACOB, 2000] Fase de Inicio (Inception): Se desarrolla una descripción del producto final
a partir de una buena idea y se presenta el análisis de negocio para el producto. Esencialmente esta fase responde a las siguientes preguntas: ¿Cuáles son las principales funciones del sistema?
¿Cómo podría ser la arquitectura del sistema? ¿Cuál es el plan del proyecto y cuanto costara desarrollar el producto? La respuesta a la primera pregunta se encuentra en un modelo de casos de uso simplificado que contenga los casos de uso más críticos. Cuando lo tengamos la arquitectura es provisional y consiste en un simple esbozo que muestra los subsistemas más importantes. En esta fase, se identifican, priorizan los riesgos más importantes, se planifica en detalle la fase de elaboración y se estima el proyecto de manera aproximada. Fase de Elaboración (Elaboration): se especifican en detalle la mayoría
de los casos de uso del producto y se diseña la arquitectura del sistema. La relación entre la arquitectura del sistema y el propio sistema es primordial. Es decir que la arquitectura es análoga al esqueleto cubierto por la piel pero con muy poco músculo (el software) entre los huesos y la piel – solo lo necesario para permitir que el esqueleto haga movimientos básicos. El sistema es el cuerpo entero con esqueleto, piel y músculos. Por lo tanto, la arquitectura se expresa en forma de vistas de todos los modelos del sistema, los cuales juntos representan al sistema entero. Esto implica que hay vistas arquitectónicas del modelo de casos de uso, del modelo de análisis, del modelo del diseño, del modelo de implementación y del modelo de despliegue. La vista del modelo de implementación incluye componentes para probar que la arquitectura es ejecutable. Durante esta fase de desarrollo, se realizan los casos de uso más críticos que se identificaron en la fase de comienzo. El resultado de esta fase es una línea base de la arquitectura. Al final de la fase de Elaboración, el director del proyecto está en disposición de planificar las actividades y estimar los recursos necesarios para terminar el proyecto. Aquí la cuestión fundamental es: ¿son suficiente estables los casos de uso, la arquitectura, el plan y están los riesgos
suficientemente controlados como para que seamos capaces de comprometernos al desarrollo entero mediante un contrato? Fase de Construcción (Construction): Se crea el producto – se añaden
los músculos (software terminado) al esqueleto (la arquitectura). En esta fase, la línea base de la arquitectura crece hasta convertirse en el sistema completo. La descripción evoluciona hasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios. Al final de esta fase, el producto contiene todos los casos de uso que la dirección y el cliente han acordado para el desarrollo de esta versión. La pregunta decisiva es: ¿cubre el producto las necesidades de algunos usuarios de manera suficiente como para hacer una primera entrega? Fase de Transición (Transition): Cubre el periodo durante el cual el
producto se convierte en versión beta. En esta versión beta un número reducido de usuarios con experiencia prueba el producto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan algunas de las mejoras sugeridas en una versión general dirigida a la totalidad de la comunidad de usuarios. La fase de transición conlleva actividades como la fabricación, formación del cliente, tras la entrega. El equipo de mantenimiento suele dividir estos defectos en dos categorías: los que tienen suficiente impacto en la operación para justificar una versión incrementada (versión delta ) y los que pueden corregirse en la versión normal.
2.2.3.3 Flujos de Trabajo Fundamentales Las fases de desarrollo conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminación de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realización de un proyecto de software , aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen:
Modelado del Negocio, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras características en la realización de un proyecto de software ; entre estas se tienen: Entorno, Gestión del Proyecto, Gestión de Configuración y Cambios. A continuación se describe rápidamente cada una de estas disciplinas. Modelado del negocio Esta disciplina tiene como objetivos comprender la estructura y la dinámica de la organización, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, además utilizan los Diagramas de Actividad y de Clases. Requerimientos Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los límites del sistema, y una interfaz de usuario, realizar una estimación del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, además utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias. Análisis y diseño Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementación, al decir análisis se refiere a transformar CU en clases, y al decir diseño se refiere a refinar el análisis para poder implementar los diagramas de clases de análisis de cada CU, los diagramas de colaboración de de cada CU, el de clases de diseño de cada CU, el de secuencia, de diseño de CU, el de estados de las clases, el modelo de despliegue de la arquitectura.
Implementación Esta disciplina tiene como objetivos implementar las clases de diseño como componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementación, conjuntamente los Diagramas de Componentes para comprender cómo se organizan los Componentes y dependen unos de otros. Pruebas Esta disciplina tiene como objetivos verificar la integración de los componentes (prueba de integración), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribución Despliegue Esta disciplina tiene como objetivos asegurar que el producto está preparado para el cliente, proceder a su entrega y recepción por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, así como la tarea de enseñar al usuario. Gestión y configuración de cambios Es esencial para controlar el número de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya se había arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas: o
Actualización simultánea: Es la actualización de algo elaborado con anterioridad, sin saber que alguien más lo está actualizando.
o
o
Notificación limitada: Al realizar alguna modificación, no se deja información sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo. Versiones múltiples: No saber con exactitud, cual es la última versión, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones.
Gestión del proyecto Su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con éxito (los que pagan el dinero) y los usuarios. Con la Gestión del Proyecto se logra una mejoría en el manejo de una entrega exitoso de software . En resumen su propósito consiste en proveer pautas para: o
Administrar proyectos de software intensivos.
o
Planear, dirigir personal, ejecutar acciones y supervisar proyectos.
o
Administrar el riesgo.
Sin embargo, esta disciplina no intenta cubrir todos los aspectos de dirección del proyecto. Por ejemplo, no cubre problemas como: o
Administración de personal: contratando, entrenando, enseñando.
o
Administración del presupuesto: definiendo, asignando.
o
Administración de los contratos con proveedores y clientes.
Ambiente Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto.
Su propósito es proveer a la organización que desarrollará el software , un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software .
2.2.4 Diseño de la Base de Datos Relacional El diagrama de clases de UML presenta un mecanismo de implementación neutral para modelar los aspectos de almacenamiento de datos del sistema. Las clases persistentes, sus atributos y sus relaciones pueden ser implementados directamente en una base de datos orientada a objetos. Pese a ello, es común emplear una base de datos relacional (BDR) para el almacenamiento de datos. Con el diagrama de clases se pueden modelar algunos aspectos del diseño de base de datos relacionales, aunque no cubre toda la semántica involucrada en el modelado relacional: para capturar esta información, un diagrama entidad/relación (E-R) se utilizará como extensión de UML. Se puede modelar también la estructura lógica de la base de datos, independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos de clase representando columnas. Se plantea la siguiente comparación para lograr una transformación de un modelo de objetos a un diagrama de entidad relación.
Figura 2.19: Modelado del diagrama E-R a partir de un diagrama de clases.
Fuente: [http://www.abcdatos.com/tutoriales/tutorial/l7157.html]
2.2.5 Herramientas de Desarrollo de Software 2.2.5.1 Servidor Web Apache En febrero de 1995, Brian Behlendorf y Chiff Skolnick ensamblaron una lista de envió, prepararon una computadora y consiguieron ancho de banda, donado por HotWired. Brian construyo un árbol CVS (Sistema de Versiones Simultaneas), en
virtud del cual todo el que quisiera podía contribuir a crear nuevas características y a reparar errores. De esta forma, un grupo de desarrolladores podían recoger las modificaciones a sus códigos y crear un producto combinado. Comenzó con HTTPd 1.3 NCSA, empezaron a aplicar estas soluciones. La primera versión de este producto, llamado Apache, fue la versión 0.6.2 lanzado en abril de 1995. Los ocho socios fundadores del Grupo Apache eran Bchlendorf, Skolnick, Roy T. Fielding, Rob Hartill, David Robinson, Randy Terbush, Robert S. Thau y Andrew Wilson. Poco después del primer lanzamiento Thau diseño una arquitectura completamente nueva. Comenzando con la versión 0.8.8 en agosto de 1995, Apache se incorporo a esta nueva base del código. Netcraft muestra que Apache sobrepasa a NCSA como primer servidor HTTP a principios de 1996. De acuerdo con la estadística de Netcraft, el servidor Web Apache se emplea más que el resto del conjunto de servidores Web. De los cerca de 7 millones de sitios Web que tiene la World Wide Web, cerca de 4 millones (el 55%) ejecutan Apache. Si también se cuenta el software para servidor basado en código Apache, esta cifra se acerca al 60%.
2.2.5.2 MySQL MySQL es una idea que nace por la empresa Opensource MySQL AB establecida en Suecia en 1995 y cuyos fundadores son David Axmark, Allan Larsson, y Michael "Monty" Widenius. Michael Widenius en la década de los 90 trató de usar mSQL para conectar las tablas usando rutinas de bajo nivel ISAM, sin embargo, mSQL no era rápido ni flexible para sus necesidades. Esto lo conllevó a crear una API SQL denominada MySQL para bases de datos muy similar a la de mSQL pero más portable. La procedencia del nombre de MySQL no es clara. Por más de 10 años, las herramientas han mantenido el prefijo My. También, se cree que tiene relación con el nombre de la hija del cofundador Monty Widenius quien se llama My.
Por otro lado, el nombre del delfín de MySQL es Sakila y fue seleccionado por los fundadores de MySQL AB en el concurso “Name the Dolphin”.
MySQL probablemente sea el gestor Bases de Datos más usado en el mundo del software libre, debido a su gran rapidez y facilidad de uso. Esta gran aceptación es debida, en parte, a que existen infinidad de librerías y otras herramientas que permiten su uso a través de gran cantidad de lenguajes de programación, además de su fácil instalación y configuración. Las principales características de este gestor de bases de datos MySQL son las siguientes: Aprovecha la potencia de sistemas multiprocesador, gracias a su implementación multi hilo. Soporta gran cantidad de tipos de datos para las columnas. Dispone de API's en gran cantidad de lenguajes (C, C++, Java, PHP, etc). Gran portabilidad entre sistemas. Soporta hasta 32 índices por tabla. Gestión de usuarios y passwords, manteniendo un muy buen nivel de seguridad en los datos.
2.2.5.3 Lenguaje de Programación PHP Rasmus Lerdof, fue quien desarrollo PHP en el año 1994 esta primera versión sin liberar, la incorporo a su página Web personal, cuya utilidad era controlar el número de usuarios que accedían a su currículum vitae online. Nadie supo de la existencia de PHP hasta principios de 1995, cuando la primera versión al fin fue liberada. Por aquel entonces era conocido como Herramienta de Páginas Web Personales (Personal Home Page Tools). A principios de 1995 PHP se puso a disposición de los desarrolladores como Personal Home Page Tools. Esta versión contenía un motor de análisis de sintaxis
(perser) que utilizaba algunas macroinstrucciones (macros) y utilidades especiales que fueron incluidas a menudo en las páginas personales. Esto hizo de PHP una opción bastante popular entre los desarrolladores que querían crear y realzar sus páginas. PHP les permitió que añadieran a sus páginas Web ciertas funciones, ahora habituales, como libros de invitados y contadores. PHP tuvo varias versiones, y a mediados de 1995 Rasmus rescribió el analizador de sintaxis y lo tituló PHP/FI versión 2, hasta mediados de 1997, el analizador de sintaxis fue reescrito totalmente por Zeec Suraski y Andi Gulmnas, este formo el núcleo de la tercera versión de PHP, conocida como PHP 3. Hasta la fecha actualmente se cuenta con la versión de PHP 5.
2.3 CALIDAD DE SOFTWARE 2.3.1 Métricas de Calidad del Software La Calidad del software se define como, concordancia con los requisitos funcionales y de rendimiento explícitamente establecido, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente. Se define en tres puntos: Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Unos estándares especificados definen un conjunto de criterios de desarrollo que guían la manera en que se hace la ingeniería de software. Si no se siguen los criterios, habrá seguramente poca calidad. Existe un conjunto de requisitos implícitos que a menudo no se nombran (tal es el caso la facilidad de mantenimiento). Si el software cumple con sus requisitos explícitos pero falta en los implícitos, la calidad del software no será fiable.
La calidad del software es una compleja mezcla de factores que varían a través de diferentes aplicaciones y según los clientes que la pidan.
2.3.2. Factores de Calidad ISO 9126 El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos clave de la calidad para el software. El estándar identifica seis atributos clave de calidad: Funcionalidad. El grado en que el software satisface las necesidades
indicadas por los siguientes sub atributos: idoneidad, corrección, interoperatividad, conformidad y seguridad. Confiabilidad. Cantidad de tiempo que el software está disponible para su
uso. Está referido por los siguientes sub atributos: madurez, tolerancia a fallos y facilidad de recuperación. Usabilidad. Grado en el que el software es fácil de usar. Viene reflejado por
los siguientes sub atributos: facilidad de comprensión, facilidad de aprendizaje y operatividad. Eficiencia. Grado en el que el software hace óptimo el uso de recursos de
sistema. Está indicado por los siguientes sub atributos: tiempo de uso y recursos utilizados. Facilidad de mantenimiento. La facilidad con que una modificación puede
ser realizada. Está indicada por los siguientes sub atributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba. Portabilidad. La facilidad con que el software puede ser llevado de un
entorno a otro. Está referido por los siguientes sub atributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio.
2.3.3 Funcionalidad Las métricas orientadas a la función, utilizan una medida de la funcionalidad entregada por la aplicación como un valor de normalización. Ya que la funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante medidas directas. Las métricas orientadas a la función fueron propuestas por primera vez por Albretch [ALBRETCH,1979], quien sugirió una medida llamada punto de función. Los puntos de función se derivan con una relación empírica según las medidas contables (directas) del dominio de información del software y las evaluaciones de la complejidad del software. Los puntos de función se evalúan según la siguiente tabla:
Tabla 2.1: Calculo de puntos de función. Factores de Ponderación Parámetro de Medición
Cuenta Simple
Media
Compleja
Número de Entradas del usuario
*
3
4
6
=
Número de salidas del usuario
*
4
5
7
=
Número de consultas del usuario
*
3
4
6
=
Número de Archivos
*
7
10
15
=
Número de Interfaces Externas
*
5
7
10
=
Cuenta TOTAL
Fuente: [PRESS, 2005]
Se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla. Los valores de dominios de información se definen de la siguiente forma: Número de Entradas de Usuario. Se cuenta cada entrada de usuario, que proporcionan diferentes datos orientados a la planificación que proporciona al usuario información.
Número de Salidas de Usuario. Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. Número de Peticiones de Usuario. Una petición se define como una entrada interactiva que produce la generación de alguna respuesta del software inmediata en forma de salida interactiva. Numero de Archivos. Se cuenta cada archivo maestro lógico sea este de la base de datos o archivo de datos. Numero de Interfaces Externas. Se cuenta todas las interfaces legibles por la maquina que se utilizan para transmitir información a otro sistema. Una vez que se han recopilado los datos anteriores, a la cuenta se la asocia un valor de complejidad. Las organizaciones que utilizan métodos de punto de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. No obstante la determinación de la complejidad es algo subjetiva. Para calcular los puntos de función (PF) se utiliza la siguiente relación:
En donde: Cuenta - Total: suma de todas las entradas PF obtenidas de la tabla 2.01. x : es la confiabilidad del sistema. Min (y) : es el error mínimo aceptable de la complejidad.
: son valores de ajuste de complejidad según las respuestas que se da a las siguientes preguntas que se detallan a continuación.
Tabla 2.2: Preguntas para hallar el valor de ajuste. Nro.
Preguntas para hallar el valor de Ajuste
1 2 3 4 5 6
¿Requiere el sistema copias de seguridad y de recuperación fiables?1 ¿Se requiere comunicación de datos? ¿Existen funciones de procesamiento? ¿Es crítico el rendimiento? ¿Se ejecutara el sistema en un entorno operativo existente y fuertemente utilizado? ¿Requiere el sistema entrada de datos interactiva? ¿Requiere la entrada de datos interactiva, que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones? ¿Se actualizan los archivos maestros de forma interactiva? ¿Son complejos las entradas, las salidas, los archivos o las peticiones? ¿Es complejo el procesamiento interno? ¿Se ha diseñado el código para ser reutilizable? ¿Están incluidas en el diseño la conversión y la instalación? ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?
7 8 9 10 11 12 13 14
Fuente: [PRESS, 2005] Cada una de las preguntas anteriores es respondida usando una escala de rangos desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial). Los valores constantes de la ecuación y los factores de peso que se aplican a las cuentas de los dominios de información se determinan empíricamente. El indicador de funcionalidad se lo encuentra calculando la siguiente relación:
2.3.4 Usabilidad La facilidad de uso es un intento de cuantificar “ lo
amigable que puede ser un sistema con el usuario ” y se puede medir en función a cuatro características: i. Habilidad intelectual y/o física requerida para aprender el sistema. ii. El tiempo requerido para llegar hacer moderadamente eficiente en el uso del sistema.
iii. Aumento neto en productividad, medida cuando alguien usa el sistema moderadamente y eficientemente. iv. Valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los usuarios hacia el sistema.
2.3.5 Facilidad de Mantenimiento Se ha propuesto métricas diseñadas explícitamente para actividades de mantenimiento. El estándar IEEE 982.1 – 1998 sugiere un índice de madurez del software (IMS) que proporciona una indicación de la estabilidad del producto software (basada en los cambios que ocurren con cada versión del producto). Este índice se determina de la siguiente manera:
Donde: MT : Número de módulos en la versión actual. Fa : Número de módulos en la versión actual que se han añadido. Fc : Número de módulos en la versión actual que se han cambiado. Fd : Número de módulos de la versión anterior que se han borrado en la
versión actual. A medida que el IMS se aproxima a 1.0, el producto se empieza a estabilizar. El IMS puede emplearse también como métrica para la planificación de las actividades del mantenimiento del software. El tiempo medio para producir una versión de un producto software puede correlacionarse con el IMS desarrollándose modelos empíricos para el mantenimiento.
2.3.6 Portabilidad La portabilidad de un sistema de información se define como la facilidad de transferir un producto a diferentes entornos de hardware/software, sin necesidad de aplicar acciones o mecanismos distintos. También es considerado como la capacidad del producto software para ser usado en lugar de otro producto software para el mismo propósito, dentro del mismo entorno. Las características más importantes que se consideran para este factor son: la facilidad de instalación, facilidad de ajuste y facilidad de adaptación al cambio.
CAPITULO III MARCO APLICATIVO
CAPITULO III MARCO APLICATIVO Según la metodología planteada, el proyecto será desarrollado según la línea del proceso unificado de desarrollado conocido comúnmente como RUP, esta metodología utiliza el Lenguaje Unificado de Modelado para su notación, el cual representa todos los esquemas de un sistema de software. El proceso unificado de desarrollo describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica rápida para diseñar y probar el sistema de acuerdo a los requerimientos y la arquitectura. El proceso de desarrollo RUP se describe en: fases, actividades, artefactos, trabajadores y flujos de trabajo que guiaran este proyecto. En este capítulo se describe el modelado del sistema “ Sistema de Información Web para el Control y Seguimiento de Activos Fijos: Fundación La Paz ”.
3.1 PLAN DE DESARROLLO DEL SISTEMA El objetivo principal es desarrollar un plan de trabajo basado en la metodología RUP de acuerdo a las características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los artefactos que serán generados. Se tomará en cuenta que el estudio preliminar se lo realizo en una primera instancia, concretamente en: la identificación del problema, objetivo general, objetivos específicos, justificaciones y alcances. En esta sección se presenta la organización en fases e iteraciones. El desarrollo del proyecto se llevara a cabo en base a las cuatro fases detalladas anteriormente con una o más iteraciones en cada una de ellas. La siguiente tabla muestra la distribución de tiempos y el número de iteraciones de cada fase.
Tabla 3.1: Tiempos estimados en las fases de RUP. Fases
Nro. Iteraciones
Duración
Fecha
Fase de Inicio
2
4 Semanas
10/08/2009 a 4/09/2009
Fase de Elaboración
3
7 Semanas
24/08/2009 a 9/10/2009
Fase de Construcción
5
12 Semanas
31/08/2009 a 13/11/2009
Fase de Transición
3
6 Semanas
12/10/2009 a 20/11/2009
Fuente: Elaboración propia. De acuerdo a la planificación que se realiza los hitos que marcan el final de cada fase se describen en la siguiente tabla: Tabla 3.2: Fases e Hitos del desarrollo de software. Fase FASE DE INICIO FASE DE ELABORACIÓN
FASE DE CONSTRUCCIÓN
FASE DE TRANSICIÓN
Hito Estudio del modelado de negocio. Requisitos aprobados para su desarrollo. Se elabora los documentos a detalle de los requisitos que serán revisados por el encargado de activos fijos. Prototipo de la arquitectura de acuerdo a los requerimientos. Casos de usos completos y aprobados. El análisis y diseño del sistema debe estar documentado y listo para su revisión. Módulos identificados en los cuales se realizan pruebas de integración. Prototipos del sistema en sus distintas versiones modificado para su revisión y aprobación. Versión concluida del sistema listo para pruebas reales. Elaboración de manuales de usuario según su funcionalidad. Con el sistema terminado se realizan las tareas de configuración. De acuerdo a la planificación el sistema se libera y se realiza en el sistema pruebas de funcionalidad e integridad. Se realizan pruebas y de acuerdo a esto modificaciones ante posibles fallas, hasta conseguir el funcionamiento correcto. Se termina la documentación del sistema para ser entregada.
Fuente: Elaboración propia. La siguiente tabla presenta un resumen de las principales tareas del proyecto en sus distintas disciplinas variando en cada fase el trabajo a realizar. En la primera fase se desarrolla especialmente las disciplinas de modelado de negocio y
requisitos, en la segunda fase se desarrolla el análisis y diseño tomando en cuenta el estudio realizado de los requerimientos, en la tercera fase se desarrolla la construcción de acuerdo al análisis y diseño realizado con anterioridad y en la cuarta fase se realizan las pruebas además de las posibles modificaciones y la conclusión de la documentación. Tabla 3.3: Artefactos de las distintas disciplinas que comprende RUP. Disciplinas MODELADO DEL NEGOCIO
REQUISITOS
ANALISIS / DISEÑO
IMPLEMENTACION PRUEBAS DESPLIEGUE GESTION Y CONFIGURACION DE CAMBIOS
Artefactos Generados o Modificados Modelo del Negocio Diagrama de Casos de Uso del Negocio. Diagramas de Actividades. Modelo de Objetos del Negocio. Diagrama de Objetos. Requisitos Funcionales. Requisitos no Funcionales. Glosario. Modelo Conceptual Modelo de Análisis/Diseño. Diagrama de CU del sistema. Descripción de los casos de uso. Diagramas de Secuencias. Diagramas de Estado. Diagrama de Clases. Modelo de Datos. Transformación del modelo OO al modelo E-R Prototipos de Interfaces Casos de Prueba Funcionales. Modelo de Despliegue. Diagrama de Componentes Diagrama de Despliegue Manual de Usuario. Plan de Mantenimiento y Continuidad.
Fuente: Elaboración propia.
3.2 FASE DE INICIO 3.2.1 Modelado del Negocio Basado en el estudio preliminar de la institución se procede a identificar y describir cada uno de los procesos del negocio, determinando el tipo de información, actividades, roles y reglas del negocio implicadas. Con esto lo que se pretende es comprender toda la actividad de la institución relacionada con el sistema a implementar.
3.2.1.1 Identificación de Procesos del Negocio El modelado del negocio se inicia identificando los principales objetivos estratégicos de la institución y los procesos de mayor relevancia asociados a estos objetivos son: De acuerdo a sus estatutos de la Fundación La Paz (FLP): “Diseñar, ejecutar y asesorar programas, proyectos y acciones de promoción y gestión social en beneficio de la población pobre de zonas suburbanas y rurales del país”. Generar procesos educativos en la perspectiva de ampliar los conocimientos de los diferentes sectores sociales del país, para elevar sus niveles de conciencia y reforzar su identidad socio cultural. Promover la participación y organización de estos sectores, para ampliar su capacidad de enfrentar situaciones críticas y mejorar sus condiciones de negociación en el contexto social en el que se desenvuelven. Contribuir en el mejoramiento de la calidad de vida de la población mediante la prestación de servicios.
3.2.1.2 Identificación de Actores del Negocio. A continuación se identifica y describe los actores del negocio correspondiente de la Fundación La Paz:
Director Área Socio Educativa (ASE), es a quien se emite los reportes sobre el movimiento y estado de los activos. Encargado de Unidad de Activos Fijos , tiene la función de controlar todo el movimiento de los activos existentes en la Fundación desde su recepción, registro, asignación, baja, etc. A su vez también está a cargo de la emisión de reportes y actas respectivas. Coordinador de Programa , es la persona encargada de realizar las solicitudes de un activo fijo para los respectivos subprogramas del programa del cual es responsable. Personal, es el personal que pertenece a los distintos programas y subprogramas de la ASE. Es también a quien se le asigna el activo y dispone de los mismos para la realización de sus funciones y responsable directo del Activo Fijo. Financiador , es la persona física o jurídica que se encarga de proveer de Activos Fijos y financiamiento económico para su compra, cuando requiera el ASE. Responsable de Contabilidad , es aquella persona la cual está encargada del departamento contable del ASE y la misma realiza la emisión de los cheques para la adquisición de un Activo Fijo.
3.2.1.3 Definición de Casos de Uso del Negocio La identificación y definición de los casos de uso así como también su respectiva descripción se la detalla a continuación: Recepcionar Pedido de Activo Fijo . El coordinador recepciona la solicitud de un determinado activo fijo de parte del personal del sub programa, el cual remite al encargado de la unidad de activos fijos. Comprar Activo Fijo . De acuerdo a la aprobación hecha en la solicitud, el coordinador del programa realiza la compra del activo solicitado.
Asignar Activo fijo . El encargado de la unidad de activos fijos realiza la asignación de activos fijos al personal solicitante. Este último será el custodio y responsable del bien. Revaluó de Activo Fijo . Se toma en consideración aquel activo fijo el cual haya cumplido sus años de vida útil o su valor neto haya alcanzado a cero y que aun pueda ser de utilidad; es entonces que el encargado de la unidad de activos fijos procederá al cambio de valores: costo, años de vida útil y la respectiva depreciación. Baja Activo . El encargado de la unidad Activos Fijos procede el retiro de los bienes que hayan ya cumplido su vida útil o que estén en un estado en el cual no preste el servicio por el cual fue adquirido. Reasignación de Activo Fijo. El encargado de la unidad de AF se encarga de la nueva ubicación de un activo fijo, el cual ahora contara con nuevo código y como es debido de un custodio o responsable. Generar Reportes. El encargado de la Unidad de AF, realiza los respectivos reportes correspondientes a la administración de los activos (incorporación, baja, asignación, revaluó, etc.). Estos reportes son solicitados por el Director del Área Socio Educativa.
3.2.1.4 Definición del Diagrama de Casos de Uso del Negocio A continuación se realiza la identificación de los diferentes procesos del negocio de la entidad. El siguiente grafico muestra los casos de uso del modelo de negocio.
Figura 3.1: Modelos de Casos de Uso del Negocio.
Recepcionar Pedido de Activo Fijo
Comprar Activo Fijo
Responsable de Contabilidad
Coordinador de Programa
Revaluo de Activo Fijo
Financiador Baja de Activo Fijo
Encargado de la Unidad de Activos Fijos
Asignar Activo Fijo
Reasignacion de Activo Fijo
Responsable de Activo Fijo
Director del Area Socio Educativa
Generar reportes
Fuente: Elaboración Propia
3.2.1.5 Diagrama de Actividades El diagrama de actividades muestra el flujo de actividades entre los elementos del dominio mismo que se puede apreciar en los siguientes gráficos:
Figura 3.2: Diagrama de Actividades Recepcionar Pedido de Activo Fijo ENCARGADO DE LA UNIDAD DE ACTIVOS FIJOS
RESPONSABLE DE CONTABILIDAD
COORDINADOR DE PROGRAMA
Realiza soli citud
Recepciona soli citud
Aproba soli citud
[No] Niega soli citud
[Si] Envia soli citud
Emite cheque
Recoge cheque
Realiza compra
Recepciona compra Registra el activo fijo
Coloca identificador
Asigna responsable y ubi cacion
Emite comprovante de entrega
Fuente: Elaboración Propia Figura 3.2: Diagrama de Actividades Comprar Activo Fijo ENCARGADO DE LA UNIDAD DE ACTIVOS FIJOS
COORDINADOR DE PROGRAMA
RESPONSABLE DE CONTABILIDAD
Realiza solicitud Recepciona solicitud Emite cheque
Recoge cheque
Realiza compra
Recepciona compra Registra el activo fijo
Fuente: Elaboración Propia
Figura 3.3: Diagrama de Actividades Asignar Activo Fijo FINANCIADOR
ENCARGADO DE LA UNIDAD DE ACTIVOS FIJOS
COORDINADOR DE PROGRAMA
Envia Donacion Compra activo fijo
Recepciona activo fijo Registra activo fijo
Coloca sticker de seguridad
Asigna responsable y ubi cacion
Emite comprovante de entrega
Fuente: Elaboración Propia
Figura 3.3: Diagrama de Actividades Revaluó de Activo Fijo ENCARGADO DE L A UNIDAD DE ACTIVOS FIJOS
Revisa registros de AF
Verifica utili dad Baja de activo fijo
Revaluo de activo fijo
Fuente: Elaboración Propia
Figura 3.4: Diagrama de Actividades Baja de Activo Fijo COORDINADOR DE PROGRAMA
ENCARGADO DE LA UNIDAD DE ACTIVOS FIJOS
Observa no usabilidad de AF
Evalua asignacion de AF Realiza informe
Devolucion de activo fijo
Recepcion informe
Realiza reubicacion interna de AF
Realiza ajustes correspondie ntes
Fuente: Elaboración Propia
Figura 3.5: Diagrama de Actividades Reasignación de Activo Fijo RESPONSABLE DE ACTIVO FIJO
COORDINADOR DE PROGRAMA
Observa no usabilidad de AF
Evalua asignacion de AF Devolucion de activo fijo
Realiza informe
Recepcion informe
Realiza reubicacion interna de AF
Realiza ajustes correspondientes
Fuente: Elaboración Propia
3.2.1.6 Modelo de Objetos Figura 3.6: Modelo de Objeto del Caso de Uso Recepcionar Pedido de AF
Registro de AF Cheque Responsable de Contabilidad
Coordinador Programa
Encargado Unidad AF
Solicitud de AF
Fuente: Elaboración Propia
Figura 3.7: Modelo de Objeto del Caso de Uso Comprar Activo Fijo
Encargado Unidad AF
Registro de AF
Responsable de Contabilidad
Solicitud de AF
Coordinador Programa
Cheque
Fuente: Elaboración Propia
Figura 3.8: Modelo de Objeto del Caso de Uso Asignar Activo Fijo
Encargado Unidad AF
Registro de AF
Responsable de AF
Fuente: Elaboración Propia Figura 3.9: Modelo de Objeto del Caso de Uso Revaluó de Activo Fijo
Encargado Unidad AF
Revaluó de AF
Registro de AF
Fuente: Elaboración Propia Figura 3.10: Modelo de Objeto del Caso de Uso Baja de AF
Coordinador Programa
Informe de baja de AF Encargado Unidad AF
Baja de AF
Fuente: Elaboración Propia Figura 3.11: Modelo de Objeto del Caso de Uso Reasignación de AF
Responsable de AF
Coordinador Programa
Informe de reasignación
Registro de AF
Fuente: Elaboración Propia
3.2.2 Modelado de Requisitos El modelo de requisitos es donde se establecen los requisitos funcionales y no funcionales del sistema, mismos que facilitan el análisis y diseño del sistema.
3.2.2.1 Requisitos Funcionales La siguiente tabla detalla las funciones elementales o requerimientos que deberán ser satisfechos para el usuario final por el sistema a implantar. Nro. R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15
Tabla 3.4: Definición de Requisitos Funcionales del Sistema. FUNCION CATEGORIA Control de ingreso para usuarios. Oculta Registro de usuarios habilitados. Evidente Registro de ingreso de activos fijos (AF). Evidente Generación automática del código identificador de AF. Oculta Registro de asignación de AF al personal. Evidente Registro de financiadores. Evidente Informe de Activos Fijos por Programa y Sub programa Evidente Realizar el revaluó técnico del Activo Fijo. Evidente Realizar el cálculo de actualización y depreciación del AF. Oculta Obtener reporte de las asignaciones realizadas de los Evidente Activos Fijos por responsable. Registrar la baja del AF y su correspondiente observación. Evidente Generar informe de Activos por rubro, sub rubro, fecha de Evidente ingreso. Registro de rubro (equipo de computación, muebles y Evidente enseres, vehículo, equipos, maquinaria, etc.) de AF. Registro de subgrupo (microprocesador, memoria, disco Evidente duro, lector DVD, etc.) de AF. Registro de responsable (funcionario). Evidente Fuente: Elaboración Propia.
3.2.2.2 Requisitos No Funcionales Para el correcto funcionamiento el sistema informático que se está desarrollando deberá cumplir con los siguientes requerimientos no funcionales en el momento de implantar el sistema, mismos que se detallan a continuación: Windows o Linux como sistema operativo al lado del cliente.
Internet Explorer o Mozila Firefox como navegador de Internet por el lado del cliente. En el lado del Servidor deberá estar instalado el Servidor Apache además del gestor de base de datos MySql y el intérprete de páginas PHP. La información almacenada deberá ser capaz de ser accedida en otros equipos conectados dentro del Área Socio Educativa de la Fundación La Paz. La aplicación no deberá consumir demasiado tiempo a la hora de acceder a la misma. Para ver el glosario de términos diríjase al Anexo E.
3.2.2. Modelo Conceptual Una parte de la investigación del dominio del problema consiste en identificar los conceptos que los conforman. La base sobre la cual se puede identificar estos conceptos es en la especificación de requisitos además del conocimiento que se tenga sobre el entorno en el cual se basan los mismos. Figura 3.12: Modelo Conceptual asociado al Control y Seguimiento de AF. Financiador Area
1
Unidad
tiene
Programa 1
*
Sub Programa
contiene
1
posee
*
* 1
1
es financiado por
es parte *
* Encargado AF 1
registra
Activo Fijo
* pertenece
*
Sub Rubro
1
* se asigna a Responsable
* *
1
* se realiza
se da 1 Baja
se efectua 1 1 Act. y Dep
Fuente: Elaboración Propia.
Revaluo
* compone 1
Rubro
3.3 FASE DE ELABORACION 3.3.1 Modelo de Casos de Uso 3.3.1.1 Actores del Sistema Encargado de Unidad de Activos Fijos , tiene la función de controlar todo el movimiento de los activos existentes en la en la Fundación desde el registro de incorporación, asignación, baja, revaluó, actualización y depreciación, etc. A su vez también está a cargo de la emisión de reportes y actas respectivas. Coordinador de Programa , es la persona encargada de realizar el registro, baja y la emisión de reportes correspondiente a los activos fijos de su programa. Director Área Socio Educativa, es quien realiza los reportes sobre el movimiento y estado de los activos. Administrador del Sistema, es la persona encargada de administrar la Base de Datos y llevar a cabo el control de accesos. Usuario , Un usuario es en general toda persona que interactúa con el sistema, tenemos como usuarios al encargado de la Unidad de Activos Fijos, Coordinador, Director Área Socioeducativa y cualquier otro funcionario de la fundación. 3.3.1.2 Definición de Casos de Uso Esenciales En función de los casos de uso ya especificados en la etapa inicial además de los nuevos casos de uso, mismos que se describen a continuación corresponderán a los casos de uso esénciales y serán definidos en formato expandido para una mejor comprensión: Registrar activo fijo. El encargado de la Unidad de Activos Fijos, Coordinador de Programa, son los responsables de realizar el registro del ingreso de los activos al
sistema. Para que esta funcionalidad pueda efectuarse se deberá tener ya identificado la clasificación del Activos, su correspondiente valor contable y el financiador correspondiente. Reasignar activo fijo. En primera instancia se da de baja al activo fijo en desuso, para después darle otra ubicación y asignarle un nuevo responsable. Actualizar y Depreciar activo fijo. El procedimiento de Actualización y Depreciación de Activos Fijos procesa los datos contables y calcula su valor correspondiente previa ejecución por parte del usuario del sistema quien tenga el privilegio respectivo. Revaluó de Activos Fijos. Los Activos Fijos que fueron revaluados son actualizados llegando a tener nuevamente uso dentro del ASE siguiendo el procedimiento respectivo. Baja de Activos Fijos. El encargado de Activos Fijos procede el retiro de los Activos Fijos que hayan ya cumplido su vida útil o que estén en un estado en el cual no preste el servicio por el cual fue adquirido. Registrar Tipo de Cambio de Moneda. El encargado de Activos Fijos ingresa el tipo de cambio a la fecha ($us y Euros). Estos datos serán utilizados como referencia para la utilización en: el ingreso y registro de Activos Fijos, actualización y depreciación, el cálculo del respectivo valor contable, baja de activo y en la adición por revaluó técnico. Generar reportes. En el caso de uso se generan reportes de acuerdo a las necesidades de usuarios que requieran emitir informes sobre los activos fijos. Administrar Sistema. El administrador es el encargado de realizar el mantenimiento y/o actualización de la base de datos y de los módulos a los cuales está a cargo. 3.3.1.3 Definición del Diagrama de Casos de Uso Esencial El siguiente diagrama corresponde al caso de uso esencial del “Sistema de Información Web para el Control y Seguimiento de Activos Fijos: Fundación La
(SISCAFW). A partir de este se especificaran los diagramas de casos de uso descritos. Paz”
Figura 3.13: Diagrama de Casos de Uso del Sistema SISCAFW
SISCAFW
Registrar activo fijo
Reasignar activo fijo
Coordinador de Programa
Actualizar y depreciar activo fijo
Encargado de la Unidad de AF
Revaluo de activo fjo
Baja de activo fjo
Registar tipo de cambio de moneda
Generar reportes
Director del ASE
Admin istrar responsable Admin istrar ususario Usuario
<
>
<>
Administrar base de datos Administrador del Sistema
<>
<>
Administrar institucion <>
Administrar financiador
Administrar rubro
Fuente: Elaboración Propia. 3.3.1.4 Descripción de los Casos de Uso Esenciales En las siguientes tablas se tiene la descripción de los casos de uso del Sistema de Información Web para el Control y Seguimiento de Activos Fijos (SISCAFW):
Tabla 3.5: Descripción Caso de Uso Registrar Activo Fijo. Caso de Uso Descripción
Flujo de Eventos
Precondiciones
Poscondiciones
Registrar Activo Fijo El actor inicializador de este caso de uso es el encargado de la unidad de Activos Fijos o el Coordinador del Programa. Registra los datos del Activo asignándole un código, el mismo que es generado de forma automática al seleccionar la ubicación del mismo y también seleccionando el rubro y sub rubro al cual corresponde. Además de introducir la información relevante del activo fijo de la incorporación de un activo fijo. Flujo Básico 1. Ingresar en el Menú Administrar Activo Fijo(AF) 2. Ingresar al enlace de Registrar AF. 3. Seleccionar la Ubicación (Área, Unidad, Programa, Sub Programa) 4. Seleccionar Rubro 5. Seleccionar Sub Rubro 6. Seleccionar Financiador 7. Introducir los datos y detalles del AF (descripción, costo, estado). 8. Ingresar la ubicación del bien y seleccionar al responsable para la asignación del activo fijo. 9. Una vez confirmado los datos del activo fijo se realiza la incorporación del activo fijo. Flujo Alternativo En 3, 4, 5, 6, 7, 8, 9,10, 11 si no existe el ítem relacionado con el área, unidad, programa, sub programa, rubro, sub rubro, financiador y responsable, en la lista de selección de cada una de estas, se podrá ingresar en el menú Administración de base de datos en donde se detalla otros sub menús para adicionar un área, unidad, programa, sub programa, rubro, sub rubro, financiador y responsable como así lo requiera el usuario. En 4, si fuese el caso de registrar el ingreso del activo fijo equipo de computación, se tendrá la siguiente secuencia de pasos: a) Seleccionar Rubro: Equipo de Computación b) Seleccionar Sub Rubro: Microprocesador c) Ingresar la descripción: Microprocesador Intel de 2.4 Gigahertz, memoria cache de 8 Megabytes, bus 1333. d) Ingresar el costo: Bs 1332 e) Ingresar el estado: Nuevo Así podemos evidenciar que el equipo de computación consta de varios elementos que son considerados como ítems de activo fijo con lo cual se realizara un mejor seguimiento y control de activos fijos. El encargado de la Unidad de Activos Fijos o el Coordinador del Programa debe realizar su correspondiente autentificación para el ingreso al sistema, para luego proceder al registro del tipo de cambio a la fecha actual. El encargado de AF debe tener las áreas, unidades, programas, sub programas, rubros y sub rubros, además del responsable del activo fijo ya definido y registrado en el sistema. El caso de Uso termina al registrar el activo fijo en el sistema.
Fuente: Elaboración Propia.
Tabla 3.6: Descripción Caso de Uso Registrar Tipo de Cambio. Caso de Uso
Registrar Tipo de Cambio
Descripción
El actor inicializador de este caso de uso es el encargado de la Unidad de Activos Fijos. Al ingresar al sistema podrá visualizar una ventana emergente en donde el podrá registrar el tipo de cambio a la fecha actual.
Flujo de Eventos
Flujo Básico 1. Ingresar el tipo de cambio de la moneda. 2. Pulsar el botón registrar para el ingreso de tipo de cambio a la fecha actual. 3. Una vez confirmado el registro del tipo de cambio se tiene acceso al sistema SISCAFW. Flujo Alternativo 1. En 1 puede que ya se haya registrado el tipo de cambio a la fecha actual, entonces el sistema no pide ingresar tipo de cambio y el usuario accede al sistema SISCAFW.
Precondiciones
El encargado de la Unidad de Activos Fijos debe realizar su correspondiente autentificación para el ingreso al sistema, para luego proceder al registro del tipo de cambio a la fecha actual
Poscondiciones
El caso de Uso termina cuando el Encargado de Activos Fijos registra el tipo de cambio.
Fuente: Elaboración Propia.
Tabla 3.7: Descripción Caso de Uso Actualizar y Depreciar Activo Fijo. Caso de Uso
Actualizar y Depreciar Activo Fijo
Descripción
El actor inicializador de este caso de uso es el encargado de la Unidad de Activos Fijos. Realiza la actualización del activo fijo y su depreciación Flujo Básico 1. Ingresar en el Menú Administrar Activo Fijo. 2. Ingresar al enlace de Actualizar Depreciar Activo Fijo. 3. Seleccionar una fecha inicial y una fecha final. 4. Una vez confirmado los datos del tipo de cambio para las fechas seleccionadas, se realiza la actualización y depreciación de activos fijos. Flujo Alternativo 1. En 4 negada la confirmación de la actualización y depreciación del activo fijo, retornará a la pantalla de actualización y depreciación.
Flujo de Eventos
Precondiciones
El encargado de la Unidad de Activos Fijos debe realizar su correspondiente autentificación para el ingreso al sistema. El encargado de Activos Fijos verifica que se tenga los tipos de cambio registrados a la fecha a la que actualizara y depreciara.
Poscondiciones
El caso de Uso termina cuando el encargado de la Unidad Activos Fijos realiza la actualización y depreciación de activos fijos.
Fuente: Elaboración Propia.
Tabla 3.8: Descripción Caso de Uso Revaluó Activo Fijo. Caso de Uso
Revaluó Activo Fijo
Descripción
El actor inicializador es el encargado de la Unidad de Activos Fijos. Deberá realizar la verificación necesaria de aquellos activos cuyo valor neto sea menor que 1 Bs. y sus años de vida hayan llegado a 0 meses. Para ello el encargado deberá de realizar el respectivo revaluó técnico que se necesite si el activo fijo aun posee utilidad.
Flujo de Eventos
Flujo Básico 1. Ingresar al Menú Administrar Activo Fijo. 2. Ingresar al enlace Revaluó Activo Fijo. 3. Verifica el estado general del activo. 4. Verificar la depreciación del activo fijo para obtener el valor neto. 5. Luego de las verificaciones necesarias se procede a hacer el revaluó del activo fijo ingresando sus nuevos valores (Fecha de ingreso, costo, estado). 6. Una vez confirmado los nuevos datos del activo fijo, se realiza el revaluó técnico de los activos fijos. Flujo Alternativo 1. En 6 si no se llegara a confirmar la aceptación de registro de los nuevos datos del activo fijo, retornará a la pantalla de valuó técnico.
Precondiciones
El encargado de la Unidad de Activos Fijos debe realizar su correspondiente autentificación para el ingreso al sistema. El encargado de la unidad debe observar el estado del activo fijo, verificar el valor neto y los años de vida útil del activo fijo.
Poscondiciones El caso de Uso termina cuando el encargado de la Unidad Activos Fijos realiza el revaluó técnico del activo fijo.
Fuente: Elaboración Propia.
Tabla 3.9: Descripción Caso de Uso Baja de Activo Fijo. Caso de Uso
Baja de Activo Fijo
Descripción
El actor inicializador de este caso de uso es el encargado de la Unidad de Activos Fijos y el coordinador de programa, deberá realizar la verificación necesaria de aquellos activos cuyo valor neto sea menor de 1 Bs. o sus años de vida hayan llegado a 0 meses u otra circunstancia por la cual se quiere dar de baja. Para ello el encargado realizará la baja del activo fijo con la observación que así lo amerite.
Flujo de Eventos
Flujo Básico 1. Ingresar al Menú Administrar Activo Fijo 2. Ingresar al enlace de Baja de Activo Fijo 3. Verifica el estado general del activo 4. Verificar la depreciación del activo fijo para obtener el valor neto. 5. Verificar que el valor neto es menor a 1 Bs, los años de vida útil ya se hayan cumplido y ya no existe la posibilidad de revaluar el activo, entonces procede a dar de baja el AF. 6. Una vez introducida la observación por la cual se da de baja al activo fijo y la confirmación de la misma, se registra la baja del activo. Flujo Alternativo 1. En 6 si no se llegara a confirmar la aceptación de registro de baja del activo fijo, retornará a la pantalla baja de activo fijo.
Precondiciones
El encargado de la Unidad de Activos Fijos debe realizar su correspondiente autentificación para el ingreso al sistema. El encargado de la unidad debe observar el estado del activo fijo.
Poscondiciones
El caso de Uso termina cuando el encargado de la Unidad de Activos Fijos registra la baja del activo fijo.
Fuente: Elaboración Propia.
Tabla 3.10: Descripción Caso de Uso Generar Reportes. Caso de Uso
Generar Reportes
Descripción
Los actores inicializadores de este caso de uso son el Encargado de la Unidad de Activos Fijos, Director del Área Socio Educativa, Coordinador de Programa y Usuario. Realizar para la generación de reportes de acuerdo a su requerimiento.
Flujo de Eventos
Flujo Básico 1. Ingresar al Menú Administrar Activo Fijo 2. Ingresar al enlace de Generar Reportes de Activo Fijo 3. Ingresar el rango de fecha del cual se requiera conocer información. 4. Seleccionar datos de las listas de selección del Área, Unidad, Programa, Sub Programa, Rubro, Sub Rubro, Baja, Incorporados y Depreciaciones. 5. Se generará el reporte con los datos seleccionados. 6. Ingresar al enlace imprimir, para emitir el reporte impreso.
Precondiciones
El encargado de la Unidad de Activos Fijos debe realizar su correspondiente autentificación para el ingreso al sistema. El encargado de AF debe tener actualizada la base de datos con los registros de activos fijos.
Poscondiciones El caso de Uso termina cuando el encargado de la Unidad de Activos Fijos realiza y despliega informes y reportes necesarios para el control de activos fijos. Fuente: Elaboración Propia.
3.3.2 Modelo de Diseño 3.3.2.1 Definición de Diagramas de Secuencia En los siguientes diagramas de secuencia se observa las operaciones proporcionadas por el SISCAFW mismas que son demandadas por los actores del sistema. En estos diagramas se muestra la interacción de los actores que fueron identificados y mencionados en este documento con los objetos del diseño a través de la secuencia de mensajes entre los mismos. Figura 3.14: Diagrama de Secuencia Registrar Activo Fijo. :IU Registrar activo fijo
: Gestor de Registrar AF
: UBICACION
: RUBRO
: SUB RUBRO
: RESPONSABLE
: FINANCIADOR
ACTIVO FIJO
Encargado Unid AF Ingreasr Datos AF
Seleccionar Ubicacion Obtener Ubicacion Seleccionar Rubro
Obtener Cod Rubro
Seleccionar Sub Rubro
Obtener Cod SRubro
Seleccionar Responsable
Obtener Datos Res
Seleccionar Financiador
Ontener Datos del Fin
Mostra Generacion de Cod Introducir(desc,estado, costo, obs) Grabar Datos Int Almacenar Nuevo Activo Fijo
Fuente: Elaboración Propia.
Figura 3.15: Diagrama de Secuencia Cálculo de Actualización y Depreciación. :IU Actual izaci on y Depreci aci on
Gestor de Act y Dep
: Acti vo Fi jo
Encargado Unid AF Seleccionar Actualizar y Depreciar Datos de Activo Fijo Obtiene Datos de AF Despliega Act y Dep Almacena Actualizacion y Depreciacion
Fuente: Elaboración Propia.
Actual izaci on y Depreci aci on
Figura 3.16: Diagrama de Secuencia Baja de Activo Fijo. :IU Baj a de Activo Fij o
Gestor Baja de AF
: UBICACION
: RUBRO
: SUB RUBRO
ACTIVO FIJO
Encargado Unid AF Ingreasr Datos AF Seleccionar Ubicacion Seleccionar Rubro
Obtener Ubicacion Obtener Cod Rubro
Seleccionar Sub Rubro
Obtener Cod SRubro
Mostra Lista de AF Seleccionar AF Ingresar Observacion Pulsar Boton Dar Baja AF Almacenar Baja de Activo Fijo
Fuente: Elaboración Propia.
Figura 3.17: Diagrama de Secuencia Registrar Tipo de Cambio. :I U Re gi st ra r T i po de C
G esto r d e T i po de Ca mb io
: Ti po de Ca mb io
Encargado Unid AF Ingresar Datos Tip o de Camb io Tipo de Cambio Desplegar mensaje de Confirmacion Almacenar Tipo de Cambio
Fuente: Elaboración Propia. Figura 3.18: Diagrama de Secuencia Revaluó Activo Fijo. :IU Revaluo de AF
Gestor de Revaluo
: Activo Fi jo
Encargado Unid AF Ingresar Datos de AF Descripcion de AF Obtiene Datos de AF Obtiene Depreciacion Despliega Datos de AF Despliega Depreciacion d e AF Almacenar Revaluo de AF Actualiza AF
Fuente: Elaboración Propia.
: Revaluo
3.3.2.2 Definición del Diagrama de Estados El siguiente diagrama de estado nos permite los estados y eventos más importantes del sistema.
Figura 3.19: Diagrama de Estados del Sistema SISCAFW.
Visualiza pantalla de ingreso al sistema
Introducir datos de usuario Verifica error de usuario
Visualiza interfaz de menu
En espera de seleccion d e menu
Solicitud de reaignación
Solicitud de incorporación Solicitud de depreciación
Solicita datos de AF a incorporar
Solicita datos de AF a depreciar
Introducir ubicación
Solicitud de baja o revaluo Verifica estado de AF
Solicita d atos de AF a reasignar
Introducir datos de AF
Introducir datos de AF Solicita ubicacion
Introducir clasificador Solicita clasificador
Verifica datos de AF
Introducir fecha Solicita rango de fecha
Efectúa baja de AF
solicita dato de AF Introducir datos de AF
Datos correctos efectúa baja de AF
Datos correctos
Solicita datos de AF a Revaluar Solicita datos de AF
Datos correctos
Datos correctos Genera codigo de AF
Realiza calculo de depreciación
Introducir datos de AF
Termina operación
Solicita nuevo responsable Termina operación
Termina operación
Graba informacion
Fuente: Elaboración Propia.
3.3.2.3 Definición de Diagramas Colaboración En los diagramas de colaboración, mostramos las interacciones entre los objetos creando entre ello y añadiendo mensajes a estos enlaces. Se identifican las clases de análisis para llevar a cabo el flujo de sucesos del caso de uso.
Figura 3.20: Diagrama de Colaboración Registrar Activo Fijo. : Encargado Unid AF
1: Ingresar Datos AF 6: Rubro 7: Sub Rubro
2: Seleccionar Area 3: Seleccionar Unidad 4: Programa
8: Responsable
5: Sub Programa
9: Financiador
22: Grabar Datos
23: Almacenar Nuevo AF : IU Registrar activo fijo
: Activo Fijo
20: Generar Codigo 18: Obtener Financiador
10: Obtener Cod Area : Gestor de Registrar AF
: Area
: Financiador 12: Obtener Cod Unidad 17: Ob tener Responsable 13: Obtener Programa : Unidad
16: Obtener Cod SR 15: Obtener Cod Rubro
14: Obtener Cod SP
: Responsable : Programa : Sub Rubro
: Rubro
: Sub Programa
Fuente: Elaboración Propia.
Figura 3.21: Diagrama de Colaboración Cálculo de Actualización y Depreciación. : Encargado Unid AF
1: Seleccionar Act y Dep
5: Almacena Act y Dep :IU Actualizacion y Depreciacion
: Actualizacion y Depreciacion
2: Datos de AF 4: Desplegar Lista de Act y Dep 3: Obtener Datos AF : Gestor de Act y Dep
: Activo Fijo
Fuente: Elaboración Propia.
Figura 3.22: Diagrama de Colaboración Baja de Activo Fijo. : Encargado Unid AF
1: Ingresar Datos AF 6: Rubro
2: Seleccionar Area 3: Seleccionar Unidad
7: Sub Rubro
4: Programa 5: Sub Programa
15: Seleccionar AF 16: Ingresar Observacion
17: Grabar Datos
18: Almacenar Baja de AF : IU Baja activo fijo1
: Activo Fijo
14: M ostrar Lista de AF 8: Obtener Area
13: Obtener SR : Gestor de Baja AF
: Area
: Sub Rubro 9: Obtener Unidad
12: Obtener Rubro
10: Obtener Programa 11: Obtener SP
: Rubro
: Unidad
: Sub Programa
: Programa
Fuente: Elaboración Propia.
Figura 3.23: Diagrama de Colaboración Registrar Tipo de Cambio. : Encargado Unid AF
1: Ingresar Datos de T C
:IU Registrar Tipo de C
2: Tipo de Cambio 3: Desplegar mensaje : Gestor de Ti po de Cambio
: Tipo de Cambio 4: Almacenar Tipo de Cambio
Fuente: Elaboración Propia.
Figura 3.24: Diagrama de Colaboración Revaluó de Activo Fijo. : Encargado Unid AF
1: Ingresar datos de AF
:IU Revaluo de AF
6: Despliega Dep de AF 2: Descripcion d e AF 5: Despliega datos AF
3: Obtene r Datos AF : Gestor de Revalu o
: Activo Fijo 4: Obtiene Depreciacion
7: Almacenar Rev de AF
8: Actualiza AF
: Revaluo
Fuente: Elaboración Propia.
3.3.2.4 Definición del Diagrama De Clases
Figura 3.25: Diagrama de Clases del sistema SISCAFW ActDep + + + + +
Area Unidad
+ area_nom : String + area_sigla : String
1..*
+ unid_nom : String + unid_sigla : String
1..1
+ adicionar () : void + eliminar () : void + listar () : void
ad_fecha_ini ad_fecha_fin valor_ant valor_act val_dep
: Date : Date : float : float : float
+ adicionar () : void + listar () : void + eliminar () : void
+ adicionar () : void + eliminar () : void + li star () : void
1..*
Rubro + + + +
1..1 Tipo Cambio
1..*
+ tc_fech : Date + tc_val : float
Sub Programa
Programa + prog_nom : String + prog_sigla : String
1..1 1..*
+ adicionar () : void + eliminar () : void
+ sprog_nombre : String + sprog_sigla : String + adicionar () : void + eliminar () : void
1..* 1..1
1..*
per_pat per_mat per_nom per_dir per_tel per_cel per_cargo
: String : String : String : String : int : int : String
+ + + +
adicionar () modificar () eliminar () li star ()
: void : void : void : void
1..*
Activo Fijo + + + 1..* + + +
Personal + + + + + + +
1..1
1..1 1..*
1..*
1..1
af_sigla af_descripcion af_costo af_estado af_fecha_ing af_observacion
Sub Rubro : String : String : float : int : Date : String
1..* 1..1
+ adicionar () : void + li star () : void
+ + + +
usu_nom usu_pasw usu_nivel usu_estado
: : : :
String String String String
+ + + +
adicionar () eliminar () li star () modificar ()
: void : void : void : void
+ adicionar () : void + eliminar () : void + listar () : void
1..1 Baja 1..1
1..* Revaluo
Usuario
+ sr_nom : String + sr_sigla : String
1..1
1..1
1..1
1..*
+ adicionar () : void + elimi nar () : void + listar () : void
1..1
1..1
1..1
+ adicionar () : void + listar () : void
rub_nom rub_sigla rub_añosVU rub_porcentajeDep
+ + + + +
rev_fech rev_valAF rev_estadoAF rev_obs rev_codTC
: date : float : int : String : int
+ adicionar () : void + listar () : void
+ baja_fecha : Date + baja_obs : String + adicionar () : void + listar () : void
1..* Reasignacion + + + +
reasig_fecha reasig_nom reasig_codAF reasig_codRes
: Date : String : int : int
+ adicionar () : void + listar () : void
Fuente: Elaboración Propia.
: String : String : int : int
3.3.2.5 Transformación del Modelo OO al Modelo E-R El proceso de transformación del diagrama de clases definido para el sistema de información SISCAFW se detalla a continuación: Figura 3.26: Diagrama Entidad Relación del sistema SISCAFW
unid_cod area_cod unid_nom inid_sigla
integer integer long varchar long .varchar
ad_cod af_cod ad_fecha_ini ad_fecha_fin valor_ant valor_act val_dep
integer integer date date float float float
Sub Programa
Programa prog_cod unid_cod prog_nom prog_sigla .
ActDep
Area . area_cod integer area_nom long varchar area_sigla long varchar
Unidad
sprog_cod prog_cod sprog_nombre sprog_sigla
integer . integer long varchar long varchar
Personal Programa
. Personal SubProg
prog_cod integer per_cod integer perp_cod integer
per_cod integer sprog_cod integer . per_sp_cod integer
.
Personal
per_cod per_pat per_mat per_nom per_dir per_tel per_cel per_cargo
integer long varchar long varchar long varchar long varchar integer integer long varchar
Tipo Cambio
integer integer long varchar integer .
tc_cod integer tc_fech date tc_val float .
Activo Fijo af_cod sr_cod tc_cod sprog_cod baja_cod af_sigla af_descripcion af_costo af_estado. af_fecha_ing
integer integer integer integer integer long varchar long varchar float integer date
Usuario
.
integer integer long varchar long varchar long varchar long varchar
rub_cod rub_nom rub_sigla rub_añosVU rub_porcentajeDep .
. .
Sub Rubro sr_cod rub_cod sr_nom sr_sigla
integer integer long varchar long varchar
. Baja baja_cod integer baja_fecha datetime baja_obs long varchar Revaluo
usu_cod per_cod usu_nom usu_pasw usu_nivel usu_estado
Rubro
rev_cod rev_fech rev_valAF rev_estadoAF rev_obs rev_codTC af_cod
integer date float integer long varchar integer integer
Reasignacion reasig_cod reasig_fecha reasig_nom reasig_codAF reasig_codRes af_cod
Fuente: Elaboración Propia
integer date long varchar integer integer integer
integer long varchar long varchar integer integer
3.3.3 Modelo de Despliegue del Sistema 3.3.3.1 Definición del Diagrama de Componentes El siguiente diagrama muestra la disposición de las partes integrantes del sistema de información SISCAFW y las dependencias entre los distintos módulos de la aplicación, donde se muestra el diagrama global de paquetes. Figura 3.27: Diagrama de Componentes del sistema SISCAFW RegistroAF.php
RegistroAF.html
Reasignacion.html
Reasignacion.php
<> DepAct.html
DepAct.php
Revaluo.html
Revaluo.php
Baja.html
Baja.html
ActivosFijos.html
<>
Index.html
MenuUsuario.html
<>
AdminInstitucion.html
AdminInstitucion.php
<> Rubro.html
Rubro.php
SubRubro.html
SubRubro.php
Rubro.html
Responsable.html
Responsable.php
<
Financiador.html
Financiador.php
Usuario.html
Usuario.php
Reportes.html
Reportes.php
TipoCambio.html
TipoCambio.html
Fuente: Elaboración Propia
3.3.3.2 Definición del Diagrama de Despliegue El sistema de información SISCAFW se implementa en un entorno de Red con un servidor central y las distintas terminales correspondientes a: la unidad de activos fijos, coordinador de programa, funcionario de subprograma.
Figura 3.28: Diagrama de Despliegue del sistema SISCAFW
PC3: B rowser
PC1: B rowser
PC2: Browse
Mod em: Acceso a Internet
I N T E R N E T
Servidor: PC <> BD_SISCAFW Mode m: Acceso a Internet.
SISCAFW: Me nu d e Usuario
Fuente: Elaboración Propia
3.4 FASE DE CONSTRUCCION En la fase de construcción las clases de la fase de diseño son convertidas a código fuente en un lenguaje de programación.
3.4.1 Implementación de Interfaces Las interfaces de del sistema para interactuar con el usuario se especifican a continuación:
Figura 3.29: Interface de Ingreso al Sistema SISCAFW.
Fuente: Elaboración Propia Es la Pantalla inicial del ingreso al sistema el cual visualiza cualquier persona que acceda a este sistema mediante un navegador. Figura 3.30: Interface del Menú Principal del Encargado de la Unidad de AF.
Fuente: Elaboración Propia. La presente pantalla es el menú principal del encargado de Activos Fijos, el cual puede acceder después de haberse autenticado.
Figura 3.31: Interface de Registro de Activo Fijo.
Fuente: Elaboración Propia. Esta pantalla permite al Encargado de AF el registro de un nuevo Activo Fijo a un subprograma y la asignación a un responsable, considerando la generación automática del código identificador del AF a partir de las características de: ubicación (Área, Unidad, Programa y Sub Programa) y clasificación (Rubro y Sub Rubro). Las interfaces restantes se encuentran en el Anexo D.
3.5 FASE DE TRANSICION El objeto de esta fase se compone en transferir a los usuarios el sistema, luego de haber concluido con la fase de implementación y después de haber realizado las pruebas necesarias, dado que el mismo está en fusión a las necesidades de los usuarios y al ambiente de la Fundación La Paz, listo para experimentarlo y dejar que manipulen el sistema con datos y actividades reales. Una vez entregado el producto se espera a ver si el usuario no tiene ningún problema con el manejo y adaptación del sistema.
a) Interfaz de Ingreso al Sistema
Este es el código para la validación del ingreso al sistema cuando el introduce su nombre de usuario y contraseña existe($fecha); if($num==0) { header ("Location: TipoCambio/administradorTC.php");} else { header ("Location: Administrador/administrador.php");} } else {if($_SESSION['usuNivel']==2) { header ("Location: Coordinador/coordinador.php");} else{if($_SESSION['usuNivel']==3) {header ("Location: DirectorASE/director.php");} else{if($_SESSION['usuNivel']==4) { header ("Location: OtherUsers/otheruser.php");} else{if($_SESSION['usuNivel']==5) { header ("Location: AdminBD/adminbd.php");} else{ $msg="EL usuario no tiene permiso de ingreso"; header ("Location: index.php?msg=".$msg.""); } } } } } }
else {
$msg="EL usuario fue dado de Baja"; header ("Location: index.php?msg=".$msg."");
} } while ($f = mysql_fetch_array($res));
} else { } ?>
$msg="EL usuario no está registrado"; header ("Location: index.php?msg=".$msg."");
b) Interfaz de Registro de Activo Fijo
Este es el código para el registro del activo fijo, en donde se puede evidenciar el manejo de clases para realizar este proceso, incluyendo el archivo “clases.php”
donde se encuentran declaradas las clases que nos permitan: inserción, actualización, eliminación y consulta de la administración de la información almacenada en la Base de Datos.
$afAmb=trim($_GET['ubicacion']); $afCodSP=trim($_GET['spCod']); $afCodSR=trim($_GET['srCod']); $afCodRes=trim($_GET['resCod']); $afCodFin=trim($_GET['finCod']); $afObs=trim($_GET['obs']); $fAVU=$objSR->mostrar_rub_subrub($afCodSR); $numAVU=$fAVU['rubAVU']*12; $valest=$afEst-1; $valrestar=$numAVU/6; $afMesVidUti=$numAVU-($valest*$valrestar); $numTC=$objTC->existe($afFecIng); $fTC=$objTC->mostrar_codTC($afFecIng); $afCodTC=$fTC['tcCod']; if($objAF>insertar(array($afSig,$afDes,$afVal,$afFecIng,$afMesVidUti,$afEst,$afAmb,$afCodSP,$afCodSR, $afCodTC,$afCodRes,$afCodFin,$afObs)) == true) { $error='0'; header ("Location: ingresarAF.php?error=".$error.""); } else { $error='1'; header ("Location: ingresarAF.php?error=".$error.""); } ?>
CAPITULO IV CALIDAD Y PRUEBAS
CAPITULO IV CALIDAD Y PRUEBAS 4.1 CALIDAD DE SOFTWARE 4.1.1 Introducción Se cuenta con herramientas para saber si nuestro sistema tiene calidad alta y baja, para tal efecto nos ayuda las medidas de calidad mostrándonos la calidad del software, siendo una compleja conjugación de índices y/o factores que varían para diferentes aplicaciones y los clientes que lo soliciten. Una evaluación de producto no es una tarea sencilla y puede ser difícil considerar todas las características y atributos deseables de una aplicación si no se cuenta con un modelo de calidad que permita especificar ordenadamente dichas características y atributos.
4.1.2 Funcionalidad Se cuantifica el tamaño y la complejidad del sistema en términos de las funciones de usuario, puede ser valorado mediante la medida de punto función, se determina cinco características del dominio de información, tomando en cuenta su cantidad. La métrica punto función se usa como medio para predecir el tamaño del sistema que se va a obtener por medio de análisis siendo una medida indirecta de software. Número de entradas de usuario Nos proporciona datos del sistema para poder así realizar distintas operaciones (Altas, bajas y modificaciones) con el objetivo de satisfacer las necesidades primordiales de una aplicación. Número de salidas de usuario Las salidas se usuario se refieren a informes por pantalla, mensajes de error brindando información orientada al sistema.
Número de peticiones Es una entrada interactiva que produce la generación de alguna respuesta de software en forma de salida interactiva. Número de Archivos Es un conjunto lógico de datos que puede ser parte de una gran base de datos o de archivos independientes. Número de interfaces Externas Es el numero de interfaces legibles por la maquina que se utilizan para transmitir información a otra máquina. Tabla 4.1: Cuenta total de entradas y salidas Entradas de Usuario Salidas de Usuario Peticiones de usuario Numero de archivos Interfaces Externas
21 23 13 15 5
Fuente: Elaboración Propia Tabla 4.2: Parámetros de Medición Parámetros de Medición Número de entradas de Número de salidas de usuario Número de peticiones de usuario Número de archivos Número de interfaces externas
Cuenta 21
Factor de Ponderación Total Simple Medio Complejo 3 4 6 84
23
4
5
7
115
13
3
4
6
52
15
7
10
15
150
5
5
7
10
35
Cuenta Total 436
Fuente: Elaboración Propia
Tabla 4.3: Valores de ajuste de la complejidad 0
1
2
3
4
5
No Influencia
Incidencia
Moderado
Medio
Significativo
Esencial
Fuente: Elaboración Propia Tabla 4.4: Ajuste de complejidad del punto función Factor 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Requiere el Sistema de copias de seguridad y de recuperación de datos fiables Se requiere de comunicación de datos Existen funciones de procesamiento distribuido Es crítico el rendimiento Se ejecuta el Sistema en un entorno operativo existente Requiere el Sistema la entrada de datos de forma interactiva, mostrando múltiples pantallas u operaciones. Se actualizan los archivos maestros de forma automática Son complejas la entradas, salidas o peticiones de usuario Es complejo el procesamiento interno Es compleja la utilización del Sistema Se ha diseñado en código para ser reutilizable Está incluida en el diseño la instalación Se ha diseñado para facilitar los cambios y sea de fácil uso para el usuario Se diseño el Sistema para soportar múltiples instalaciones en diferentes departamentos
Valor 5 4 4 5 5 4 3 3 3 3 4 4 4 5 56
Fuente: Elaboración Propia Para calcular puntos función:
Donde: Cuenta - Total=Suma de todas las entradas obtenidas 0.01=Error de confiabilidad de Sistema =Sumatoria de los factores de complejidad
Calculando: PF= 436 (0.65+0.01*56)= 527.56 PF Máximo= 436 (0.65+0.01*70)= 588.60
Funcionalidad = (PF / PF Máximo )*100 = (527.56/588.60)*100= 89% Entonces su funcionalidad del Sistema es de 89%
4.1.3 FACILIDAD DE MANTENIMIENTO La facilidad de mantenimiento está asociada a la detección y corrección de errores, a los cambios debido a los requerimientos del usuario a las adaptaciones requeridas a medida que evoluciona el software. El estándar IEEE982.1-1999 sugiere un índice de madurez del software (IMS) que proporciona una indicación de estabilidad de un producto software. La determinación de este indicador es como sigue a continuación: IMS
Mt
( Fa
Fc
Fd )
Mt
Reemplazando en la formula con los siguientes datos MT =9, Fa =1, Fc =0 y Fd =0, se tiene: IMS
9
(1 0 9
0)
0.889
Por lo tanto el índice de madurez del software indica que el Sistema es maduro en un 88.9% por estar próximo al 100%. Este valor significa, la capacidad posible en la facilidad del mantenimiento con la cual se pueda: corregir el sistema si es que se encuentra una falla, se necesite la adaptación a un entorno distinto o en el caso de que el cliente necesite algún cambio en la aplicación.
4.1.4 PORTABILIDAD De acuerdo a los factores de calidad “ la
portabilidad es el esfuerzo necesario para transferir una aplicación de un entorno Sistema Hardware y/o Software a otro ” [PRESS, 2005]. El sistema de información SISCAFW por estar diseñado para un entorno de acceso vía web, mide la portabilidad en: el lado del Servidor, y en el lado del
Cliente. La portabilidad del software se enfoca en tres aspectos: Hardware del Servidor, Sistema Operativo y Software Servidor. Hardware del servidor: Pentium IV o superior Velocidad 1 GHz o más Memoria RAM 256 MB o más Disco Duro 40 GB o más Sistema Operativo: Microsoft Windows: Win 9X, Win 2000, Win 2003, Win XP, Windows Vista, Windows 7. GNU Linux: Redhat, Fedora Core, Susse, Ubunt Software Servidor: Apache, MySQL y PH
Por lo mencionado anteriormente el sistema SISCAFW, es portable en sus diferentes entornos tanto en hardware y software por lo que se puede considerar una portabilidad del 100%.
4.1.5 USABILIDAD El estándar ISO-9126 define la Usabilidad como “ la capacidad de un producto de software de facilitar a usuarios específicos alcanzar metas especificas con eficacia, productividad, seguridad y satisfacción en un contexto especifico de uso ”. Añade que “calidad en uso es la visión de calidad de los usuarios de un ambiente conteniendo software y es medida sobre los resultados de usar el software en el ambiente, antes que las propiedades del software en sí mismo ”. El SISCAFW con relación a la usabilidad tiene la característica de ser compresible además de disponer de la facilidad de uso para los usuarios finales como el encargado de activos fijos u otro con privilegios limitados que cumplan funciones relacionadas con el manejo y gestión de activos fijos de la Fundación La Paz. La usabilidad y facilidad de uso se logro conforme se hacían las entregas del software en las cuales se han hecho las modificaciones necesarias conforme a las
peticiones del usuario en cuanto: a la interfaz y el manejo del sistema esto con la finalidad de facilitarle al usuario a alcanzar sus objetivos y metas especificas para realizar el control y seguimiento de activos fijos. La usabilidad es lo mismo decir facilidad de uso, esta métrica nos muestra el costo de aprender a manejar el producto, lo cual se calcula con la siguiente fórmula.
Donde: Es el puntaje de evaluación de cada pregunta Es el número de preguntas que se realizó Es el puntaje máximo que se da en la evaluación Tabla 4.5: Descripción de la escala de evaluación Descripción de la escala de Evaluación Pésimo 1 Malo 2 Regular 3 Bueno 4 Muy Bueno 5 Fuente: Elaboración Propia Se debe formular las siguientes preguntas: Tabla 4.6 Ajuste de Preguntas N°
Preguntas
Evaluación
1
¿El sistema satisface los requerimientos de manejo de información? ¿Las salidas del sistema están de acuerdo a sus requerimientos? ¿Cómo considera el ingreso de datos al sistema? ¿Cómo considera los formularios que elabora el sistema? ¿El sistema facilita el trabajo que realiza? TOTAL
4
2 3 4 5
Fuente: Elaboración Propia
5 4 4 5 22
Con los datos obtenidos remplazamos en la formula:
Por lo tanto concluimos que la facilidad de uso es de 88%.
4.2 PRUEBAS 4.2.1 Casos de Prueba Un Caso de Prueba es una especificación, usualmente formal, de un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados, identificados con el propósito de hacer una evaluación de aspectos particulares de un caso de uso determinado. Figura 4.1: Caso de Prueba Registrar Activo Fijo Caso de Prueba de Aceptación Código Caso de Prueba:01
Código Caso de Uso:01
Descripción de la Prueba: Registrar Activo Fijo. Registra los datos del Activo asignándole un código, el mismo que es generado de forma automática al seleccionar la ubicación del mismo y también seleccionando el rubro y sub rubro al cual corresponde. Además de introducir la información relevante del activo fijo de la incorporación de un activo fijo. Condiciones de Ejecución: Debe encontrarse de la pantalla principal haber elegido del menú la opción de Activo Fijo, Registrar Entrada / Pasos de Ejecución: Elegir la opción de ubicación (Área, Unidad, Programa, Sub Programa). Se desplegará los rubros y sub rubros que pertenecen a esta ubicación. Elegir el rubro y sub rubro al cual pertenece el Activo Fijo. Introducir los datos de Precio, Estado, Financiador, fecha de ingreso, responsable, ubicación y observación Presionar el botón “Incorporar”. Aparece un mensaje de Confirmación. Presionar el botón “Aceptar”.
Resultado Esperado: Registra la incorporación del Activo Fijo en la Base de Datos. Evaluación de la Prueba: El registro de la incorporación del Activo Fijo es satisfactoria.
Fuente: Elaboración Propia
Figura 4.2: Caso de Prueba Registrar Activo Fijo Caso de Prueba de Aceptación Código Caso de Prueba:02
Código Caso de Uso:02
Descripción de la Prueba: Registrar Tipo de Cambio. Al ingresar al sistema podrá visualizar una ventana emergente en donde el podrá registrar el tipo de cambio a la fecha actual. Condiciones de Ejecución: Debe ser la primera vez que ingresa al sistema en el día el encargado de Activos Fijos y haberse identificado como usuario. Entrada / Pasos de Ejecución: Aparece asignado la fecha actual. Ingresar el tipo de cambio de la moneda y la observación. Pulsar el botón “Registrar” para el ingreso de tipo de cambio a la fecha actual.
Una vez confirmado el registro del tipo de cambio se tiene acceso al sistema SISCAFW. Resultado Esperado: Registra el tipo de cambio en la base de datos. Tiene el acceso al menú principal del sistema el encargado de Activos Fijos . Evaluación de la Prueba: El registro del tipo de cambio es satisfactorio.
Fuente: Elaboración Propia
4.2.2 Pruebas de Caja Blanca Para las pruebas de caja blanca se utilizara la métrica de McCabe para hallar la complejidad ciclomática V(G), el cual nos permite determinar el número de casos de prueba que debe ejecutarse para que con este resultado se pueda garantizar las sentencias de un determinado modulo. Se aplicara la prueba de caja blanca al procedimiento de Registro de Activos Fijos, cuya funcionalidad se la puede observar según el siguiente diagrama de flujo.
Figura 4.3: Diagrama de Flujo Registro de Activos Fijos. INICIO
Datos del usuario
No
Verificar Autenticacion y Privilegios
Si
Datos del AF, Ubicacion y Responsable
Mensaje de Error
No Comprobar Datos
Verificar Datos Si Confirmacion de Registro
Verificar Confirmacion
Si Almacenar Datos
No Mensaje Datos Registrados
FIN
Fuente: Elaboración Propia.
Figura 4.4: Grafo de Flujo Registro de Activos Fijos.
Figura 4.5: Grafo de Flujo Simplificado de Activos Fijos.
Fuente: Elaboración Propia.
Fuente: Elaboración Propia. Según el grafo de flujo presentado en la figura 4.3 se procede al cálculo de la complejidad ciclomática en función de la siguiente relación:
Reemplazando con los siguientes datos: n=3 se tiene:
Este resultado determina el número de caminos independiente a seguir para llevar a cabo los casos de prueba: Camino 1: 1-2-8-9-10. Camino 2 : 1-2-3-4-5-7-9-10. Camino 3 : 1-2-3-4-3-5-6-7-9-10. Camino 4 : 1-2-3-4-5-6-7-9-10.
Caso de Prueba del Camino 1 (1-2-8-9-10). El usuario que ingresa al sistema deberá tener el privilegio de encargado o coordinador, para realizar el respectivo registro de activos caso contrario no se le permite el ingreso al procedimiento y se le muestra el mensaje de operación restringida. Caso de Prueba del Camino 2 (1-2-3-4-5-7-9-10). El usuario que tiene los privilegios para realizar el registro de activos deberá introducir los datos correspondientes del bien a registrar caso contrario se le notificara el dato faltante. Caso de Prueba del Camino 3 (1-2-3-4-3-5-6-7-9-10). El usuario con privilegios para realizar el registro de activo fijo además de haber introducido los datos correspondientes al bien deberá confirmar el almacenamiento y registro de los datos en caso de no realizar este evento se le desplegara un mensaje señalando que no se almacenaron los datos. Caso de Prueba del Camino 4 (1-2-3-4-5-6-7-9-10). El usuario con privilegios para realizar el registro de activo fijo y que a través de la interfaz de usuario introdujo y selecciono lo datos correspondientes al bien y además efectuó la confirmación del almacenamiento y registro de los datos, el sistema despliega un mensaje indicando que los datos fueron almacenados correctamente. La verificación de cada camino comprueba la finalidad y el objetivo con el cual fue diseñado desde el punto de vista lógico, es decir, la comprobación de cada camino devolverá un valor de verdadero o falso.
4.2.3 Pruebas de Caja Negra Las pruebas de caja negra demuestran la funcionalidad operativa del sistema por lo tanto estas pruebas de caja negra se aplican conforme el “ Sistema de Información web para el Seguimiento y Control de Activos Fijos ” se va construyendo. Esto lo podemos realizar mediante las pruebas de corrida del programa realizadas para verificar el funcionamiento correcto de cada uno de los módulos del sistema, al finalizar el desarrollo de los mismos. En el presente proyecto las pruebas de caja negra se las realiza bajo los siguientes niveles: Pruebas Unitarias , que se las realiza en el momento de desarrollar cada uno de los módulos del sistema SISCAFW. Pruebas de Integración , esta prueba se realiza cuando todos los módulos están desarrollados para luego integrarlos y posteriormente realizar la prueba general del sistema. Pruebas del Sistema , una vez integrados todos los módulos se procede a la prueba del sistema con datos e información real de la empresa. Pruebas de Implantación , para esta prueba es importante contar con los requisitos de hardware y software descritos en los anteriores puntos. Se planifica un periodo de 20 a 30 días posteriores a la implantación para evaluar la evolución del sistema. Pruebas de Aceptación , pasado el periodo de prueba se espera la aceptación del nuevo sistema de información SISCAFW por parte de los funcionarios de la Fundación La Paz. La funcionalidad del sistema se ha corroborado con las pantallas de corrida que se muestran en anteriores puntos.
CAPITULO V CONCLUSIONES Y RECOMENDACIONES
CAPITULO V CONCLUSIONES Y RECOMENDACIONES 5.1 CONCLUSIONES El “Sistema
de Información Web para el Seguimiento y Control de Activos Fijos: Fundación La Paz ”, llego a su conclusión de forma satisfactoria, cumpliendo con todos los requisitos especificados en la etapa de análisis, dando lugar así al cumplimiento de su objetivo principal.
Al obtener el producto final, se ha logrado construir una Base de Datos para el sistema antes ya mencionado, el cual logra cumplir con uno de los objetivos específicos. Se puede afirmar que la implementación del presente sistema, ha mejorado el desempeño en la Unidad de Activos Fijos de la Fundación La Paz, es decir mejoro la gestión de Activos Fijos en cuanto a: la incorporación, baja, reasignación, revaluó, actualización y depreciación de Activos Fijos. Por otra parte el “ Sistema
de Información Web para el Seguimiento y Control de Activos Fijos: Fundación La Paz” presenta ventajas en cuanto a: Tiempo de respuesta óptimo en cada proceso. Bajos costos y tiempo reducido en la obtención de reportes. o
o
Tomando en cuenta a la seguridad del sistema en un determinado nivel, se ha implementado una interface de autentificación y control para el ingreso de usuarios, en donde se tiene restricciones a los módulos, para determinados usuarios del sistema. El logro de los objetivos tanto general y espec í ficos se debe tambi én a la colaboración que nos brinda el empleo del Proceso Unificado de Racional (RUP) para un enfoque detallado, claro y eficiente del an álisis diseño, modelado y construcción del SISCAFW. Dando lugar a un modelado preciso de acuerdo a los requerimientos identificados, dicho modelado se logro gracias al empleo del Lenguaje Unificado de Modelado (UML).
De esta manera se concluye que todos los objetivos mencionados al inicio del proyecto han sido cumplidos en su totalidad.
5.2 RECOMENDACIONES Como recomendaciones del presente proyecto que ayuden al mejoramiento y proporcionen mayores funcionalidades a los usuarios del sistema, se plantean las siguientes recomendaciones: Se deberán implementar los vínculos necesarios para la interacción de los ítems existentes en almacenes con los activos fijos que se manejan con el presente proyecto.
En cuanto al sistema desarrollado SISCAFW se recomienda realizar la capacitación al usuario respectivo encargado del manejo de activos fijos, esto para el buen manejo de la información de valor y del propio sistema. Además es recomendable realizar una evaluación constante con el fin de garantizar la fiabilidad de la misma, realizar un mantenimiento preventivo y de adaptación del sistema con el fin de mejoras funcionales y adaptación del software a su entorno. Se recomienda al usuario del sistema cambiar su contraseña, para no sufrir ningún contratiempo al momento de ingreso al sistema, ya que existe el riesgo de que esta contraseña sea descubierta. En consideración a ello es necesario el cambio de la contraseña en un intervalo de tiempo corto (mensual, semestral) para una mayor seguridad.
BIBLIOGRAFIA
BIBLIOGRAFÍA [JACOB, 2000]
Jacobson, I., Booch, G. y Rumbaugh, J., “El Proceso Unificado de Desarrollo de Software”, Pearson Educación,
Madrid, 2000. [BOOCH,1999]
Booch, G., Rumbaugh, J. y Jacobson, I., “El Lenguaje Unificado de Modelado”, Addison Wesley
Iberoamericana,
Madrid, 1999. [RUMBA, 2000]
Rumbaugh, J., Jacobson, I. y Booch, G., “El Lenguaje Unificado de Modelo. Manual de Referencia”, Pearson
Educación, Madrid, 2000. [LARMAN, 1999] Larman, G., “UML y Patrones. Introducción al análisis y diseño orientado a objetos”, Prentice Hall, México, 1999. [SILBE, 1998]
Silberschatz, A., Korth S. y Sudarshan S., “Fundamentos de Bases de Datos”, 3ª ed., McGraw -Hill, Madrid, 1998.
[BOWEN, 2000]
Bowen, R. y Coar, K., “Servidor Apache al Descubierto”,
Pearson Educación, Madrid, 2000. [FUNES, 2003]
Funes, J., “Contabilidad Intermedia”, Sabiduría, Bolivia, 2003.
[PRESS, 2005]
Pressman, R. S., “Ingeniería del Software. Un enfoque práctico”, 5ª ed., McGraw -Hill, 2003.
[FLP, 2006]
Reglamento para el Control de Activo Fijo de la Fundación La Paz, 2006.
[RUEDA, 2006]
Rueda Chacón Julio C., “Aplicación de la metodología RUP
para el Desarrollo Rápido de Aplicaciones basado en el Estándar J2EE”, Guatemala, 2006.
[FOWLER, 1999]
Fowler Martin, Kendall Scott, “UML Gota a Gota”,
Educación, México, 1999.
Pearson
[NBSABS, 2000] Decreto Supremo No. 25964 Normas Básicas del Sistema de Administración de Bienes y Servicios (NB-SABS). [RESABS, 2003] Reglamento Específico del Sistema de Administración de Bienes y Servicios (RE-SABS). [SAFCO, 1990]
Ley de Administración y Control Gubernamentales (Ley 1178, SAFCO).
REFERENCIAS WEB “Diseño de Interfaces”
http://www.imageandart.com/tutoriales/web_design/diseno_interfaces/index.html “Componentes de una Interfaz Web”
http://www.desarrolloweb.com/manuales/64/ “Herramientas de Desarrollo para PHP”
http://www.ribosomatic.com/articulos/ “Sistema de Autentificación PHP”
http://www.desarrolloweb.com/manuales/37/ “Código PHP para Múltiples utilidades”
http://www.forosdelweb.com “Consultas más utilizadas en MySQL”
http://blog.aplicacionesweb.cl/2008/06/24/mysql-consultas-mas-usadas/ “Manual de Taller de CSS”
http://www.desarrolloweb.com/manuales/63/
ANEXOS
ANEXO A ESTRUCTURA ORGÁNICA
ANEXO B ANEXO DEL CAPITULO 22°DECRETO SUPREMO 24051 DEPRECIACIONES DEL ACTIVO FIJO
ANEXO B ANEXO DEL CAPITULO 22°DECRETO SUPREMO 24051 DEPRECIACIONES DEL ACTIVO FIJO
ANEXO C
DECRETO SUPREMO N ° 29190 EVO MORALES AYMA PRESIDENTE CONSTITUCIONAL DE LA REPÚBLICA TÍTULO III SUBSISTEMA DE MANEJO DE BIENES CAPÍTULO I ASPECTOS GENERALES
ARTÍCULO 75.- (CONCEPTO). El Subsistema de Manejo de Bienes, es el conjunto interrelacionado de principios, elementos jurídicos, técnicos y administrativos que regulan el manejo de bienes de propiedad de la entidad y los que se encuentran bajo su cuidado o custodia. Tiene por objetivo optimizar la disponibilidad, el uso y el control de los bienes y la minimización de los costos de sus operaciones. ARTÍCULO 76.- (ALCANCE). Las presentes Normas Básicas se aplicarán para el manejo de bienes de uso y consumo institucional de propiedad de la entidad y los que estén a su cargo o custodia. El manejo de bienes de los productos que sean resultado de servicios de consultorías, software y otros similares, serán regulados en la reglamentación de las presentes Normas Básicas. ARTÍCULO 77.- (EXCEPCIONES). Se encuentran fuera del alcance de las presentes Normas Básicas: a) Los bienes de dominio público. b) El material bélico de las Fuerzas Armadas. c) Los bienes declarados patrimonio histórico y cultural. El manejo de estos bienes estará sujeto a reglamentación especial, que podrá tomar como referencia el contenido de las presentes Normas Básicas en las partes afines a su operación y control. ARTÍCULO 78.- (COMPONENTES). Los componentes del Subsistema de Manejo, son los siguientes: a) Administración de almacenes. b) Administración de activos fijos muebles. c) Administración de activos fijos inmuebles. ARTÍCULO 79.- (RESPONSABILIDAD POR EL MANEJO DE BIENES). I. El responsable de la Unidad Administrativa, es el responsable principal ante la Máxima Autoridad Ejecutiva: a) Por el manejo de bienes en lo referente a la organización, funcionamiento y control de las unidades operativas especializadas en la materia, por el cumplimiento de la normativa vigente, por el desarrollo y cumplimiento de reglamentos, procedimientos, instructivos y por la aplicación del régimen de penalizaciones por daño, pérdida o utilización indebida. b) Por la adecuada conservación, mantenimiento y salvaguarda de los bienes que están a cargo de la entidad. c) Porque la entidad cuente con la documentación legal de los bienes que son de su propiedad o estén a su cargo, así como de la custodia y registro de esta documentación en las instancias correspondientes. d) En caso necesario, solicitará a la Unidad Jurídica de la entidad el saneamiento de la documentación legal pertinente. e) Por el envío de la información sobre los bienes de la entidad al Servicio Nacional de Patrimonio del Estado - SENAPE. II. Los responsables de almacenes, activos fijos, mantenimiento y salvaguarda de bienes, deben responder ante el responsable de la Unidad Administrativa por el cumplimiento de las normas,
reglamentos, procedimientos y/o instructivos establecidos para el desarrollo de sus funciones, así como por el control, demanda de servicios de mantenimiento y salvaguarda de estos bienes. III. Todos los servidores públicos son responsables por el debido uso, custodia, preservación y demanda de servicios de mantenimiento de los bienes que les fueren asignados, de acuerdo al régimen de Responsabilidad por la Función Pública, establecido en la Ley 1178 y sus reglamentos. ARTÍCULO 80.- (INCLUSIÓN EN EL PROGRAMA DE OPERACIONES). Las actividades y tareas inherentes al manejo de bienes deben estar incluidos en el POA, para asegurar que su desarrollo se efectúe en función de los objetivos de gestión de la entidad. ARTÍCULO 81.- (CONTROLES ADMINISTRATIVOS). I. El control es el proceso que comprende funciones y actividades para evaluar el manejo de bienes, desde su ingreso a la entidad hasta su baja o devolución, utilizando los registros correspondientes como fuente de información. Para efectuar este control, la Unidad Administrativa debe: a) Realizar inventarios y recuentos periódicos, planificados o sorpresivos. b) Verificar la correspondencia entre los registros y las existencias. c) Verificar las labores de mantenimiento y salvaguarda. d) Verificar la existencia de la documentación legal y registro de los bienes. II. Para la elaboración de la información relacionada con el manejo de bienes, se utilizarán registros e informes. a) Los registros permanentemente actualizados y debidamente documentados permitirán: i. Verificar fácil y rápidamente la disponibilidad de los bienes. ii. Evaluar el curso y costo históricos de los bienes. iii. Conocer su identificación, clasificación, codificación y ubicación. iv. Conocer las condiciones de conservación, deterioro, remodelaciones, etc., así como las de tecnología y obsolescencia en que se encuentran los bienes. v. Verificar la documentación legal sobre la propiedad y registro de los bienes de la entidad, así como de los asignados, alquilados, prestados, etc., a cargo de la institución. vi. Establecer responsabilidad sobre el empleo de los bienes y la administración de las existencias. b) Los informes permitirán describir y evaluar la situación de los bienes en un momento dado. ARTÍCULO 82.- (TOMA DE INVENTARIOS). I. La toma de inventarios es el recuento físico de los bienes de uso y consumo institucional, que será realizado en las entidades para actualizar la existencia de los bienes por cualquiera de los métodos generalmente aceptados. II. Las entidades públicas desarrollarán reglamentos, procedimientos y/o instructivos para el recuento físico de los bienes de consumo, activos fijos muebles y activos fijos inmuebles, en los que considerarán inventarios periódicos, planificados y sorpresivos, con los objetivos de: a) Establecer con exactitud la existencia de bienes en operación, tránsito, arrendamiento, depósito, mantenimiento, desuso, inservibles, sustraídos, siniestrados, en poder de terceros. Identificando además fallas, faltantes y sobrantes. b) Proporcionar información sobre la condición y estado físico de los bienes. c) Ser fuente principal para realizar correcciones y ajustes, establecer responsabilidades por mal uso, negligencia y descuido o sustracción. d) Verificar las incorporaciones y retiros de bienes que por razones técnicas o de otra naturaleza no hubieran sido controlados. e) Considerar decisiones que mejoren y modifiquen oportunamente deficiencias en el uso, mantenimiento y salvaguarda de los bienes. f) Comprobar el grado de eficiencia del manejo de bienes de uso. g) Generar información básica para la disposición de bienes. h) Programar adquisiciones futuras. ARTÍCULO 83.- (BIENES ADQUIRIDOS CON FINANCIAMIENTO EXTERNO).
Para el manejo de bienes adquiridos con financiamiento externo, se utilizarán los Reglamentos Específicos de las entidades y las presentes Normas Básicas, si el convenio de financiamiento no dispone lo contrario. ARTÍCULO 84.- (BIENES DONADOS O TRANSFERIDOS). I. Los bienes de uso o consumo que perciba una entidad por concepto de donación y/o transferencia, deberán ser recibidos por la Comisión de Recepción conformada de acuerdo al Artículo 16 de las presentes Normas Básicas, la misma que debe levantar un acta detallando el tipo de bien, cantidad y especificaciones técnicas de los mismos. II. El responsable de almacenes o el responsable de activos fijos debe adjuntar copia del convenio de donación o transferencia y acta de recepción, al documento de ingreso a almacenes o activos fijos, según corresponda, continuando con los procedimientos regulados en las presentes Normas Básicas. CAPÍTULO III ADMINISTRACIÓN DE ACTIVOS FIJOS MUEBLES ARTÍCULO 104.- (CONCEPTO). La administración de activos fijos muebles, es la función administrativa que comprende actividades y procedimientos relativos al ingreso, asignación, mantenimiento, salvaguarda, registro y control de bienes de uso de las entidades públicas. ARTÍCULO 105.- (OBJETIVO). Tiene por objetivo lograr la racionalidad en la distribución, uso y conservación de los activos fijos muebles de las entidades públicas. ARTÍCULO 106.- (ALCANCE). Las disposiciones contenidas en este Capítulo, se aplicarán a todos los activos fijos muebles de propiedad de la entidad y los que estén a su cargo o custodia. ARTÍCULO 107.- (ORGANIZACIÓN PARA LA ADMINISTRACIÓN DE ACTIVOS FIJOS MUEBLES). I. Las entidades crearán una unidad especializada en la administración de activos fijos, si la magnitud de estos lo amerita. En caso de no existir una unidad especializada, se debe asignar la función a un servidor público determinado. II. La organización de las actividades de activos fijos muebles estará basada en las características de las operaciones de distribución, salvaguarda, mantenimiento y control de los bienes de uso. III. En caso necesario, se utilizarán depósitos y bodegas, bajo responsabilidad de la unidad o el servidor público responsable de activos fijos. Las bodegas y depósitos deberán tener las condiciones indispensables que faciliten el movimiento de los bienes y garanticen su seguridad. IV. En cada entidad, la Unidad Administrativa desarrollará procedimientos y/o instructivos relativos a la administración de activos fijos muebles. ARTÍCULO 108.- (RECEPCIÓN). I. La recepción de estos bienes para su incorporación al activo fijo de la entidad, será realizada por la unidad o responsable de activos fijos, aplicándose de manera similar las normas sobre recepción de bienes a almacenes, reguladas en los Artículos 89 y 90 de las presentes Normas Básicas. II. La recepción de bienes a cargo de la entidad o bajo su custodia, debe estar respaldada por los documentos de asignación, préstamo de uso, alquiler o arrendamiento, etc. ARTÍCULO 109.- (ASIGNACIÓN DE ACTIVOS FIJOS MUEBLES). I. La asignación de activos fijos muebles es el acto administrativo mediante el cual se entrega a un servidor público un activo o conjunto de estos, generando la consiguiente responsabilidad sobre su debido uso, custodia y mantenimiento. II. La entrega de activos fijos muebles a los servidores públicos sólo podrá ser realizada por la unidad o responsable de activos fijos, la misma que procederá cuando exista orden documentada y autorizada por instancia competente establecida en el Reglamento Específico. ARTÍCULO 110.- (DOCUMENTO DE ENTREGA).
I. La constancia de entrega de un bien se realizará en forma escrita, en la que el servidor público receptor exprese su conformidad mediante firma. II. La unidad o responsable de activos fijos, debe mantener registros actualizados de los documentos de entrega y devolución de activos. ARTÍCULO 111.- (LIBERACIÓN DE LA RESPONSABILIDAD). I. Para ser liberado de la responsabilidad, el servidor público deberá devolver a la unidad o responsable de activos fijos, el o los bienes que estaban a su cargo, debiendo recabar la conformidad escrita de esta unidad o responsable. Mientras no lo haga, estará sujeto al régimen de Responsabilidad por la Función Pública, establecida en la Ley 1178 y sus reglamentos. II. El servidor público será responsable por el debido uso, custodia y mantenimiento, de los bienes a su cargo, mientras se encuentre en instalaciones de la entidad pública, prestando servicios. III. El área Administrativa, es responsable de ejecutar las acciones necesarias para proporcionar los mecanismos idóneos para asegurar la custodia de los bienes asignados a los servidores públicos. ARTÍCULO 112.- (CODIFICACIÓN). I. Para controlar la distribución de los bienes, la Unidad de Activos Fijos adoptará sistemas de identificación interna, mediante códigos, claves o símbolos que: a) Permitan la identificación, ubicación y el destino del bien. b) Discriminen claramente un bien de otro. c) Diferencien una unidad de las partes que la componen. d) Sea compatible con el sistema contable vigente en la entidad. e) Faciliten el recuento físico. II. La codificación de activos fijos muebles, debe basarse en normas nacionales y en ausencia de éstas en normas internacionales. ARTÍCULO 113.- (INCORPORACIONES AL REGISTRO DE ACTIVOS FIJOS MUEBLES). La incorporación de bienes muebles al activo fijo de la entidad, consiste en su registro físico y contable. Se producirá después de haber sido recepcionados por el responsable de activos fijos o por la comisión de recepción. ARTÍCULO 114.- (REGISTRO DE ACTIVOS FIJOS MUEBLES). La unidad o responsable de activos fijos, debe crear y mantener actualizado un registro de todos y cada uno de los activos fijos muebles de propiedad, a cargo o en custodia de la entidad. Este registro debe considerar como mínimo: a) La existencia física debidamente identificada, codificada y clasificada. b) La documentación que respalda su propiedad o tenencia. c) La identificación del usuario y dependencia a los que está asignado. d) El valor del bien, depreciaciones y revalorizaciones. e) Reparaciones, mantenimientos, seguros, etc. f) La disposición temporal. g) La disposición definitiva y baja, de acuerdo al Subsistema de Disposición de Bienes. ARTÍCULO 115.- (REGISTRO DEL DERECHO PROPIETARIO). I. Los activos fijos muebles como los vehículos y otros motorizados deben registrar su derecho propietario a nombre de la entidad en las instancias correspondientes, labor que estará a cargo de la Unidad Administrativa de cada entidad en coordinación con el asesor legal . II. La Unidad o responsable de activos fijos, deberá efectuar seguimiento y control sobre el saneamiento de la documentación legal de los vehículos y motorizados de la entidad, informando al responsable de la Unidad Administrativa. ARTÍCULO 116.- (MANTENIMIENTO DE ACTIVOS FIJOS MUEBLES). I. El mantenimiento, es la función especializada de conservación técnica que se efectúa a los activos, para que permanezcan en condiciones de uso.
II. El responsable de la Unidad Administrativa, debe establecer políticas y procedimientos de mantenimiento para promover el rendimiento efectivo de los bienes en servicio, evitando su deterioro incontrolado, averías u otros resultados indeseables que pongan en riesgo la conservación del bien. ARTÍCULO 117.- (DEMANDA DE SERVICIOS DE MANTENIMIENTO). Los servidores públicos que tienen asignado un bien serán responsables de demandar con la debida anticipación, servicios de mantenimiento preventivo para que estos sean previstos en el (POA) de cada entidad. ARTÍCULO 118.- (SALVAGUARDA DE ACTIVOS FIJOS MUEBLES). I. La salvaguarda es la protección de los bienes contra pérdidas, robos, daños y accidentes. II. El responsable de la Unidad Administrativa desarrollará procedimientos y/o instructivos para salvaguardar los activos fijos muebles de la entidad, delegando a la unidad o responsable de activos fijos la implantación de las medidas de salvaguarda. III. La unidad o responsable de activos fijos, en función del valor e importancia de los bienes de la entidad, tiene la obligación de: a) Solicitar la contratación de seguros para prevenir riesgos de pérdida económica. b) Fortalecer permanentemente los controles de seguridad física e industrial, para el uso, ingreso o salida de los bienes, dentro o fuera de la entidad, velando además porque éstos no sean movidos internamente, ni retirados sin la autorización y el control correspondiente. c) Formular y aplicar los reglamentos e instructivos específicos de seguridad física e industrial. IV. Las actividades y tareas de salvaguarda deben ser incorporadas por la Unidad Administrativa en el POA de cada entidad. ARTÍCULO 119.- (PROHIBICIONES SOBRE EL MANEJO DE ACTIVOS FIJOS MUEBLES). La unidad o responsable de activos fijos, está prohibido de: a) Entregar o distribuir bienes sin documento de autorización, emitido por autoridad competente. b) Aceptar documentos con alteraciones, sin firma, incompletos o sin datos inherentes al bien solicitado. c) Permitir el uso de bienes para fines distintos a los de la entidad. ARTÍCULO 120.- (PROHIBICIÓN PARA LOS SERVIDORES PUBLICOS SOBRE EL USO ACTIVOS FIJOS MUEBLES). I. Los servidores públicos quedan prohibidos de: a) Usar los bienes para beneficio particular o privado. b) Permitir el uso para beneficio particular o privado. c) Prestar o transferir el bien a otro empleado público. d) Enajenar el bien por cuenta propia. e) Dañar o alterar sus características físicas o técnicas. f) Poner en riesgo el bien. g) Ingresar bienes particulares sin autorización de la unidad o responsable de activos fijos. h) Sacar bienes de la entidad sin autorización de la unidad o responsable de activos fijos. II. La no observancia a estas prohibiciones generará responsabilidades establecidas en la Ley N ° 1178 y sus reglamentos. CAPÍTULO IV ADMINISTRACIÓN DE ACTIVOS FIJOS INMUEBLES ARTÍCULO 121.- (CONCEPTO). La administración de activos fijos inmuebles, es la función administrativa que comprende actividades y procedimientos inherentes al uso, conservación, salvaguarda, registro y control de edificaciones, instalaciones y terrenos. ARTÍCULO 122.- (OBJETIVO). La administración de activos fijos inmuebles tiene por objetivo lograr la racionalidad en el uso y conservación de las edificaciones, instalaciones y terrenos de las entidades públicas, preservando su integridad, seguridad y derecho propietario.
ARTÍCULO 123.- (ALCANCE). Las disposiciones de este Capítulo se aplicarán a todos los bienes inmuebles de propiedad de la entidad y los que están a su cargo o custodia. ARTÍCULO 124.- (ORGANIZACIÓN PARA LA ADMINISTRACIÓN DE ACTIVOS FIJOS INMUEBLES). I. El responsable de la Unidad Administrativa, delegará la administración de bienes inmuebles a la Unidad de Activos Fijos. En caso de no existir ésta, se asignará a un servidor público determinado. II. La unidad o responsable de activos fijos, debe cumplir y hacer cumplir las disposiciones establecidas para el efecto. III. La organización de las actividades de activos fijos inmuebles estará basada en las características de las operaciones de mantenimiento, salvaguarda y control de estos bienes. IV. Las entidades públicas desarrollarán procedimientos y/o instructivos para la administración de activos fijos inmuebles. ARTÍCULO 125.- (RECEPCIÓN DE INMUEBLES). I. La recepción de inmuebles para su incorporación al activo fijo será realizada por la Comisión de Recepción, conformada de acuerdo al Artículo 16 de las presentes Normas Básicas. II. Se realizará la recepción provisional, en forma obligatoria, en la misma que deberá verificarse e inventariar las instalaciones y ambientes que formen parte del inmueble, además de exigir toda la documentación técnica y legal del mismo. Desde la recepción provisional hasta la recepción definitiva, se evaluarán las condiciones técnicas del inmueble, debiendo además ejercitarse las garantías de evicción y vicios, de acuerdo a Ley. III. La recepción de un inmueble será definitiva cuando la comisión levante un acta en el que exprese su conformidad y sirva de recibo a quién entregó el bien. ARTÍCULO 126.- (INCORPORACIÓN AL REGISTRO DE ACTIVOS FIJOS INMUEBLES). La incorporación de bienes inmuebles al activo fijo de la entidad, consiste en su registro físico y contable, acompañado de la documentación técnico - legal de los mismos. Se producirá después de haber sido recibido en forma definitiva por la Comisión de Recepción. ARTÍCULO 127.- (REGISTRO DEL DERECHO PROPIETARIO). I. Todos los inmuebles que forman parte del patrimonio de la entidad deben estar registrados a su nombre en Derechos Reales y en el Catastro Municipal que corresponda, actividad que estará a cargo de la Unidad Administrativa de cada entidad en coordinación con el asesor legal. II. Permanentemente, la unidad o responsable de activos fijos de la entidad, deberá efectuar seguimiento y control sobre el saneamiento de la documentación técnico legal de los bienes inmuebles, informando al responsable de la Unidad Administrativa. ARTÍCULO 128.- (REGISTRO DE ACTIVOS FIJOS INMUEBLES). La unidad o responsable de activos fijos debe crear y mantener actualizado un registro de todos y cada uno de los bienes inmuebles de propiedad, a cargo o en custodia de la entidad. El registro debe considerar, según corresponda: a) Características del bien inmueble, consignando superficie, edificaciones, instalaciones, así como la historia de modificaciones, ampliaciones o reducciones que hubiera experimentado. b) Documentación legal del derecho propietario. c) Documentación técnica que acredite la situación del terreno, diseños, planos de construcción e instalaciones, planos de instalaciones sanitarias y eléctricas y otros que considere la entidad. d) Valor del inmueble, depreciaciones y revalorizaciones. e) Refacciones, mantenimientos, seguros, etc. f) Disposición temporal. g) Disposición definitiva y baja, de acuerdo al Subsistema de Disposición de Bienes. ARTÍCULO 129.- (ASIGNACIÓN DE INSTALACIONES Y AMBIENTES).
I. La asignación de instalaciones y ambientes a cada unidad de la entidad, así como su acondicionamiento para el cumplimiento de los objetivos de dichas unidades, es función de la Unidad Administrativa. II. La asignación estará en función de las demandas y características de la actividad que realiza cada unidad y de la disponibilidad de la entidad, evitando la subutilización del espacio, el hacinamiento, los riesgos por deterioro y los riesgos de accidentes. III. El Jefe de la Unidad a quien se le asignó el ambiente es el responsable principal por el debido uso de las instalaciones y la preservación de su funcionalidad. ARTÍCULO 130.- (MANTENIMIENTO DE INMUEBLES). El mantenimiento es la función de conservación técnica especializada que se efectúa a los bienes inmuebles para conservar su funcionalidad y preservar su valor. a) La Unidad Administrativa de cada entidad establecerá medidas para evitar el deterioro de los inmuebles y alteraciones que puedan afectar su funcionalidad, realizando inspecciones periódicas sobre el estado y conservación de los inmuebles. b) El responsable de la Unidad Administrativa, en coordinación con los jefes de las unidades que tengan asignados edificaciones o instalaciones deben prever en el POA las actividades y tareas necesarias para llevar a cabo el mantenimiento, destinado a conservar los bienes en condición de funcionalidad. ARTÍCULO 131.- (SALVAGUARDA). I. La salvaguarda es la protección de los bienes inmuebles contra daños, deterioro y riesgos por la pérdida del derecho propietario, tareas que deben ser previstas por la Unidad Administrativa, en el POA de cada entidad. II. El responsable de la Unidad Administrativa tiene la obligación de implantar medidas de salvaguarda, debiendo: a) Solicitar la contratación de seguros contra incendios, inundaciones, desastres naturales y los que la entidad considere pertinentes. b) Establecer medidas de vigilancia y seguridad física. c) Establecer medidas de seguridad industrial. d) Mantener saneada y resguardada la documentación técnico legal de los bienes inmuebles de la entidad. ARTÍCULO 132.- (INSPECCIONES Y CONTROL FISICO DE INMUEBLES). I. Es obligación de la Unidad de Activos Fijos realizar inspecciones periódicas sobre el estado y conservación de los inmuebles. II. Estas inspecciones deben permitir controlar y precisar la situación real de los inmuebles en un momento dado, y prever las decisiones que se deben tomar en el corto, mediano y largo plazo. ARTÍCULO 133.- (PROHIBICIONES SOBRE EL MANEJO DE ACTIVOS FIJOS INMUEBLES). La unidad o responsable de activos fijos está prohibido de: a) Entregar un inmueble a otra entidad sin un documento de arrendamiento u otra forma de disposición señalada en las presentes Normas Básicas. b) Usar los inmuebles para beneficio particular o privado. c) Permitir el uso del inmueble por terceros. d) Mantener inmuebles sin darle un uso, por tiempo indefinido.
ANEXO D Figura: Interface del Registro del Tipo de Cambio.
Fuente: Elaboración Propia Esta pantalla es la que aparece al encargado de Activos Fijos para el registro diario del tipo de cambio, una vez que este se haya autenticado en el sistema. Esta pantalla solo aparece una vez por día. Figura: Interface Ventana del Registro de Rubro
Fuente: Elaboración Propia. Esta pantalla permite al encargado de AF registrar el rubro del Activo Fijo.
Figura: Interface del Registro del Sub Rubro.
Fuente: Elaboración Propia. Esta pantalla permite registrar al encargado de AF el sub rubro de un Activo Fijo, correspondiente a un rubro. Figura: Interface del Registro de Sub Programa.
Fuente: Elaboración Propia. Esta pantalla permite registrar al encargado de AF los distintos sub programas de un determinado programa correspondiente a la unidad, a la que corresponde en el Área Socioeducativa
Figura: Interface del Registro de Responsable.
Fuente: Elaboración Propia. Esta pantalla permite registrar al encargado de AF a aquellas personas que serán los responsable de un Activo Fijo, dando a detalle a que subprograma corresponde.
ANEXO E GLOSARIO DE TERMINOS El glosario de términos define e incluye todos los términos además de una descripción textual de los elemento del modelo, esto para evitar que exista la posibilidad de ambigüedad en la comprensión de los términos utilizados. Se define la siguiente tabla de términos utilizados con el fin de registrar todos los términos usados en las fases siguientes: Activo Fijo TIPO Bien de uso con el cual se cuenta dentro de la institución, el cual sirve para el desarrollo de las actividades. Actualización de Activo CASO DE USO Es la valoración de un activo fijo de acuerdo a una determinada fecha y cotización desde su fecha de adquisición. Asignación de Activo CASO DE USO Es la asignación de un bien de uso al personal dentro de un sub programa. Depreciación de Activo CASO DE USO Es el cálculo de pérdida de valor que sufre un bien de uso a causa del uso que se le da conforme al tiempo ya transcurrido. Edificio TIPO Es un tipo de activo fijo Equipo de Computación TIPO Es un tipo de activo fijo Personal ACTOR Es una determinada persona física cuya relación es laboral dentro de la institución. Financiador ACTOR Es una determinada persona física cuya relación con la institución en la de donar o en su caso financiar económicamente la adquisición de bienes. Encargado de la Unidad de Activos Fijos ACTOR Es una determinada persona física cuya relación dentro de la institución es la de gestionar y controlar el manejo de bienes de la institución.
