UNIVERSIDAD MAYOR DE SAN ANDRS 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 TTULO DE LICENCIATURA EN INFORMTICA MENCION: INGENIERA DE SISTEMAS INFORMTICOS
Postulante : Tutor Revisor : : Enrique Richard Conde Canaviri Lic. Roberto Vargas Blacutt 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 formacin que me dieron para luchar en la vida. A mis hermanas, Martha y Brenda por su comprensin 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 ms 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 gua en todo momento.

A mi docente revisor

Lic. Ramiro Flores Rojas, por la amistad,

colaboracin, orientacin y sugerencias que me condujeron a la finalizacin del proyecto de grado.

Al encargado de la Unidad de Activos Fijos de la Fundacin La Paz, Sr. Jaime Zamudio por su colaboracin, confianza y la oportunidad de desarrollar el presente proyecto en dicha institucin.

A Sonia Tintaya Paredes quien fue la persona que estuvo siempre a mi lado y me acompao en todo momento y en circunstancias muy difciles.

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 Fundacin La Paz es una institucin privada, sin fines de lucro y de solidaridad que nace en el ao 1971 como Fundacin San Gabriel, la misma est dedicada a promover y fortalecer movimientos sociales, mediante procesos de organizacin, participacin y prestacin de servicios orientados a mejorar las condiciones y calidad de vida de la poblacin. Focaliza su accin en mujeres nios y nias por su acentuada situacin de pobreza, exclusin y discriminacin. El presente proyecto de grado titulado: Sistema de Informacin Web para el Seguimiento y Control de Activos Fijos: Fundacin La Paz, propone mejorar la administracin de los Activos Fijos de la fundacin, aprovechando el potencial de comunicacin que proporciona Internet. El control que se le da en la Unidad de Activos Fijos no es el apropiado, ya que estos procesos (incorporacin del Activo Fijo, asignacin, reasignacin, depreciaciones, revalorizacin y baja) se los realiza de forma semi-automatizada. En este proyecto se realizo un anlisis previo y con el mismo se realiz el diseo de cada uno de los procesos, utilizando como metodologa de desarrollo de software el Proceso Unificado de Desarrollo de Software (RUP), que permite modelar el comportamiento que va a tener el sistema, tambin se har uso del Lenguaje Unificado de Modelado (UML), el cual modelar cada uno de los procesos. A partir de esta situacin se procede a desarrollar las aplicaciones del producto final. En la etapa de implementacin se hace uso del preprocesador de hipertexto (PHP), que juntamente con Apache y MySQL hacen que la aplicacin construida pueda ser accedida desde cualquier computador con ayuda del navegador, sin mucha

complicacin. De esta manera el personal de la fundacin 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 construccin del software se realizaron entrega de prototipos a los usuarios finales, producto de las iteraciones de la metodologa 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
CAPTULO I MARCO INTRODUCTORIO
1 2 5 6 7 7 7 7 7 8 10 11

1.1 Introduccin 1.2 Antecedentes 1.3 Planteamiento del Problema 1.4 Justificacin 1.5 Objetivos 1.5.1 1.5.2 1.6.1 1.6.2 Objetivo General Objetivos Especficos Limites Alcances

1.6 Limites y Alcances

1.7 Importancia del Estudio (Aportes) 1.8 Metodologa y Herramientas

CAPTULO II

MARCO TERICO
12 12 12 13 14 14 14 15 15 16 16

2.1 Marco Conceptual 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.2.1 Activos Fijos o Bienes De Uso 2.1.1.1 Clasificacin de Los Activos Fijos Codificacin de Activos Fijos Depreciacin de Activos Fijos Mtodo de Depreciacin 2.1.4.1 Mtodo de Lnea Recta Revalorizacin Tcnica de Activos Fijos Baja de Activos Fijos Ingeniera de Software Orientada a Objetos

2.2 Metodologas para el Desarrollo de Software

2.2.1.1 2.2.1.2 2.2.1.3 2.2.2 2.2.3 2.2.2.1 2.2.3.1 2.2.3.2 2.2.3.3 2.2.4 2.2.5

Conceptos y principios Orientados a Objeto Anlisis Orientado a Objetos (AOO) Diseo Orientado a Objetos (DOO) Descripcin de los Diagramas Caractersticas esenciales del RUP Fases dentro de un Ciclo Flujos de Trabajo Fundamentales

17 19 20 21 23 30 30 33 35 39 40 40 41 42 43 43 44 45 47 48 49

Lenguaje Unificado de Modelado Proceso Unificado de Desarrollo de Software (RUP)

Diseo de la Base de Datos Relacional Herramientas de Desarrollo de Software 2.2.5.1 2.2.5.2 2.2.5.3 Servidor Web Apache MySQL Lenguaje De Programacin PHP

2.3

Calidad De Software 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 Mtricas de Calidad Del Software Factores de Calidad ISO 9126 Funcionalidad Usabilidad Facilidad de Mantenimiento Portabilidad

CAPTULO III
3.1

MARCO APLICATIVO
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

Plan de desarrollo del sistema 3.2.1 Modelado del negocio 3.2.1.1 3.2.1.2 3.2.1.3 3.2.1.4 3.2.1.5 3.2.1.6 3.2.2 3.2.2.1 3.2.2.2 3.2.2.3 3.3.1 Identificacin de Procesos del Negocio Identificacin de Actores del Negocio Definicin de Casos de Uso del Negocio Definicin del diagrama de casos de uso del Negocio Diagrama de actividades Modelo de objetos Requisitos funcionales Requisitos no funcionales Modelo conceptual

3.2 Fase de inicio

Modelado de requisitos

3.3 Fase de Elaboracin Modelo de casos de uso Actores del Sistema Definicin de los casos de uso Esenciales Definicin del diagrama de Casos de Uso Esencial Descripcin de los Casos de Uso Esenciales Definicin de Diagramas de Secuencia Definicin del Diagrama de Estados Definicin de Diagramas de Colaboracin Definicin del Diagrama de Clases Transformacin del Modelo OO al Modelo E-R Definicin del Diagrama de Componentes Definicin del Diagrama de Despliegue 3.3.1.1 3.3.1.2 3.3.1.3 3.3.1.4 3.3.2 3.3.2.1 3.3.2.2 3.3.2.3 3.3.2.4 3.3.2.5 3.3.3 3.3.3.1 3.3.3.2 3.4.1

Modelo de Diseo

Modelo de Despliegue del Sistema

3.4 Fase de Construccin Implementacin de Interfaces 3.5 Fase de Transicin

CAPTULO IV

CALIDAD Y PRUEBAS
88 88 88 91 91 92 94 94 95 99

4.1 Calidad de Software 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.2.1 4.2.2 4.2.3 Introduccin Funcionalidad Facilidad de Mantenimiento Portabilidad Usabilidad Casos de Prueba Pruebas de Caja Blanca Pruebas de Caja Negra

4.2 Pruebas

CAPTULO V

CONCLUSIONES Y RECOMENDACIONES
100 101

5.1 Conclusiones 5.2 Recomendaciones

BIBLIOGRAFIA ANEXOS

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 Clasificacin y Representacin en la Posicin Financiera Codificacin de Activo Fijo existente Codificacin de Activo Fijo del sistema Representacin Grfica de una Clase Orientada a Objetos Jerarqua de Clases Evolucin de UML Diagramas, partes de un modelo Diagrama de casos de uso Diagrama de clases Estereotipos de clases estndar de UML Diagrama de Estados Diagrama de Actividades Diagrama de Secuencia Diagrama de Colaboracin Diagrama de Componentes Diagrama de Despliegue Proceso de desarrollo de software Descripcin 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 Reasignacin 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 Reasignacin 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 Clculo de Actualizacin y Depreciacin 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 Colaboracin Registrar Activo Fijo Diagrama de Colaboracin Clculo de Actualizacin y Depreciacin Diagrama de Colaboracin Baja de Activo Fijo Diagrama de Colaboracin Registro de Tipo de Cambio Diagrama de Colaboracin Revalu de Activo Fijo Diagrama de Clases Diagrama Entidad Relacin 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 funcin. 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 Definicin de Requisitos Funcionales del Sistema Descripcin Caso de Uso Registrar Activo Fijo Descripcin Caso de Uso Registrar Tipo de Cambio Descripcin Caso de Uso Actualizar y Depreciar Activo Fijo Descripcin Caso de Uso Revalu Activo Fijo Descripcin Caso de Uso Baja de Activo Fijo Descripcin Caso de Uso Generar Reportes Cuenta total de entradas y salidas Parmetros de Medicin Valores de ajuste de la complejidad Ajuste de complejidad del punto funcin Descripcin de la escala de evaluacin 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

CAPTULO I
MARCO INTRODUCTORIO 1.1 INTRODUCCIN

El software, es una herramienta muy importante, pues es un transformador de informacin; produce, gestiona, adquiere, modifica y muestra la informacin que as se requiera. En consecuencia las instituciones deben hacer uso de los recursos tecnolgicos existentes para no quedarse relegadas en sus actividades. Por ello deben obtener de la tecnologa informtica 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 nmero de instituciones (pblicas y privadas) puedan disponer, teniendo una gran variedad de contenido y funcionalidad, por lo cual precisan contar con el activo ms importante como es la informacin y todas las caractersticas que esta debe tener para una buena toma de decisiones, como ser precisa, oportuna y fiable. La utilizacin de un navegador2, permite visualizar la informacin que contiene una pgina web. Toda institucin para llevar a cabo sus actividades, requiere de la utilizacin 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 funcin, se les denomina Activos Fijos. Es de resaltar que una de las principales caractersticas de esos activos, es la de ser permanentes en la institucin, hasta que dichos bienes dejen de ser tiles por el paso del tiempo y debido a la depreciacin3. La Fundacin La Paz es una institucin privada, sin fines de lucro y de solidaridad de fomento y promocin de la participacin de la poblacin, la misma que cuenta con subprogramas ubicados en distintos sectores de la ciudad de La
1 2

Web: son sistemas que utilizan la Internet para su ejecucin. Navegador: aplicacin en donde se pueden visualizar pginas web. 3 Depreciacin: Es la prdida del valor que sufre un bien de uso a travs del tiempo por el servicio que presta, por inclemencias climatolgicas u obsolescencia.

Paz, es responsable del rea de Promocin 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, asignacin, registro, salvaguarda, mantenimiento, depreciacin y control de los Activos Fijos. Esta administracin se la realiza de manera semi-automatizada, es decir se tiene registros de los activos fijos en hojas electrnicas, lo que ocasiona retraso en la emisin de informes y no existe una administracin adecuada en la gestin de los activos fijos. El Sistema de Informacin Web, que se ha desarrollado tiene como objetivo principal el seguimiento y control de los activos fijos del rea Socio Educativa de la Fundacin La Paz, lo cual contempla: la incorporacin, asignacin, revalu, baja, reasignacin, depreciacin y actualizacin de activos fijos. En el captulo I, se describe los antecedentes y la problemtica actual que atraviesa el rea Socio Educativa de la Fundacin La Paz, asimismo se especifica tanto el problema principal y los objetivos trazados en la elaboracin del presente proyecto, descripcin del alcance y los lmites que se tendr. En el captulo II, se especifica las herramientas y conceptos que se utilizan para el desarrollo de la implementacin del proyecto. En el captulo III, se orienta al anlisis y diseo del sistema, considerando los requerimientos definidos por la Institucin. En el captulo IV, se describen las pruebas realizadas y se aplica mtricas de calidad al sistema. Finalmente en el captulo V, se detallan las conclusiones y recomendaciones del proyecto.

1.2

ANTECEDENTES

La Fundacin La Paz es una institucin privada, sin fines de lucro y de solidaridad que nace en el ao 1971 como Fundacin San Gabriel, con programas

de carcter asistencial, cambiando su enfoque progresivamente hacia la consolidacin de una institucin de fomento y promocin de la participacin de la poblacin. La Fundacin La Paz, cuya misin, est dedicada a promover y fortalecer movimientos sociales, mediante procesos de organizacin, participacin y prestacin de servicios orientados a mejorar las condiciones y calidad de vida de la poblacin. Focaliza su accin en mujeres nios y nias por su acentuada situacin de pobreza, exclusin y discriminacin. La estructura orgnica de la Fundacin se detalla en el Anexo A. La Unidad de Activos Fijos, es la que administra la informacin 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: Recepcin de Activos Fijos. Asignacin de los Activos Fijos. Codificacin y Clasificacin de los Activos Fijos. Registro e Incorporacin de Activos Fijos. Reasignacin de Activos Fijos. Baja de los Activos Fijos. Depreciacin y Actualizacin de Activos Fijos. Revalu de los Activos Fijos.

La codificacin de cada activo fijo se realiza de acuerdo a la unidad, programa, subprograma, rubro, sub rubro y el correspondiente nmero correlativo al que pertenece, una vez realizada la donacin o adquisicin del mismo. Est codificacin 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 incorporacin en un subprograma. La forma en la que se lleva actualmente la gestin y control de activos fijos es semi-automatizada e inadecuada, puesto que solo cuenta con un registro de activos fijos en una planilla electrnica (Excel), el mismo que responde a limitadas tareas para la obtencin de informacin y la cual es susceptible a tener errores debido al excesivo volumen de informacin. Los proyectos similares se detallan en la tabla 1.1 Tabla 1.1: Proyectos Similares Sistema Sistema de Control de Activos Fijos,[Quispe Patana Johnny, 2006] Descripcin Proyecto de Grado que administra y controla los activos fijos de la Honorable Alcalda Municipal de Jess de Machaca. Proyecto Control y Seguimiento de Activos Fijos,[Canchillo Sanga Mario, 2006] de grado para controlar el

registro, asignacin, depreciacin, bajas y revalorizacin 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

Sistema de Informacin de Activos Fijos y Almacenes,[Silva Choque Martha, 2003]

informacin moderno que proporcione a los encargados de la administracin de activos fijos informacin adecuada en el momento preciso.

Fuente: Elaboracin Propia.

1.3

PLANTEAMIENTO DEL PROBLEMA

Durante el proceso de recopilacin de informacin juntamente con la colaboracin del rea Socioeducativa se realizo un estudio general de los problemas existentes y los nuevos requerimientos que surgieron a consecuencia de esta investigacin. 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). Despus de analizar los sntomas, causas y diagnosticar el problema, se ha podido identificar, deficiencias en el actual manejo y disposicin de activos fijos y otros problemas asociados: Inadecuado manejo de la informacin, debido a que esta se encuentra registrada en una hoja electrnica, la misma que no cuenta con la debida seguridad. Dificultad en el procedimiento para obtener informacin del registro de los responsables de los Activos Fijos, por el excesivo volumen de informacin. La Unidad de Activos Fijos no cuenta con informacin 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 aos de vida til. Ausencia de informacin en tiempo real y oportuna de la actualizacin depreciacin y revalu tcnico de los Activos fijos. Inadecuada asignacin del cdigo para un determinado Activo Fijo. Dificultad en el procedimiento para obtener informacin 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.

Informacin incompleta en el registro del Activo Fijo en el momento de su incorporacin. Demora en la obtencin de reportes. No existe el registro de los activos fijos dados de baja. Comunicacin inadecuada de los diferentes subprogramas hacia la Unidad de Activos Fijos, respecto de la solicitud, incorporacin y baja de Activos Fijos. En consecuencia la formulacin del problema es la siguiente: El Sistema de Informacin Web para el Control y Seguimiento de Activos Fijos: Fundacin La Paz, permitir la administracin de manera eficiente y eficaz de los Activos Fijos?

1.4

JUSTIFICACIN

La Fundacin La Paz dispone de recursos computacionales, servidor de pginas y conexin a internet, disponible este ltimo en los subprogramas. Estos recursos no son utilizados adecuadamente en consideracin al seguimiento y control de activos fijos, porque las actividades y tareas que realizan al respecto son semi automatizadas. Por tanto existen las condiciones tecnolgicas para poder desarrollar el nuevo proyecto, as los recursos computacionales de la Fundacin tendrn un adecuado uso para la administracin 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 fundacin podrn realizar una mejor administracin de los activos fijos del rea Socioeducativa.

1.5

OBJETIVOS

1.5.1 Objetivo General

Desarrollar e implementar el sistema de informacin web para el seguimiento y control de activos fijos del rea Socioeducativa perteneciente a la Fundacin La Paz, para tener un eficiente seguimiento y control de los bienes de uso.

1.5.2 Objetivos Especficos

Controlar y validar el ingreso de usuarios autorizados. Realizar un control adecuado de los registros de incorporacin, asignacin, reasignacin, actualizacin-depreciacin, revalu, baja de los Activos Fijos. Elaborar una base de datos para el registro, actualizacin, eliminacin y consulta de la informacin concerniente a la gestin de Activos Fijos. Realizar el clculo de la actualizacin y depreciacin de los Activos Fijos. Elaborar el revalu tcnico de los Activos Fijos. Generar de manera automtica el cdigo del Activo Fijo a ser incorporado, de acuerdo a ciertas caractersticas, como ser: la ubicacin del bien, al rubro y sub rubro al cual pertenece. Mejorar la rapidez y confiabilidad al momento de obtener reportes. Disear y desarrollar las interfaces que faciliten la operabilidad del sistema.

1.6

LIMITES Y ALCANCES

1.6.1 Limites El presente trabajo proporciona.

Informacin referente al seguimiento y control de los Bienes de Uso Tangibles y no as los intangibles. Informacin referente a los Activos Fijo del rea Socioeducativa, es decir se obtendr informacin 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 podrn acceder a la pgina inicial de presentacin de la fundacin.

1.6.2 Alcances
El presente proyecto, sistema de informacin web para el control y seguimiento de activos fijos de la Fundacin La Paz, contempla los siguientes mdulos:

Mdulo de Administracin: Este modulo constara de los siguientes submdulos Institucin, se realizara la administracin de la informacin 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 artculo 22 del decreto supremo 24051(reglamento del impuesto a las Utilidades), y los correspondientes sub rubros.

Organismo financiador: Se registra que tipo de organizacin sea extranjera o nacional financia la adquisicin del Activo Fijo. Cambio de moneda (tipo de cambio): En este modulo se registra el tipo de cambio de moneda en Dlares Estadounidenses.

Mdulo de Procesos: Este modulo constara de los siguientes sub-mdulos

Control del movimiento fsico: Incorporacin de nuevos Activos Fijos (AF): Se registran las nuevas adquisiciones corresponde. Asignacin de AF: Se realiza el registro de la asignacin al responsable del AF. Reasignacin de AF. Baja de AF. Control del movimiento econmico: Revalu Tcnico de AF. Actualizacin y depreciacin de AF. codificados y clasificados por el rubro que

Modulo de Consultas y Reportes: Este mdulo constara de los siguientes sub

mdulos Listado de AF por rubros. Listado de AF por sub rubros. Listado de AF por sub programas. Listado de la Asignacin de AF, por responsable o por rubro o por subprograma.

Cantidad de AF por programa. Depreciacin y actualizacin de AF. Listado de AF dados de baja. Revalu tcnico de AF.

Modulo de Herramientas: Este mdulo contar con los siguientes sub-mdulos

Cambio de contrasea o password, para los usuarios del sistema. Ventanas para, notificaciones de incorporacin, solicitud, baja de activos, para la respectiva actualizacin y depreciacin de los activos fijos. Tambin para el registro del tipo de cambio diario. Creacin de respaldos de informacin de la base de datos del sistema de informacin web. Con este sistema de informacin va web, se lograra disminuir la demora en los diferentes procesos de obtencin de informacin y brindar informacin actualizada de la depreciacin, bajas, reevalu, ubicacin fsica, asignacin a responsables, y consecuentemente ste desempea un papel importante en el proceso de evolucin del rea Socioeducativa de la Fundacin La Paz en cuanto al mejoramiento de su trabajo para el beneficio de la institucin. Tambin l sistema solucionara problemas de comunicacin y falta de coordinacin entre los subprogramas involucrados del rea Socioeducativa. Se tendr informes de acuerdo a los requerimientos del usuario, el acceso a la informacin de los Activos Fijos ser ms completo.

1.7

IMPORTANCIA DEL ESTUDIO (APORTES)

El sistema que se implementara tendr las caractersticas necesarias para proveer informacin de todo lo concerniente a la administracin de Activos Fijos, consecuentemente desempea un papel importante en el proceso de evolucin

del rea Socioeducativa de la Fundacin La Paz, en cuanto al mejoramiento de su trabajo para beneficio de la institucin misma y nuestro pas. En consideracin a la informacin 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 computacin el cual por poseer ms de un componente no solo requiere de un rubro llamado Equipo de Computacin, sino tambin de sub rubros como ser: Microprocesador, Memoria, disco duro, entre otros. Ya que si el equipo de computacin requiere cambiar algn componente o simplemente mejorarlo o darlo de baja, este tenga una mejor administracin del mismo con respecto al seguimiento y control de este Activo Fijo.

1.8

METODOLOGA Y HERRAMIENTAS

Para el desarrollo del proyecto se usa una metodologa orientada a objetos, especficamente la metodologa RUP (Rational Unified Process) por ser un proceso de desarrollo de software configurable que se adapta a los proyectos de variado tamao y complejidad, y por ajustarse a los requerimientos de este proyecto. Para el modelado del anlisis y diseo 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 programacin sea har uso de JavaSript para el desarrollo de interfaces de usuario mejoradas y pginas web dinmicas, adems de hacer uso de PHP el mismo que est diseado especialmente para desarrollo web y puede ser incrustado dentro de cdigo HTML. Como sistema gestor de Base de Datos se utilizara MySQL.

CAPITULO II MARCO TEORICO

CAPTULO II
MARCO TERICO 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 estn destinados a la venta, tales como: Terrenos, edificios, muebles y enseres, vehculos, maquinaria y equipo, herramientas y equipos de computacin. Los bienes de uso (activos fijos) a diferencia de los activos corrientes, no entran en la rotacin comercial o industrial del negocio por su naturaleza constituyen inversiones de carcter permanente que se encuentran al servicio de la empresa.

2.1.1.1 Clasificacin de los Activos Fijos Los activos fijos en forma general se clasifican en dos grandes grupos: Figura 2.1: Clasificacin y Representacin en la Posicin Financiera
No Sujetos a Depreciacin Terrenos Edificios Muebles y Enseres Maquinaria y Equipo Vehculos Equipo de Computacin etc. Pozos Petrolferos Fondos Mineros Canteras, etc. Bosques madereros Agricultura Arboricultura

Sujetos a Depreciacin

TANGIBLES Recurso Naturales Sujetos a Agotamiento

No Renovables

Renovables Patentes Derechos de Autor Concesiones Mejoras en arrendamiento, etc. Marcas de Fabrica Crdito Mercantil

Sujetos a Amortizacin INTANGIBLES No Sujetos a Amortizacin

Fuente: [FUNES, 2003]

2.1.2 Codificacin de Activos Fijos

Para realizar el control adecuado de los activos fijos se hace necesario usar una codificacin particular, que es la siguiente: Nombre de la institucin, rea, Unidad, Programa, Sub programa, Rubro y un nmero correlativo. Esta codificacin permite ver e identificar la ubicacin, el destino del bien, discriminando claramente un bien del otro, facilitando el recuento fsico peridico. Por ejemplo, un mueble que pertenece al programa Wawauta correspondiente al sub programa Valle Pacasa su codificacin ser: Figura 2.2: Codificacin 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 NMERO CORRELATIVO

Fuente: [FLP, 2006] Una vez que se le asigna el cdigo anteriormente descrito, el paso siguiente es colocar o pegar un sticker sobre el activo fijo, esta operacin es realizada por el encargado de Unidad de Activos Fijos de la fundacin. En consideracin a los requerimientos obtenidos, los mismos que se detallan en el captulo III, la nueva codificacin del activo fijo se detalla a continuacin: Figura 2.3: Codificacin 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 NMERO CORRELATIVO

Fuente: Elaboracin Propia

2.1.3 Depreciacin de Activos Fijos (Bienes de Uso)

Es la prdida de valor que sufre el bien de uso a travs del tiempo por el servicio que presta, su manipulacin y otros. La depreciacin se estima por su vida til y su valor residual, se entiende por vida til el lapso de vida que tiene un activo en aos. El importe de la depreciacin no debe deducirse directamente del costo del activo, si no debe acreditarse a una cuenta complementaria como: depreciacin acumulada, por dos razones que se indican a continuacin: La depreciacin 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 depreciacin acumulada, de esta manera el valor que refleja el Balance General o Posicin Financiera es el valor neto del activo a una determinada fecha.

2.1.4 Mtodo de Depreciacin (Lnea Recta)

En el presente proyecto para la depreciacin de activos fijos utiliz el mtodo de depreciacin de lnea recta.

2.1.4.1 Mtodo de lnea recta La depreciacin en lnea recta supone que el bien de uso se desgasta por igual durante cada periodo. Este mtodo se usa con frecuencia por ser sencillo y fcil de calcular. Este mtodo se basa conforme a la disposicin contenida en el primer prrafo del Artculo 22 del Decreto Supremo 24051, ver Anexo B. Entonces se tiene la siguiente ecuacin:

Donde: Fa = Factor de actualizacin. tci = Tipo de cambio inicial tcf = Tipo de cambio final. Va = Valor actualizado. D = Depreciacin. AVU= Aos de Vida til.

2.1.5 Revalorizacin Tcnica de Activos Fijos

Es un procedimiento reconocido contablemente, a travs del cual los peritos independientes asignan nuevos valores o determinan justiprecios a estos mas los correspondientes aos de vida til residual en funcin al estado de conservacin. Los activos fijos de la revalorizacin tcnica de activos fijos son: Asignar nuevos valores a los bienes. Asignar aos 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 situacin, por inclemencias climatolgicas, por siniestros, por hurto, por robo, por obsolescencia o por haber cumplido con su vida til. Adems, se deber seguir el siguiente procedimiento:

Cumplir con lo estipulado en el Artculo 23 del Decreto Supremo No. 24051. Actualizar valores hasta la fecha cuando se realiza la baja. Efectuar clculos de la depreciacin 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 recuperacin. Preceder a la preparacin de registro contable. Para ver las caractersticas de la administracin 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 Ingeniera de Software Orientada a Objetos
La ingeniera de software orientada a objetos (ISOO) tiene como principal protagonista al objeto, pero, una forma de describirlo en trminos sencillos seria: El mundo en el cual vivimos est rodeado de objetos. Estos objetos estn 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 Visin Orientada a Objetos para el desarrollo de sistemas informticos basados en objetos, utilizando para ello una abstraccin del entorno mismo. Este paradigma tubo como inicios los finales de los aos 60s en los que se escucho por primera vez. Pero tuvieron que pasar 20 aos para que en la dcada de los 90s llegue a ser ampliamente difundida y usada en el entorno. Cabe mencionar que la aparicin de nuevas herramientas de desarrollo ayudo a este propsito, como por ejemplo: C++, Eiffel, SmalTalk, C#, Java y en los ltimos aos a PHP.

2.2.1.1 Conceptos y Principios Orientados a Objetos Para una mejor comprensin de la ingeniera orientada a objetos se presenta los siguientes conceptos y principios bsicos: 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: Representacin Grfica 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 travs de las operaciones definidas en la clase, por tanto, la clase encapsula los atributos. Entonces una clase es una descripcin generalizada que describe a una coleccin de objetos similares. Por definicin todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulacin de los datos. Atributo, es una propiedad o caracterstica 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 fsico los atributos posibles serian: forma, peso, color, tipo de material, etc. Los posibles valores por defecto para el atributo peso llegaran a ser: 1 Kg o 200 grs, esto segn se defina en la necesidad del objeto. Operaciones, que tambin son llamados mtodos o servicios, no son ms que algoritmos especficos capaces de manipular los datos representados como una coleccin de atributos. Una operacin tiene un nombre especfico y parmetros que son definidos. Las operaciones representan el comportamiento de los objetos y son invocadas a travs de mensajes. Mensajes, son el media mediante el cual los objetos interactan entre s. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor, este comportamiento se ejecuta al realizarse una operacin. Encapsulamiento, una de las caractersticas 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 tambin para otras clases, llegndose a obtener los siguientes beneficios: o Los detalles de la implementacin de los datos y algoritmos estn ocultos para el mundo exterior, lo cual reduce los efectos colaterales al efectuarse los cambios. o La estructura de los datos y las operaciones que las manipulan estn unidas en una sola entidad llamada clase. Esto facilita la reutilizacin de componentes. o Las interfaces entre objetos estn simplificadas, un objeto que enva un mensaje no tiene que preocuparse por los detalles de la estructura de los datos internos del objeto receptor. Polimorfismo, es una caracterstica que reduce en gran medida el esfuerzo para extender un sistema y consiste en operaciones o mtodos con un

mismo nombre que actan de manera distinta, generalmente la nica diferencia entre ellos es el paso de parmetros o argumentos. Herencia, es una de las diferencias entre los sistemas convencionales y los sistemas orientados a objetos. No es ms que la especializacin 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: Jerarqua de Clases.

Fuente: [PRESS, 2005] 2.2.1.2 Anlisis 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 semnticos que interactan y se comportan de acuerdo a los requisitos del sistema. El AOO se fundamenta en un conjunto de cinco principios bsicos: Modelar el dominio de la informacin. Describir la funcin del modulo. Representar el comportamiento del modelo. Dividir el modelo para mostrar ms detalles.

Observar que los modelos inciales representan la esencia del problema mientras que los ltimos aportan detalles de la implementacin. El propsito del AOO es definir todas las clases, adems 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 bsicos del usuario deben comunicarse entre el cliente y el ingeniero del software. Identificar las clases, definiendo los atributos y los mtodos. Especificar una jerarqua 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 Diseo Orientado a Objetos (DOO) El diseo orientado a objetos (DOO) transforma el producto obtenido en la anterior etapa o sea el modelo de anlisis en un modelo de diseo que sirve como un anteproyecto para la construccin de software. A diferencia de los mtodos convencionales de diseo del software, el DOO constituye un tipo de diseo que logra un cierto nmero de diferentes niveles de modularidad. Los componentes principales del sistema estn organizados en mdulos denominados subsistemas. El DOO debe describir la organizacin de datos especficos, de atributos y los detalles procedimentales de las operaciones individuales. Esta representacin 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 diseo clsico del software:

Abstraccin, consiste en ignorar aquellos aspectos del problema en estudio que no son relevantes para centrarse en aquellos que s son importantes Ocultacin de la informacin, 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 mdulos u operaciones sean capaces de realizar o especializarse en una tarea en particular Modularidad, esto concepto permite la reutilizacin y facilita la verificacin y depuracin de los mismos. Los objetos son mdulos naturales ya que corresponden a una representacin lgica de la realidad. Para los sistemas orientados a objetos es posible definir un diseo en pirmide con las siguientes cuatro capas: Subsistema. Contiene una representacin de cada uno de los subsistemas que le permiten al software conseguir los requisitos definidos por el cliente e implementar la infraestructura tcnica que los soporta. Clases y objetos. Contiene las jerarquas de clases que permiten crear el sistema utilizando generalizaciones y especializaciones mejor definidas incrementalmente. Tambin contiene representaciones de diseo 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 diseo algortmico para todos los atributos y operaciones de cada objeto.

2.2.2 Lenguaje Unificado de Modelado

El Lenguaje Unificado de Modelado comnmente 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, disear, configurar, mantener y controlar la informacin sobre tales sistemas. Est pensado para usarse con todos los mtodos de desarrollo, etapas de ciclo de vida, dominios de aplicacin y medios. El Lenguaje Unificado de Modelado pretende unificar la experiencia pasada sobre tcnicas de modelado e incorporar las mejores prcticas actuales en un acercamiento estndar. Figura 2.6: Evolucin de UML.

Fuente: [BOOCH, 1999] UML fue desarrollado en un esfuerzo para simplificar y consolidar el gran nmero de mtodos de desarrollo orientado a objetos que hasta ese momento haba ya surgido. Es as que partir del ao 1994, Grady Booch y Jim Rumbaugh creador de OMT se unen en una empresa comn, Rational Software Corporation, y comienzan a unificar sus dos mtodos. Un ao ms tarde, en octubre de 1995, aparece 0.8, la que se considera como la primera versin del UML. A finales de ese mismo ao, Ivan Jacobson, creador de la Ingeniera de Software Orientado a Objetos -OOSE (Object Oriented Software Engineer) se aade al grupo.

UML se quiere convertir en un lenguaje estndar 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 estndar de desarrollo, sino nicamente un lenguaje de modelado. Otros mtodos de modelaje como OMT (Object Modeling Technique) o Booch s definen procesos concretos. En UML los procesos de desarrollo son diferentes segn los distintos dominios de trabajo. Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los mtodos ms utilizados sigan evolucionando en conjunto y no por separado. Y adems, unificar las perspectivas entre diferentes tipos de sistemas no slo software, sino tambin en el mbito de los negocios, al aclarar las fases de desarrollo, los requerimientos de anlisis, el diseo, la implementacin y los conceptos internos de la metodologa OO.

2.2.2.1 Descripcin de los diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Un diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices 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 inters. Es aqu donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems 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 utilizacin 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 continuacin: Figura 2.7: Diagramas, partes de un modelo

Fuente: [RUEDA, 2006] Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupndola en descripciones de acciones ejecutadas por un sistema para obtener un resultado, tambin 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 caractersticas comunes) que componen el sistema y cmo se relacionan entre s. Figura 2.9: Diagrama de clases

Fuente: [FOWLER, 1999]

Diagrama de Objetos: muestra una serie de objetos (instancias de las

clases) y sus relaciones. Cada una de las clases de entidad, interfaz y

control,

aislaran

los

cambios

al

comportamiento

(estereotipos

estandarizados en UML) y a la informacin que representan, como se puede observar en la figura 2.9:

Figura 2.10: Estereotipos de clases estndar de UML

Fuente: [BOOCH, 1999]

Diagramas encuentran:

de

Comportamiento:

dentro

de

estos

diagramas

se

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. Tambin se pueden utilizar caminos verticales para mostrar los responsables de cada actividad.

Figura 2.12: Diagrama de Actividades

Fuente: [FOWLER, 1999]

o Diagramas de Interaccin: Estos diagramas a su vez se dividen en 2 tipos de diagramas, segn la interaccin que enfatizan:

Diagrama de Secuencia: enfatiza la interaccin 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] Diagrama de Colaboracin: igualmente, muestra la

interaccin entre los objetos resaltando la organizacin estructural de los objetos en lugar del orden de los mensajes intercambiados. Figura 2.14: Diagrama de Colaboracin

Fuente: [BOOCH, 1999] Diagramas de implementacin o Diagrama de Componentes: muestra la organizacin 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 distribucin 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 ms que un simple proceso; es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaos de proyectos.

2.2.3.1 Caractersticas Esenciales del RUP El proceso Unificado se base en los siguientes aspectos caractersticos: 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 especificacin 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. Tambin guan su diseo, implementacin y prueba: esto es, guan 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 construccin. El concepto de la arquitectura software incluye los aspectos estticos y dinmicos ms significativos. Como la plataforma en la que tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema gestin de base de datos, protocolos para comunicaciones en red), los bloques de construccin reutilizables de que se dispone (por ejemplo: un marco de trabajo para interfaces grficas de usuario), consideraciones de implantacin, sistemas heredados y requisitos no funcionales (por ejemplo, rendimiento y fiabilidad). La arquitectura es una vista del diseo completo con las caractersticas ms importantes resaltadas, dejando los detalles de lado. Cmo se relacionan los casos de uso y la arquitectura? Cada producto tiene tanto una funcin como una forma. Estas dos fuerzas deben equilibrarse para poder obtener un producto con xito. Es esta la situacin, la funcin correspondiente a los casos de uso y la forma de la arquitectura. Debe haber la iteracin 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 disearse para permitir que el sistema evolucione, no solo en el desarrollo inicial, sino tambin a lo largo de las futuras

generaciones. Para encontrar, esa forma los arquitectos deben trabajar sobre la comprensin 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 ao o ms. Es prctico dividir el trabajo en partes ms pequeas o mini-proyectos. Cada mini-proyecto es una iteracin 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 mxima, las iteraciones deben estar controladas; esto es, deben seleccionarse y ejecutarse de forma planificada. Esto es por lo que son mini-proyectos. La iteracin trata: un conjunto de casos de uso y los riesgos ms importantes. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la iteracin. Al ser mini-proyectos, comienzan con los casos de uso y continan a travs de desarrollo subsiguiente Anlisis, Diseo, Implementacin y Prueba, que termina convirtindose en cdigo ejecutable los casos de uso que se desarrollan en la iteracin, vase 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 diseo superficial por uno detallado o sofisticado. En las fases posteriores los incrementos son tpicamente aditivos. En cada iteracin los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseo utilizando la arquitectura seleccionada como gua, implementan el diseo mediante componentes y verifican que los componentes satisfacen los casos de uso. Si una iteracin cumple con sus objetivos-como suele suceder- el desarrollo contina con la siguiente iteracin. Cuando una iteracin 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 versin 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 travs 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: Descripcin del Proceso Unificado

Fuente: [JACOB, 2000] Fase de Inicio (Inception): Se desarrolla una descripcin del producto final a partir de una buena idea y se presenta el anlisis de negocio para el producto. Esencialmente esta fase responde a las siguientes preguntas: Cules son las principales funciones del sistema?

Cmo podra ser la arquitectura del sistema? Cul 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 ms crticos. Cuando lo tengamos la arquitectura es provisional y consiste en un simple esbozo que muestra los subsistemas ms importantes. En esta fase, se identifican, priorizan los riesgos ms importantes, se planifica en detalle la fase de elaboracin y se estima el proyecto de manera aproximada. Fase de Elaboracin (Elaboration): se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura del sistema. La relacin entre la arquitectura del sistema y el propio sistema es primordial. Es decir que la arquitectura es anloga al esqueleto cubierto por la piel pero con muy poco msculo (el software) entre los huesos y la piel solo lo necesario para permitir que el esqueleto haga movimientos bsicos. El sistema es el cuerpo entero con esqueleto, piel y msculos. 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 arquitectnicas del modelo de casos de uso, del modelo de anlisis, del modelo del diseo, del modelo de implementacin y del modelo de despliegue. La vista del modelo de implementacin incluye componentes para probar que la arquitectura es ejecutable. Durante esta fase de desarrollo, se realizan los casos de uso ms crticos que se identificaron en la fase de comienzo. El resultado de esta fase es una lnea base de la arquitectura. Al final de la fase de Elaboracin, el director del proyecto est en disposicin de planificar las actividades y estimar los recursos necesarios para terminar el proyecto. Aqu la cuestin fundamental es: son suficiente estables los casos de uso, la arquitectura, el plan y estn los riesgos

suficientemente

controlados

como

para

que

seamos

capaces

de

comprometernos al desarrollo entero mediante un contrato? Fase de Construccin (Construction): Se crea el producto se aaden los msculos (software terminado) al esqueleto (la arquitectura). En esta fase, la lnea base de la arquitectura crece hasta convertirse en el sistema completo. La descripcin 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 direccin y el cliente han acordado para el desarrollo de esta versin. La pregunta decisiva es: cubre el producto las necesidades de algunos usuarios de manera suficiente como para hacer una primera entrega? Fase de Transicin (Transition): Cubre el periodo durante el cual el producto se convierte en versin beta. En esta versin beta un nmero 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 versin general dirigida a la totalidad de la comunidad de usuarios. La fase de transicin conlleva actividades como la fabricacin, formacin del cliente, tras la entrega. El equipo de mantenimiento suele dividir estos defectos en dos categoras: los que tienen suficiente impacto en la operacin para justificar una versin incrementada (versin delta) y los que pueden corregirse en la versin 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 culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen:

Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A continuacin se describe rpidamente cada una de estas disciplinas. Modelado del negocio Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin, 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, adems 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 lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias. Anlisis y diseo Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU, el de secuencia, de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura.

Implementacin Esta disciplina tiene como objetivos implementar las clases de diseo 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 Implementacin, conjuntamente los Diagramas de Componentes para comprender cmo se organizan los Componentes y dependen unos de otros. Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado para el cliente, proceder a su entrega y recepcin 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 ensear al usuario. Gestin y configuracin de cambios Es esencial para controlar el nmero 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 haba arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas: o Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin saber que alguien ms lo est actualizando.

o Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo. o Versiones mltiples: No saber con exactitud, cual es la ltima versin, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones.

Gestin 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 Gestin del Proyecto se logra una mejora en el manejo de una entrega exitoso de software. En resumen su propsito 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 direccin del proyecto. Por ejemplo, no cubre problemas como: o Administracin de personal: contratando, entrenando, enseando. o Administracin del presupuesto: definiendo, asignando. o Administracin 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 propsito es proveer a la organizacin que desarrollar el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software.

2.2.4 Diseo de la Base de Datos Relacional

El diagrama de clases de UML presenta un mecanismo de implementacin 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 comn emplear una base de datos relacional (BDR) para el almacenamiento de datos. Con el diagrama de clases se pueden modelar algunos aspectos del diseo de base de datos relacionales, aunque no cubre toda la semntica involucrada en el modelado relacional: para capturar esta informacin, un diagrama entidad/relacin (E-R) se utilizar como extensin de UML. Se puede modelar tambin la estructura lgica 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 comparacin para lograr una transformacin de un modelo de objetos a un diagrama de entidad relacin.

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 poda contribuir a crear nuevas caractersticas y a reparar errores. De esta forma, un grupo de desarrolladores podan recoger las modificaciones a sus cdigos y crear un producto combinado. Comenz con HTTPd 1.3 NCSA, empezaron a aplicar estas soluciones. La primera versin de este producto, llamado Apache, fue la versin 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 despus del primer lanzamiento Thau diseo una arquitectura

completamente nueva. Comenzando con la versin 0.8.8 en agosto de 1995, Apache se incorporo a esta nueva base del cdigo. Netcraft muestra que Apache sobrepasa a NCSA como primer servidor HTTP a principios de 1996. De acuerdo con la estadstica de Netcraft, el servidor Web Apache se emplea ms 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 tambin se cuenta el software para servidor basado en cdigo 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 dcada de los 90 trat de usar mSQL para conectar las tablas usando rutinas de bajo nivel ISAM, sin embargo, mSQL no era rpido 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 ms portable. La procedencia del nombre de MySQL no es clara. Por ms de 10 aos, las herramientas han mantenido el prefijo My. Tambin, se cree que tiene relacin con el nombre de la hija del cofundador Monty Widenius quien se llama My.

Por otro lado, el nombre del delfn 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 ms usado en el mundo del software libre, debido a su gran rapidez y facilidad de uso. Esta gran aceptacin es debida, en parte, a que existen infinidad de libreras y otras herramientas que permiten su uso a travs de gran cantidad de lenguajes de programacin, adems de su fcil instalacin y configuracin. Las principales caractersticas de este gestor de bases de datos MySQL son las siguientes: Aprovecha la potencia de sistemas multiprocesador, gracias a su implementacin 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. Gestin de usuarios y passwords, manteniendo un muy buen nivel de seguridad en los datos.

2.2.5.3 Lenguaje de Programacin PHP Rasmus Lerdof, fue quien desarrollo PHP en el ao 1994 esta primera versin sin liberar, la incorporo a su pgina Web personal, cuya utilidad era controlar el nmero de usuarios que accedan a su currculum vitae online. Nadie supo de la existencia de PHP hasta principios de 1995, cuando la primera versin al fin fue liberada. Por aquel entonces era conocido como Herramienta de Pginas Web Personales (Personal Home Page Tools). A principios de 1995 PHP se puso a disposicin de los desarrolladores como Personal Home Page Tools. Esta versin contena un motor de anlisis de sintaxis

(perser) que utilizaba algunas macroinstrucciones (macros) y utilidades especiales que fueron incluidas a menudo en las pginas personales. Esto hizo de PHP una opcin bastante popular entre los desarrolladores que queran crear y realzar sus pginas. PHP les permiti que aadieran a sus pginas 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 versin 2, hasta mediados de 1997, el analizador de sintaxis fue reescrito totalmente por Zeec Suraski y Andi Gulmnas, este formo el ncleo de la tercera versin de PHP, conocida como PHP 3. Hasta la fecha actualmente se cuenta con la versin de PHP 5.

2.3 CALIDAD DE SOFTWARE

2.3.1 Mtricas de Calidad del Software
La Calidad del software se define como, concordancia con los requisitos funcionales y de rendimiento explcitamente establecido, con los estndares de desarrollo explcitamente documentados, y con las caractersticas implcitas 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 estndares especificados definen un conjunto de criterios de desarrollo que guan la manera en que se hace la ingeniera de software. Si no se siguen los criterios, habr seguramente poca calidad. Existe un conjunto de requisitos implcitos que a menudo no se nombran (tal es el caso la facilidad de mantenimiento). Si el software cumple con sus requisitos explcitos pero falta en los implcitos, la calidad del software no ser fiable.

La calidad del software es una compleja mezcla de factores que varan a travs de diferentes aplicaciones y segn los clientes que la pidan.

2.3.2. Factores de Calidad ISO 9126

El estndar ISO 9126 ha sido desarrollado en un intento de identificar los atributos clave de la calidad para el software. El estndar identifica seis atributos clave de calidad: Funcionalidad. El grado en que el software satisface las necesidades indicadas por los siguientes sub atributos: idoneidad, correccin,

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 recuperacin. Usabilidad. Grado en el que el software es fcil de usar. Viene reflejado por los siguientes sub atributos: facilidad de comprensin, 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 modificacin puede ser realizada. Est indicada por los siguientes sub atributos: facilidad de anlisis, 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 instalacin, facilidad de ajuste, facilidad de adaptacin al cambio.

2.3.3 Funcionalidad
Las mtricas orientadas a la funcin, utilizan una medida de la funcionalidad entregada por la aplicacin como un valor de normalizacin. Ya que la funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante medidas directas. Las mtricas orientadas a la funcin fueron propuestas por primera vez por Albretch [ALBRETCH,1979], quien sugiri una medida llamada punto de funcin. Los puntos de funcin se derivan con una relacin emprica segn las medidas contables (directas) del dominio de informacin del software y las evaluaciones de la complejidad del software. Los puntos de funcin se evalan segn la siguiente tabla:

Tabla 2.1: Calculo de puntos de funcin.

Factores de Ponderacin Parmetro de Medicin Cuenta Simple Nmero de Entradas del usuario Nmero de salidas del usuario Nmero de consultas del usuario Nmero de Archivos Nmero de Interfaces Externas * * * * * 3 4 3 7 5 Cuenta TOTAL Media 4 5 4 10 7 Compleja 6 7 6 15 10 = = = = =

Fuente: [PRESS, 2005]

Se determinan cinco caractersticas de dominios de informacin y se proporcionan las cuentas en la posicin apropiada de la tabla. Los valores de dominios de informacin se definen de la siguiente forma: Nmero de Entradas de Usuario. Se cuenta cada entrada de usuario, que proporcionan diferentes datos orientados a la planificacin que proporciona al usuario informacin.

Nmero de Salidas de Usuario. Se cuenta cada salida que proporciona al usuario informacin orientada a la aplicacin. Nmero de Peticiones de Usuario. Una peticin se define como una entrada interactiva que produce la generacin de alguna respuesta del software inmediata en forma de salida interactiva. Numero de Archivos. Se cuenta cada archivo maestro lgico 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 informacin 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 mtodos de punto de funcin desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. No obstante la determinacin de la complejidad es algo subjetiva. Para calcular los puntos de funcin (PF) se utiliza la siguiente relacin:

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 mnimo aceptable de la complejidad. : son valores de ajuste de complejidad segn las respuestas que se da a
las siguientes preguntas que se detallan a continuacin.

Tabla 2.2: Preguntas para hallar el valor de ajuste. Nro.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Preguntas para hallar el valor de Ajuste

Requiere el sistema copias de seguridad y de recuperacin fiables?1 Se requiere comunicacin de datos? Existen funciones de procesamiento? Es crtico 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 mltiples 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 diseado el cdigo para ser reutilizable? Estn incluidas en el diseo la conversin y la instalacin? Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario?

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 ecuacin y los factores de peso que se aplican a las cuentas de los dominios de informacin se determinan empricamente. El indicador de funcionalidad se lo encuentra calculando la siguiente relacin:

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 funcin a cuatro caractersticas: i. Habilidad intelectual y/o fsica 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. Valoracin subjetiva (a veces obtenida mediante un cuestionario) de la disposicin de los usuarios hacia el sistema.

2.3.5 Facilidad de Mantenimiento

Se ha propuesto mtricas diseadas explcitamente para actividades de mantenimiento. El estndar IEEE 982.1 1998 sugiere un ndice de madurez del software (IMS) que proporciona una indicacin de la estabilidad del producto software (basada en los cambios que ocurren con cada versin del producto). Este ndice se determina de la siguiente manera:

Donde: MT: Nmero de mdulos en la versin actual. Fa: Nmero de mdulos en la versin actual que se han aadido. Fc: Nmero de mdulos en la versin actual que se han cambiado. Fd: Nmero de mdulos de la versin anterior que se han borrado en la versin actual. A medida que el IMS se aproxima a 1.0, el producto se empieza a estabilizar. El IMS puede emplearse tambin como mtrica para la planificacin de las actividades del mantenimiento del software. El tiempo medio para producir una versin de un producto software puede correlacionarse con el IMS desarrollndose modelos empricos para el mantenimiento.

2.3.6 Portabilidad
La portabilidad de un sistema de informacin se define como la facilidad de transferir un producto a diferentes entornos de hardware/software, sin necesidad de aplicar acciones o mecanismos distintos. Tambin es considerado como la capacidad del producto software para ser usado en lugar de otro producto

software para el mismo propsito, dentro del mismo entorno. Las caractersticas ms importantes que se consideran para este factor son: la facilidad de instalacin, facilidad de ajuste y facilidad de adaptacin al cambio.

CAPITULO III MARCO APLICATIVO

CAPITULO III
MARCO APLICATIVO

Segn la metodologa planteada, el proyecto ser desarrollado segn la lnea del proceso unificado de desarrollado conocido comnmente como RUP, esta metodologa utiliza el Lenguaje Unificado de Modelado para su notacin, 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 gua arquitectnica rpida para disear 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 captulo se describe el modelado del sistema Sistema de Informacin Web para el Control y Seguimiento de Activos Fijos: Fundacin La Paz.

3.1 PLAN DE DESARROLLO DEL SISTEMA

El objetivo principal es desarrollar un plan de trabajo basado en la metodologa RUP de acuerdo a las caractersticas del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los artefactos que sern generados. Se tomar en cuenta que el estudio preliminar se lo realizo en una primera instancia, concretamente en: la identificacin del problema, objetivo general, objetivos especficos, justificaciones y alcances. En esta seccin se presenta la organizacin en fases e iteraciones. El desarrollo del proyecto se llevara a cabo en base a las cuatro fases detalladas anteriormente con una o ms iteraciones en cada una de ellas. La siguiente tabla muestra la distribucin de tiempos y el nmero de iteraciones de cada fase.

Tabla 3.1: Tiempos estimados en las fases de RUP.

Fases
Fase de Inicio Fase de Elaboracin Fase de Construccin Fase de Transicin

Nro. Iteraciones
2 3 5 3

Duracin
4 Semanas 7 Semanas 12 Semanas 6 Semanas

Fecha
10/08/2009 a 4/09/2009 24/08/2009 a 9/10/2009 31/08/2009 a 13/11/2009 12/10/2009 a 20/11/2009

Fuente: Elaboracin propia. De acuerdo a la planificacin 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 ELABORACIN Hito Estudio del modelado de negocio. Requisitos aprobados para su desarrollo. Se elabora los documentos a detalle de los requisitos que sern revisados por el encargado de activos fijos. Prototipo de la arquitectura de acuerdo a los requerimientos. Casos de usos completos y aprobados. El anlisis y diseo del sistema debe estar documentado y listo para su revisin. Mdulos identificados en los cuales se realizan pruebas de integracin. Prototipos del sistema en sus distintas versiones modificado para su revisin y aprobacin. Versin concluida del sistema listo para pruebas reales. Elaboracin de manuales de usuario segn su funcionalidad. Con el sistema terminado se realizan las tareas de configuracin. De acuerdo a la planificacin 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 documentacin del sistema para ser entregada.

FASE DE CONSTRUCCIN

FASE DE TRANSICIN

Fuente: Elaboracin 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 anlisis y diseo tomando en cuenta el estudio realizado de los requerimientos, en la tercera fase se desarrolla la construccin de acuerdo al anlisis y diseo realizado con anterioridad y en la cuarta fase se realizan las pruebas adems de las posibles modificaciones y la conclusin de la documentacin. Tabla 3.3: Artefactos de las distintas disciplinas que comprende RUP.
Disciplinas 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 Anlisis/Diseo. Diagrama de CU del sistema. Descripcin de los casos de uso. Diagramas de Secuencias. Diagramas de Estado. Diagrama de Clases. Modelo de Datos. Transformacin 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.

MODELADO DEL NEGOCIO

REQUISITOS

ANALISIS / DISEO

IMPLEMENTACION PRUEBAS DESPLIEGUE GESTION Y CONFIGURACION DE CAMBIOS

Fuente: Elaboracin propia.

3.2 FASE DE INICIO

3.2.1 Modelado del Negocio
Basado en el estudio preliminar de la institucin se procede a identificar y describir cada uno de los procesos del negocio, determinando el tipo de informacin, actividades, roles y reglas del negocio implicadas. Con esto lo que se pretende es comprender toda la actividad de la institucin relacionada con el sistema a implementar.

3.2.1.1 Identificacin de Procesos del Negocio El modelado del negocio se inicia identificando los principales objetivos estratgicos de la institucin y los procesos de mayor relevancia asociados a estos objetivos son: De acuerdo a sus estatutos de la Fundacin La Paz (FLP): Disear, ejecutar y asesorar programas, proyectos y acciones de promocin y gestin social en beneficio de la poblacin pobre de zonas suburbanas y rurales del pas. Generar procesos educativos en la perspectiva de ampliar los conocimientos de los diferentes sectores sociales del pas, para elevar sus niveles de conciencia y reforzar su identidad socio cultural. Promover la participacin y organizacin de estos sectores, para ampliar su capacidad de enfrentar situaciones crticas y mejorar sus condiciones de negociacin en el contexto social en el que se desenvuelven. Contribuir en el mejoramiento de la calidad de vida de la poblacin mediante la prestacin de servicios.

3.2.1.2 Identificacin de Actores del Negocio. A continuacin se identifica y describe los actores del negocio correspondiente de la Fundacin 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 funcin de controlar todo el movimiento de los activos existentes en la Fundacin desde su recepcin, registro, asignacin, baja, etc. A su vez tambin est a cargo de la emisin 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 tambin a quien se le asigna el activo y dispone de los mismos para la realizacin de sus funciones y responsable directo del Activo Fijo. Financiador, es la persona fsica o jurdica que se encarga de proveer de Activos Fijos y financiamiento econmico 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 emisin de los cheques para la adquisicin de un Activo Fijo.

3.2.1.3 Definicin de Casos de Uso del Negocio La identificacin y definicin de los casos de uso as como tambin su respectiva descripcin se la detalla a continuacin: 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 aprobacin 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 asignacin de activos fijos al personal solicitante. Este ltimo ser el custodio y responsable del bien. Revalu de Activo Fijo. Se toma en consideracin aquel activo fijo el cual haya cumplido sus aos 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, aos de vida til y la respectiva depreciacin. Baja Activo. El encargado de la unidad Activos Fijos procede el retiro de los bienes que hayan ya cumplido su vida til o que estn en un estado en el cual no preste el servicio por el cual fue adquirido. Reasignacin de Activo Fijo. El encargado de la unidad de AF se encarga de la nueva ubicacin de un activo fijo, el cual ahora contara con nuevo cdigo 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 administracin de los activos (incorporacin, baja, asignacin, revalu, etc.). Estos reportes son solicitados por el Director del rea Socio Educativa.

3.2.1.4 Definicin del Diagrama de Casos de Uso del Negocio A continuacin se realiza la identificacin 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

Responsable de Contabilidad

Comprar Activo Fijo

Coordinador de Programa

Revaluo de Activo Fijo

Financiador Baja de Activo Fijo

Encargado de la Unidad de Activos Fijos

Asignar Activo Fijo

Responsable de Activo Fijo

Reasignacion de Activo Fijo

Director del Area Socio Educativa

Generar reportes

Fuente: Elaboracin 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 grficos:

Figura 3.2: Diagrama de Actividades Recepcionar Pedido de Activo Fijo

ENCARGADO DE LA UNIDAD DE ACT IVOS FIJOS COORDINADOR DE PROGRAMA RESPONSABLE DE CONT ABILIDAD

Real i za sol i ci tud

Recepci ona sol i ci tud

Aproba sol i ci tud [Si ] Envi a sol i ci tud

[No] Ni ega sol i ci tud

Emi te cheque

Recoge cheque

Real i za compra

Recepci ona compra Regi stra el acti vo fi j o

Col oca i denti fi cador

Asi gna responsabl e y ubi caci on

Emi te comprovante de entrega

Fuente: Elaboracin 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: Elaboracin 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 ubicacion

Emite comprovante de entrega

Fuente: Elaboracin Propia

Figura 3.3: Diagrama de Actividades Revalu de Activo Fijo

ENCARGADO DE LA UNIDAD DE ACTIVOS FIJOS

Revisa registros de AF

Verifica utilidad Baja de activo fijo Revaluo de activo fijo

Fuente: Elaboracin 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 Devolucion de activo fijo Realiza informe

Recepcion informe

Realiza reubicacion interna de AF

Realiza ajustes correspondientes

Fuente: Elaboracin Propia

Figura 3.5: Diagrama de Actividades Reasignacin 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: Elaboracin 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

Encargado Unidad AF

Coordinador Programa

Solicitud de AF

Fuente: Elaboracin Propia

Figura 3.7: Modelo de Objeto del Caso de Uso Comprar Activo Fijo

Encargado Unidad AF

Registro de AF

Responsable de Contabilidad
Coordinador Programa

Solicitud de AF

Cheque

Fuente: Elaboracin Propia

Figura 3.8: Modelo de Objeto del Caso de Uso Asignar Activo Fijo

Encargado Unidad AF

Responsable de AF

Registro de AF

Fuente: Elaboracin Propia Figura 3.9: Modelo de Objeto del Caso de Uso Revalu de Activo Fijo

Encargado Unidad AF

Registro de AF

Revalu de AF

Fuente: Elaboracin 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: Elaboracin Propia Figura 3.11: Modelo de Objeto del Caso de Uso Reasignacin de AF

Responsable de AF

Informe de reasignacin

Coordinador Programa

Registro de AF

Fuente: Elaboracin 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 anlisis y diseo del sistema.

3.2.2.1 Requisitos Funcionales La siguiente tabla detalla las funciones elementales o requerimientos que debern ser satisfechos para el usuario final por el sistema a implantar. Tabla 3.4: Definicin de Requisitos Funcionales del Sistema. Nro. R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 FUNCION Control de ingreso para usuarios. Registro de usuarios habilitados. Registro de ingreso de activos fijos (AF). Generacin automtica del cdigo identificador de AF. Registro de asignacin de AF al personal. Registro de financiadores. Informe de Activos Fijos por Programa y Sub programa Realizar el revalu tcnico del Activo Fijo. Realizar el clculo de actualizacin y depreciacin del AF. Obtener reporte de las asignaciones realizadas de los Activos Fijos por responsable. Registrar la baja del AF y su correspondiente observacin. Generar informe de Activos por rubro, sub rubro, fecha de ingreso. Registro de rubro (equipo de computacin, muebles y enseres, vehculo, equipos, maquinaria, etc.) de AF. Registro de subgrupo (microprocesador, memoria, disco duro, lector DVD, etc.) de AF. Registro de responsable (funcionario). Fuente: Elaboracin Propia. 3.2.2.2 Requisitos No Funcionales Para el correcto funcionamiento el sistema informtico que se est desarrollando deber cumplir con los siguientes requerimientos no funcionales en el momento de implantar el sistema, mismos que se detallan a continuacin: Windows o Linux como sistema operativo al lado del cliente. CATEGORIA Oculta Evidente Evidente Oculta Evidente Evidente Evidente Evidente Oculta Evidente Evidente Evidente Evidente Evidente Evidente

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 adems del gestor de base de datos MySql y el intrprete de pginas PHP. La informacin almacenada deber ser capaz de ser accedida en otros equipos conectados dentro del rea Socio Educativa de la Fundacin La Paz. La aplicacin no deber consumir demasiado tiempo a la hora de acceder a la misma. Para ver el glosario de trminos dirjase al Anexo E.

3.2.2. Modelo Conceptual

Una parte de la investigacin 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 especificacin de requisitos adems 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 tiene * Unidad 1 contiene * Programa 1 posee * 1 es parte * Encargado AF 1 registra * * se asigna a Responsable 1 se da 1 Baja 1 1 Act. y Dep Revaluo * * se realiza se efectua * * * pertenece 1 Sub Rubro * compone 1 Rubro Activo Fijo 1 es financiado por Sub Programa

Fuente: Elaboracin Propia.

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 funcin de controlar todo el movimiento de los activos existentes en la en la Fundacin desde el registro de incorporacin, asignacin, baja, revalu, actualizacin y depreciacin, etc. A su vez tambin est a cargo de la emisin de reportes y actas respectivas. Coordinador de Programa, es la persona encargada de realizar el registro, baja y la emisin 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 interacta con el sistema, tenemos como usuarios al encargado de la Unidad de Activos Fijos, Coordinador, Director rea Socioeducativa y cualquier otro

funcionario de la fundacin.

3.3.1.2 Definicin de Casos de Uso Esenciales En funcin de los casos de uso ya especificados en la etapa inicial adems de los nuevos casos de uso, mismos que se describen a continuacin correspondern a los casos de uso esnciales y sern definidos en formato expandido para una mejor comprensin: 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 clasificacin 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 despus darle otra ubicacin y asignarle un nuevo responsable. Actualizar y Depreciar activo fijo. El procedimiento de Actualizacin y Depreciacin de Activos Fijos procesa los datos contables y calcula su valor correspondiente previa ejecucin 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 estn 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 sern utilizados como referencia para la utilizacin en: el ingreso y registro de Activos Fijos, actualizacin y depreciacin, el clculo del respectivo valor contable, baja de activo y en la adicin por revalu tcnico. 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 actualizacin de la base de datos y de los mdulos a los cuales est a cargo. 3.3.1.3 Definicin del Diagrama de Casos de Uso Esencial El siguiente diagrama corresponde al caso de uso esencial del Sistema de Informacin Web para el Control y Seguimiento de Activos Fijos: Fundacin La

Paz (SISCAFW). A partir de este se especificaran los diagramas de casos de uso descritos. Figura 3.13: Diagrama de Casos de Uso del Sistema SISCAFW

SISCAFW

Registrar activo fijo

Reasignar activo fijo

Coordinador de Programa

Encargado de la Unidad de AF

Actualizar y depreciar activo fijo

Revaluo de activo fjo

Baja de activo fjo

Registar tipo de cambio de moneda

Director del ASE

Generar reportes

Administrar responsable Administrar ususario Usuario

<<extends>>

<<extends>>

Administrar base de datos Administrador del Sistema <<extends>>

<<extends>>

Administrar institucion <<extends>> Administrar rubro Administrar financiador

Fuente: Elaboracin Propia. 3.3.1.4 Descripcin de los Casos de Uso Esenciales En las siguientes tablas se tiene la descripcin de los casos de uso del Sistema de Informacin Web para el Control y Seguimiento de Activos Fijos (SISCAFW):

Tabla 3.5: Descripcin Caso de Uso Registrar Activo Fijo.

Caso de Uso 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 asignndole un cdigo, el mismo que es generado de forma automtica al seleccionar la ubicacin del mismo y tambin seleccionando el rubro y sub rubro al cual corresponde. Adems de introducir la informacin relevante del activo fijo de la incorporacin de un activo fijo. Flujo Bsico 1. Ingresar en el Men Administrar Activo Fijo(AF) 2. Ingresar al enlace de Registrar AF. 3. Seleccionar la Ubicacin (rea, Unidad, Programa, Sub Programa) 4. Seleccionar Rubro 5. Seleccionar Sub Rubro 6. Seleccionar Financiador 7. Introducir los datos y detalles del AF (descripcin, costo, estado). 8. Ingresar la ubicacin del bien y seleccionar al responsable para la asignacin del activo fijo. 9. Una vez confirmado los datos del activo fijo se realiza la incorporacin 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 seleccin de cada una de estas, se podr ingresar en el men Administracin de base de datos en donde se detalla otros sub mens 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 computacin, se tendr la siguiente secuencia de pasos: a) Seleccionar Rubro: Equipo de Computacin b) Seleccionar Sub Rubro: Microprocesador c) Ingresar la descripcin: 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 computacin 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 autentificacin 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, adems 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.

Descripcin

Flujo de Eventos

Precondiciones

Poscondiciones

Fuente: Elaboracin Propia.

Tabla 3.6: Descripcin Caso de Uso Registrar Tipo de Cambio.

Caso de Uso Registrar Tipo de Cambio El actor inicializador de este caso de uso es el encargado de la Unidad de Descripcin 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 Bsico 1. Ingresar el tipo de cambio de la moneda. 2. Pulsar el botn registrar para el ingreso de tipo de cambio a la fecha actual. Flujo de Eventos 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. El encargado de la Unidad de Activos Fijos debe realizar su Precondiciones correspondiente autentificacin 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: Elaboracin Propia.

Tabla 3.7: Descripcin Caso de Uso Actualizar y Depreciar Activo Fijo.

Caso de Uso Descripcin Actualizar y Depreciar Activo Fijo El actor inicializador de este caso de uso es el encargado de la Unidad de Activos Fijos. Realiza la actualizacin del activo fijo y su depreciacin Flujo de Eventos Flujo Bsico 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 actualizacin y depreciacin de activos fijos. Flujo Alternativo 1. En 4 negada la confirmacin de la actualizacin y depreciacin del activo fijo, retornar a la pantalla de actualizacin y depreciacin. Precondiciones El encargado de la Unidad de Activos Fijos debe realizar su correspondiente autentificacin 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 actualizacin y depreciacin de activos fijos.

Fuente: Elaboracin Propia.

Tabla 3.8: Descripcin Caso de Uso Revalu Activo Fijo. Caso de Uso Descripcin Revalu Activo Fijo El actor inicializador es el encargado de la Unidad de Activos Fijos. Deber realizar la verificacin necesaria de aquellos activos cuyo valor neto sea menor que 1 Bs. y sus aos de vida hayan llegado a 0 meses. Para ello el encargado deber de realizar el respectivo revalu tcnico que se necesite si el activo fijo aun posee utilidad. Flujo de Eventos Flujo Bsico 1. Ingresar al Men Administrar Activo Fijo. 2. Ingresar al enlace Revalu Activo Fijo. 3. Verifica el estado general del activo. 4. Verificar la depreciacin 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 tcnico de los activos fijos. Flujo Alternativo 1. En 6 si no se llegara a confirmar la aceptacin de registro de los nuevos datos del activo fijo, retornar a la pantalla de valu tcnico. Precondiciones El encargado de la Unidad de Activos Fijos debe realizar su correspondiente autentificacin para el ingreso al sistema. El encargado de la unidad debe observar el estado del activo fijo, verificar el valor neto y los aos de vida til del activo fijo. Poscondiciones El caso de Uso termina cuando el encargado de la Unidad Activos Fijos realiza el revalu tcnico del activo fijo.

Fuente: Elaboracin Propia.

Tabla 3.9: Descripcin Caso de Uso Baja de Activo Fijo.

Caso de Uso Descripcin Baja de Activo Fijo 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 verificacin necesaria de aquellos activos cuyo valor neto sea menor de 1 Bs. o sus aos 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 observacin que as lo amerite. Flujo de Eventos Flujo Bsico 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 depreciacin del activo fijo para obtener el valor neto. 5. Verificar que el valor neto es menor a 1 Bs, los aos 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 observacin por la cual se da de baja al activo fijo y la confirmacin de la misma, se registra la baja del activo. Flujo Alternativo 1. En 6 si no se llegara a confirmar la aceptacin 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 autentificacin 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: Elaboracin Propia.

Tabla 3.10: Descripcin Caso de Uso Generar Reportes. Caso de Uso Descripcin Generar Reportes 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 generacin de reportes de acuerdo a su requerimiento. Flujo de Eventos Flujo Bsico 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 informacin. 4. Seleccionar datos de las listas de seleccin 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 autentificacin 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: Elaboracin Propia.

3.3.2 Modelo de Diseo

3.3.2.1 Definicin 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 interaccin de los actores que fueron identificados y mencionados en este documento con los objetos del diseo a travs de la secuencia de mensajes entre los mismos. Figura 3.14: Diagrama de Secuencia Registrar Activo Fijo.
:IU Registrar activo fijo Encargado Unid AF Ingreasr Datos AF : Gestor de Registrar AF : UBICACION : RUBRO : SUB RUBRO : RESPONSABLE : FINANCIADOR ACTIVO FIJO

Seleccionar Ubicacion Obtener Ubicacion Seleccionar Rubro Seleccionar Sub Rubro Seleccionar Responsable Seleccionar Financiador Mostra Generacion de Cod Introducir(desc,estado, costo, obs) Grabar Datos Int Almacenar Nuevo Activo Fijo

Obtener Cod Rubro Obtener Cod SRubro Obtener Datos Res Ontener Datos del Fin

Fuente: Elaboracin Propia.

Figura 3.15: Diagrama de Secuencia Clculo de Actualizacin y Depreciacin.

:IU Actualizacion y Depreciacion Encargado Unid AF Seleccionar Actualizar y Depreciar Datos de Activo Fijo Obtiene Datos de AF Despliega Act y Dep Almacena Actualizacion y Depreciacion Gestor de Act y Dep : Activo Fijo Actualizacion y Depreciacion

Fuente: Elaboracin Propia.

Figura 3.16: Diagrama de Secuencia Baja de Activo Fijo.

:IU Baja de Activo Fijo Encargado Unid AF Ingreasr Datos AF Seleccionar Ubicacion Seleccionar Rubro Seleccionar Sub Rubro Mostra Lista de AF Seleccionar AF Ingresar Observacion Pulsar Boton Dar Baja AF Almacenar Baja de Activo Fijo Obtener Ubicacion Obtener Cod Rubro Obtener Cod SRubro Gestor Baja de AF : UBICACION : RUBRO : SUB RUBRO ACTIVO FIJO

Fuente: Elaboracin Propia.

Figura 3.17: Diagrama de Secuencia Registrar Tipo de Cambio.

:IU Registrar Tipo de Cambio Gestor de Tipo de Cambio Encargado Unid AF Ingresar Datos Tipo de Cambio Tipo de Cambio Desplegar mensaje de Confirmacion Almacenar Tipo de Cambio : Tipo de Cambio

Fuente: Elaboracin Propia. Figura 3.18: Diagrama de Secuencia Revalu Activo Fijo.
:IU Revaluo de AF Encargado Unid AF Ingresar Datos de AF Descripcion de AF Obtiene Datos de AF Obtiene Depreciacion Despliega Datos de AF Despliega Depreciacion de AF Almacenar Revaluo de AF Actualiza AF Gestor de Revaluo : Activo Fijo : Revaluo

Fuente: Elaboracin Propia.

3.3.2.2 Definicin del Diagrama de Estados

El siguiente diagrama de estado nos permite los estados y eventos ms 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 de menu

Solicitud de incorporacin Solicitud de depreciacin Solicita datos de AF a incorporar Solicita datos de AF a depreciar Solicitud de baja o revaluo Verifica estado de AF

Solicitud de reaignacin

Solicita datos de AF a reasignar

Introducir ubicacin Solicita ubicacion Verifica datos de AF

Introducir datos de AF solicita dato de AF Introducir datos de AF

Introducir datos de AF Efecta baja de AF

Introducir clasificador Solicita clasificador

Introducir fecha Solicita rango de fecha

Datos correctos efecta baja de AF

Datos correctos

Solicita datos de AF a Revaluar Solicita datos de AF

Datos correctos Genera codigo de AF

Datos correctos Realiza calculo de depreciacin Termina operacin Introducir datos de AF Solicita nuevo responsable Termina operacin Termina operacin

Graba informacion

Fuente: Elaboracin Propia.

3.3.2.3 Definicin de Diagramas Colaboracin En los diagramas de colaboracin, mostramos las interacciones entre los objetos creando entre ello y aadiendo mensajes a estos enlaces. Se identifican las clases de anlisis para llevar a cabo el flujo de sucesos del caso de uso.

Figura 3.20: Diagrama de Colaboracin Registrar Activo Fijo.

: Encargado Unid AF

1: Ingresar Datos AF 6: Rubro 7: Sub Rubro 8: Responsable 9: Financiador

2: Seleccionar Area 3: Seleccionar Unidad 4: Programa 5: Sub Programa 22: Grabar Datos

23: Almacenar Nuevo AF : IU Registrar activo fijo1 : Activo Fijo

20: Generar Codigo 18: Obtener Financiador : Gestor de Registrar AF : Financiador 12: Obtener Cod Unidad 17: Obtener Responsable 13: Obtener Programa 16: Obtener Cod SR 15: Obtener Cod Rubro : Responsable : Programa : Sub Rubro : Rubro : Sub Programa 14: Obtener Cod SP : Unidad 10: Obtener Cod Area : Area

Fuente: Elaboracin Propia.

Figura 3.21: Diagrama de Colaboracin Clculo de Actualizacin y Depreciacin.

: 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: Elaboracin Propia.

Figura 3.22: Diagrama de Colaboracin Baja de Activo Fijo.

: Encargado Unid AF

1: Ingresar Datos AF 6: Rubro 7: Sub Rubro

2: Seleccionar Area 3: Seleccionar Unidad 4: Programa 5: Sub Programa 17: Grabar Datos

15: Seleccionar AF 16: Ingresar Observacion

18: Almacenar Baja de AF : IU Baja activo fijo1 : Activo Fijo

14: Mostrar Lista de AF 8: Obtener Area : Gestor de Baja AF : Sub Rubro 9: Obtener Unidad : Area

13: Obtener SR

12: Obtener Rubro 11: Obtener SP : Rubro

10: Obtener Programa

: Unidad

: Sub Programa

: Programa

Fuente: Elaboracin Propia.

Figura 3.23: Diagrama de Colaboracin 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 Tipo de Cambio 4: Almacenar Tipo de Cambio : Tipo de Cambio

Fuente: Elaboracin Propia.

Figura 3.24: Diagrama de Colaboracin Revalu de Activo Fijo.

: Encargado Unid AF

1: Ingresar datos de AF

:IU Revaluo de AF

6: Despliega Dep de AF 2: Descripcion de AF 5: Despliega datos AF

3: Obtener Datos AF : Gestor de Revaluo 4: Obtiene Depreciacion 7: Almacenar Rev de AF 8: Actualiza AF : Activo Fijo

: Revaluo

Fuente: Elaboracin Propia.

3.3.2.4 Definicin del Diagrama De Clases

Figura 3.25: Diagrama de Clases del sistema SISCAFW

ActDep + + + + + ad_fecha_ini ad_fecha_fin valor_ant valor_act val_dep : Date : Date : float : float : float

Area Unidad + unid_nom : String + unid_sigla : String + adicionar () : void + eliminar () : void + listar () : void 1..1 1..* Programa + prog_nom : String + prog_sigla : String + adicionar () : void + eliminar () : void 1..1 1..* Personal + + + + + + + + + + + per_pat per_mat per_nom per_dir per_tel per_cel per_cargo adicionar () modificar () eliminar () listar () 1..1 + + + + + : String : String : String : String : int : int : String : void : void : void : void 1..1 + + + 1..* + + + 1..1 1..* Sub Programa + sprog_nombre : String + sprog_sigla : String + adicionar () : void + eliminar () : void 1..1 1..* 1..* 1..1 1..* 1..1 + area_nom : String + area_sigla : String + adicionar () : void + eliminar () : void + listar () : void

+ adicionar () : void + listar () : void + eliminar () : void 1..* + + + + Rubro rub_nom rub_sigla rub_aosVU rub_porcentajeDep : String : String : int : int

Tipo Cambio + tc_fech : Date + tc_val : float + adicionar () : void + listar () : void 1..1

+ adicionar () : void + eliminar () : void + listar () : void 1..1 1..*

1..1 Activo Fijo af_sigla af_descripcion af_costo af_estado af_fecha_ing af_observacion

1..* Sub Rubro : String : String : float : int : Date : String 1..* 1..1 + sr_nom : String + sr_sigla : String + adicionar () : void + eliminar () : void + listar () : void

+ adicionar () : void + listar () : void 1..1 1..1

1..1

Baja 1..* Revaluo rev_fech rev_valAF rev_estadoAF rev_obs rev_codTC : date : float : int : String : int 1..1 + baja_fecha : Date + baja_obs : String + adicionar () : void + listar () : void 1..* Reasignacion + + + + reasig_fecha reasig_nom reasig_codAF reasig_codRes : Date : String : int : int

1..* Usuario + + + + + + + + usu_nom usu_pasw usu_nivel usu_estado adicionar () eliminar () listar () modificar () : String : String : String : String : void : void : void : void

+ adicionar () : void + listar () : void

+ adicionar () : void + listar () : void

Fuente: Elaboracin Propia.

3.3.2.5 Transformacin del Modelo OO al Modelo E-R El proceso de transformacin del diagrama de clases definido para el sistema de informacin SISCAFW se detalla a continuacin: Figura 3.26: Diagrama Entidad Relacin del sistema SISCAFW
Unidad unid_cod area_cod unid_nom inid_sigla integer <pk> integer <fk> long varchar long .varchar Area . area_cod integer <pk> area_nom long varchar area_sigla long varchar ActDep ad_cod af_cod ad_fecha_ini ad_fecha_fin valor_ant valor_act val_dep integer <pk> integer <fk> date date float float float

Programa prog_cod unid_cod prog_nom prog_sigla . integer <pk> . integer <fk> long varchar long varchar

Sub Programa sprog_cod prog_cod sprog_nombre sprog_sigla integer <pk> integer <fk> long varchar integer . Tipo Cambio tc_cod integer <pk> tc_fech date tc_val float .

Rubro rub_cod rub_nom rub_sigla rub_aosVU rub_porcentajeDep . integer <pk> long varchar long varchar integer integer

Personal Programa prog_cod integer <fk2> per_cod integer <fk1> perp_cod integer <pk>

. Personal SubProg per_cod integer <fk1> sprog_cod integer <fk2> . per_sp_cod integer <pk>

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

. <pk> <fk1> <fk5> . <fk2> <fk3>

Sub Rubro sr_cod rub_cod sr_nom sr_sigla integer <pk> integer <fk> long varchar long varchar

. per_cod per_pat per_mat per_nom per_dir per_tel per_cel per_cargo

Personal integer <pk> long varchar long varchar long varchar long varchar integer integer long varchar

. Baja baja_cod integer <pk> baja_fecha datetime baja_obs long varchar Revaluo rev_cod rev_fech rev_valAF rev_estadoAF rev_obs rev_codTC af_cod integer <pk> date float integer long varchar integer integer <fk> Reasignacion reasig_cod reasig_fecha reasig_nom reasig_codAF reasig_codRes af_cod integer <pk> date long varchar integer integer integer <fk>

Usuario usu_cod per_cod usu_nom usu_pasw usu_nivel usu_estado

integer <pk> integer <fk> long varchar long varchar long varchar long varchar

Fuente: Elaboracin Propia

3.3.3 Modelo de Despliegue del Sistema

3.3.3.1 Definicin del Diagrama de Componentes El siguiente diagrama muestra la disposicin de las partes integrantes del sistema de informacin SISCAFW y las dependencias entre los distintos mdulos de la aplicacin, 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

<<hiperlink>> DepAct.html DepAct.php

Revaluo.html ActivosFijos.html

Revaluo.php

<<hiperlink>>

Baja.html

Baja.html

Index.html

MenuUsuario.html

AdminInstitucion.html

AdminInstitucion.php

<<hiperlink>>

<<hiperlink>> Rubro.html Rubro.html SubRubro.html SubRubro.php Rubro.php

Responsable.html <<hiperlink> > Financiador.html

Responsable.php

Financiador.php

Usuario.html

Usuario.php

Reportes.html

Reportes.php

TipoCambio.html

TipoCambio.html

Fuente: Elaboracin Propia

3.3.3.2 Definicin del Diagrama de Despliegue El sistema de informacin 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: Browser

PC2: Browser

PC1: Browser

Modem: Acceso a Internet

IN T E R N E T

Servidor: PC <<Base de Datos>> BD_SISCAFW Modem: Acceso a Internet.

SISCAFW: Menu de Usuario

Fuente: Elaboracin Propia

3.4 FASE DE CONSTRUCCION

En la fase de construccin las clases de la fase de diseo son convertidas a cdigo fuente en un lenguaje de programacin.

3.4.1 Implementacin de Interfaces

Las interfaces de del sistema para interactuar con el usuario se especifican a continuacin:

Figura 3.29: Interface de Ingreso al Sistema SISCAFW.

Fuente: Elaboracin 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: Elaboracin Propia. La presente pantalla es el men principal del encargado de Activos Fijos, el cual puede acceder despus de haberse autenticado.

Figura 3.31: Interface de Registro de Activo Fijo.

Fuente: Elaboracin Propia.

Esta pantalla permite al Encargado de AF el registro de un nuevo Activo Fijo a un subprograma y la asignacin a un responsable, considerando la generacin automtica del cdigo identificador del AF a partir de las caractersticas de: ubicacin (rea, Unidad, Programa y Sub Programa) y clasificacin (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 implementacin y despus de haber realizado las pruebas necesarias, dado que el mismo est en fusin a las necesidades de los usuarios y al ambiente de la Fundacin 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 ningn problema con el manejo y adaptacin del sistema.

a) Interfaz de Ingreso al Sistema

Este es el cdigo para la validacin del ingreso al sistema cuando el introduce su nombre de usuario y contrasea
<?php include_once("Conexion/conexion.php"); require_once("Clases/clases.php"); $vusr=$_GET['usr'];$vpsw=$_GET['psw'];$conex=fconectar(); $res=mysql_query("select usuNiv,usuEst,usuCod,usuCodPer from usuario where usuNom like '$vusr' and usuPas like '$vpsw'",$conex); $verr=mysql_error(); if ($f = mysql_fetch_array($res)) { do {session_start(); $_SESSION['usuNivel'] = $f[0];$_SESSION['usuEstado'] = $f[1]; $_SESSION['usuCodigo'] = $f[2];$_SESSION['usuCodigoPersona'] = $f[3]; if($_SESSION['usuEstado']==1) { if($_SESSION['usuNivel']==1) { $objTC=new TC;$fecha=date("Y-m-d");$num=$objTC->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 cdigo 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: insercin, actualizacin, eliminacin y consulta de la administracin de la informacin almacenada en la Base de Datos.
<?php require_once('../Clases/clases.php'); $objAF=new AF; $objSR=new SubRubro; $objTC=new TC; $afSig=trim($_GET['sigla']); $afDes=trim($_GET['descrip']); $afVal=trim($_GET['valor']); $afFecIng=trim($_GET['fecIng']); $afEst=trim($_GET['estado']);

$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 Introduccin
Se cuenta con herramientas para saber si nuestro sistema tiene calidad alta y baja, para tal efecto nos ayuda las medidas de calidad mostrndonos la calidad del software, siendo una compleja conjugacin de ndices y/o factores que varan para diferentes aplicaciones y los clientes que lo soliciten. Una evaluacin de producto no es una tarea sencilla y puede ser difcil considerar todas las caractersticas y atributos deseables de una aplicacin si no se cuenta con un modelo de calidad que permita especificar ordenadamente dichas caractersticas y atributos.

4.1.2 Funcionalidad
Se cuantifica el tamao y la complejidad del sistema en trminos de las funciones de usuario, puede ser valorado mediante la medida de punto funcin, se determina cinco caractersticas del dominio de informacin, tomando en cuenta su cantidad. La mtrica punto funcin se usa como medio para predecir el tamao del sistema que se va a obtener por medio de anlisis siendo una medida indirecta de software. Nmero 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 aplicacin. Nmero de salidas de usuario Las salidas se usuario se refieren a informes por pantalla, mensajes de error brindando informacin orientada al sistema.

Nmero de peticiones Es una entrada interactiva que produce la generacin de alguna respuesta de software en forma de salida interactiva. Nmero de Archivos Es un conjunto lgico de datos que puede ser parte de una gran base de datos o de archivos independientes. Nmero de interfaces Externas Es el numero de interfaces legibles por la maquina que se utilizan para transmitir informacin a otra mquina.

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: Elaboracin Propia

Tabla 4.2: Parmetros de Medicin

Parmetros de Medicin Nmero de entradas de Nmero de salidas de usuario Nmero de peticiones de usuario Nmero de archivos Nmero de interfaces externas Cuenta 21 23 13 15 5 Factor de Ponderacin Simple 3 4 3 7 5 Medio 4 5 4 10 7 Complejo 6 7 6 15 10 Total 84 115 52 150 35

Cuenta Total 436

Fuente: Elaboracin Propia

Tabla 4.3: Valores de ajuste de la complejidad

0 No Influencia 1 Incidencia 2 Moderado 3 Medio 4 Significativo 5 Esencial

Fuente: Elaboracin Propia

Tabla 4.4: Ajuste de complejidad del punto funcin Factor

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Requiere el Sistema de copias de seguridad y de recuperacin de datos fiables Se requiere de comunicacin de datos Existen funciones de procesamiento distribuido Es crtico el rendimiento Se ejecuta el Sistema en un entorno operativo existente Requiere el Sistema la entrada de datos de forma interactiva, mostrando mltiples pantallas u operaciones. Se actualizan los archivos maestros de forma automtica Son complejas la entradas, salidas o peticiones de usuario Es complejo el procesamiento interno Es compleja la utilizacin del Sistema Se ha diseado en cdigo para ser reutilizable Est incluida en el diseo la instalacin Se ha diseado para facilitar los cambios y sea de fcil uso para el usuario Se diseo el Sistema para soportar mltiples instalaciones en diferentes departamentos

Valor
5 4 4 5 5 4 3 3 3 3 4 4 4 5 56

Fuente: Elaboracin Propia

Para calcular puntos funcin:

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 Mximo= 436(0.65+0.01*70)= 588.60

Funcionalidad = (PF/PF Mximo)*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 deteccin y correccin de errores, a los cambios debido a los requerimientos del usuario a las adaptaciones requeridas a medida que evoluciona el software. El estndar IEEE982.1-1999 sugiere un ndice de madurez del software (IMS) que proporciona una indicacin de estabilidad de un producto software. La determinacin de este indicador es como sigue a continuacin:

IMS

Mt ( Fa Fc Mt

Fd )

Reemplazando en la formula con los siguientes datos MT=9, Fa=1, Fc=0 y Fd=0, se tiene:

IMS

9 (1 0 0) 9

0.889

Por lo tanto el ndice de madurez del software indica que el Sistema es maduro en un 88.9% por estar prximo 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 adaptacin a un entorno distinto o en el caso de que el cliente necesite algn cambio en la aplicacin.

4.1.4 PORTABILIDAD
De acuerdo a los factores de calidad la portabilidad es el esfuerzo necesario para transferir una aplicacin de un entorno Sistema Hardware y/o Software a otro [PRESS, 2005]. El sistema de informacin SISCAFW por estar diseado para un entorno de acceso va 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 ms Memoria RAM 256 MB o ms Disco Duro 40 GB o ms 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 estndar ISO-9126 define la Usabilidad como la capacidad de un producto de software de facilitar a usuarios especficos alcanzar metas especificas con eficacia, productividad, seguridad y satisfaccin en un contexto especifico de uso. Aade que calidad en uso es la visin 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 relacin a la usabilidad tiene la caracterstica de ser compresible adems 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 gestin de activos fijos de la Fundacin La Paz. La usabilidad y facilidad de uso se logro conforme se hacan 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 mtrica nos muestra el costo de aprender a manejar el producto, lo cual se calcula con la siguiente frmula.

Donde: Es el puntaje de evaluacin de cada pregunta Es el nmero de preguntas que se realiz Es el puntaje mximo que se da en la evaluacin Tabla 4.5: Descripcin de la escala de evaluacin Descripcin de la escala de Evaluacin Psimo 1 Malo 2 Regular 3 Bueno 4 Muy Bueno 5 Fuente: Elaboracin Propia Se debe formular las siguientes preguntas: Tabla 4.6 Ajuste de Preguntas N
1 2 3 4 5

Preguntas
El sistema satisface los requerimientos de manejo de informacin? Las salidas del requerimientos? sistema estn de acuerdo a sus

Evaluacin
4 5 4 4 5 22

Cmo considera el ingreso de datos al sistema? Cmo considera los formularios que elabora el sistema? El sistema facilita el trabajo que realiza? TOTAL

Fuente: Elaboracin Propia

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 especificacin, usualmente formal, de un conjunto de entradas de prueba, condiciones de ejecucin y resultados esperados, identificados con el propsito de hacer una evaluacin de aspectos particulares de un caso de uso determinado. Figura 4.1: Caso de Prueba Registrar Activo Fijo
Caso de Prueba de Aceptacin Cdigo Caso de Prueba:01 Cdigo Caso de Uso:01

Descripcin de la Prueba: Registrar Activo Fijo. Registra los datos del Activo asignndole un cdigo, el mismo que es generado de forma automtica al seleccionar la ubicacin del mismo y tambin seleccionando el rubro y sub rubro al cual corresponde. Adems de introducir la informacin relevante del activo fijo de la incorporacin de un activo fijo. Condiciones de Ejecucin: Debe encontrarse de la pantalla principal haber elegido del men la opcin de Activo Fijo, Registrar Entrada / Pasos de Ejecucin: Elegir la opcin de ubicacin (rea, Unidad, Programa, Sub Programa). Se desplegar los rubros y sub rubros que pertenecen a esta ubicacin. Elegir el rubro y sub rubro al cual pertenece el Activo Fijo. Introducir los datos de Precio, Estado, Financiador, fecha de ingreso, responsable, ubicacin y observacin Presionar el botn Incorporar. Aparece un mensaje de Confirmacin. Presionar el botn Aceptar. Resultado Esperado: Registra la incorporacin del Activo Fijo en la Base de Datos. Evaluacin de la Prueba: El registro de la incorporacin del Activo Fijo es satisfactoria.

Fuente: Elaboracin Propia

Figura 4.2: Caso de Prueba Registrar Activo Fijo

Caso de Prueba de Aceptacin Cdigo Caso de Prueba:02 Cdigo Caso de Uso:02

Descripcin 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 Ejecucin: Debe ser la primera vez que ingresa al sistema en el da el encargado de Activos Fijos y haberse identificado como usuario. Entrada / Pasos de Ejecucin: Aparece asignado la fecha actual. Ingresar el tipo de cambio de la moneda y la observacin. Pulsar el botn 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. Evaluacin de la Prueba: El registro del tipo de cambio es satisfactorio.

Fuente: Elaboracin Propia

4.2.2 Pruebas de Caja Blanca

Para las pruebas de caja blanca se utilizara la mtrica de McCabe para hallar la complejidad ciclomtica V(G), el cual nos permite determinar el nmero 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 segn 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

Mensaje de Error

Datos del AF, Ubicacion y Responsable No Comprobar Datos

Verificar Datos Si Confirmacion de Registro

Verificar Confirmacion

Si Almacenar Datos

No Mensaje Datos Registrados

FIN

Fuente: Elaboracin Propia.

Figura 4.4: Grafo de Flujo Registro de Activos Fijos.

Figura 4.5: Grafo de Flujo Simplificado de Activos Fijos.

Fuente: Elaboracin Propia.

Fuente: Elaboracin Propia. Segn el grafo de flujo presentado en la figura 4.3 se procede al clculo de la complejidad ciclomtica en funcin de la siguiente relacin:

Reemplazando con los siguientes datos: n=3 se tiene:

Este resultado determina el nmero 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 operacin 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 adems 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 sealando 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 travs de la interfaz de usuario introdujo y selecciono lo datos correspondientes al bien y adems efectu la confirmacin del almacenamiento y registro de los datos, el sistema despliega un mensaje indicando que los datos fueron almacenados correctamente. La verificacin de cada camino comprueba la finalidad y el objetivo con el cual fue diseado desde el punto de vista lgico, es decir, la comprobacin 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 Informacin 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 mdulos 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 mdulos del sistema SISCAFW. Pruebas de Integracin, esta prueba se realiza cuando todos los mdulos estn desarrollados para luego integrarlos y posteriormente realizar la prueba general del sistema. Pruebas del Sistema, una vez integrados todos los mdulos se procede a la prueba del sistema con datos e informacin real de la empresa. Pruebas de Implantacin, 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 das posteriores a la implantacin para evaluar la evolucin del sistema. Pruebas de Aceptacin, pasado el periodo de prueba se espera la aceptacin del nuevo sistema de informacin SISCAFW por parte de los funcionarios de la Fundacin 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 Informacin Web para el Seguimiento y Control de Activos Fijos: Fundacin La Paz, llego a su conclusin de forma satisfactoria, cumpliendo con todos los requisitos especificados en la etapa de anlisis, 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 especficos. Se puede afirmar que la implementacin del presente sistema, ha mejorado el desempeo en la Unidad de Activos Fijos de la Fundacin La Paz, es decir mejoro la gestin de Activos Fijos en cuanto a: la incorporacin, baja, reasignacin, revalu, actualizacin y depreciacin de Activos Fijos. Por otra parte el Sistema de Informacin Web para el Seguimiento y Control de Activos Fijos: Fundacin La Paz presenta ventajas en cuanto a: o Tiempo de respuesta ptimo en cada proceso. o Bajos costos y tiempo reducido en la obtencin de reportes. Tomando en cuenta a la seguridad del sistema en un determinado nivel, se ha implementado una interface de autentificacin y control para el ingreso de usuarios, en donde se tiene determinados usuarios del sistema. El logro de los objetivos tanto general y especficos se debe tambin a la colaboracin que nos brinda el empleo del Proceso Unificado de Racional (RUP) para un enfoque detallado, claro y eficiente del anlisis diseo, modelado y construccin 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). restricciones a los mdulos, para

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 debern implementar los vnculos necesarios para la interaccin 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 capacitacin al usuario respectivo encargado del manejo de activos fijos, esto para el buen manejo de la informacin de valor y del propio sistema. Adems es recomendable realizar una evaluacin constante con el fin de garantizar la fiabilidad de la misma, realizar un mantenimiento preventivo y de adaptacin del sistema con el fin de mejoras funcionales y adaptacin del software a su entorno. Se recomienda al usuario del sistema cambiar su contrasea, para no sufrir ningn contratiempo al momento de ingreso al sistema, ya que existe el riesgo de que esta contrasea sea descubierta. En consideracin a ello es necesario el cambio de la contrasea en un intervalo de tiempo corto (mensual, semestral) para una mayor seguridad.

BIBLIOGRAFIA

BIBLIOGRAFA
[JACOB, 2000] Jacobson, I., Booch, G. y Rumbaugh, J., El Proceso Unificado de Desarrollo de Software, Pearson Educacin, 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 Educacin, Madrid, 2000. [LARMAN, 1999] Larman, G., UML y Patrones. Introduccin al anlisis y diseo orientado a objetos, Prentice Hall, Mxico, 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 Educacin, Madrid, 2000. [FUNES, 2003] [PRESS, 2005] Funes, J., Contabilidad Intermedia, Sabidura, Bolivia, 2003. Pressman, R. S., Ingeniera del Software. Un enfoque prctico, 5 ed., McGraw-Hill, 2003. [FLP, 2006] Reglamento para el Control de Activo Fijo de la Fundacin La Paz, 2006. [RUEDA, 2006] Rueda Chacn Julio C., Aplicacin de la metodologa RUP para el Desarrollo Rpido de Aplicaciones basado en el Estndar J2EE, Guatemala, 2006.
[FOWLER, 1999]

Fowler Martin, Kendall Scott, UML Gota a Gota, Pearson Educacin, Mxico, 1999.

[NBSABS, 2000]

Decreto Supremo No. 25964 Normas Bsicas del Sistema de Administracin de Bienes y Servicios (NB-SABS).

[RESABS, 2003]

Reglamento Especfico del Sistema de Administracin de Bienes y Servicios (RE-SABS).

[SAFCO, 1990]

Ley de Administracin y Control Gubernamentales (Ley 1178, SAFCO).

REFERENCIAS WEB Diseo 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 Autentificacin PHP http://www.desarrolloweb.com/manuales/37/ Cdigo PHP para Mltiples utilidades http://www.forosdelweb.com Consultas ms 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 ORGNICA

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 REPBLICA TTULO III SUBSISTEMA DE MANEJO DE BIENES CAPTULO I ASPECTOS GENERALES ARTCULO 75.- (CONCEPTO). El Subsistema de Manejo de Bienes, es el conjunto interrelacionado de principios, elementos jurdicos, tcnicos 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 minimizacin de los costos de sus operaciones. ARTCULO 76.- (ALCANCE). Las presentes Normas Bsicas se aplicarn para el manejo de bienes de uso y consumo institucional de propiedad de la entidad y los que estn a su cargo o custodia. El manejo de bienes de los productos que sean resultado de servicios de consultoras, software y otros similares, sern regulados en la reglamentacin de las presentes Normas Bsicas. ARTCULO 77.- (EXCEPCIONES). Se encuentran fuera del alcance de las presentes Normas Bsicas: a) Los bienes de dominio pblico. b) El material blico de las Fuerzas Armadas. c) Los bienes declarados patrimonio histrico y cultural. El manejo de estos bienes estar sujeto a reglamentacin especial, que podr tomar como referencia el contenido de las presentes Normas Bsicas en las partes afines a su operacin y control. ARTCULO 78.- (COMPONENTES). Los componentes del Subsistema de Manejo, son los siguientes: a) Administracin de almacenes. b) Administracin de activos fijos muebles. c) Administracin de activos fijos inmuebles. ARTCULO 79.- (RESPONSABILIDAD POR EL MANEJO DE BIENES). I. El responsable de la Unidad Administrativa, es el responsable principal ante la Mxima Autoridad Ejecutiva: a) Por el manejo de bienes en lo referente a la organizacin, 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 aplicacin del rgimen de penalizaciones por dao, prdida o utilizacin indebida. b) Por la adecuada conservacin, mantenimiento y salvaguarda de los bienes que estn a cargo de la entidad. c) Porque la entidad cuente con la documentacin legal de los bienes que son de su propiedad o estn a su cargo, as como de la custodia y registro de esta documentacin en las instancias correspondientes. d) En caso necesario, solicitar a la Unidad Jurdica de la entidad el saneamiento de la documentacin legal pertinente. e) Por el envo de la informacin 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 pblicos son responsables por el debido uso, custodia, preservacin y demanda de servicios de mantenimiento de los bienes que les fueren asignados, de acuerdo al rgimen de Responsabilidad por la Funcin Pblica, establecido en la Ley 1178 y sus reglamentos. ARTCULO 80.- (INCLUSIN 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 efecte en funcin de los objetivos de gestin de la entidad. ARTCULO 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 devolucin, utilizando los registros correspondientes como fuente de informacin. Para efectuar este control, la Unidad Administrativa debe: a) Realizar inventarios y recuentos peridicos, 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 documentacin legal y registro de los bienes. II. Para la elaboracin de la informacin relacionada con el manejo de bienes, se utilizarn registros e informes. a) Los registros permanentemente actualizados y debidamente documentados permitirn: i. Verificar fcil y rpidamente la disponibilidad de los bienes. ii. Evaluar el curso y costo histricos de los bienes. iii. Conocer su identificacin, clasificacin, codificacin y ubicacin. iv. Conocer las condiciones de conservacin, deterioro, remodelaciones, etc., as como las de tecnologa y obsolescencia en que se encuentran los bienes. v. Verificar la documentacin legal sobre la propiedad y registro de los bienes de la entidad, as como de los asignados, alquilados, prestados, etc., a cargo de la institucin. vi. Establecer responsabilidad sobre el empleo de los bienes y la administracin de las existencias. b) Los informes permitirn describir y evaluar la situacin de los bienes en un momento dado. ARTCULO 82.- (TOMA DE INVENTARIOS). I. La toma de inventarios es el recuento fsico 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 mtodos generalmente aceptados. II. Las entidades pblicas desarrollarn reglamentos, procedimientos y/o instructivos para el recuento fsico de los bienes de consumo, activos fijos muebles y activos fijos inmuebles, en los que considerarn inventarios peridicos, planificados y sorpresivos, con los objetivos de: a) Establecer con exactitud la existencia de bienes en operacin, trnsito, arrendamiento, depsito, mantenimiento, desuso, inservibles, sustrados, siniestrados, en poder de terceros. Identificando adems fallas, faltantes y sobrantes. b) Proporcionar informacin sobre la condicin y estado fsico de los bienes. c) Ser fuente principal para realizar correcciones y ajustes, establecer responsabilidades por mal uso, negligencia y descuido o sustraccin. d) Verificar las incorporaciones y retiros de bienes que por razones tcnicas 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 informacin bsica para la disposicin de bienes. h) Programar adquisiciones futuras. ARTCULO 83.- (BIENES ADQUIRIDOS CON FINANCIAMIENTO EXTERNO).

Para el manejo de bienes adquiridos con financiamiento externo, se utilizarn los Reglamentos Especficos de las entidades y las presentes Normas Bsicas, si el convenio de financiamiento no dispone lo contrario.

ARTCULO 84.- (BIENES DONADOS O TRANSFERIDOS). I. Los bienes de uso o consumo que perciba una entidad por concepto de donacin y/o transferencia, debern ser recibidos por la Comisin de Recepcin conformada de acuerdo al Artculo 16 de las presentes Normas Bsicas, la misma que debe levantar un acta detallando el tipo de bien, cantidad y especificaciones tcnicas de los mismos. II. El responsable de almacenes o el responsable de activos fijos debe adjuntar copia del convenio de donacin o transferencia y acta de recepcin, al documento de ingreso a almacenes o activos fijos, segn corresponda, continuando con los procedimientos regulados en las presentes Normas Bsicas. CAPTULO III ADMINISTRACIN DE ACTIVOS FIJOS MUEBLES ARTCULO 104.- (CONCEPTO). La administracin de activos fijos muebles, es la funcin administrativa que comprende actividades y procedimientos relativos al ingreso, asignacin, mantenimiento, salvaguarda, registro y control de bienes de uso de las entidades pblicas. ARTCULO 105.- (OBJETIVO). Tiene por objetivo lograr la racionalidad en la distribucin, uso y conservacin de los activos fijos muebles de las entidades pblicas. ARTCULO 106.- (ALCANCE). Las disposiciones contenidas en este Captulo, se aplicarn a todos los activos fijos muebles de propiedad de la entidad y los que estn a su cargo o custodia. ARTCULO 107.- (ORGANIZACIN PARA LA ADMINISTRACIN DE ACTIVOS FIJOS MUEBLES). I. Las entidades crearn una unidad especializada en la administracin de activos fijos, si la magnitud de estos lo amerita. En caso de no existir una unidad especializada, se debe asignar la funcin a un servidor pblico determinado. II. La organizacin de las actividades de activos fijos muebles estar basada en las caractersticas de las operaciones de distribucin, salvaguarda, mantenimiento y control de los bienes de uso. III. En caso necesario, se utilizarn depsitos y bodegas, bajo responsabilidad de la unidad o el servidor pblico responsable de activos fijos. Las bodegas y depsitos debern 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 administracin de activos fijos muebles. ARTCULO 108.- (RECEPCIN). I. La recepcin de estos bienes para su incorporacin al activo fijo de la entidad, ser realizada por la unidad o responsable de activos fijos, aplicndose de manera similar las normas sobre recepcin de bienes a almacenes, reguladas en los Artculos 89 y 90 de las presentes Normas Bsicas. II. La recepcin de bienes a cargo de la entidad o bajo su custodia, debe estar respaldada por los documentos de asignacin, prstamo de uso, alquiler o arrendamiento, etc. ARTCULO 109.- (ASIGNACIN DE ACTIVOS FIJOS MUEBLES). I. La asignacin de activos fijos muebles es el acto administrativo mediante el cual se entrega a un servidor pblico 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 pblicos slo 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 Especfico. ARTCULO 110.- (DOCUMENTO DE ENTREGA).

I. La constancia de entrega de un bien se realizar en forma escrita, en la que el servidor pblico receptor exprese su conformidad mediante firma. II. La unidad o responsable de activos fijos, debe mantener registros actualizados de los documentos de entrega y devolucin de activos. ARTCULO 111.- (LIBERACIN DE LA RESPONSABILIDAD). I. Para ser liberado de la responsabilidad, el servidor pblico 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 rgimen de Responsabilidad por la Funcin Pblica, establecida en la Ley 1178 y sus reglamentos. II. El servidor pblico ser responsable por el debido uso, custodia y mantenimiento, de los bienes a su cargo, mientras se encuentre en instalaciones de la entidad pblica, prestando servicios. III. El rea Administrativa, es responsable de ejecutar las acciones necesarias para proporcionar los mecanismos idneos para asegurar la custodia de los bienes asignados a los servidores pblicos. ARTCULO 112.- (CODIFICACIN). I. Para controlar la distribucin de los bienes, la Unidad de Activos Fijos adoptar sistemas de identificacin interna, mediante cdigos, claves o smbolos que: a) Permitan la identificacin, ubicacin 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 fsico. II. La codificacin de activos fijos muebles, debe basarse en normas nacionales y en ausencia de stas en normas internacionales. ARTCULO 113.- (INCORPORACIONES AL REGISTRO DE ACTIVOS FIJOS MUEBLES). La incorporacin de bienes muebles al activo fijo de la entidad, consiste en su registro fsico y contable. Se producir despus de haber sido recepcionados por el responsable de activos fijos o por la comisin de recepcin. ARTCULO 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 mnimo: a) La existencia fsica debidamente identificada, codificada y clasificada. b) La documentacin que respalda su propiedad o tenencia. c) La identificacin del usuario y dependencia a los que est asignado. d) El valor del bien, depreciaciones y revalorizaciones. e) Reparaciones, mantenimientos, seguros, etc. f) La disposicin temporal. g) La disposicin definitiva y baja, de acuerdo al Subsistema de Disposicin de Bienes. ARTCULO 115.- (REGISTRO DEL DERECHO PROPIETARIO). I. Los activos fijos muebles como los vehculos 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 coordinacin con el asesor legal. II. La Unidad o responsable de activos fijos, deber efectuar seguimiento y control sobre el saneamiento de la documentacin legal de los vehculos y motorizados de la entidad, informando al responsable de la Unidad Administrativa. ARTCULO 116.- (MANTENIMIENTO DE ACTIVOS FIJOS MUEBLES). I. El mantenimiento, es la funcin especializada de conservacin tcnica que se efecta a los activos, para que permanezcan en condiciones de uso.

II. El responsable de la Unidad Administrativa, debe establecer polticas y procedimientos de mantenimiento para promover el rendimiento efectivo de los bienes en servicio, evitando su deterioro incontrolado, averas u otros resultados indeseables que pongan en riesgo la conservacin del bien. ARTCULO 117.- (DEMANDA DE SERVICIOS DE MANTENIMIENTO). Los servidores pblicos que tienen asignado un bien sern responsables de demandar con la debida anticipacin, servicios de mantenimiento preventivo para que estos sean previstos en el (POA) de cada entidad. ARTCULO 118.- (SALVAGUARDA DE ACTIVOS FIJOS MUEBLES). I. La salvaguarda es la proteccin de los bienes contra prdidas, robos, daos 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 implantacin de las medidas de salvaguarda. III. La unidad o responsable de activos fijos, en funcin del valor e importancia de los bienes de la entidad, tiene la obligacin de: a) Solicitar la contratacin de seguros para prevenir riesgos de prdida econmica. b) Fortalecer permanentemente los controles de seguridad fsica e industrial, para el uso, ingreso o salida de los bienes, dentro o fuera de la entidad, velando adems porque stos no sean movidos internamente, ni retirados sin la autorizacin y el control correspondiente. c) Formular y aplicar los reglamentos e instructivos especficos de seguridad fsica e industrial. IV. Las actividades y tareas de salvaguarda deben ser incorporadas por la Unidad Administrativa en el POA de cada entidad. ARTCULO 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 autorizacin, 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. ARTCULO 120.- (PROHIBICIN PARA LOS SERVIDORES PUBLICOS SOBRE EL USO ACTIVOS FIJOS MUEBLES). I. Los servidores pblicos 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 pblico. d) Enajenar el bien por cuenta propia. e) Daar o alterar sus caractersticas fsicas o tcnicas. f) Poner en riesgo el bien. g) Ingresar bienes particulares sin autorizacin de la unidad o responsable de activos fijos. h) Sacar bienes de la entidad sin autorizacin 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. CAPTULO IV ADMINISTRACIN DE ACTIVOS FIJOS INMUEBLES ARTCULO 121.- (CONCEPTO). La administracin de activos fijos inmuebles, es la funcin administrativa que comprende actividades y procedimientos inherentes al uso, conservacin, salvaguarda, registro y control de edificaciones, instalaciones y terrenos. ARTCULO 122.- (OBJETIVO). La administracin de activos fijos inmuebles tiene por objetivo lograr la racionalidad en el uso y conservacin de las edificaciones, instalaciones y terrenos de las entidades pblicas, preservando su integridad, seguridad y derecho propietario.

ARTCULO 123.- (ALCANCE). Las disposiciones de este Captulo se aplicarn a todos los bienes inmuebles de propiedad de la entidad y los que estn a su cargo o custodia. ARTCULO 124.- (ORGANIZACIN PARA LA ADMINISTRACIN DE ACTIVOS FIJOS INMUEBLES). I. El responsable de la Unidad Administrativa, delegar la administracin de bienes inmuebles a la Unidad de Activos Fijos. En caso de no existir sta, se asignar a un servidor pblico determinado. II. La unidad o responsable de activos fijos, debe cumplir y hacer cumplir las disposiciones establecidas para el efecto. III. La organizacin de las actividades de activos fijos inmuebles estar basada en las caractersticas de las operaciones de mantenimiento, salvaguarda y control de estos bienes. IV. Las entidades pblicas desarrollarn procedimientos y/o instructivos para la administracin de activos fijos inmuebles. ARTCULO 125.- (RECEPCIN DE INMUEBLES). I. La recepcin de inmuebles para su incorporacin al activo fijo ser realizada por la Comisin de Recepcin, conformada de acuerdo al Artculo 16 de las presentes Normas Bsicas. II. Se realizar la recepcin provisional, en forma obligatoria, en la misma que deber verificarse e inventariar las instalaciones y ambientes que formen parte del inmueble, adems de exigir toda la documentacin tcnica y legal del mismo. Desde la recepcin provisional hasta la recepcin definitiva, se evaluarn las condiciones tcnicas del inmueble, debiendo adems ejercitarse las garantas de eviccin y vicios, de acuerdo a Ley. III. La recepcin de un inmueble ser definitiva cuando la comisin levante un acta en el que exprese su conformidad y sirva de recibo a quin entreg el bien. ARTCULO 126.- (INCORPORACIN AL REGISTRO DE ACTIVOS FIJOS INMUEBLES). La incorporacin de bienes inmuebles al activo fijo de la entidad, consiste en su registro fsico y contable, acompaado de la documentacin tcnico - legal de los mismos. Se producir despus de haber sido recibido en forma definitiva por la Comisin de Recepcin. ARTCULO 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 coordinacin 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 documentacin tcnico legal de los bienes inmuebles, informando al responsable de la Unidad Administrativa. ARTCULO 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, segn corresponda: a) Caractersticas del bien inmueble, consignando superficie, edificaciones, instalaciones, as como la historia de modificaciones, ampliaciones o reducciones que hubiera experimentado. b) Documentacin legal del derecho propietario. c) Documentacin tcnica que acredite la situacin del terreno, diseos, planos de construccin e instalaciones, planos de instalaciones sanitarias y elctricas y otros que considere la entidad. d) Valor del inmueble, depreciaciones y revalorizaciones. e) Refacciones, mantenimientos, seguros, etc. f) Disposicin temporal. g) Disposicin definitiva y baja, de acuerdo al Subsistema de Disposicin de Bienes. ARTCULO 129.- (ASIGNACIN DE INSTALACIONES Y AMBIENTES).

I. La asignacin de instalaciones y ambientes a cada unidad de la entidad, as como su acondicionamiento para el cumplimiento de los objetivos de dichas unidades, es funcin de la Unidad Administrativa. II. La asignacin estar en funcin de las demandas y caractersticas de la actividad que realiza cada unidad y de la disponibilidad de la entidad, evitando la subutilizacin 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 preservacin de su funcionalidad. ARTCULO 130.- (MANTENIMIENTO DE INMUEBLES). El mantenimiento es la funcin de conservacin tcnica especializada que se efecta 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 peridicas sobre el estado y conservacin de los inmuebles. b) El responsable de la Unidad Administrativa, en coordinacin 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 condicin de funcionalidad. ARTCULO 131.- (SALVAGUARDA). I. La salvaguarda es la proteccin de los bienes inmuebles contra daos, deterioro y riesgos por la prdida 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 obligacin de implantar medidas de salvaguarda, debiendo: a) Solicitar la contratacin de seguros contra incendios, inundaciones, desastres naturales y los que la entidad considere pertinentes. b) Establecer medidas de vigilancia y seguridad fsica. c) Establecer medidas de seguridad industrial. d) Mantener saneada y resguardada la documentacin tcnico legal de los bienes inmuebles de la entidad. ARTCULO 132.- (INSPECCIONES Y CONTROL FISICO DE INMUEBLES). I. Es obligacin de la Unidad de Activos Fijos realizar inspecciones peridicas sobre el estado y conservacin de los inmuebles. II. Estas inspecciones deben permitir controlar y precisar la situacin real de los inmuebles en un momento dado, y prever las decisiones que se deben tomar en el corto, mediano y largo plazo. ARTCULO 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 disposicin sealada en las presentes Normas Bsicas. 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: Elaboracin 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 da. Figura: Interface Ventana del Registro de Rubro

Fuente: Elaboracin Propia. Esta pantalla permite al encargado de AF registrar el rubro del Activo Fijo.

Figura: Interface del Registro del Sub Rubro.

Fuente: Elaboracin 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: Elaboracin 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: Elaboracin Propia.

Esta pantalla permite registrar al encargado de AF a aquellas personas que sern los responsable de un Activo Fijo, dando a detalle a que subprograma corresponde.

ANEXO E
GLOSARIO DE TERMINOS El glosario de trminos define e incluye todos los trminos adems de una descripcin textual de los elemento del modelo, esto para evitar que exista la posibilidad de ambigedad en la comprensin de los trminos utilizados. Se define la siguiente tabla de trminos utilizados con el fin de registrar todos los trminos usados en las fases siguientes: Activo Fijo TIPO Bien de uso con el cual se cuenta dentro de la institucin, el cual sirve para el desarrollo de las actividades. Actualizacin de Activo CASO DE USO Es la valoracin de un activo fijo de acuerdo a una determinada fecha y cotizacin desde su fecha de adquisicin. Asignacin de Activo CASO DE USO Es la asignacin de un bien de uso al personal dentro de un sub programa. Depreciacin de Activo CASO DE USO Es el clculo de prdida 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 Computacin TIPO Es un tipo de activo fijo Personal ACTOR Es una determinada persona fsica cuya relacin es laboral dentro de la institucin. Financiador ACTOR Es una determinada persona fsica cuya relacin con la institucin en la de donar o en su caso financiar econmicamente la adquisicin de bienes. Encargado de la Unidad de Activos Fijos ACTOR Es una determinada persona fsica cuya relacin dentro de la institucin es la de gestionar y controlar el manejo de bienes de la institucin.

Historial TIPO Es el registro de todos los procesos a los cuales fue sometido un determinado bien de uso a lo largo de su vida til. Registro de Financiadores CASO DE USO Es la recopilacin de los datos correspondientes a los financiadores y que el sistema requiere para gestionar el origen de los bienes. Asignacin de Activos CASO DE USO El es proceso por el cual se realiza la asignacin de los bienes solicitados al personal que custodiar el bien. Baja de Activos Fijos CASO DE USO Es el proceso que se efecta para el retiro de un bien en funcin de una determinada causa detectada. Revalu CASO DE USO Es el proceso de la modificacin del estado del activo fijo y sus principales caractersticas. Clasificacin de Activos Fijos TIPO Es la identificacin de bien segn los rubro. Rubro TIPO Es un tipo de clasificador segn la caracterstica del activo fijo. Sub rubro. TIPO Es un tipo de clasificador segn la caracterstica del rubro al cual pertenece el AF.