MANUALCEMENTERIO

UNIVERSIDAD MAYOR FACULTAD DE INGENIERIA SANTIAGO DE CHILE

DISEO E IMPLEMENTACION DE UNA SOLUCION INFORMATICA PARA LA GESTION EN

CEMENTERIOS MUNICIPALES

Profesor Gua: Igor Caracci Marabol, Profesor de estado de Matemticas y estadsticas, Doctor (c) en Ingeniera en Computacin.

Nombres alumnos: Marcela Andrea Gonzlez Daz Luis Eduardo Cifuentes Quintanilla

Santiago de Chile Agosto 20102

INDICERESUMEN ....................................................................................................................... 8 ABSTRACT ..................................................................................................................... 9 CAPITULO I .................................................................................................................. 10 INTRODUCCION.......................................................................................................... 10 1.1 1.2 1.3 1.4 1.5 1.6 Planteamiento y Justificacin del problema ................................................... 13 Objetivo General............................................................................................. 14 Objetivos Especficos ..................................................................................... 14 Metodologa.................................................................................................... 14 Alcances y limitaciones .................................................................................. 16 Resultados esperados...................................................................................... 17

CAPITULO II................................................................................................................. 18 ESTADO DEL ARTE .................................................................................................... 18 2.1 2.1.1 2.1.2 2.1.3 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 SISTEMA DE INFORMACION ADMINISTRATIVO (SIA)...................... 18 Funciones de un Sistema de Informacin....................................................... 18 Clasificacin de los Sistemas de Informacin................................................ 21 Ciclo de Vida de un Sistema de Informacin ................................................. 25 UML ............................................................................................................... 26 PROGRAMACION ORIENTADA A OBJETOS. ........................................ 30 CONTROL DE GESTION............................................................................. 31 Caractersticas del control de gestin ............................................................. 32 Clasificacin del Control de Gestin.............................................................. 32 Elementos que integran el control de gestin................................................. 33 Indicadores de gestin .................................................................................... 34 Proceso de construccin de indicadores de gestin........................................ 36 Modelo de indicadores de gestin KPI........................................................... 36

CAPITULO III ............................................................................................................... 38 DEFINICION DE REQUERIMIENTOS....................................................................... 38 3.1 REQUERIMIENTOS PARA SISTEMA COMPUTACIONAL DE CEMENTERIOS MUNICIPALES. ......................................................................................................... 38 3.1.1 Requisitos funcionales .....................................................................................38 3

3.1.2 Requerimientos no funcionales........................................................................41 CAPITULO IV ............................................................................................................... 42 ANALISIS Y DISEO DEL SISTEMA ....................................................................... 42 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 4.4 ANALISIS DEL DOMINIO DEL PROBLEMA........................................... 42 Modelo conceptual preliminar...................................................................42 Modelo del Dominio..................................................................................43 Glosario de Conceptos...............................................................................44 CASOS DE USO ............................................................................................ 48 Actores.......................................................................................................48 Diagrama de caso de uso: General del sistema..........................................49 Descripcin de Alto Nivel. ........................................................................50 Descripcin esencial o expandida. ............................................................52 DIAGRAMAS DE SECUENCIA. ................................................................. 64 Diagrama de secuencia: Registrar Venta...................................................65 Diagrama de secuencia: Registrar Libro de Inhumacin...........................66 Diagrama de secuencia: Registrar Reclamos.............................................67 Diagrama de secuencia: Administrar Propietario......................................68 Diagrama de secuencia: Administrar Sepulturas.......................................69 Diagrama de secuencia: Controlar Gestin Cementerio............................70 Diagrama de Secuencia: Administrar Usuarios.........................................71 Diagrama de Secuencia: Validar Usuario..................................................72 DIAGRAMA DE CLASES ............................................................................ 73

CAPITULO V ................................................................................................................ 74 PROTOTIPO .................................................................................................................. 74 5.1 5.2 5.3 5.4 5.5 5.6 5.7 Pantalla Control de acceso.............................................................................. 74 Pantalla men principal .................................................................................. 75 Pantalla de Registro de ventas. ....................................................................... 76 Pantalla de administracin Sepulturas............................................................ 77 Formulario Informacin Sepulturas................................................................ 78 Pantalla formulario Administracin de Reclamos.......................................... 79 Pantalla formulario Libro de inhumacin....................................................... 80

4

5.8 5.9 5.10 5.11

Pantalla Control de Gestin............................................................................ 81 Pantalla de Administracin propietarios. ....................................................... 82 Pantalla de administracin de Usuarios.......................................................... 83 Pantalla de Ingreso de U.T.M......................................................................... 84

CAPITULO VI ............................................................................................................... 85 CONCLUSIONES.......................................................................................................... 85 ANEXOS ........................................................................................................................ 87 Anexo 1 Reglamento Municipal..............................................................................................87 Fuente: I. Municipalidad de Melipilla ......................................................................93 Anexo 2 Resumen peridico de Recaudacin .........................................................................94 Anexo 3 Reporte impreso de recaudacin acumulada ............................................................95 Anexo 4 Organigrama de los cementerios Municipales..........................................................96 Anexos 5 Diagrama de caso de uso: Ventas .............................................................................97

INDICE DE TABLAS Tabla 1 Distribucin de Poblacin por Edades. ................................................................11 Tabla 2 ndices de Natalidad y mortalidad. Fuente: Servicio Reg. Civil e identificacin Ministerio de Justicia Chile ........................................................................................12 Tabla 3 Concepto del dominio del problema.....................................................................47

INDICE DE FIGURAS Fig. 1 Distribucin porcentual de Poblacin por Edades. Fuente: www.infopais.cl.........11 Fig. 2 ndice de Natalidad y mortalidad. Fuente: Servicio Reg. Civil e identificacin Ministerio de Justicia Chile ........................................................................................12 Fig. 3 Modelo de Dominio ................................................................................................43 Fig. 4 Diagrama de caso de uso General del sistema. .......................................................49

5

Fig. 5 Diagrama de secuencia Ventas................................................................................65 Fig. 6 Diagrama de secuencia Registrar Libro de inhumacin..........................................66 Fig. 7 Diagrama de secuencia Registrar Reclamos ...........................................................67 Fig. 8 Diagrama de secuencia Administrar Propietario.....................................................68 Fig. 9 Diagrama de secuencia Administrar Sepultura .......................................................69 Fig. 10 Diagrama de secuencia Controlar Gestin Cementerio ........................................70 Fig. 11 Diagrama de secuencia Administrar Usuarios ......................................................71 Fig. 12 Diagrama de secuencia Validar Usuario ...............................................................72 Fig. 13 Diagrama de Clases general del sistema ...............................................................73 Fig. 14 Pantalla de Ingreso de usuario y contrasea..........................................................74 Fig. 15 Pantalla principal Sistema de gestin Cementerio ................................................75 Fig. 16 Pantalla de Registro de venta ................................................................................76 Fig. 17 Pantalla de formulario de administracin Sepulturas............................................77 Fig. 18 Pantalla de Informacin de sepulturas ..................................................................78 Fig. 19 Pantalla de Libro de reclamos ...............................................................................79 Fig. 20 Pantalla de Libro de inhumacin...........................................................................80 Fig. 21 Pantalla de control de Gestin...............................................................................81 Fig. 22 Pantalla de administracin de propietarios............................................................82 Fig. 23 Pantalla de formulario de administracin de usuarios ..........................................83 Fig. 24 Pantalla de ingreso de UTM..................................................................................84 Fig. 25 Caso de Uso Ventas ..............................................................................................97 Fig. 26 Caso de Uso Administrar Indicadores de Gestin ................................................98 Fig. 27 Caso de Uso Manejo de propietarios.....................................................................99

6

AGRADECIMIENTOS

Marcela Gonzlez Si se trata de agradecer quisiera partir por quien hizo que hoy este ac, a quien le ha dado fortaleza y razn a mi vida, es ms a quien me amo sobre todo, a mi mamita Emperatriz por su apoyo incondicional y por el gran amor que me da da a da, tambin quisiera agradecer a mi compaero, amigo y amor de mi vida, Rodrigo por su apoyo incondicional amor y conocimientos entregados, a mi sobrinito Pedrito por dar motivacin y la mayor alegra a mi vida. Finalmente quiero agradecer a todos mis amigos y familia por su apoyo y por insistirme constantemente en seguir hasta el final, a Eduardo por apoyarme y motivarme da a da, gracias por ser un excelente compaero y por tolerarme, por supuesto agradecer a nuestro profesor gua Igor, que sin el nada hubiese sido posible, gracias por escucharnos, ensearnos, darnos de su tiempo y por sobre todo por motivarnos y apoyarnos.

Luis Cifuentes Agradecer hoy y siempre a mi padre Luis por su gran fortaleza, apoyo y empuje, ya que sin su ayuda mis estudios y carrera no hubiesen sido posible, a mi hermana Carola, por su cario y siempre desinteresada ayuda, a mi sobrina Aracelli, que con su hermosa sonrisa ayuda a aliviar los mal pasares, a toda mi familia, amigos y compaeros de carrera que siempre me han dado palabras de entusiasmo y perseverancia, para terminar mis estudios. A mis amigos Leo, Fabin, Niko, Daniel, y a sus familias que siempre, de alguna manera u otra, me han brindado ayuda durante mi carrera y en la vida en general.

A nuestro profesor gua, que con su dedicacin y conocimientos nos sirvi de gran apoyo para la finalizacin de este proyecto de titulo, a la seora Emperatriz, por su siempre motivadora y generosa hospitalidad, a Rodrigo por su constante ayuda y grandes aportes a nuestros conocimientos, y por supuesto a Marcela, que con sus conocimientos, dedicacin y motivacin ayudaron en todo momento para hacer un excelente y entretenido grupo de trabajo, mil y mil gracias.

7

RESUMEN

La presente tesis titulada Diseo e implementacin de una solucin informtica para la gestin en cementerios municipales, se cre bajo la premisa que la red de cementerios municipales hoy no cuenta con un sistema centralizado y de fcil utilizacin, y por tanto, la deja fuera de una competencia real. La problemtica planteada no abarca solo a un cementerio sino a un conjunto de ellos, motivo por el cual es fundamental incorporar metodologa que permitan el desarrollo de un sistema informtico integral y reutilizable, para este proyecto se ha utilizado la metodologa iterativa e incremental de modo que sea posible ir modificando a lo largo del camino los requerimiento del sistema; el proyecto ha sido realizado de tal manera de cumplir cabalmente con los objetivos definidos en la primera etapa de requerimientos, implementado metodologas de desarrollo de software orientado a objeto y modelamiento de lenguaje unificado (UML), considerando ello, se crea un producto de software de fcil utilizacin y fiable, optimizando notablemente las tareas de vendedores y administrativos, adems de desarrollar una herramienta para el control de gestin apoyando al rea de administracin de los cementerios. Cabe destacar que la metodologa de desarrollo de software que se aplica y que posteriormente se entregar para su desarrollo e implementacin permite ser adaptable a cualquier software de desarrollo orientado a objeto; ya que con este proyecto se pretende brindar en principio el apoyo a cementerios en forma local y en un futuro cubrir la red de cementerios municipales. Los contenidos se han estructurado en cinco captulos. El captulo I en el que se entrega una Introduccin, la que incluye los antecedentes generales en el que se encuentra hoy Chile en el plan estadsticos, en entorno al mercado objetivo, tambin la identificar de la problemtica actual e indicar que se espera con la construccin de este sistema. En el captulo II se describe el estado del arte, en el cual se entregar toda la base terica para el desarrollo de este sistema; en el capitulo III se detectan y enumeran las funcionalidades del sistema, realizando el estudio de requerimientos. En el captulo IV se efecta el anlisis de los requerimientos obteniendo diagramas que bosquejan la solucin informtica planteada. En el captulo V se muestra un prototipo bsico del como se espera opere el sistema. Llegando finalmente al capitulo VI en el cual se muestran las conclusiones y evaluacin del proyecto realizado.

8

ABSTRACT

The present thesis titled Design & Implementation of a Computing Solution for Municipal Cemeteries Management has been created based on the fact that the current network of municipal cemeteries lacks a friendly and centralized system which deprives it from the actual competition. The problem exposed here involves not only one cemetery, but a grouping of them. For this reason, the implementation of methodologies to help developing an integrated and reusable computing system is essential. In this project, interactive and incremental methodologies have been used in order to allow changes according to future system requirements. The project has been made to fully fulfill the objectives defined in the first stage of requirements through the implementation of software-developing methodologies oriented to object and Unified Modeling Language (UML). Taking this into consideration, we have created a friendly and reliable software product that remarkably optimizes sellers and clerks duties and also offer a management tool that supports cemeteries administration. Notice that the applicable methodology of software development that will be delivered for development and implementation, allows being adapted to any development software oriented to object, as this project primarily, intends to provide support to local cemeteries but also, to the entire cemetery network in the future. The contents are contained in five chapters; Chapter I provide an introduction including general background and statistics of the current situation for the targeted market in Chile; identifies the present problems and explains what can be expected by setting-up this system. Chapter II describes the state-of-the-art which will provide the whole theoretical base in order to develop this system. Chapter III identifies and enumerates the system functionalities by performing the requirements study. In chapter IV the analysis of the requirements is performed and diagrams are obtained which outline the proposed computing solution. On chapter V, the expected working prototype of the system is showed. Finally chapter VI evaluates the project and provides conclusions.

9

CAPITULO I

INTRODUCCION

En un mundo en que la incertidumbre est siempre presente, contar con informacin de calidad, en el momento oportuno y con un costo menor al beneficio probable que reportar, sin lugar a dudas, es una variable de diferenciacin entre los competidores directos y una fuente para maximizar las utilidades frente al entorno econmico y social de la organizacin. Asimismo, contar con una solucin informtica que es la que se propondr a lo largo de la presente investigacin es un aspecto fundamental para apoyar la toma de decisiones de los ejecutivos y generar valor en la institucin o compaa segn sea su naturaleza.

Actualmente la red de cementerios municipales al ser entendida como un servicio pblico tiene como misin Proveer a las familias chilenas de un servicio confiable y accesible de proteccin y cobertura funeraria que les otorgue tranquilidad y seguridad

A fin de comprender el mercado o sector industrial en el que se inserta este servicio pblico, se describirn algunas variables que muestran tendencias relevantes en este; entre ellas la poblacin en la regin Metropolitana, distribucin de la poblacin por edades, llegando finalmente a los ndices de natalidad y mortalidad.

A) Poblacin en la regin metropolitana Considerando los dos ltimos censos de poblacin y vivienda, se puede constatar que entre 1992 y 2002 la poblacin de la Regin Metropolitana creci a una tasa promedio anual de 1,42 personas por cada cien habitantes, lo cual la ubica entre las cuatro regiones del pas con mayor crecimiento durante el perodo 1992-2002. An cuando la Regin ha disminuido en los ltimos aos su velocidad de crecimiento demogrfico, su tasa media anual de incremento poblacional sigue siendo mayor que la tasa promedio del pas que en igual perodo que alcanz a 1,24 personas por cada cien habitantes. En cifras absolutas, la Regin Metropolitana 10

pas de 5.257.937 a 6.061.185 personas, lo que representa un aumento de 803.248 personas en los ltimos diez aos (13,2% de variacin intercensal). En cuanto a la dinmica de crecimiento demogrfico a nivel comunal, destaca en la Provincia de Santiago la comuna de Quilicura la que registra una tasa de crecimiento promedio anual de 11,24%, seguida por las comunas de Maip y Lo Barnechea con un 6,02% y 4,01%, respectivamente. En la Provincia de Cordillera destaca la comuna de Puente Alto con una tasa promedio de crecimiento de 6,6%; en tanto que en las Provincias de Chacabuco y Maipo, son las comunas de Lampa y Calera de Tango las que presentan un mayor incremento poblacional con un 4,74% y 4,32%, respectivamente. Para las Provincias restantes, Melipilla y Talagante, las tasas de crecimiento que se registran son algo menores, siendo las comunas de Curacav y Talagante las que presentan un incremento ms acelerado de su poblacin, con un 2,43% y 2,86%, respectivamente.

B) Distribucin de Poblacin por Edades La distribucin de poblacin del ao 2007 en la regin Metropolitana, se estimo en 23,3% de la estaba entre los 0 y 14 aos, el 64.9 % entre los 15 y 59 y el 11.8% tiene 60 o ms aos.

Grupos de edades0 a 14 aos 15 a 50 aos 60 o ms aos

Estimacin porcentual23,3 % 64,9 % 11,8 %

Tabla 1 Distribucin de Poblacin por Edades. Fuente Instituto Nacional de Estadsticas

Fig. 1 Distribucin porcentual de Poblacin por Edades. Fuente: www.infopais.cl

11

C) ndice de Natalidad y Mortalidad El 40,6% de los nacimientos que se registran en la Regin Metropolitana, 11,5% en Biobo y 9,4% en Valparaso, aportando estas tres regiones en conjunto el 61,5% del total de nacimientos. Las restantes regiones aportan entre menos de 1 (Aisn) y algo menos de 6 (Maule y Araucana) nacimientos vivos por cada cien del total de nacidos del pas. Por otra parte, las defunciones del pas registran el 38,0% se registraron en la Regin Metropolitana, 12,7% en Biobo y 11,7% en Valparaso. Las regiones con el menor aporte porcentual a las defunciones son Aisn con 0,5% y Magallanes y Antrtica, con 1,0%.

Regin Nacimientos Fallecimientos 38% 40,60% Metropolitana 11,50% 12,70% Bio Bio 11,70% 9,40% Valparaso 38,50% 37,60% Otras regiones Tabla 2 ndices de Natalidad y mortalidad. Fuente: Servicio Reg. Civil e identificacin Ministerio de Justicia Chile

90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Series2 Series1

Fig. 2 ndice de Natalidad y mortalidad. Fuente: Servicio Reg. Civil e identificacin Ministerio de Justicia Chile

12

1.1 Planteamiento y Justificacin del problema

El presente proyecto se origina en la necesidad actual de la Red de Cementerios Municipales de la Regin Metropolitana de contar con un sistema de informacin computacional integral que permita lograr una gestin eficiente, eficaz para brindar informacin clara y oportuna a los diferentes stakeholders1

En este sentido el proyecto considera el diseo y desarrollo de un prototipo de un sistema de administracin electrnica que permita registrar, clasificar, buscar y recuperar eficientemente la informacin crtica y relevante en torno a la gestin de los cementerios. En este aspecto, el sistema, contar con una base de datos segura y confiable que permita reducir los tiempos de almacenamiento, reemplazar el trabajo fsico de administracin de archivos e innecesario de documentos, automatizar los procesos de trabajo y la generacin de documentos entre otras.

Esta solucin administrar una base de datos con un nico acceso para realizar una gestin integral que incorpora la gestin financiera, cliente y funeraria.

El primer concepto incluye la recaudacin, cobranzas, manejo de impuestos y gestin de convenios por productos y servicios. Por otra parte, la gestin de clientes est orientada a la retro-alimentacin, a travs de un libro de sugerencia y reclamos y por ltimo la gestin funeraria referida a obtener informacin sobre el registro histrico de propiedades sepulcrales.

Gracias a las prestaciones de bsqueda y automatizacin que la solucin presenta, el sistema podr otorgar una solucin eficiente a los distintos requerimientos.

1 Se entiende por Stakeholders, toda aquella persona, grupo, empresas, la comunidad y la sociedad en cuanto tienen intereses en la existencia de una empresa pblica o privada. Son los grupos que tiene inters en que la empresa sobreviva. Estos grupos de inters (personas u organizaciones) pueden afectar o verse afectados por las decisiones de la empresa publica o privada de la que estn interesados

13

1.2 Objetivo General

El objetivo general de este proyecto es contar con un sistema de informacin computacional integral que permita llevar a cabo el control de gestin que sustente la toma de decisiones en forma eficiente, eficaz y efectiva2 de las autoridades municipales en la prestacin y gestin de este tipo de servicio.

1.3 Objetivos Especficos

Para llevar a cabo el objetivo general se desprenden los siguientes objetivos especficos:

Definir el estado del arte, etapa en la cual se reunir la informacin documental necesaria para entregar una base terica sobre la cual se basar el siguiente proyecto.

Identificar requerimientos de informacin, de esta manera se pretende tener un mejor enfoque del problema contextualizando las necesidades planteadas por el solicitante del sistema.

Disear y analizar el sistema, de esta manera se pretende dar una solucin al problema planteado y el cmo se debe desarrollar.

Desarrollar un prototipo del sistema para entregar una visin preliminar al sistema futuro que se implantar.

1.4 Metodologa

La metodologa utilizada para la elaboracin del proyecto ser de tipo iterativo e incremental, es decir, a medida que avanza el desarrollo del sistema se incorporarn las distintas mejoras que vayan surgiendo y de esta forma ir corrigindolo y mejorndolo. En definitiva, mejorar gradualmente la versin, las capacidades y las funcionalidades del sistema a partir de los requerimientos definidos.

2 Segn Mosher Frederick la eficiencia consiste en lograr los mximos resultados u objetivos organizacionales al menor costo, energa y tiempo. La eficacia esta orientada a lograr los objetivos propuestos sin importar el cmo y por ltimo la efectividad consiste en lograr satisfaccin de la necesidades del grupo objetivo al que esta orientada la solucin

14

Es decir, la metodologa utilizada para el diseo y, por tanto, para el desarrollo del sistema se basar principalmente en el proceso unificado de desarrollo de software (UP)3 y se utilizarn elementos del lenguaje unificado de modelamiento (UML)4, para ello se manejar como herramienta Enterprise Architect 7.5.

El proceso comienza con la captura de requisitos, que describir las funcionalidades y caractersticas que ofrecer el sistema, luego continuar con la etapa de anlisis y diseo donde se definirn las funciones lgicas para la realizacin del sistema (Diagramas). Posteriormente la etapa de desarrollo la cual contempla la construccin de un prototipo de los mdulos funcionales e interfaces de usuarios definidas en el diseo. La etapa de implementacin se generar en forma posterior al anlisis y no ser considerado en este proyecto de titulo, sin embargo, cabe destacar que en la etapa de diseo las interfaces quedarn definitivas, al igual que el modelo de la base de datos fsica.

Por otra parte, este sistema ser implementado sobre una plataforma multiusuario, cliente/servidor, con aplicaciones funcionales bajo el sistema operativo Windows, con la utilizacin de documentos generados en Microsoft Excel, soportado sobre una base datos MySQL. El prototipo de la aplicacin ser desarrollada bajo lenguaje de programacin Microsoft Visual Basic 6.0, la interfaz con el usuario ser a travs de formularios en ambiente Windows haciendo de est una aplicacin atractiva y sencilla de utilizar.

3 El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental 4 Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables.

15

1.5 Alcances y limitaciones

Respecto a este aspecto se han definido los siguientes alcances y limitaciones del proyecto, los cuales son:

El sistema abarcar la gestin financiera, gestin clientes y gestin funeraria El proyecto se basar en la normativa y ordenanzas legales municipales existentes. La arquitectura a utilizar ser cliente servidor, donde los clientes realizarn funciones de: o Manejo de la interfaz de usuario. o Captura y validacin de los datos de entrada. o Generacin de consultas e informes sobre las bases de datos. Por su parte el servidor realizar las siguientes funciones: o Gestin de perifricos compartidos. o Control de accesos concurrentes a bases de datos compartidas. Los usuarios se conectarn al servidor de base de datos mediante una red de rea local. El sistema no emitir documentacin electrnica. El sistema permitir el registro de los pagos en totalidad o en abonos. El sistema permitir el registro de los pagos en efectivo o documentos. El sistema no requerir la conexin con otros sistemas. El sistema generar informes diarios, mensuales, semestrales y anuales de los ingresos. Se realizar un prototipo del sistema.

16

1.6 Resultados esperados

Una vez desarrollado cada objetivo especfico se espera contar con los siguientes resultados: Sistematizacin de la informacin actual. Contar con informacin centralizada. Optimizar procesos administrativos crticos. Dar una solucin tecnolgica de apoyo administrativo. Crear un acceso gil, seguro y de alta disponibilidad. Optimizar el servicio de acceso y consultas por parte del rea financiera y comercial para responder a las necesidades de los clientes. Facilitar la generacin de distintos tipos de reportes que permitan realizar control de gestin.

17

CAPITULO II

ESTADO DEL ARTE

En el estado del arte se buscar definir y explicar los conceptos ms relevantes que se utilizarn en el transcurso del presente proyecto de titulacin.

2.1 SISTEMA DE INFORMACION ADMINISTRATIVO (SIA)

Existen muchas definiciones del concepto brindada por distintos autores, sin embargo, todos ellos coinciden en la importancia que tienen en cuanto proporcionan informacin a los administradores en apoyo de las actividades de planeacin, control y toma de decisiones, por medio de una gran variedad de informes o reportes de la gestin que se procesa en una organizacin.

2.1.1

Funciones de un Sistema de Informacin

Los sistemas de informacin difieren en sus tipos de entradas y salidas, en el tipo de procesamientos y en su estructura. Estos elementos estn determinados por el propsito u objetivos del sistema, el cual es establecido a su vez, por la organizacin y en todos ellos podemos encontrar un conjunto de funciones que son:

a) Procesamiento de Transacciones: La cual consiste en capturar o recolectar, clasificar, ordenar, calcular, resumir y almacenar los datos originados por las transacciones, que tienen lugar durante la realizacin de actividades en la organizacin.

b) Definicin de Archivos: Consiste en almacenar los datos capturados por el procesamiento de transacciones, de acuerdo a una estructura u organizacin de almacenamiento adecuado (base de datos o archivo) un mtodo que facilite su

18

almacenamiento,

actualizacin

y

acceso,

y

un

dispositivo

apropiado

de

almacenamiento (disco, cintas, CD, y otros).

c) Mantenimiento de Archivos: Los archivos o bases de datos del sistema deben mantenerse actualizados. Las operaciones bsicas de mantenimiento son la insercin, la modificacin y la eliminacin de datos en los medios de almacenamiento.

d) Generacin de Reportes: La realizacin de esta funcin es esencial para el sistema de informacin, ella se encarga de producir la informacin requerida y trasmitirla a los puntos o centros de informacin que la soliciten. Esta transmisin de informacin se puede efectuar mediante el movimiento fsico de los elementos de almacenamiento (cintas magnticas, CD, y otros) o mediante la comunicacin de seales elctricas digitales o analgicas a dispositivos receptores (terminales, convertidores, estaciones remotas u otro computador). Los reportes que genera el sistema de informacin se clasifican en:

1) Reportes de Errores: Proporcionan informacin sobre los errores que ocurren y se detectan durante el procesamiento de transacciones.

2) Reportes de Actividades: Proporcionan informacin sobre las actividades elementos de la organizacin. No estn orientados a la toma de decisiones. Por ejemplo. Listados de empleados, listados de inventarios de piezas, y otros.

3) Reportes Regulares: Estn orientados a la toma de decisiones. Se preparan a intervalos definidos de tiempo y en un formato fijo, por lo que se pueden generar automticamente.

4) Reporte de Excepcin: tiles para controlar situaciones anormales pues sealar la ocurrencia de condiciones fuera de limite. Tienen un formato predefinido y se pueden generar automticamente bajo solicitud o cuando ocurra la condicin anormal.

19

5) Reportes no Planeados: Requeridos eventualmente para la toma de decisiones. Se generan cuando se solicitan y pueden tener un formato predefinido.

6) Reportes Especiales: Requeridos generalmente una sola vez con fines de analizar situaciones o resolver problemas involucran el uso de modelos que respondan a interrogantes del tipo que ocurre si No tienen formato predefinido y pueden o no generarse automticamente. Los dos primeros reportes son producidos por los subsistemas de procesamiento de transacciones, mientras que los restantes los producen los subsistemas de procesamientos de informacin.

e) Procesamientos de Consultas: Parte de la informacin requerida por los usuarios responde a interrogantes no predefinidas y cuyas respuestas son generalmente cortas por lo que no requiere un formato complejo como el de los reportes. Estas interrogantes reciben el nombre de consultas interactivas y constituyen un medio directo de comunicacin hombre-mquina. Esta funcin es generalmente ejecutada por los subsistemas de administracin de datos que facilita el acceso a los datos y de procesamiento de informacin. La mayora de los sistemas de manejo de bases de datos que existen, poseen una herramienta que facilita la realizacin de esta funcin, denominada lenguaje de consultas o de interrogacin o lenguajes para el dilogo hombre-mquina.

f) Mantenimiento de la Integridad de los Datos: Los datos mantenidos por el sistema de informacin deben ser confiables y veraces por lo que una de sus funciones debe garantizar la integridad de tales datos y protegerlos contra accesos indebidos o no autorizados y contra modificaciones mal intencionadas.

20

2.1.2

Clasificacin de los Sistemas de Informacin

Una organizacin generalmente posee ms de un tipo de sistemas de informacin, cada uno de ellos tiene sus propias caractersticas y cada uno juega un rol fundamental en el logro de la satisfaccin de necesidades de informacin de dicha organizacin. La mayora de estos sistemas estn interrelacionados, no necesariamente integrados, bien en forma directa en respuesta a los requerimientos de sus diseos, o en forma indirecta debido a la comunicacin formal o informal de informacin entre ellos.

En general, varios autores estn de acuerdo en la existencia de dos tipos de sistemas de informacin en cualquier organizacin, que son:

1) Sistema de Informacin Formal: Basados en un conjunto de normas, estndares y procesamientos que permiten que la informacin se genere y llegue a quien la necesita en el momento deseado. La informacin formal puede ser producida por el computador.

2) Sistema de Informacin Informal: Estn basados en la comunicacin no formalizada ni predefinida entre las personas de la organizacin. Este tipo de sistema no tiene estructuras y no sigue normas o procesamientos establecidos porque su informacin puede ser bastante imprecisa, irregular e incierta, imposibilitndose as el procesamiento automtico.

Una clasificacin de los sistemas de informacin de una organizacin, en base a su naturaleza y objetivos, se puede hacer de la siguiente manera:

1) Sistemas de Comunicacin: Transmiten informacin entre diferentes subsistemas de una organizacin. Estos subsistemas pueden ser personas de la organizacin o equipos electrnicos (computadores, terminales, impresoras, entre otros). La informacin producida como salida por uno o varios de estos subsistemas puede ser utilizada como datos de entrada por otros de ellos, por lo que la interface entre dos

21

subsistemas es el mensaje que se trasmite. Se establece de este modo toda una red de comunicacin de informacin entre los diferentes subsistemas de la organizacin. El objetivo de esta red es impartir conocimiento, ideas, percepciones, propiedades, rdenes y datos organizados entre los subsistemas que lo componen.

2) Sistemas de Informacin Informal: Es una red no estructurada de comunicacin informal entre personas dentro o en el ambiente de la organizacin. Este tipo de sistemas surge del contacto entre las personas orientadas a satisfacer sus necesidades de informacin relativas al trabajo o hacia el deseo de todo individuo de conocer lo que ocurre en el ambiente (rumores, chismes, entre otros). No tiene un objetivo definido, aunque puede ser utilizado como medio muy eficiente, pero poco confiable, de transmisin y divulgacin de informacin til a la organizacin.

3) Sistemas de Informacin Organizacional: Formados por los flujos o canales de informacin que transmiten mensajes entre los diferentes niveles de planificacin, pasando por los de control, hasta los operacionales. El sentido de la comunicacin puede ser de arriba hacia abajo o viceversa. Los mensajes trasmitidos estn relacionados con los objetivos, metas, planes polticas, procedimientos, normas, estndares, directivas e instrucciones u rdenes para ejecutar las tareas de la organizacin (sentido de arriba hacia abajo), as como con los resultados, rendimiento, alcance, productividad, entre otros, originados al ejecutar la tareas (sentido de abajo hacia arriba). Por consiguiente, el objetivo de este tipo de sistema de informacin es transmitir las directivas organizacionales desde los niveles gerenciales hacia los operativos y proveer la informacin de retroalimentacin necesaria para controlar la organizacin. La comunicacin en este tipo de sistemas es de tipo verbal o escrita por lo que la automatizacin de informacin organizacional es difcil y quizs necesaria.

4) Sistemas de Informacin Operativos: Son definidos como sistemas de informacin que recogen, mantienen y procesan los datos ocasionados por la realizacin de operaciones bsicas en el de preparar y mantener los registros de datos

22

originados por las operaciones elementales (rutinarias) de la organizacin. Ejemplo de ello son los sistemas de nminas de pago, los sistemas de contabilidad, los sistemas de adquisicin de datos y los sistemas de reservacin de pasajes. El carcter rutinario de las operaciones de una organizacin hace que este tipo de sistema pueda ser fcilmente automatizado. De hecho, una gran mayora de sistemas de informacin existentes en la actualidad corresponden a este tipo.

5) Sistemas de Informacin Gerencial: Es un tipo de sistema que proporciona la informacin necesaria para que gerentes o directivos puedan ejecutar los procesos de toma de decisiones y solucin de problemas en una organizacin. El objetivo de este tipo de sistemas es proporcionar a los gerentes informacin confiable a tiempo y completa, relacionada con el rendimiento y estado de la organizacin. Muy a menudo, los datos de entrada de este sistema son producidos por el sistema de informacin operario, el cual, a su vez puede ser subconjunto del sistema de informacin gerencial.

Las salidas del sistema estn constituidas fundamentalmente por 2 tipos de reporte:

1- Reporte de Actividad, necesarios para determinar el rendimiento de las actividades que toman lugar en la organizacin durante un cierto periodo de tiempo (Ej. Reporte de Ejecucin Presupuestaria, Reporte de Ventas, Estados de Ganancia y Prdidas, entre otros). 2- Reporte de Estado, utilizados para determinar las condiciones de los diferentes subsistemas o elementos de la organizacin en un momento dado de tiempo (Ej. Balance General, Listado de Inventario, Listado de Empleados, Estadsticas, entre otros).

6) Sistemas de Apoyo para la Toma de Decisiones: Es un tipo muy especial de sistema de informacin caracterizado por procesar datos para realizar automticamente parte o el proceso de toma de decisiones e indicar la accin que se debe tomar para mantener a la organizacin dentro de condiciones normales de funcionamiento. En el

23

rea gerencial su objetivo es ayudar al gerente en el proceso de toma de decisiones permitindole evaluar, mediante el uso de modelos automatizados de decisin, control, simulacin, entre otras diferentes alternativas.

7) Sistemas de Procesamiento de Datos: El procesamiento de datos es parte fundamental e implica la mayora de sistemas de informacin discutidos anteriormente. Sin embargo, existe un tipo de sistema de informacin cuyo objetivo exclusivo es transformar datos en informacin fcil de entender y utilizar la informacin producida para que pueda ser utilizada por el usuario con algn fin especifico en la realizacin de sus tareas o actividades. Este tipo de sistemas recibe el nombre de sistema de procesamiento de datos. Algunos de los ms conocidos son los sistemas de anlisis de datos estadsticos (SAS, SPSS, y otros), y los procesadores de texto o palabras (RUN OFF, EASYWRITER, entre otros).

24

2.1.3

Ciclo de Vida de un Sistema de Informacin

Un sistema de informacin tiene un origen (nacimiento), generalmente ocasionado por necesidades, a partir del cual se emprende su desarrollo que va desde la definicin, del proyecto hasta la puesta en operacin (Crecimiento) seguidamente se inicia su operacin u mantenimiento por un perodo mayor a los dems durante el cual alcanza el mximo rendimiento posible (maduracin). Luego, factores tales como la dinmica de la organizacin, los avances tecnolgicos y las presiones externas o internas vuelven obsoleto e ineficaz al sistema (decaimiento), lo cual origina su paralizacin (muerte). En este ltimo perodo se toma la decisin de renovar el sistema. Lo que origina un nuevo ciclo de vida, o desecharlo por completo, lo cual marca su fin definitivo. Los perodos relevantes del ciclo de vida de un sistema de informacin se pueden agrupar en las siguientes etapas:

Surgimiento de necesidades. Desarrollo. Operacin y Mantenimiento. Disposicin (Renovacin o Extincin).

Estas etapas, a su vez, se dividen en fases, las fases en actividades y las actividades en tareas, estas dos ltimas producen la evaluacin del sistema.

25

2.2 UMLUML (Unified Modeling Language) es un lenguaje para especificar, construir, visualizar y documentar los sistemas software. Con UML se tiene un lenguaje visual para el modelado, pero no un lenguaje visual de programacin, es decir, a partir de l no se deriva el cdigo en algn tipo de lenguaje de programacin. Algunos elementos del software (bucles, saltos) quedan mucho mejor expresados con el propio cdigo fuente, pero la arquitectura y estructura del sistema se puede expresar y comprender perfectamente a partir del lenguaje UML. Con esta metodologa se cubrirn las etapas de desarrollo software de anlisis, diseo, programacin y testeo.

Haciendo una breve historia, se puede decir que el desarrollo de UML comenz en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software comenzaron a trabajar en la unificacin de los lenguajes de modelado Booch y OMT, es entonces cuando fueron reconocidos mundialmente a la cabeza del desarrollo de metodologas orientadas a objetos. Fue entonces cuando terminaron su trabajo de unificacin obteniendo el borrador de la versin 0.8 del denominado Unified Method en octubre de 1995. Tras esto tambin en 1995, Ivar Jacobson padre de la metodologa OOSE se uni con Rational Software para obtener finalmente UML 0.9 y 0.91 en junio y octubre de 1996. Tras esto muchas organizaciones como Microsoft, Hewlett- Packard, Oracle, Sterling Software MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjectTime, Platinum Technology, Ptech, Taskon, Reich Technologies, Softeam. Se asociaron junto con Rational Software para dar como resultado UML 1.0 y UML 1.1. Llegando hoy en da hasta UML 1.4 y UML 2.0.

Se eligi UML (Unified Modeling Language) ya que es una herramienta que permite realizar anlisis bajo un lenguaje claro para especificar, construir, visualizar y documentar los sistemas, para as obtener un buen modelo que representa el software a desarrollar.

Son muchas las organizaciones que han incorporado UML como un estndar en el desarrollo de sus procesos y productos, teniendo como gran ventaja que al ser no propietario est abierto a su uso en la comunidad cientfica. Los elementos grficos de la metodologa, pretenden 26

aportar un lenguaje de descripcin comn, y fcil de entender, entre todas las personas involucradas en un proyecto. Este es uno de los objetivos del uso de UML: conseguir intercambiar informacin sin invertir gran esfuerzo en estas tareas, puesto que se comparte una determinada notacin. UML dispone de diferentes construcciones para representar grficamente el sistema. Estas construcciones se denominan vistas, las cuales, intentan resaltar determinadas caractersticas que componen el software. Durante las etapas del ciclo de vida se utilizarn aquellas que se consideren necesarias segn la naturaleza del software que se pretenda modelar, por ejemplo:

Diagrama de casos de uso: Para realizar la descripcin del sistema desde un punto de vista de alto nivel. stos describen la funcionalidad de un sistema siguiendo una metodologa descendente, es decir, partiendo de una visin de alto nivel del sistema y continuando con una descomposicin del mismo en partes ms concretas. El propsito de un caso de uso es definir una pieza de comportamiento coherente, sin revelar la estructura interna del sistema. La notacin consiste en crculos que representan tareas que se realizan unidos entre s mediante lneas con dos tipos de cualificacin:

-

Uses: Representa una relacin de inclusin, es decir, una tarea que incluye a otras determinadas tareas.

-

Extend: Representa una relacin de extensin. Se pueden tratar ests, como diferentes formas de realizacin o especializaciones de dicha tarea.

-

Include: Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a una descripcin individual, desde el caso de uso que lo incluye hasta el caso de uso incluido.

27

Diagrama de objetos: Este diagrama representa los aspectos estticos del sistema a desarrollar. Estos aspectos estticos modelan caractersticas del software como pueden ser la estructura interna, tanto del mismo cdigo fuente como lo que es ms importante, la representacin que se har de la informacin en el sistema informtico. ste suele ser el ncleo de todos los desarrollos software, ya que un buen modelado produce un software de buena calidad, por lo que se debe emplear gran esfuerzo en esta tarea. Este diagrama estar formado por objetos, representados con cajas cuadradas, y enlazados entre s.

Estas relaciones junto con los objetos tienen como objetivo conseguir, en el mayor grado posible, una abstraccin de la realidad que pretendemos representar, que abarque en su totalidad los elementos y caractersticas del sistema que pretendemos representar.

Diagramas de estados y Diagramas de Actividad: UML provee una serie de mecanismos para modelar el comportamiento dinmico de un sistema, como son los diagramas de estado y diagramas de actividad. La descripcin se va a centrar en los diagramas de actividad ya que estos se suelen usar cuando el comportamiento de un sistema no depende en gran medida de eventos externos, se requiere un flujo de objetos/datos entre los diferentes pasos, es decir, modela sistemas con un fuerte componente secuencial. Es evidente que la herramienta de simulacin que se est modelando es de naturaleza totalmente secuencial. En cambio, los diagramas de estado describen mediante mquinas de mealy moore el comportamiento de las diferentes clases que se modelan, las cuales cambian de estado al recibir diferentes eventos.

Una vez descritos los componentes bsicos de la metodologa esta ser utilizada para describir todas las fases del ciclo de vida del desarrollo del software de gestin para cementerio Es necesario indicar que tradicionalmente, este ciclo de vida se compone de las siguientes fases, a las cuales se han asociado determinados elementos de UML:

28

Anlisis global o conceptualizacin: Es una primera fase en la que el principal objetivo es marcar las pautas del problema a resolver. Se suelen realizar conjuntos de requisitos, tareas, resultados, etc. que se pretende que el sistema pueda realizar.

Anlisis de requisitos: Es una etapa en la que se pretende organizar los requisitos de la primera fase de forma ordenada y refinada, con la finalidad de poder realizar un anlisis de los mismos para detectar posibles inconsistencias, omisiones, redundancias, etc.

Diseo del sistema: Se obtendr una visin global del sistema que se desea desarrollar desde un punto de vista de alto nivel. En esta fase se han usado los diagramas.

Diseo de objetos: Esta fase obtiene como resultado un modelo de objetos que podr ser implementado en la siguiente fase. Este modelo de objetos debe representar la realidad que se desea abstraer en el sistema informtico fielmente. Esta fase ha usado los elementos de UML denominados diagrama de clases.

29

2.3 PROGRAMACION ORIENTADA A OBJETOS.

Si bien existen varias definiciones de programacin orientada a objetos se ha optado por la definicin que realiza Grady Booch5, quien define la programacin orientada a objetos (POO) como:

Un mtodo de implementacin en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representan una instancia de alguna clase, y cuyas clases son todas miembros de una jerarqua de clases unidades mediante relaciones de herencias

Existen tres importantes partes de la definicin: la programacin orientada a objetos 1) utiliza objetos, no algortmicos, como bloques de construccin lgicos (jerarqua de objetos);2) cada objeto es una instancia de una clase, y 3) las clases se relacionan unas con otras por medio de relaciones de herencia.

La POO es una extensin natural de la actual tecnologa de programacin, y representa un enfoque nuevo y distinto al tradicional, al igual que cualquier otro programa. El diseo de un POO es nico en el sentido de que se organiza en funcin de los objetos que se manipularn, probablemente la parte ms difcil de la creacin de software orientado a objetos es identificar las clases necesarias y el modo en que interactan entre s. Desgraciadamente, no hay reglas fciles para determinar las clases de un programa dado, la identificacin de clases puede ser tanto arte como ciencia. El proceso es algo impreciso, y por esta causa han surgido numerosos mtodos que proporcionan reglas para la identificacin de clases y las relaciones existentes entre ellas.

5 Grady Booch autor del mtodo de diseo orientado a objetos.

30

Las ventajas ms importantes de la programacin orientada a objetos son las siguientes:

Mantenible (facilidad de mantenimiento). Los programas que se disean utilizando el concepto de orientacin a objetos son ms fciles de leer y comprender y el control de la complejidad del programa se consigue gracias a la ocultacin de la informacin que permite. Consiste en dejar visible slo los detalles ms relevantes.

Modificable (facilidad para modificar los programas). Se pueden realizar aadidos o supresiones a programas simplemente aadiendo, suprimiendo o modificando objetos.

Reusable. Los objetos, si han sido correctamente diseados, se pueden usar numerosas veces y en distintos proyectos.

Fiable. Los programas orientados a objetos suelen ser ms fiables ya que se basan en el uso de objetos ya definidos que estn ampliamente testados.

2.4 CONTROL DE GESTION

Si bien es cierto existen muchos conceptos relativos al control de gestin, en un sentido amplio todos los autores concuerdan en que es un proceso integrado y sistmico mediante el cual la plana ejecutiva de una empresa se asegura de la obtencin de los recursos necesarios y de su empleo eficiente y eficaz en el cumplimiento de los objetivos, metas y desarrollo del plan estratgico6 de la compaa u organismo pblico. Este proceso junto con evaluar, debe constituir un incentivo y motivacin permanente a la iniciativa, la mejora y el ptimo desempeo. El objetivo del control de gestin es apoyar a los directivos en el proceso de toma de decisiones con visin empresarial para que obtengan los resultados esperados. Es decir, se6 El plan estratgico es el plan maestro que tiene la empresa o institucin donde incorpora los objetivos, las metas, los recursos y en definitiva la forma de llevar a cabo la Misin de la institucin.

31

trata de lograr la congruencia de las metas, para lo cual el control de gestin crea el marco dentro del cual las acciones tomadas por los distintos directivos no solo responden al inters de su propio servicio, sino que al inters de la empresa como conjunto

2.4.1

Caractersticas del control de gestin

Las caractersticas esenciales de un sistema de control de gestin son: a) Totalidad: Se aplica sobre aspectos generales y abarca un conjunto de aspectos b) Equilibrio: Cada aspecto se distribuye igualitariamente, de manera de evitar una visin sesgada de la unidad de anlisis. c) Oportunidad: Las acciones correctivas debe realizarse a tiempo a fin de lograr eficacia. d) Eficiencia: Orientada a la consecucin de los objetivos y al centro de los problemas. e) Creatividad: Es la contina bsqueda y anlisis de las variables endgenas y ergenas al sistema que permitan una evaluacin global de la gestin, orientndola hacia el logro de la estrategia. f) Impulso a la accin: Debe alertar al directivo para proyectar e impulsar las acciones adecuadas.

2.4.2

Clasificacin del Control de Gestin

Existen distintas clasificaciones segn el criterio utilizado, as tenemos:

1) mbito de evaluacin: Segn el mbito de aplicacin del control, tenemos que el control de gestin puede estar referido tanto a una evaluacin de la gestin interna como externa de la organizacin. 2) Nivel de control: Segn el tipo de informacin y tipo de datos a analizar se puede encontrar 3 niveles de control de una organizacin: control estratgico o de gestin control directivo o tctico control transaccional u operativo

32

a) Control estratgico o de gestin: Abarca a toda la organizacin en una visin de largo plazo, con una supervisin distante, analiza las interrelaciones entre unidades de negocios o divisiones, supervisa el logro de la estrategia y el presupuesto organizacional. b) Control directivo o tctico: Este control tiene una visin peridica y de ms corto alcance que el anterior. Controla el desempeo en el mbito de los negocios, como las interrelaciones entre reas funcionales. c) Control transaccional u operativo: Este tipo de control es de corto plazo, busca el cumplimiento de los programas, reglamentos y presupuestos. Controla el desempeo de trabajos individuales y de grupos. El control interno es el componente bsico del control operativo.

2.4.3

Elementos que integran el control de gestin

Est integrado por un conjunto de elementos que son:

1) Planificacin estratgica La base para poder llevar un control de gestin adecuado esta en contar con un plan estratgico debidamente estructurado y cuantificado.

2) Plan de organizacin Toda estrategia al ser implementada requiere contar con una organizacin estructurada claramente con responsabilidades bien definidas para cada unidad que la compone.

3) Sistema de informacin La base del control es la informacin ya sea de carcter cuantitativo y cualitativo mediante la cual se debe ir evaluando el cumplimiento de la estrategia y tomando acciones correctivas.

El componente ms importante en este mbito lo constituyen los indicadores de gestin cuyo fin es obtener informacin til de manera de ser utilizada por los directivos para la toma de decisiones.

33

2.4.4

Indicadores de gestin

Pueden ser definidos como un referente emprico de una variable que permite un acercamiento indirecto a ella, cuyo rango de operacionalizacin contribuye a observar el cumplimiento de una meta. Se debe tener presente que para que realmente tenga utilidad debe estar estrechamente relacionados con tres sistemas: El sistema de indicadores propiamente tal, en cuanto a sus caractersticas y proceso dentro de la empresa; El sistema de control de gestin, que permite realizar las correcciones pertinentes para lograr mejores resultados; y por ltimo el sistema de informacin, que sirve para la alimentacin oportuna de los indicadores.

Los indicadores de gestin deben tener varias caractersticas que permitan obtener informacin, lo ms precisa como sea posible. Entre otras se pueden enunciar las siguientes:

a) Representatividad El indicador escogido debe estar claramente ligado al tipo de resultado que se pretende reflejar.

b) Objetividad Todo indicador debe referirse, en lo posible, a hechos objetivos sobre los cuales no pueda haber discrepancia de opiniones o diferentes interpretaciones, de modo que sea universalmente aceptado por quienes se vean afectados, directa o indirectamente por su aplicacin.

c) Verificabilidad Un buen indicador debe permitir su verificacin para disipar eventuales dudas. En lo posible debe generarse bajo criterios de consenso, para darle mayor transparencia y aceptacin.

d) Accesibilidad Un buen indicador debe estar disponible en un tiempo que sea ptimo.

34

e) Sensibilidad Los mejores indicadores son los que tiene mayor capacidad para reflejar en breve plazo los cambios en las variables, y ante pequeas variaciones en ellas debieran tener repercusiones amplificadas en el comportamiento del indicador.

f) Costo Una de las condiciones bsicas de la construccin de indicadores es tener presente el costo que implica la obtencin y mantencin del indicador, que en algunos casos, puede ser considerable o desproporcionado.

35

2.4.5

Proceso de construccin de indicadores de gestin

Una vez que se han definidos los procesos crticos es posible elaborar e integrar al sistema de informacin de la empresa o institucin los indicadores de gestin que se determinen, sean tanto de carcter cuantitativo como cualitativo. Para su construccin se debe considerar los siguientes aspectos:

Los indicadores han de poner en evidencia, de forma sistmica solo la informacin precisa Los indicadores han de destacar las informaciones mas significativas del periodo respectivo Los indicadores han de presentarse en forma peridica Debe preocuparse de que los informes sean sinpticos o computacionales Las representaciones numricas de los datos han de ir acompaadas de representaciones grficas que resulten significativas Las informaciones deben tener un carcter de permanencia a fin de absorber tendencias

2.4.6

Modelo de indicadores de gestin KPI

Como se ha expuesto anteriormente, el presente proyecto se basar en la construccin y medicin de indicadores de gestin KPI, por lo que a continuacin se presentan algunas definiciones importantes y que estn directamente relacionadas a estos y que son:

KPI Un KPI Key Performance Indicador puede ser definido como un indicador clave de desempeo que mide las distintas reas de gestin expresadas en procesos crticos con el fin de contar con informacin gerencial relevante para la toma de decisiones por parte de los ejecutivos.

Target Describe un objetivo o cantidad de objetivos que los KPI necesitan medir en el negocio.

36

Indicator Un indicador es la expresin en formula de cmo un KPI ser medido. En este sentido, el negocio puede ser medido en trminos de un promedio, en porcentajes o volmenes.

Metric La mtrica describe el rango de valores para los cuales los KPI sern medidos.

Priority La prioridad de un KPI describe los datos sobre los cuales los informes de KPI pueden estar disponibles.

37

CAPITULO III

DEFINICION DE REQUERIMIENTOS

En este captulo se presenta y se enumeran las funcionalidades del sistema, basndose en la informacin adquirida al entrevistar al administrador de cementerio municipal de Melipilla, de esta manera se especifican las caractersticas funcionales y no funcionales que debe poseer un sistema de informacin para cementerios tradicionales municipalizado.

3.1

REQUERIMIENTOS

PARA

SISTEMA

COMPUTACIONAL

DE

CEMENTERIOS MUNICIPALES.

Es necesario permitir a la administracin conocer en resumen y detalle informacin estadstica respecto a los procesos crticos que han sido definidos en cada uno de los mdulos funcionales de este sistema (funeraria, clientes y financiera). Para ello se presentar un listado con los requerimientos funcionales, comenzando con los requerimientos bsicos de entrada para luego generar los requerimientos necesarios para el control de gestin.

3.1.1 Requisitos funcionales

1. El sistema debe poseer un control de acceso por usuario y contrasea dependiendo del tipo de usuario: Administrador, Vendedor y Administrativo. 2. El sistema debe permitir crear sepulturas. 3. El sistema debe permitir listar la creacin de Propietario. 4. El sistema debe permitir el ingreso de ventas 5. El sistema debe permitir la generacin de comprobante de recaudacin para cliente. 6. El sistema debe permitir el registro de difuntos para el Libro actual de inhumacin 7. El sistema debe generar el historial de cada sepultura.

38

8. El sistema debe exigir el ingreso del valor de la U.T.M. al inicio de cada mes, ya que los valores son expresados en este sistema monetario. 9. El sistema debe permitir los ingresos de descuentos o paga en cuotas que se aplicara a la venta de sepulturas y/o servicios que se solicite dentro de un Convenio o repactacin. 10. El sistema debe permitir el ingreso de servicios realizados a sepulturas. 11. El sistema debe mostrar en detalle de ventas el ingreso de servicios a sepultura. 12. El sistema debe permitir el ingreso de reclamos, sugerencias y felicitaciones 13. El sistema debe permitir relacionar los derechos con el cobro de cada servicio y valor asociado a el en UTM asignado en la ordenanza municipal (Ver Anexo1) 14. El sistema debe permitir incorporar nuevos derechos describiendo su servicio y valor asociado a el en UTM 15. El sistema solo debe permitir 1 convenio y 1 repactacin del arancel mensual. 16. El valor de la letra de cobranza debe estar sujeto a la formula de calculo de Deuda/Factor. (Ver Anexo1) 17. El sistema debe generar listados de consultas ya sea por impresin o por pantalla 18. El Sistema debe entregar un resumen peridico de recaudacin (rango de fecha desde-hasta, con el siguiente formato dd-mm-aaaa), para el administrador (Ver Anexo 2) El Sistema debe entregar un reporte impreso de recaudacin acumulada a tesorera municipal con formato genrico municipal (Ver anexo 3). 19. Sistema debe entregar una impresin del reclamo realizado. 20. El sistema debe permitir generar un listado de sepulturas con deuda. 21. Sistema debe entregar informacin de la disponibilidad de sepulturas, ubicacin y valor. 22. El sistema debe permitir generar un listado de pagos pendientes por propietario. 23. El sistema debe entregar informacin para la gestin, basado en el plan estratgicodesarrollado por el administrador:

24.1

El sistema debe entregar informacin, Gestin financiera, de

acuerdo a los siguientes indicadores del proceso de Venta: Kpi 1: Nmero de ventas generados trimestralmente con y sin convenio. 39

Kpi 2: Nmero de ventas por derechos de servicios trimestralmente de sepulturas

24.2

Kpi 3: Cantidad de ventas trimestralmente por tipo de sepulturas. El sistema debe entregar informacin, para gestin financiera, de

acuerdo a los siguientes indicadores de proceso de Recaudacin: 24.3 Kpi 1: Cantidad Recaudacin trimestral por tipo de sepultura. Kpi 2: Cantidad Recaudacin trimestral por cobrador. Kpi 3: Cantidad de morosidad de pago trimestral. El sistema debe entregar informacin, para gestin funeraria, de

acuerdo a los siguientes indicadores del Proceso de Operaciones. Kpi 1: Cantidad de tipo de sepultura construidas,

trimestralmente. Kpi 2: Cantidad de servicios realizados, por tipo de sepultura, trimestralmente. 24.4 Kpi 3: Cantidad de disponibilidad de sepultura para la venta, trimestralmente. El sistema debe entregar informacin, para gestin cliente, de

acuerdo a los siguientes indicadores del proceso de reclamos. Kpi 1: Cantidad trimestral de reclamos generados por motivo, donde motivo es: robo o destrozos y calidad de atencin. Kpi 2: Cantidad trimestral de reclamos generados por tipo de interaccin con clientes, donde tipo es: reclamo, felicitaciones, sugerencias. 24. El sistema debe permitir al administrador ingresar los valores esperados para su control de gestin, de acuerdo a los indicadores dados en los requerimientos Nmero 24.

40

3.1.2 Requerimientos no funcionales.

Se detallan a continuacin los requerimientos mnimos de hardware que la aplicacin necesita para su funcionamiento ptimo.

1. El Servidor de datos debe tener, la siguiente configuracin de hardware: Procesador 3 GHz o superior, memoria RAM 2 GB o superior, Disco Duro 500 GB o superior, unidad grabadora de DVD para respaldos peridicos de Informacin, teclado, mouse y monitor. 2. El Servidor debe tener la siguiente configuracin de software: Sistema operativo Windows 2003 advanced Server, motor de Base de Datos MySQL 4.1 para Windows, MySQL Control Center, antivirus. 3. Tres computadores para estacin de trabajo (Clientes) con la siguiente configuracin de hardware: Procesador 1 GHz o superior, memoria RAM 1 GB o superior, Disco Duro 80 GB o superior, unidad CD o DVD, teclado, mouse y monitor. Estos equipos sern utilizados como clientes de la aplicacin y sern distribuidos segn lo requiriera la administracin. 4. Estacin Cliente con la siguiente configuracin de software: Sistema operativo Windows XP, Office Basic 2000 (Word, Excel y Outlook) o superior, Cliente MyODBC 3.51 para Windows y Antivirus. 5. Impresora Matriz de punto carro angosto (Para reporte de recaudacin). 6. Impresora Lser o inyeccin de tinta para reportes de sepulturas disponibles, reclamos y otros informes 7. Un Switch

41

CAPITULO IV

ANALISIS Y DISEO DEL SISTEMA

4.1 ANALISIS DEL DOMINIO DEL PROBLEMA

4.1.1

Modelo conceptual preliminar

El diagrama que se presenta a continuacin (Ver Fig.3.- Modelo de dominio) muestra los conceptos relevantes del dominio del problema, obtenido a partir de la informacin entregada en la especificacin de requerimientos, adems se visualizan las relaciones existentes entre los distintos conceptos identificados.

Este diagrama es elaborado con el propsito de definir un glosario de objetos para su utilizacin durante las siguientes etapas del desarrollo. Por este motivo, los conceptos identificados en esta etapa no necesariamente constituyen clases que vayan a implementarse posteriormente, ya que las clases que deben ser implementadas, sern identificadas durante las siguientes etapas del anlisis, as como sus respectivos atributos y operaciones.

42

4.1.2

Modelo del Dominio

En la siguiente figura presentamos el modelo del dominio en forma grfica.

Fig. 3 Modelo de Dominio

43

4.1.3

Glosario de Conceptos

En la tabla 3 se presenta el glosario de conceptos que han sido identificados como resultado del anlisis sobre los requerimientos del sistema. La denominacin de cada uno de los conceptos identificados debe ser utilizada en las etapas siguientes del desarrollo. De esta manera se logra reducir la ambigedad en los conceptos que puedan dar origen a errores en el diseo del sistema.

Conceptos del domino del problema

1. ENTIDAD DESCRIPCION

USUARIO

El usuario es quien realiza las operaciones de ingreso y/o mantencin de los datos de venta, recaudacin, ingreso libro de inhumacin y reclamos.


ADMINISTRADOR

Es quien realiza la generacin de reportes de gestin, de acuerdo a los datos de venta, recaudacin, ingreso libro de inhumacin y reclamos.


ADMINISTRATIVO

Es quien realiza la tarea de mantencin de informacin respecto a sepulturas creadas, ingreso de difuntos al libro de inhumacin, ingreso de reclamos, sugerencias o felicitaciones.


PROPIETARIO

Es quien solicita una venta o tipo de trabajo y tiene una sepultura. Estos pueden ser personas naturales, empresas en general o instituciones. 44


LISTA DE CONTACTOS

Listado de personas que tiene asociados a un propietario, adems representa informacin valiosa para el libro de sugerencia y reclamos.


DIRECCION

Direccin fsica que permite identificar donde se encuentra la sepultura/bveda/nicho, emplazada dentro de un subsector, sector, zona.


ZONA

La zona es un lugar que agrupa una cantidad sectores y que permite identificar donde se encuentra un grupo de sepultura/bveda/nicho.


SECTOR

El sector es un lugar fsico, dentro de una zona, que agrupa un conjunto de subsectores y permite identificar donde se encuentra la sepultura/bveda/nicho.


SUB SECTOR

El sub sector es un lugar fsico, dentro del sector, que agrupa un conjunto de sepulturas y permite identificar donde se encuentra la sepultura/bveda/nicho.


SEPULTURA

La sepultura representa al lugar y/o tipo donde se realizan las inhumaciones de los difuntos y/o el lugar fsico donde se realizan los trabajos o servicios que los

45

propietarios solicitan; est se puede identificar de acuerdo a su direccin.


VENTA

Representa la operacin de transaccin de compra que los propietarios solicitan al cementerio y tiene involucrado un pago de por medio.


CUENTAS POR COBRAR

Lista de cobros pendientes asociados a una venta.


DERECHO POR SERVICIO

Representa una venta especial por la realizacin de trabajos en una propiedad, que son definidos en la Ordenanza Municipal.


CONTROL DE GESTION

Resumen con indicadores de control para la administracin del cementerio.


DIFUNTO

Informacin respecto al difunto, que debe ser registrado en el libro de inhumacin.


LIBRO DE INHUMACIN

Registro con informacin del difunto, basado en certificado de defuncin emitido por el Registro Civil (causa de fallecimiento y nmero de inscripcin) y la ubicacin de la sepultura en el cementerio.

46


RECLAMOS

Registro de los reclamos, sugerencias y felicitaciones, respecto a propiedades y/o servicios realizados por parte de propietarios o contactos, que permitir la generacin de informacin para el control de gestin de clientes.

18. ENTIDAD DESCRIPCION Registro de eventos que tiene una sepultura.

HISTORIAL DE SEPULTURA


CONVENIOS

Acuerdo subscrito para generacin de una venta con descuento o con pago en cuotas.


UTM

Valor monetario, con el cual se calcula el valor de una propiedad o servicio a realizar para una sepultura.

Tabla 3 Concepto del dominio del problema.

47

4.2 CASOS DE USO

El propsito de este modelo es entender la forma en cmo interactan los distintos actores con el Sistema, enfocando cules son los principales procesos a tomar en cuenta a la hora del desarrollo e implementacin de la solucin propuesta.

4.2.1

Actores.

Administrador: Persona que tiene la responsabilidad de gestionar los recursos del cementerio y est a cargo del sistema. Realiza las tareas de crear, eliminar y actualizar cuentas de usuarios, adems visualiza y genera indicadores de gestin para el cementerio, basndose en el plan estratgico para la posterior toma de decisiones.

Vendedor: Persona que ingresa las ventas, pago de cuotas, realiza control cobranza respecto a cuotas por vencer, genera resumen peridico de recaudacin para el administrador, reportes de recaudacin acumulada a tesorera, listado de sepultura con deuda, visualiza las ubicaciones de cada sepultura y disponibilidad de ellas.

Administrativo: Persona que ingresa al sistema informacin relevante a la administracin del cementerio, como los valores de derechos, sepulturas, ingresa e imprime anotaciones al libro de reclamos/sugerencias, tambin visualiza las ubicacin de cada sepultura y disponibilidad de ellas.

Propietario: Persona natural o empresa que realiza la compra de sepulturas, con diferentes formas de pago, ya sea al contado o por convenios adquiridos en la municipalidad anteriormente (cuotas y/o descuentos); realiza pago de cuotas. Es el responsable de entregar informacin personal o comercial para mantener actualizados sus datos

Los diagramas de casos de uso realizado se dividieron de tal manera, que el primer diagrama se presenta en forma general, luego los casos de usos derivados de este para la solucin del problema planteado. 48

4.2.2

Diagrama de caso de uso: General del sistema

El diagrama de caso de uso general del sistema (Ver Fig.4.- Diagrama de caso de uso General del sistema) muestra como los actores, usuarios del sistema interactan con los distintos mdulos del sistema, para realizar cada una de las actividades segn corresponda su rol o funcin dentro de la institucin, y as responder a los requerimientos capturados, incluyendo el proceso de venta, administracin de datos fundamentales respecto al rea de negocio estudiado, y finalmente el caso de uso para responder al proceso gestin con indicadores de desempeo para la toma de decisiones del administrador.

Fig. 4 Diagrama de caso de uso General del sistema.

49

4.2.3

Descripcin de Alto Nivel.

4.2.3.1 Caso de Uso: Registrar VentasNombre: Registrar Ventas. Descripcin: El Vendedor se encarga de Registrar las ventas realizadas por concepto de propiedades y servicios, de acuerdo a la solicitud del nuevo o actual propietario. Actores: Vendedor, Propietario. Tipo: Primario. Referencias Cruzadas: Req04, Req05, Req09, Req10, Req13, Req14, Req15, Req16, Req17, Req18, Req19, Req22, Req23.

4.2.3.2 Caso de Uso: Registrar Libro de InhumacinNombre: Registrar Libro de Inhumacin. Descripcin: El Actor se encarga de Registrar la informacin respecto al difunto, certificado de defuncin y la sepultura adquirida por el propietario, identificado por el lugar fsico de este. Actores: Administrador, Administrativo, Vendedor. Tipo: Primario. Referencias Cruzadas: Req02, Req03, Req06, Req018

4.2.3.3 Caso de Uso: Registrar Libro de ReclamosNombre: Registrar Libro de reclamos. Descripcin: El administrativo se encargar de Registrar la informacin respecto a los reclamos, sugerencias y felicitaciones, respecto a propiedades y/o servicios realizados, el que ser informado por parte de propietarios o contactos, una vez registrado se entregar un documento impreso al propietario. Actores: Administrativo, Propietario. Tipo: Primario. Referencias Cruzadas: Req12

50

4.2.3.4 Caso de Uso: Administrar PropietariosNombre: Administrar Propietarios. Descripcin: El Actor se encarga de registrar la informacin personal, y de contacto de los propietarios actuales de sepulturas. Actores: Vendedor, administrativo. Tipo: Primario. Referencias Cruzadas: Req03, Req04

4.2.3.5 Caso de Uso: Administrar SepulturasNombre: Administrar Sepulturas. Descripcin: Este caso de uso se encarga de administrar la informacin respecto a la propiedad sepulcral, denominada Sepultura, con la informacin de su ubicacin e historial respecto a difuntos inhumados y a servicios realizados. Actores: Administrador, Administrativo, Vendedor. Tipo: Primario. Referencias Cruzadas: Req02, Req10

4.2.3.6 Caso de Uso: Administrar UsuariosNombre: Administrar Usuarios. Descripcin: El Administrador se encarga de manejar la informacin personal, de acuerdo al perfil y rol, de cada uno de los usuarios del Sistema. Actores: Administrador. Tipo: Primario. Referencias Cruzadas: Req01, Req11

4.2.3.7 Caso de Uso: Administrar Indicadores de GestinNombre: Administrar Indicadores de Gestin Descripcin: El Administrador se encarga de manejar y generar los reportes de gestin financiera, funeraria y de clientes, para la toma de decisiones respecto a la informacin obtenida. Actores: Administrador. Tipo: Primario. Referencias Cruzadas: Req18, Req19, Req24, Req24, Req25.

51

4.2.4

Descripcin esencial o expandida.

4.2.4.1 Caso de Uso: Registrar VentasNombre: Registrar Ventas. Resumen: En este caso de uso el Vendedor se encarga de Registrar las ventas realizadas por concepto de propiedades y servicios, de acuerdo a la solicitud del nuevo o actual propietario y cobra el valor de estos, finalmente imprimir un comprobante de recaudacin para el propietario.

Actor 1 Cliente solicita compra de sepultura o servicio. 2 El vendedor ingresa al sistema con su 3 RUT y contrasea.

Sistema

El sistema despliega el men principal con listado de las opciones que posee:

1. Registrar Ventas 2. Registrar Libro de Inhumacin 3. Registrar Libro de Reclamos 4. Administrar propietario 5. Administrar Sepulturas4 El vendedor selecciona la opcin 5 El sistema presenta formulario de venta, para el ingreso de una nueva Venta, con los siguientes datos: Registrar Ventas.

6 El vendedor ingresa RUT de propietario 7

Datos de propietario Datos de sepultura Datos de Convenio

El sistema busca RUT del propietario, al no existir, enva mensaje de Propietario no registrado y habilita opcin listar

disponibilidad de sepulturas. 8 El vendedor ingresa informacin de propietario. 9 El vendedor selecciona opcin listar 10 disponibilidad de sepulturas. El sistema muestra listado con sepulturas disponibles por tipo, ubicacin y con precio.

52

11

El vendedor selecciona la opcin indicada 12 por el propietario

El Sistema asocia la sepultura seleccionada al formulario de ventas.

13 14

Propietario entrega convenio a vendedor El vendedor selecciona opcin Ingreso de 15 Convenio. El sistema habilita zona de ingreso de datos de convenio, en formulario de ventas. ingresa los datos de 17 El sistema calcula el valor de la cuota en UTM a pagar y lo muestra en el formulario.

16

El

vendedor

convenio. 18 19 El propietario vlida y acepta la compra El vendedor presiona Guardar e imprimir 20

El sistema guarda la venta, guarda nuevo propietario, guarda nuevo convenio, cambia estado sepultura y emite comprobante de recaudacin para imprimir.

21

El vendedor entrega comprobante de venta y cierra la sesin en el sistema.

Curso alterno de eventos o cursos alternativos. 2. El sistema no encontr al usuario y envi un mensaje de error. 7. El propietario existe en la base de datos 7.1. El sistema muestra los datos del propietario en formulario de ventas y habilita opcin listar disponibilidad de sepulturas y Listar servicios. 9.- El vendedor selecciona Listar Servicios. 9.1 El sistema muestra listado de sepulturas del propietario 9.2 El vendedor selecciona sepultura que requiere servicio 9.3 El sistema muestra Servicios disponibles para la compra. 9.4 El vendedor selecciona uno o ms servicios. 9.5 El sistema calcula el valor final y lo agrega al formulario de venta, as como tambin el detalle del o los servicios seleccionados. 14. El vendedor selecciona la opcin de compra al Contado. 19. Hubo un error, no se completo la operacin. 21. El vendedor no guarda la informacin y sale del sistema.

53

4.2.4.2 Caso de Uso: Registrar Libro de inhumacinNombre: Registrar Libro de Inhumacin. Resumen: En este caso de uso el usuario, ya sea administrador, vendedor o administrativo, se encarga de registrar la informacin respecto al difunto, certificado de defuncin y la sepultura adquirida por el propietario, identificado por el comprobante de compra.

Actor 1 El usuario ingresa al sistema con su RUT 2 y contrasea.

Sistema El sistema despliega el men principal con listado de las opciones que posee:

1. Registrar Libro de Inhumacin 2. Registrar Libro de Reclamos 3. Administrar propietario 4. Administrar Sepulturas3 El usuario selecciona la opcin Registrar 4 Libro de inhumacin. 5 El usuario ingresa los datos del difunto 6 solicitados en el formulario y asignar sepultura de acuerdo al nmero de compra. 7 El usuario selecciona Asignar sepultura. 8 El sistema adjunta informacin de sepultura en formulario del libro de inhumacin. 9 El usuario ingresa los datos requeridos 10 por el formulario y presiona Aceptar. El sistema valida existencia de datos de difunto y sepultura asignada. Y enva un mensaje de aceptacin 11 El usuario presiona Guardar 12 El sistema Registra los datos en la base de datos y enva mensaje de operacin exitosa. 13 El usuario cierra la sesin en el sistema. El sistema presenta un formulario para el ingreso de los datos al libro de inhumacin. El Sistema lista sepulturas adquiridas.

Curso alterno de eventos o cursos alternativos. 1. El sistema no encontr al usuario y envi un mensaje de error. 3. Hubo un error, no se completo la operacin. 8. La sepultura adquirida no se encuentra en la base de datos.

10. Si falta informacin de sepultura y difunto, se enva mensaje de error.

54

4.2.4.3 Caso de Uso: Registrar Libro de ReclamosNombre: Registrar Libro de Reclamos. Resumen: En este caso de uso el usuario, ya sea administrador, vendedor o administrativo, se encarga de Registrar los reclamos, sugerencias o felicitaciones que informan los propietarios respecto a sus sepulturas o servicios realizados en ellas.

Actor 1 Cliente solicita registrar comentarios por servicio a sepultura. 2 El usuario ingresa al sistema con su RUT 3 y contrasea.

Sistema

El sistema despliega el men principal con listado de las opciones que posee:

1. Registrar Ventas 2. Registrar Libro de Inhumacin 3. Registrar Libro de Reclamos 4. Administrar propietario 5. Administrar Sepulturas4 El usuario selecciona la opcin Registrar 5 Reclamos. 6 El usuario ingresa datos de propietario 7 El sistema presenta un formulario para el ingreso de un nuevo comentario. El sistema valida si RUT del propietario ya existe y muestra sepulturas adquiridas por el propietario. 8 9 El usuario selecciona Sepultura El usuario selecciona en combo 10 El sistema habilita zona de edicin para ingresar otros comentarios.

desplegable:

Tipo de interaccin con clientes: Reclamo, felicitaciones, sugerencias. Motivo: Robo, calidad de mantencin o atencin cobranza.11 El usuario ingresa los datos requeridos 12 por el formulario y presiona Aceptar. 13 El usuario cierra la sesin en el sistema. El sistema Registra los datos de entrada y emite comprobante para imprimir.

55

Curso alterno de eventos o cursos alternativos. 2. El sistema no encontr al usuario y envi un mensaje de error. 7. El propietario no existe en la base de datos. 7.1. Se abre formulario para agregar propietario/contacto. 11. Hubo un error, no se completo la operacin.

4.2.4.4 Caso de Uso: Administrar PropietariosNombre: Administrar Propietarios. Resumen: Este caso de uso se encarga de registrar o editar y eliminar informacin personal de los propietarios actuales de sepulturas.

Actor 1 El usuario ingresa al Sistema con su RUT 2 y contrasea.


1. Registrar Ventas 2. Registrar Libro de Inhumacin 3. Registrar Libro de Reclamos 4. Administrar propietario 5. Administrar Sepulturas3 El usuario ingresa la opcin Administrar 4 propietario. El sistema presenta un formulario con las opciones:

A. Agregar B. Actualizar C. Eliminar5 El usuario selecciona la opcin (B) 6 Actualizar. 7 El usuario ingresa RUT de propietario 8 Sistema busca en la base de datos y entrega informacin de propietario. 9 El usuario edita la informacin de propietario. 10 El usuario selecciona la opcin Guardar cambios 12 El usuario cierra la sesin en el sistema. 11 El sistema guarda la informacin y enva mensaje de operacin exitosa. El sistema presenta formulario de propietarios.

56

Curso alterno de eventos o cursos alternativos. 3. El sistema no encontr al usuario y envi un mensaje de error. 5. El sistema no encontr propietario y muestra mensaje Propietario no existe y sugiere agregar propietario.

Opcin A: Agregar.

Actor 1 El usuario selecciona la opcin (A) 2 Agregar. 3 El usuario ingresa RUT de propietario y 4 presiona aceptar.

Sistema El sistema muestra formulario de propietarios.

El sistema busca en la base de datos y enva mensaje RUT no encontrado, desea agregar nueva informacin de propietario

5

El usuario selecciona Aceptar.

6

El sistema habilita la zona de edicin para ingresar nuevos datos de propietarios.

7

El

usuario

ingresa

los

datos

de 8

El sistema guarda la informacin y enva mensaje de operacin exitosa.

propietarios 9 El usuario cierra la sesin en el sistema.

Opcin C: Eliminar

Actor 1 El usuario selecciona la opcin (C) 2 Eliminar 3 El usuario ingresa RUT de propietario y 4 presiona aceptar. 5 El usuario selecciona Eliminar 6

Sistema El sistema muestra formulario con lista de propietarios. El sistema busca en la base de datos y entrega informacin de propietario El sistema enva mensaje de confirmacin de eliminacin 8 El sistema elimina en forma lgica de la base de datos el registro.

propietario. 7 El usuario Acepta Eliminacin

9

El usuario cierra la sesin en el sistema.

57

4.2.4.5 Caso de Uso: Administrar SepulturasNombre: Administrar Sepulturas. Resumen: Este caso de uso se encarga de registrar, editar y eliminar informacin respecto a las sepulturas.

Actor 1 El usuario ingresa al sistema con su RUT 2 y contrasea.


1. Registrar Libro de Inhumacin 2. Registrar Libro de Reclamos 3. Administrar propietario 4. Administrar Sepulturas3 El usuario ingresa la opcin Administrar 4 Sepultura. El sistema presenta un formulario con las opciones:

A. Agregar B. Actualizar C. Eliminar 57 El usuario selecciona la opcin (B) 6 Actualizar El usuario selecciona sepultura del listado 8 El sistema muestra formulario con lista de sepulturas creadas El sistema entrega informacin de sepultura a formulario 9 El usuario edita datos de sepultura seleccionada 10 El usuario presiona Guardar cambios 11 El sistema guarda la informacin y enva mensaje de operacin exitosa. 12 El usuario cierra la sesin en el sistema.

Curso alterno de eventos o cursos alternativos. 3. El sistema no encontr al usuario y envi un mensaje de error. 5. El sistema no encontr propietario y muestra mensaje Propietario no existe y sugiere agregar propietario.

58

Opcin A: Agregar. Este curso alternativo de evento, se genera al realizar un anlisis del terreno disponible.

Actor 1 El usuario selecciona la opcin 2

Sistema El sistema muestra formulario con lista de tipos de sepultura

(A)Agregar 3 4 El usuario selecciona tipo de sepultura El usuario ingresa datos de sepultura nueva, incluyendo direccin 5 El usuario selec

MANUALCEMENTERIO

Documents

Transcript of MANUALCEMENTERIO