Sei sulla pagina 1di 102

ÍNDICE GENERAL

CAPÍTULO 1: ASPECTOS GENERALES ...............................................................................................1


1. INTRODUCCIÓN ..............................................................................................................................1
1.1 ANTECEDENTES .........................................................................................................................1
1.1.1 Antecedentes de la Institución ..........................................................................................1
1.1.1.1 Misión ...............................................................................................................................1
1.1.1.2 Visión ................................................................................................................................2
1.1.1.3 Organigrama de la Institución........................................................................................2
1.1.2 Antecedentes del Contexto ................................................................................................3
1.1.2.1 Ubicación Geográfica .....................................................................................................3
1.1.2.2 Situación Económica ......................................................................................................3
1.1.2.3 Salud y Educación ..........................................................................................................3
1.1.2.4 Transporte ........................................................................................................................4
1.1.2.5 Servicios Básicos ............................................................................................................4
1.1.3 Antecedentes del Tema ......................................................................................................4
1.1.3.1 Antecedentes de Proyectos Relacionados ...................................................................4
1.2 PLANTEAMIENTO DEL PROBLEMA .........................................................................................5
1.2.1 Fundamentación del Problema ..........................................................................................5
1.2.2 Formulación del Problema .................................................................................................6
1.3 OBJETIVOS ..................................................................................................................................6
1.3.1 Objetivo General ..................................................................................................................6
1.3.2 Objetivo Específico .............................................................................................................6
1.4 JUSTIFICACIÓN DEL PROYECTO .............................................................................................6

CAPITULO 2: MARCO TEÓRICO ............................................................................................................7


2.1 SISTEMAS DE INFORMACIÓN ...................................................................................................7
2.1.1 Entrada de Información ......................................................................................................8
2.1.2 Procesamiento de la Información ......................................................................................8
2.1.3 Actividades que Realiza un Sistema de Información ......................................................9
2.1.4 Tipos y Usos de los Sistemas de Información ...............................................................9
2.1.5 Salida de Información ...................................................................................................... 12
2.2 TECNOLOGÍAS DE ADMINISTRACIÓN DE LA INFORMACIÓN ........................................... 12
2.2.1 Bases de Datos ................................................................................................................. 12
2.2.2 Administración de Base de Datos .................................................................................. 12
2.3 METODOLOGÍA DE DESARROLLO DE SOFTWARE ............................................................ 13
2.3.1 Rational Unified Process (RUP) ...................................................................................... 14
2.3.1.1 Lenguaje Unificado de Modelado (UML) ................................................................ 14
2.3.2 Ciclo de Vida de un Sistema de Información ............................................................... 15
2.3.2.1 Incremental ................................................................................................................... 15
2.3.2.2 Evolutivo ....................................................................................................................... 16
2.3.2.3 Cascada ......................................................................................................................... 18
2.4 TECNOLOGÍAS WEB ................................................................................................................ 19
2.4.1 Servidores de Archivos Web........................................................................................... 19
2.4.1.1 PHP (Paginas Preprocesador de Hipertexto) ........................................................ 19
2.4.1.2 HTML (Lenguaje de Marcado de Hipertexto) ......................................................... 20
2.4.1.3 Java Script ............................................................................................................... 20
2.4.2 Navegadores Web ............................................................................................................ 21
2.4.3 Tecnologías Cliente Servidor .......................................................................................... 22

CAPÍTULO 3: ANALISIS DEL SISTEMA.............................................................................................. 24


3.1 DESCRIPCIÓN DEL SISTEMA ................................................................................................. 24
3.2 ANALISIS DE REQUERIMIENTOS ........................................................................................... 24
3.3 DEFINICIÓN DE REQUERIMIENTOS ....................................................................................... 24
3.3.1 Requerimientos Funcionales .......................................................................................... 24
3.3.2 Requerimientos no Funcionales ..................................................................................... 28
3.3.3 Requerimientos de Hardware y Software ...................................................................... 28
3.4 IDENTIFICACIÓN DE USUARIOS ............................................................................................ 29
3.4.1 Requerimientos de Seguridad (BackUps) ..................................................................... 29
3.5 MODELO DE CASOS DE USO DEL SISTEMA....................................................................... 30
3.5.1 Identificación de Actores ................................................................................................. 30
3.5.2 Identificación de Casos de Uso ...................................................................................... 30
3.5.3 Diagrama de Casos de Uso del Sistema ........................................................................ 31
3.5.3.1 Caso de uso Secretario de Actas ........................................................................... 32
3.5.3.2 Caso de uso Secretario de Haciendas ................................................................... 42
3.5.3.3 Caso de uso Presidente ........................................................................................... 48

CAPÍTULO 4: DISEÑO DEL SISTEMA................................................................................................. 51


4.1 Diseño del Sistema .................................................................................................................. 51
4.1.1 Introducción ...................................................................................................................... 51
4.2 Diagrama de Interacción.......................................................................................................... 51
4.2.1 Diagrama de Estados de los Casos de Uso .................................................................. 51
4.2.1.1 Diagrama de Estado Secretario de Actas .............................................................. 52
4.2.1.2 Diagrama de Estado Secretario de Haciendas ...................................................... 57
4.2.1.3 Diagrama de Estado Presidente ............................................................................. 60
4.2.2 Diagrama de Secuencia de los Casos de Uso............................................................... 61
4.2.2.1 Diagrama de Secuencia Secretario de Actas ........................................................ 62
4.2.2.2 Diagrama de Secuencia Secretario de Haciendas ................................................ 67
4.2.2.3 Diagrama de Secuencia Presidente ....................................................................... 70
4.3 Diagrama de Clases ................................................................................................................. 72
4.4 DIAGRAMA DE BASES DE DATOS ........................................................................................ 73
4.4.1 Modelo Conceptual Entidad-Relación ............................................................................ 73
4.4.2 Modelo Físico ................................................................................................................... 75
4.5 Diseño de Interfaz .................................................................................................................... 76

CAPITULO 5: IMPLEMENTACIÓN ....................................................................................................... 79


5.1 INTRODUCCIÓN ....................................................................................................................... 79
5.2 ELECCIÓN DE HERRAMIENTAS DE DESARROLLO UTILIZADAS ...................................... 79
5.2.1 Elección del Lenguaje de Programación ....................................................................... 79
5.2.2 Elección del Manejador de Base de Datos .................................................................... 81
5.2.3 Elección del Sistema Operativo ...................................................................................... 81
5.2.4 Elección del Ciclo de Vida ............................................................................................... 81
5.2.5 Herramientas de Apoyo para el Desarrollo de Software .............................................. 81

CAPITULO 6: PRUEBAS Y VALIDACIÓNES DEL SISTEMA ............................................................. 82


6.1 INTRODUCCIÓN ....................................................................................................................... 82
6.2 TIPOS DE PRUEBAS ................................................................................................................ 82
6.2.1 Pruebas en los Sistemas Operativos ............................................................................. 82
6.2.2 Pruebas de Robustez ....................................................................................................... 82
6.2.3 Grado de Flexibilidad de Interfaz .................................................................................. 85

CAPITULO 7: CONCLUSIONES Y RECOMENDACIÓNES................................................................ 86


7.1 CONCLUSIONES RESPECTO A LOS ABJETIVOS ................................................................ 86
7.2 CONCLUSIONES RESPECTO A LA METODOLOGÍA USADA ............................................. 86
7.3 CONCLUSIONES RESPECTO A LAS HERRAMIENTAS DE DESARROLLO ....................... 86
7.4 RECOMENDACIONES EN GENERAL ..................................................................................... 86
7.5 EXTECIONES FUTURAS DEL SISTEMA DE INFORMACIÓN................................................ 87
BIBLIOGRAFIA ..................................................................................................................................... 88
Libros Consultados .............................................................................................................................. 88
Consultas web ...................................................................................................................................... 88
ANEXOS ................................................................................................................................................ 89
PROYECTO

SISTEMA DE INFORMACIÓN DE CONTROL DE


VENTAS DE COMBUSTIBLE “EL SURTIDOR”
CAPÍTULO 1: ASPECTOS GENERALES

1. INTRODUCCIÓN

En los últimos años el avance tecnológico ha tenido grandes logros siendo beneficiada la
sociedad y las personas en general. Transformando a las empresas, e instituciones y
organizaciones sociales. Proponiendo la automatización y sistemas de información y
administración. Dejando el sistema manual.

1.1 ANTECEDENTES

1.1.1 Antecedentes de la Institución

a) Ubicación

El surtidor está ubicada en la av. panamá, pertenece al municipio de Cochabamba provincia


Cercado distrito 9 cantón San Joaquín de Intocta del departamento de Cochabamba está
ubicada a 8 km.

b) Historia

El surtidor inicio sus actividades (25 de febrero de 2000)1comenzó su funcionamiento con 6


empleados encabezado por el dueño Sr. Alan hernan. Actualmente se encuentra bajo la
dirección del mismo el Sr. Alan Hernan.
El surtidor fue fundada por que en la zona no contaban con este servicio, necesario para los
usuarios de la zona.

1.1.1.1 Misión

1
La misión de El surtidor es brindar el suministro de medicamentos a la Av. Panama
abastezca de combestibles.
1.1.1.2 Visión

En lo posterior ser modelo líder de otras surtidores, y extender sus dominios hacia otras
comunidades vecinas, siendo cadena de surtidor

1.1.1.3 Organigrama de la Institución

El surtidor está conformada por el siguiente directorio con los siguientes cargos2.

Gerente
Propietario

administrativo

Bombas de gas Bombas de gasolina

Encargado de Encargado de limpieza


inspección

Figura 1. Organigrama de El surtidor “surtidor”


Fuente: Documentación de El surtidor “El surtidor”

2
1.1.2 Antecedentes del Contexto

1.1.2.1 Ubicación Geográfica

La Propiedad de El surtidor, pertenece al Sr. Alan Heredia municipio de Cochabamba


provincia Cercado Av. Panama acera oeste #455

TOTAL DE HABITANTES 4.305


Mujeres 1.689
Hombres 2.616
Viviendas 884
Familias 861

Tabla 1. Estadísticas de la Comunidad Pucarita Chica del censo 2012


Fuente: Censo Nacional 2012

1.1.2.2 Situación Económica

El surtidor esta dedicada a subministrar combustible ala población en general .

1.1.2.3 Salud y Educación

La Comunidad Campesina Pucarita Chica cuenta con un centro de salud de primer nivel fue
construido en la gestión del Alcalde Manfred Relles Villa construcción efectuado por el
proyecto integrado de servicio de salud (PROSISS) en (junio 1998),3 ofrece las
especialidades de Medicina General, Pediatría a todos los comunarios.
La Comunidad Campesina Pucarita Chica cuenta con un colegio convenio .Eusebio Tudela
tapia fue fundado el 4 de Marzo de 1985, se cursa nivel inicial, primaria, secundaria y
bachillerato tanto en turno mañana y tarde.

3
1.1.2.4 Transporte

En la Comunidad Campesina Pucarita Chica algunos comunarios proporcionan sus


camiones como herramientas de trabajo para el traslado de ganados al mercado, cuenta
con los siguientes servicio de transporta público. Así como se muestra en la siguiente tabla.

TIPO DE AUTO LINEA


Taxi Trufi y Micro M
Taxi Trufi 46
Taxi Trufi 104

Tabla 2. Servicio de Transporte Público


Fuente: Elaboración propia

1.1.2.5 Servicios Básicos

La Comunidad Campesina Pucarita Chica cuenta con servicios domiciliarios como Agua, red
de energía eléctrica; y a la vez se beneficia de servicio de telefonía móvil.

1.1.3 Antecedentes del Tema

Empezando de la recopilación de información se pretende analizar, para desarrollar el


sistema, atraves de las entrevistas realizadas al presidente Esteban Escalera de la
asociación y al resto del directorio, y además observaciones realizadas en las distintas
reuniones asistidas al surtidor “El surtidor “se identificaron los siguientes problemas.
En la empresa la parte administrativa todos los procesos son manuales con exactitud es
moroso buscar los datos de los socios para realizar cobros específicos, también se identifica
un indeficiente control de ingresos y egresos.

1.1.3.1 Antecedentes de Proyectos Relacionados

4
En la Comunidad Campesina Pucarita Chica no existe otra empresa de surtidor de
combustible. La Asociación “El surtidor” será el primero en contar con un sistema de
información y administrativo del flujo de sus recursos económicos según sus necesidades.

1.2 PLANTEAMIENTO DEL PROBLEMA

1.2.1 Fundamentación del Problema

Los problemas identificados en base al análisis son:

 El registro de dato de socios es insuficiente e incompleto.


 El registro de socios activos pasivos no se encuentra actualizados.
 El registro de lecturación de consumo.
 Desconformidad de los socios con el informe económico del directorio.
 Dificultad en el control.
 la búsqueda de datos.
 Perdidas por falta de control de ingresos.

La asociación “El surtidor” tiene ingresos por los siguientes conceptos:

 Cuota de afiliación a la Asociación.


 Multa por faltas y retrasos a reuniones ordinarias y extraordinarias.
 Multa por falta de trabajo.
 Multa por demora.
 Pago de consumo de combustible.

La asociación tiene los siguientes egresos:

 Compra de materiales de conexión de gasolina, cañerías y otros materiales para


extender las redes de combustible.
 Pago de viáticos al directorio de la asociación.
 Pago mensual al personal.
5
En la asociación los problemas que presenta son: registro de socios registró y control de la
lecturación así como también la administración económica, falta de información en el
momento requerido Por lo tanto el sistema cumplirá con los requerimientos planificados.

1.2.2 Formulación del Problema

¿Cómo mejorara el Sistema de Información Administrativo para el control de flujo de los


recursos económicos de Asociación “El surtidor” de la Comunidad
Campesina Pucarita Chica?
1.3 OBJETIVOS

1.3.1 Objetivo General

Desarrollar un Sistema de Información Administrativo para facilitar el Control el Flujo de sus


recursos económicos de la Asociación El surtidor de la Comunidad Campesina Pucarita
Chica.

1.3.2 Objetivo Específico

 Recopilar información relevante para el desarrollo del sistema.


 Diseñar la base de datos que almacene la información necesaria.
 Diseñar interfaz de usuario amigable.
 Codificar la funcionalidad del sistema, qué cumpla con los requerimientos de la
Asociación “El surtidor”.
 Realizar un conjunto de pruebas para validar el sistema.
 Formalizar la documentación del desarrollo del sistema para plasmar la guía de
usuario.

1.4 JUSTIFICACIÓN DEL PROYECTO

6
Dado el resultado de la encuesta de la Asociación “El surtidor” se pudo evidenciar que en la
actualidad no tiene un buen control de la información y administración de sus recursos
económicos.
Consecuentemente es necesario la construcción de un Sistema de Información
Administrativo, que facilitara el control y movimiento de sus recursos económicos, La
búsqueda de los reportes será eficaz en el momento que la requiera la directiva o los socios,
y por lo tanto garantizara la seguridad de la información.

CAPITULO 2: MARCO TEÓRICO

2.1 SISTEMAS DE INFORMACIÓN

Vamos a definir tanto el concepto de sistema informático como el de sistema de información.

a) Sistema Informático

Un sistema informático (SI) se puede definir como todo el conjunto de partes que funcionan
relacionados entre sí, para conseguir un objetivo preciso.
Las partes de un sistema informático son:

 Hardware: Está formado por los dispositivos electrónicos y mecánicos que realizan
los cálculos y manejo de información todo lo que podemos tocar.
 Software: son las aplicaciones y los datos que explotan nuestro hardware estará
almacenado en nuestro hardware.
 Personal: Está conformado por los usuarios que interactúan con los equipos
hardware y software.
 Información descriptiva: Es el conjunto de manuales técnicos o de usuario.
Formularios, documentación de procedimientos o cualquier soporte técnico de
instrucciones, sobré el uso del sistema de informático.

7
b) Sistema de Información

Un sistema de información es un conjunto de elementos que interactúan entre sí con el fin de


apoyar las actividades de una empresa o negocio.
Un sistema de información realiza cuatro actividades: almacenamiento, procesamiento, y
salida de información.
Cualquier empresa necesita intercambiar información entre sus departamentos o usuarios de
la organización. Al sistema que se utiliza para este propósito se lo conoce como sistema de
información

2.1.1 Entrada de Información

Es el proceso mediante el cual el Sistema de Información toma los datos que requiere para
procesar la información. Las entradas pueden ser manuales o automáticas. Las manuales
son aquellas que se proporcionan en forma directa por el usuario, mientras que las
automáticas son datos o información que provienen o son tomados de otros sistemas o
módulos. Denominados interfaces automáticas.
Las unidades típicas de entrada de datos a las computadoras son las terminales, las cintas
magnéticas, las unidades de diskette, los códigos de barras, los escáner, la voz,
los monitores sensibles al tacto, el teclado y el mouse, entre otras.

2.1.2 Procesamiento de la Información

Es la capacidad del Sistema de Información para efectuar cálculos de acuerdo con una
secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos
introducidos recientemente en el sistema o bien con datos que están almacenados. Esta
característica de los sistemas permite la transformación de datos fuente en información que
puede ser utilizada para la toma de decisiones4, lo que hace posible, entre otras cosas, que
un tomador de decisiones genere una proyección financiera a partir de los datos que
contiene un estado de resultados o un balance general de un año base.

4
http://www.monografias.com/trabajos7/sisinf/sisinf.shtml
8
2.1.3 Actividades que Realiza un Sistema de Información

Las diferentes actividades que realiza un sistema de información son: entrada,


procesamiento, almacenamiento, salida.
Así como se puede observar en el diseño conceptual de la siguiente figura:

Entrada de Reportes e
datos informes

Proceso

Almacenamiento
(DB)
Interfaz Interfaz
automática automática
de entrada de salida

Figura 2.1. Actividad que realiza un sistema de información.


Fuente: http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

2.1.4 Tipos y Usos de los Sistemas de Información

Durante los próximos años, los sistemas de información cumplirán tres objetivos básicos
dentro de las organizaciones:

1. Automatización de procesos operativos.


2. Proporcionar información que sirva de apoyo al proceso de toma de decisiones.
3. Lograr ventajas competitivas a través de su implementación y uso.

9
Los sistemas de información que logran la automatización de procesos operativos dentro de
una organización, son llamadas frecuentemente Sistemas Transaccionales, ya que su
función primordial consiste en procesar transacciones tales como pagos, cobros, pólizas,
entradas, salidas.
Por otra parte, los sistemas de información que apoyan el proceso de toma de decisiones
son los Sistemas de Soporte a la Toma de Decisiones, Sistemas para Toma de Decisiones
de grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistemas de
información para ejecutivos.
Los sistemas estratégicos, se desarrollan en las organizaciones con el fin de lograr ventajas
competitivas, a través del uso de la tecnología de información.
A continuación se muestran las principales características de estos tipos de Sistemas de
Información.

a) Sistemas Transaccionales.

Sus principales características son:

 A través de estos suelen lograrse ahorros significativos de mano de obra, debido a


que automatizan tareas operativas de la organización.
 Con frecuencia son el primer tipo de información que se implanta en las
organizaciones. Se empieza apoyando las tareas a nivel operativo de la organización.
 Son intensivos en entrada y salida de información; sus cálculos y procesos suelen ser
simples y poco sofisticados.
 Tienen la propiedad de ser recolectores de información, es decir, a través de estos
sistemas se cargan las grandes bases de información para su explotación posterior.
 Son fáciles de justificar ante la dirección general, ya que sus beneficios son visibles y
palpables.

b) Sistemas de Apoyo de las Decisiones.

Las principales características de estos son:

10
 Suelen introducirse después de haber implantado los Sistemas Transaccionales más
relevantes de la empresa, ya que estos últimos constituyen su plataforma de
información.
 La información que generan sirve de apoyo a los mandos intermedios y a la alta
Administración en el proceso de toma de decisiones.
 Suelen ser intensivos en cálculos y escasos en entradas y salidas de información.
Así, por ejemplo, un modelo de planeación financiera requiere poca información de
entrada, genera poca información como resultado, pero puede realizar muchos
cálculos durante su proceso.
 No suelen ahorrar mano de obra. Debido a ello, la justificación económica para
el desarrollo de estos sistemas es difícil, ya que no se conocen
los ingresos del proyecto de inversión.
 Suelen ser Sistemas de Información interactivos y amigables, con altos estándares
de diseño gráfico y visual, ya que están dirigidos al usuario final.
 Apoyan la toma de decisiones que, por su misma naturaleza son repetitivos y de
decisiones no estructuradas que no suelen repetirse. Por ejemplo, un Sistema de
Compra de Materiales que indique cuándo debe hacerse un pedido al proveedor o un
Sistema de Simulación de Negocios que apoye la decisión de introducir un
nuevo producto al mercado.
 Estos sistemas pueden ser desarrollados directamente por el usuario final sin la
participación operativa de los analistas y programadores del área de informática.

c) Sistemas Estratégicos.

Sus principales características son:

 Su función primordial no es apoyar la automatización de procesos operativos ni


proporcionar información para apoyar la toma de decisiones.
 Suelen desarrollarse in house, es decir, dentro de la organización, por lo tanto no pueden
adaptarse fácilmente a paquetes disponibles en el mercado.
 Típicamente su forma de desarrollo es a base de incrementos y a través de su evolución
dentro de la organización. Se inicia con un proceso o función en particular y a partir de
ahí se van agregando nuevas funciones o procesos.

11
 Su función es lograr ventajas que los competidores no posean, tales como ventajas
en costos y servicios diferenciados con clientes y proveedores. En este contexto, los
Sistema Estratégicos son creadores de barreras de entrada al negocio. Por ejemplo, el
uso de cajeros automáticos en los bancos en un Sistema Estratégico, ya que brinda
ventaja sobre un banco que no posee tal servicio. Si un banco nuevo decide abrir sus
puertas al público, tendrá que dar este servicio para tener un nivel similar al de sus
competidores.
 Apoyan el proceso de innovación de productos y proceso dentro de la empresa debido a
que buscan ventajas respecto a los competidores y una forma de hacerlo en innovando o
creando productos y procesos.

Por último, es importante aclarar que algunos autores consideran un cuarto tipo de sistemas
de información denominado Sistemas Personales de Información, el cual está enfocado a
incrementar la productividad de sus usuarios.

2.1.5 Salida de Información

La salida es la capacidad de un Sistema de Información para sacar la información procesada


o bien datos de entrada al exterior. Las unidades típicas de salida son las impresoras,
terminales, diskettes, cintas magnéticas, la voz, los graficadores y los plotters, entre otros. Es
importante aclarar que la salida de un Sistema de Información puede constituir la entrada a
otro Sistema de Información o módulo. En este caso, también existe una interface
automática de salida.

2.2 TECNOLOGÍAS DE ADMINISTRACIÓN DE LA INFORMACIÓN

2.2.1 Bases de Datos


Se guardara toda información y se usara la misma en el mismo sistema con una copia de seguridad
para la administración y para las autoridades competentes

2.2.2 Administración de Base de Datos

12
El administrador de datos (DA) es la persona identificable que tendrá
la responsabilidad central sobre los datos dentro de la empresa. Ya que los datos son uno de
los activos más valiosos de la empresa, es imperativo que exista una persona que los
entienda junto con las necesidades de la empresa con respecto a esos datos, a un nivel
de administración superior. Por lo tanto, es labor del administrador decidir en primer lugar
qué datos deben ser almacenados en la base de datos y establecer políticas para mantener
y manejar esos datos una vez almacenados.
El administrador de base de datos (DBA) es el técnico responsable de implementar las
decisiones del administrador de datos. Por lo tanto, debe ser un profesional en IT. El
trabajo del DBA consiste en crear la base de datos real e implementar los controles técnicos
necesarios para hacer cumplir las diversas decisiones de las políticas hechas por el DA. El
DBA también es responsable de asegurar que el sistema opere con el rendimiento adecuado
y de proporcionar una variedad de otros servicios técnicos.
Los principales sistemas de administración de datos son:

 BorlandParadox  SQL Server 11


 Filemaker  PostgreSQL
 IBM DB2  Oracle
 INGRES  Microsoft FoxPro
 MySQL  Microsoft Access
 Sybase  Microsoft SQL server
 mSQL  Interbase

Tabla 2.3. Manejadores de bases de datos


Fuente: Elaboración propia

2.3 METODOLOGÍA DE DESARROLLO DE SOFTWARE

Una metodología de desarrollo de software se refiere a un framework que es usado para


estructurar, planear y controlar el proceso de desarrollo en sistemas de información.
A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose
por su fortaleza y debilidad.

13
El framework para metodología de desarrollo de software consiste en:

 Una filosofía de desarrollo de programas de computación con el enfoque del proceso


de desarrollo de software.
 Herramientas, modelos y métodos para asistir al proceso de desarrollo de software.

2.3.1 Rational Unified Process (RUP)

El Proceso Unificado de Rational (Rational Unified Process )(RUP) es un proceso de


desarrollo5 de software desarrollado por la empresa Rational Software, actualmente
propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la
metodología estándar más utilizada para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software, también desarrollado por Rational, que
incluye información entrelazada de diversos artefactos y descripciones de las diversas
actividades. Está incluido en el Rational Method Composer (RMC), que permite la
personalización de acuerdo con las necesidades.

2.3.1.1 Lenguaje Unificado de Modelado (UML)

(UML) (Unified Modeling Language) es el lenguaje de modelado de sistemas


de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object
Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y
documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema
(modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas
de bases de datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para
describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos

5
http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm
14
en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está
descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a
una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP),
pero no específica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje
Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización
en un requerimiento. Mientras que, programación estructurada, es una forma de programar
como lo es la orientación a objetos, la programación orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados
a objetos.

2.3.2 Ciclo de Vida de un Sistema de Información

El ciclo de vida de un sistema de información es un enfoque por fases del análisis6 y diseño
que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un
ciclo especifico de actividades del analista y del usuario. Según James Senn, existen tres
estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo
de sistemas, el método de desarrollo por análisis estructurado y el método de construcción
de prototipos de sistemas. Cada una de estas estrategias tiene un uso amplio en cada una
de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de
manera adecuada.

2.3.2.1 Incremental

6
http://www.monografias.com/trabajos29/ciclo-sistema/ciclo-sistema.shtml
15
Figura 2.2. Modelo Incremental
Fuente: http://procesosoftware.wikispaces.com/Modelo+Incremental

Provee una estrategia para controlar la complejidad y los riegos, desarrollando una parte del
producto software7 reservando el resto de aspectos para el futuro.

Los principios básicos son:

 Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada
modelo de desarrollo se han completado para una pequeña parte de los sistemas,
antes de proceder a la próxima incremental.
 Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-
Cascada de desarrollo de cada uno de los incrementos del sistema.
 El concepto inicial de software, análisis de las necesidades, y el diseño de la
arquitectura y colectiva básicas se definen utilizando el enfoque de cascada, seguida
por iterativo de prototipos, que culmina en la instalación del prototipo final.

2.3.2.2 Evolutivo

7
http://ingenexescom.blogspot.com/2012/02/modelo-incremental.html
16
El ciclo de vida evolutivo, permiten desarrollar versiones cada vez más completas y
complejas8, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la
fase de operación. Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los
más conocidos y utilizados del tipo evolutivo.
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el
sistema adecuado.Una ventaja de este modelo es que se obtiene una rápida realimentación
del usuario9, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en
cada iteración.

Actividades Concurrentes

Versión Inicial
Especificación

Versiones
Descripción Desarrollo
Intermedias
Del sistema

Validación
Versión Final

Figura 2.3. Modelo Evolutivo


Fuente: http://jorgetrejos.blogspot.com/2010/08/modelo-evolutivo.html

Existen dos tipos de desarrollo evolutivo:

 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los


requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que
se tiene más claras. El sistema evoluciona conforme se añaden nuevas
características propuestas por el usuario.
 Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y
trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo
exploratorio, se comienza por definir los requisitos que no están claros para el usuario

8
http://jorgetrejos.blogspot.com/2010/08/modelo-evolutivo.html
9
www.manycomics.com/ingenieria-del-software/ciclo-vida-software
17
y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de
definir estos requisitos.

Ventajas

 La especificación puede desarrollarse de forma creciente.


 Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se
refleja en una mejora de la calidad del software.
 Es más efectivo que el modelo de cascada, ya que cumple con las necesidades
inmediatas del cliente.

Desventajas

 Proceso no Visible: Los administradores necesitan entregas para medir el progreso.


Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que
reflejen cada versión del sistema.
 Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales
para la estructura del software haciendo costoso el mantenimiento.
 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan
herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

2.3.2.3 Cascada

Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia
abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades,
el diseño, implantación, pruebas (validación), la integración, y mantenimiento.

Los principios básicos del modelo de cascada son los siguientes:

 El proyecto está dividido en fases secuenciales, con cierta superposición.


 Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución
de todo un sistema de una sola vez.

18
 Un estricto control se mantiene durante la vida del proyecto a través de la utilización
de una amplia documentación escrita, así como a través de comentarios y
aprobación por el usuario y la tecnología de la información de gestión al final de la
mayoría de las fases antes de comenzar la próxima fase.

2.4 TECNOLOGÍAS WEB

Las tecnologías Web sirven para acceder a los recursos de conocimiento10 disponibles en
Internet o en las intranets utilizando un navegador. Están muy extendidas por muchas
razones: facilitan el desarrollo de sistemas de Gestión del Conocimiento su flexibilidad en
términos de escalabilidad, es decir, a la hora de expandir el sistema; su sencillez de uso y
que imitan la forma de relacionarse de las personas, al poner a disposición de todos el
conocimiento de los demás, por encima de jerarquías, barreras formales u otras cuestiones.
Estas tecnologías pueden llegar a proporcionar recursos estratégicos, pero, evidentemente,
no por la tecnología en sí misma, que está disponible ampliamente, sino por lo fácil que es
personalizarla y construir con ella sistemas de gestión de conocimientos.

2.4.1 Servidores de Archivos Web

2.4.1.1 PHP (Paginas Preprocesador de Hipertexto)

Es un lenguaje de programación de uso general de código del lado del servidor


originalmente diseñado para el desarrollo web.
PHP puede ser desplegado en la mayoría de los servidores web y en casi todo los sistemas
operativos y plataformas sin costo alguno.
Permite la conexión a diferentes tipos de servidores de base de datos tanto SQL como
NoSQL tales como MySQL, PostgreSQL, Oracle, ODBC, DB2, Microsoft SQL Server,
Firebird, SQLite.
Php también tiene la capacidad de ser ejecutado en la mayoría de los sistemas operativos
tales como Unix, Linux o Mac OSX y Microsoft Windows.

10
http://www.sociedadelainformacion.com/12/tecnologiasweb.pdf

19
Características

 El código fuente escrito en PHP es invisible al navegador web y al cliente.


 Es considerado un lenguaje fácil de aprender ya que en su desarrollo se
simplificaron distintas especificaciones.
 Capacidad de conexión con la mayoría de los motores de base de datos.
 Permite aplicar técnicas de programación orientado a objetos.
 No requiere definición de tipos de variables.

2.4.1.2 HTML (Lenguaje de Marcado de Hipertexto)

Es un lenguaje de, marcado para la elaboración de páginas web. Es un estándar que sirve
de referencia para la elaboración de páginas web en sus diferentes versiones, define una
estructura básica y un código (denominado código HTML) para la definición de contenido de
una página web, como texto, imágenes, etc. Es un estándar a cargo de la organización
dedicada a la estandarización de casi todas las tecnologías ligadas a la web, sobre todo en
lo referente a su escritura e interpretación. Es el lenguaje con el que se definen las páginas
web.
El lenguaje HTML basa su filosofía de desarrollo en la referenciación. Para añadir un
elemento externo a la página (imagen, vídeo, script, etc.).

2.4.1.3 Java Script

Es un lenguaje de programación interpretado dialecto del estándar Se define como orientado


a objetos basado en prototipos, imperativo, débilmente tipado y dinámico.
Se utiliza principalmente en su forma del lado del cliente, implementado como parte de
un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas
JavaScript se diseñó con una sintaxis similar al C, aunque adopta nombres y convenciones
del lenguaje de programación Java. Sin embargo Java y JavaScript no están relacionados y
tienen semánticas y propósitos diferentes.

20
2.4.2 Navegadores Web

Un navegador web es una aplicación utilizada en internet y que se utiliza para la


interpretación de sitios web o archivos que generalmente están desarrollados en el código
HTML. Los buscadores son entonces los que permiten visualizar textos, gráficos,
animaciones, acceder a sonidos y ejecutar programas.
Los navegadores más usados actualmente son:

 Google Chrome

Es un navegador web desarrollado por Google y copilado con base en componentes11 de


código abierto. Está disponible gratuitamente bajo condiciones de servicio específico puede
ser considerado el navegador más usado de internet variando hasta el segundo puesto
algunas beses logrando popularidad mundial en la primera posición.
Su interfaz es agradable y solo tiene lo esencial por lo cual hay un gran espacio de pantalla.
Consume menos recursos de la computadora que mozilla Firefox.

 Mozilla Firefox

Es un navegador web libre y de código abierto desarrollado para Microsoft Windows, Mac
OS X y GNU/Linux coordinado por la Corporación Mozilla y la Fundación Mozilla. Usa el
motor Gecko para renderizar páginas webs, el cual implementa actuales y futuros estándares
web A partir de agosto de 2012 Firefox tiene aproximadamente un 23 % de la cuota de
mercado, convirtiéndose en el tercer navegador web más usado, con particular éxito
en Indonesia, Alemania y Polonia, donde es el más popular con un 65 %, 47 %y 47 %de uso,
respectivamente. Está en el número 2 en la lista de más descargas de navegadores web
en Softonic.

11
http://www.ayudaenlaweb.com/navegadores/que-es-google-chrome/
21
 Internet Explorer

Es un navegador web desarrollado por Microsoft para el sistema operativo Microsoft


Windows desde 1995. Es el navegador web más utilizado de Internet desde 1999, con un
pico máximo de cuota de utilización del 95% entre el 2002 y 2003. Sin embargo, dicha cuota
de mercado ha disminuido paulatinamente con los años debido a una renovada competencia
por parte de otros navegadores.

2.4.3 Tecnologías Cliente Servidor

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se


reparten entre los proveedores de recursos o servicios, llamados servidores12, y los
demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor,
quien le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan
sobre una sola computadora, aunque es más ventajosa en un sistema
operativo multiusuario distribuido a través de una red de computadoras.

Características

 Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la


comunicación (dispositivo maestro o amo).
 Espera y recibe las respuestas del servidor.
 Por lo general, puede conectarse a varios servidores a la vez.
 Normalmente interactúa directamente con los usuarios finales mediante una interfaz
gráfica de usuario.
 Al contratar un servicio de redes, se debe tener en cuenta la velocidad de conexión
que le otorga al cliente y el tipo de cable que utiliza, por ejemplo: cable de cobre
ronda entre 1 ms y 50 ms.
 Al receptor de la solicitud enviada por el cliente se conoce como servidor. Sus
características son:

12
http://www.monografias.com/trabajos24/arquitectura-cliente-servidor/arquitectura-cliente-servidor.shtml

22
 Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan
entonces un papel pasivo en la comunicación (dispositivo esclavo).
 Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
 Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos
casos el número máximo de peticiones puede estar limitado).
 No es frecuente que interactúen directamente con los usuarios finales.

23
CAPÍTULO 3: ANALISIS DEL SISTEMA

3.1 DESCRIPCIÓN DEL SISTEMA

El sistema información administrativo a desarrollar, proporcionara una información confiable,


dado que la información se almacenara en una base de datos desde un interfaz amigable
con el usuario, la búsqueda de algún dato será inmediata y, los reportes se realizaran en el
momento que se requiera, reducirá la perdida de información.

3.2 ANALISIS DE REQUERIMIENTOS

Se realiza la especificación correcta del comportamiento del sistema, según la investigación


y las alternativas, identificar y documentar realizando una descripción de los servicios que el
sistema debe proveer al usuario.
La compresión de los requerimientos es fundamentalmente para el desarrollo del sistema,
donde se presentara un modelo del sistema propuesto, en el que se definirán las entidades
que interactuaran con el sistema.

3.3 DEFINICIÓN DE REQUERIMIENTOS

Un requerimiento es una condición o capacidad que debe exhibir o poseer un sistema para
satisfacer un contrato, estándar, especificación, u otra documentación formalmente
impuesta.
Los requerimientos son declaraciones que identifican atributos, capacidades, características
y cualidades que necesita cumplir un sistema para que tenga valor y utilidad para el usuario.

3.3.1 Requerimientos Funcionales

Es todo lo que el sistema debe cumplir o hacer, estos describen la funcionalidad que se
espera del sistema.
La Asociación de Agua Potable “San Haniel” tendrá las siguientes funciones en el sistema.

24
Secretario de Actas

 Administrador de Socios
 Registrar socios
 Modificar los datos de los socios
 Dar baja datos del socio
 Lista de socios
 Lista de socios dados de baja

 Administrador de actividades
 Registrar asistencia de actividades
 Modificar asistencia de actividades
 Lista de socios presentes en la actividad según fecha
 Lista de socios con faltas de asistencia en la actividad
 Lista se socios con retraso en asistencia
 Historial de asistencia de los socios a las actividades

 Administrador del Directorio


 Registrar asignar cargo al socio
 Modificar cargo asignado al socio
 Dar baja socio con cargo asignado
 Lista de directorio según Gestión
 Lista de directorio dados de baja según gestión

 Administrador del Personal de Apoyo


 Registrar personal de apoyo
 Modificar personal de apoyo
 Dar baja personal de apoyo
 Lista del personal de apoyo
 Lista del personal de apoyo dados de baja

 Administrador de tipo cargo


 Cargos del directorio

25
o Registrar crear tipo cargo
o Modificar tipo cargo
o Dar de baja tipo cargo
o Lista de tipo cargo
o Lista de tipo cargo dados de baja

 Generar reportes
 Reporte de socios
o Reporte de socios activos
o Reporte de socios dados de baja según fecha
 Reporte de actividades
o Reporte de actividades según tipo de asistencia y fecha
o Reporte de socios según tipo de asistencia a la actividad
 Reporte de la mesa directiva según gestión
 Reporte de mesa directiva según cargo
 Reporte del personal de apoyo dados de baja según fecha

Secretario de Haciendas

 Gestor de cobros
 Registrar cobro cuota de afiliación
 Registrar cobro de deuda de actividades según tipo de asistencia
 Registrar cobro el consumo de agua
 Historial de socios de pago de consumo de agua
 Historial de socios de pago de actividades
 Registrar emite recibo de pago

 Administración de lecturación
 Registrar lecturación de medidor
 Lista de socios sin lecturación registrada
 Lista de socios con lecturación registrada
 Historial de socios de consumo

26
 Administración económica
 Registrar ingreso
 Registrar egreso
 Lista de ingresos
 Lista de egresos

 Administrador de afiliación
 Modificar deuda de afiliación
 Lista de socios con duda de afiliación

 Administrador de precio
 Registrar precio de consumo
 Registrar precio recargue de consumo
 Registrar precios de faltas de actividades según tipo de asistencia
 Dar de baja precio
 Lista de precio
 Lista de precios dados de baja

 Caja
 Reporte de saldo en caja
 Reporte de egresos según fecha
 Reporte de ingresos según fecha

 Administrador de días de tolerancia


 Registrar días de tolerancia de pago de consumo
 Modificar días de tolerancia

 Generar reportes
 Reporte de socios con deuda de consumo
 Reporte de socios con deuda de actividad
 Reporte de socios con deuda de afiliación

27
Presidente
 Generar reporte de socios
 Generar reporte de caja
 Reporte de ingresos según fecha
 Reporte de egresos según fecha
 Reporte de socios con deuda según tipo de deuda
 Generar reporte de usuarios

3.3.2 Requerimientos no Funcionales

 Flexible el sistema podrá modificarse según la necesidad de la Asociación.


 Confiable el sistema realizara su función de manera satisfactoria garantizará la
seguridad de información de los socios y el movimiento de sus recursos económicos.
 Robusto El sistema será capaz de mostrar mensajes de error en casos de falla del
sistema.

3.3.3 Requerimientos de Hardware y Software


 Requerimientos de Hardware Cliente
 Procesador 1.00 Ghz o superior
 Disco duro espacio libre 500 Gb o superior libre
 Memoria RAM 1 Gb o superior
 Video 512 Mb o superior
 Monitor SVGA
 Teclado, Mouse
 Impresora

 Requerimientos de Software Cliente


 Sistema Operativo Windows7/Linux Ubuntu
 PhP 5.3.27
 Mysql 5.5.34
 Apache 2.2.26

28
 Requerimientos de Hardware Servidor
 Procesador 3.0 i7 Ghz o superior
 Disco duro 1 Tera espacio libre 500 Mb
 Memoria RAM 4 Gb o superior
 Video 1 Gb o superior
 Monitor SVGA
 Teclado, Mouse

3.4 IDENTIFICACIÓN DE USUARIOS

La identificación de los usuarios es muy importante para el Sistema de Información, debido a


que todos los servicios se realizan partiendo desde sus informaciones.
A continuación se mencionan los usuarios identificados: El sistema funcionara como (mono
usuario o multiusuario).
Mono usuario es un sistema operativo o aplicación que solamente puede ser usado por un
único usuario en un determinado momento y multiusuario son aquellos que permiten uno o
más usuarios.

3.4.1 Requerimientos de Seguridad (BackUps)

Para crear backup se debe tener en cuenta los siguientes factores:


Hardware frente a software: Aunque el hardware es importante, la flexibilidad de los backups
dependen del software, los cuales determinan si los requerimientos del usuario pueden ser
satisfechos o no.
Cada usuario puede hacer diferentes Backups dependiendo a la necesidad cada uno tiene
su propia aplicación los cuales son:

 Backups incrementales: Se puede copiar todos los archivos que han sido
modificados desde el backup anterior.
 Backups Simultáneos: Cuando los sistemas de imagen espejo pueden escribir los
datos dos veces en discos duros idénticos.
 Backups en serie: se hace una serie de copias del mismo archivo, capturado cada
etapa de su evolución.

29
 Backups Globales: Se pueden copiar todos los datos del disco duro, incluyendo la
estructura del árbol y los archivos del sistema.
 Backups Parciales: Se puede copiar un grupo relacionado de archivos y crea una
imagen de los datos de un determinado momento.

3.5 MODELO DE CASOS DE USO DEL SISTEMA

3.5.1 Identificación de Actores

 Sistema
 Usuario

3.5.2 Identificación de Casos de Uso

a) Usuario Secretario de actas

 Caso de uso registrar socios


 Caso de uso modificar socio
 Caso de uso dar baja socio
 Caso de uso registrar crear tipo cargo
 Caso de uso modificar tipo cargo
 Caso de uso dar baja tipo cargo
 Caso de uso registrar asistencia de actividades
 Caso de uso modificar asistencia de actividades
 Caso de uso reporte de socios dados de baja
 Caso de uso reporte de directorio según gestión

b) Usuario Secretario de Haciendas

 Caso de uso registrar lecturación de medidor


 Caso de uso modificar lecturación
 Caso de uso registrar emite recibo de pago
 Caso de uso registrar cobro de consumo de agua

30
 Caso de uso registrar cobro de cuota de afiliación
 Caso de uso registrar egreso

c) Usuario Presidente

 Caso de uso reporte de ingresos y egresos


 Caso de uso reporte de pago de consumo de agua según fecha
 Caso de uso reporte de socios con deuda según tipo de deuda

3.5.3 Diagrama de Casos de Uso del Sistema

El diagrama de caso de uso muestra todas las relaciones que existe entre los actores y
los casos de usos del sistema, representando la funcionalidad que ofrece el sistema al
usuario es decir interacción externa.

31
3.5.3.1 Caso de uso Secretario de Actas

DIAGRAMA DE CASO DE USO REGISTRAR SOCIO

 Registrar socio (Ver figura 3.1 y tabla 3.1).

SISTEMA

Llenar
formulario
<< include >>

Verificar datos

<< include >>

Registrar socio

SECRETARIO DE ACTAS

Figura 3.1. Diagrama de caso de uso: Registrar socio

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Datos en formulario  Llenar formulario  Lista de socios


 Verificar datos
 registrar

Tabla 3.1. Registrar socio


Precondición:
 Nuevo solicitud de registro.
Condiciones resultantes:
 Datos guardados en la base de datos.

32
DIAGRAMA DE CASO DE USO MODIFICAR DATOS DE SOCIO

 Modificar socio (Ver figura 3.2 y tabla 3.2).

SISTEMA

Buscar datos
datos
<< include >>

Editar datos en le
formulario
<< include >>

Verificar datos
<< include >>

SECRETARIO DE ACTAS Guardar cambios

Figura 3.2. Diagrama de caso de uso: Modificar socio

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Buscar datos del  Buscar datos de  Lista de socios


socio socio
 Editar datos
 Verificar datos
 Guardar cambios

Tabla 3.2. Modificar socio


Precondición:
 Socio registrado en el sistema.
Condiciones resultantes:
 Datos guardados en la base de dato.
33
DIAGRAMA DE CASO DE USO DAR BAJA SOCIO

 Dar baja socio (Ver figura 3.3 y tabla 3.3).

SISTEMA

Buscar socio
<< include >>

Verificar datos

<< include >>

Dar baja

SECRETARIO DE ACTAS
Figura 3.3. Diagrama de caso de uso: Dar baja socio

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Buscar datos del  Buscar socio  Lista de socios


socio  Verificar datos
 Dar baja

Tabla 3.3. Dar baja socio

Precondición:
 Socio registrado en el sistema.
Condiciones resultantes:
 Datos guardados en la base de datos.
34
DIAGRAMA DE CASO DE USO CREAR TIPO CARGO

 Crear tipo cargo (Ver figura 3.4 y tabla 3.4).

SISTEMA

Llenar formulario
<< include >>

Verificar datos

<< include >>

Registrar cargo

SECRETARIO DE ACTAS

Figura 3.4. Diagrama de caso de uso: Crear tipo cargo

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Datos en formulario  Llenar formulario  Lista de cargos


 Verifica datos
 Registra cargo

Tabla 3.4. Registrar crear tipo cargo


Precondición:
 Nuevo solicitud de registro.
Condiciones resultantes:
 Datos guardados en la base de datos.

35
DIAGRAMA DE CASO DE USO MODIFICAR TIPO CARGO

 Modificar tipo cargo (Ver figura 3.5 y tabla 3.5).

SISTEMA

Buscar cargo
<< include >>

Editar datos al
formulario << include >>

Verificar datos
<< include >>

Guardar
cambios

SECRETARIO DE ACTAS

Figura 3.5. Diagrama de caso de uso: Modificar tipo cargo

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Buscar datos del  Buscar socio  Lista de cargos


cargo  Editar datos
 Verifica datos
 Guardar cambios

Tabla 3.5. Modificar tipo cargo


Precondición:
 Tipo cargo registrado en el sistema.
Condiciones resultantes:
 Datos guardados en la base de datos.
36
DIAGRAMA DE CASO DE USO DAR BAJA TIPO CARGO

 Dar baja tipo cargo (Ver figura 3.6 y tabla 3.6).

SISTEMA

Buscar tipo cargo


<< include >>

Verificar datos

<< include >>

Dar baja cargo

SECRETARIO DE ACTAS

Figura 3.6. Diagrama de caso de uso: Dar baja tipo cargo

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Buscar datos del  Buscar tipo cargo  Lista de cargos


cargo  Verifica datos
 Dar baja cargo

Tabla 3.6. Dar baja tipo cargo


Precondición:
 Tipo cargo registrado en el sistema.
Condiciones resultantes:
 Datos guardados en la base de datos.

37
DIAGRAMA DE CASO DE USO REGISTRAR ASISTENCIA DE ACTIVIDADES

 Registrar asistencia de actividad (Ver figura 3.7 y tabla 3.7).

SISTEMA

Generar lista de socios

<< include >>

Verificar datos

<< include >>

Registrar asistencia

SECRETARIO DE ACTAS

Figura 3.7. Diagrama de caso de uso: Registrar asistencia de actividades

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Lista de socios  Genera lista  Lista de asistencia


 Verifica datos
 Registra asistencia

Tabla 3.7. Registrar asistencia trabajos comunales


Precondición:
 Nuevo solicitud de registro.
Condiciones resultantes:
 Datos guardados en la base de datos.

38
DIAGRAMA DE CASO DE USO MODIFICAR ASISTENCIA DE ACTIVIDADES

 Modificar asistencia de actividad (Ver figura 3.8 y tabla 3.8).

SISTEMA

Buscar datos de socio

<<include>>

Verificar datos

<<include>>

Modificar asistencia

SECRETARIO DE ACTAS

Figura 3.8. Diagrama de caso de uso: Modificar asistencia de actividad

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Lista de socios  Buscar datos de  Lista de asistencia


socio
 Verifica datos
 Modificar asistencia

Tabla 3.8. Modificar asistencia trabajos comunales


Precondición:
 Asistencia registrada en el sistema.
Condiciones resultantes:
 Datos guardados en la base de datos.

39
DIAGRAMA DE CASO DE USO REPORTE DE SOCIOS DADOS DE BAJA

 Reporte de socios dados de baja (Ver figura 3.9 y tabla 3.9).

SISTEMA

Seleccionar
reporte
<< include >>

Verificar datos

<< include >>

Imprimir

SECRETARIO DE ACTAS

Figura 3.9. Diagrama de caso de uso: Reporte de socios dados de baja

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Seleccionar reporte  Seleccionar reporte  Lista de socios


 Verifica datos dados de baja
 Imprimir reporte

Tabla 3.9. Reporte de socios dados de baja


Precondición:
 Socio dado de baja en el sistema.
Condiciones resultantes:
 Lista de socios dados de baja impreso.

40
DIAGRAMA DE CASO DE USO REPORTE DEL DIRECTORIO GESTIÓN

 Reporte de directorio gestión (Ver figura 3.10 y tabla 3.10).

SISTEMA

Seleccionar
reporte
<< include >>

Buscar gestión

<< include >>

Imprimir

SECRETARIO DE ACTAS

Figura 3.10. Diagrama de caso de uso: Reporte de directorio gestión

Actor: Usuario Secretario de Actas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Seleccionar reporte  Seleccionar reporte  Petición de reporte


 Buscar gestión mostrado
 Imprimir reporte  Imprimir

Tabla 3.10. Reporte de directorio gestión


Precondición:
 Petición de reporte mostrado.
Condiciones resultantes:
 Lista de directorio según gestión impreso.

41
3.5.3.2 Caso de uso Secretario de Haciendas

DIAGRAMA DE CASO DE USO REGISTRAR LECTURACIÓN DE MEDIDOR

 Registrar lecturación (Ver figura 3.11 y tabla 3.11).

SISTEMA

Buscar medidor

<< include >>

Verificar datos

<< include >>

Registrar
lecturación

SECRETARIO DE
HACIENDAS

Figura 3.11. Diagrama de caso de uso: Registrar lecturación

Actor: Usuario Secretario de Haciendas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Buscar medidor  Buscar datos de  Lista de medidores


medidor
 Verificar datos
 Registrar lecturación

Tabla 3.11. Registrar lecturación de medidor


Precondición:
 Nuevo solicitud de registro.
Condiciones resultantes:
 Datos guardados en la base de datos.

42
DIAGRAMA DE CASO DE USO MODIFICAR LECTURACIÓN DE MEDIDOR

 Modificar lecturación (Ver figura 3.12 y tabla 3.12).

SISTEMA

Buscar medidor

<< include >>

Editar datos

<< include >>

Verificar datos

<< include >>

Registrar datos
SECRETARIO DE modificados
HACIENDAS

Figura 3.12. Diagrama de caso de uso: Modificar lecturación

Actor: Usuario Secretario de Haciendas.


Descripción:

ENTRADA ACTIVIDAD SALIDA


 Buscar datos de
 Buscar medidor Medidor  Lista de medidores
 Editar datos
 Verificar datos
 Registrar datos

Tabla 3.12. Modificar lecturación de medidor


Precondición:
 Lecturación registrado en el sistema.
Condiciones resultantes:
 Datos guardados en la base de datos.
43
DIAGRAMA DE CASO DE USO REGISTRAR EMITE RECIBO

 Registra emite recibo (Ver figura 3.13 y tabla 3.13).

SISTEMA

Generar recibo de pago

<<include>>

Verificar datos de recibo

<<include>>

Imprimir recibo
SECRETARIO DE
HACIENDAS

Figura 3.13. Diagrama de caso de uso: Registra emite recibo

Actor: Usuario Secretario de Haciendas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Generar recibo  Genera recibo  Recibo impreso


 Verifica datos
 Imprimir recibo

Tabla 3.13. Registrar emite recibo

Precondición:
 Nuevo solicitud de registro.
Condiciones resultantes:
 Datos guardados en la base de datos.

44
DIAGRAMA DE CASO DE USO REGISTRAR COBRO DE CONSUMO DE AGUA

 Registra cobro de consumo de agua (Ver figura 3.14 y tabla 3.14).

SISTEMA

Generar lista de cobros


<<include>>

Verificar cobros

<<include>>

Registrar cobrar

<<include>>

SECRETARIO DE
Generar recibos
HACIENDAS

Figura 3.14. Diagrama de caso de uso: Registra cobro de consumo de agua

Actor: Usuario Secretario de Haciendas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Lista de cobros  Genera lista cobros  Lista de cobros


 Verifica cobros
 Registrar cobrar
 Generar recibos

Tabla 3.14. Registrar cobro de consumo de agua

Precondición:
 Nuevo solicitud de cobro.
Condiciones resultantes:
 Datos guardados en la base de datos.
45
DIAGRAMA DE CASO DE USO REGISTRAR COBRO DE CUOTA DE AFILIACIÓN

 Registra cobro de afiliación (Ver figura 3.15 y tabla 3.15).

SISTEMA

Generar lista de cobros


<<include>>

Verificar cobros

<<include>>

Registrar cobrar

<<include>>

SECRETARIO DE Generar recibo de


HACIENDAS afiliación

Figura 3.15. Diagrama de caso de uso: Registra cobro de cuota de afiliación

Actor: Usuario Secretario de Haciendas.


Descripción:

ENTRADA ACTIVIDAD SALIDA


 Lista de cobros  Genera lista cobros  Lista de cobros
 Verifica cobros
 Registrar cobrar
 Generar recibos

Tabla 3.15. Registrar cobro de cuota de afiliación

Precondición:
 Nuevo solicitud de cobro.
Condiciones resultantes:
 Datos guardados en la base de datos.

46
DIAGRAMA DE CASO DE USO REGISTRAR EGRESO

 Registrar egreso (Ver figura 3.16 y tabla 3.16).

SISTEMA

Llenar
formulario
<< include >>

Verificar datos

<< include >>

Registrar egreso
SECRETARIO DE
HACIENDAS

Figura 3.16. Diagrama de caso de uso: Registrar egreso

Actor: Usuario Secretario de Haciendas.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Datos en formulario  Llenar formulario  Lista de egresos


 Verificar datos
 Registrar egreso

Tabla 3.16. Registrar egreso


Precondición:
 Nuevo solicitud de registro.
Condiciones resultantes:
 Datos guardados en la base de datos.
47
3.5.3.3 Caso de uso Presidente

DIAGRAMA DE CASO DE USO: REPORTE DE INGRESOS Y EGRESOS

 Reporte de ingresos y egresos (Ver figura 3.17 y tabla 3.17).

SISTEMA

Seleccionar egreso
económico
<< include >>
Parámetros de
fecha

<< include >> << include >>


Seleccionar ingreso
económico
Imprimir
reporte
PRESIDENTE

Figura 3.17. Diagrama de caso de uso: Reporte de ingresos y egresos

Actor: Usuario Presidente.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Seleccionar reporte  Seleccionar reporte  Petición de reporte


 Para metros de mostrado
fecha  imprimir
 Imprimir reporte

Tabla 3.17. Reporte de ingresos y egresos


Precondición:
 Ingreso o egreso registrado en el sistema.
Condiciones resultantes:
 Reporte de ingreso o egreso impreso.

48
DIAGRAMA DE CASO DE USO: REPORTE DE PAGO DE CONSUMO DE AGUA

 Reporte de pago de consumo de agua (Ver figura 3.18 y tabla 3.18).

SISTEMA

Seleccionar
reporte pago
consumo << include >>

Para metros de
fecha
<< include >>

Imprimir
reporte

PRESIDENTE

Figura 3.18. Diagrama de caso de uso: Reporte de pago de consumo de agua

Actor: Usuario Presidente.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Seleccionar reporte  Seleccionar reporte  Reporte impreso


 Verificar reporte
 Imprimir reporte

Tabla 3.18. Reporte de pago de consumo de agua


Precondición:
 Solicitud de reporte.
Condiciones resultantes:
 Reporte de pago de consumo de agua impreso.

49
DIAGRAMA DE CASO DE USO: REPORTE DE SOCIOS TIPO DEUDA

 Reporte de socios tipo deuda (Ver figura 3.19 y tabla 3.19).

SISTEMA

Seleccionar
reportes
<< include >>

Verificar

<< include >>

Imprimir
reporte
PRESIDENTE

Figura 3.19. Diagrama de caso de uso: Reporte de socio tipo deuda

Actor: Usuario Presidente.


Descripción:

ENTRADA ACTIVIDAD SALIDA

 Seleccionar reporte  Seleccionar reporte  Petición de reporte


 Para metros de mostrado
fecha  imprimir
 Imprimir reporte

Tabla 3.19. Reporte de socios tipo deuda


Precondición:
 Solicitud de reporte.
Condiciones resultantes:
 Reporte de socios tipo deuda impreso.

50
CAPÍTULO 4: DISEÑO DEL SISTEMA

4.1 Diseño del Sistema

4.1.1 Introducción

En la fase de diseño, el ciclo de vida de desarrollo del sistema, se utiliza la información


recopilada, para realizar el diseño lógico del sistema de información. Realizando
procedimientos precisos para la captura de datos que aseguran que los datos que ingresan
al sistemas de información sean correctos, mediante técnicas adecuadas de diseño de
formularios y pantallas13.

4.2 Diagrama de Interacción

4.2.1 Diagrama de Estados de los Casos de Uso

El diagrama de estados muestra los diferentes estados en que un objeto se encuentra y


como se dan las transiciones de cada estado a otros estados. Un diagrama de estado
contiene los siguientes componentes:

 Los estados se muestran dentro de cuadros con esquinas redondeadas.


 Transiciones entre estados mediante flechas.
 Sucesos que provocan las transiciones entre estados.
 Marca de parada (fin), indica que un objeto ha alcanzado el final.

13
E.KENDALL, KENNETH /Análisis y diseño de sistemas/Sexta edición /PEARSON EDUCACION/México 2005
51
4.2.1.1 Diagrama de Estado Secretario de Actas

 Diagrama de Estados de Casos de Uso: Registrar Socio

Menú registrar Solicita datos Registra nuevos


socio de socio datos
Datos solicitados por el
Formulario mostrado Registrar datos
secretario de actas

Verificar datos
Negar
registración
Datos incorrectos Datos verificados

Datos aceptado
Menú salir
Datos registrados correctamente
Datos almacenados en DB Datos registrado

Figura 4.1. Diagrama de estado de caso de uso: Registrar socio

 Diagrama de Estado de Caso de Uso: Modificar Datos Socio

Buscar datos Verificar datos


Menú modificar solicitados
socio
Datos solicitados por
Buscar datos Datos encontrados
secretario de actas

Modificar datos
Verificar datos

Solicitar datos Datos no encontrados Datos modificado

Menú salir Actualizar DB


Los datos se guardaron correctamente
Datos almacenados en DB DB actualizada

Figura 4.2. Diagrama de estado de caso de uso: Modificar socio

52
 Diagrama de Estado de Caso de Uso: Dar Baja Socio

Menú opción Buscar datos Verificar datos


Dar baja solicitados

Datos solicitados por


Buscar datos Datos encontrados
secretario de actas

Dar baja
Verificar datos

Solicitar datos Datos no encontrados Dado de baja

Menú salir

Actualizar datos
Datos de baja en DB

Figura 4.3. Diagrama de estado de caso de uso: Dar baja socio

 Diagrama de Estado de Caso de Uso: Registrar Crear Tipo cargo

Menú registrar
cargo Llenar datos Registrar datos
Datos llenados por Secretario
Formulario mostrado Registrar datos
de Actas

Verificar datos
Negar
registración
Datos incorrectos Datos verificados

Datos aceptado
Menú salir
Datos registrados correctamente
Datos almacenados en
Datos registrado
DB

Figura 4.4. Diagrama de estado de caso de uso: Registrar crear tipo cargo

53
 Diagrama de Estado de Caso de Uso: Modificar Tipo Cargo

Buscar datos Verificar datos


Menú modificar solicitados
cargo

Ingresar datos a buscar Buscar datos Datos encontrados

Modificar datos
Verificar datos

Solicitar datos Datos no encontrados Datos modificado

Menú salir Actualizar DB


Los datos se guardaron correctamente
Datos almacenados en DB DB actualizada

Figura 4.5. Diagrama de estado de caso de uso: Modificar tipo cargo

 Diagrama de Estado de Caso de Uso: Dar baja Tipo Cargo

Buscar datos Verificar datos


Menú Dar de baja solicitados
Tipo cargo

Ingresar datos a buscar Buscar datos Datos encontrados

Dar de baja
Verificar datos

Solicitar datos Datos no encontrados Datos dados de baja

Menú salir Actualizar DB


Los datos se guardaron correctamente
Datos dados de baja en DB DB actualizada

Figura 4.6. Diagrama de estado de caso de uso: Dar bajo tipo cargo

54
 Diagrama de Estado de Caso de Uso: Registrar Asistencia de Actividad

Menú registrar
asistencia de Asignar tipo de Registra nuevo
actividades asistencia asistecia
Lista de socios mostrado Tipo asistencia asignada Registrar datos

Verificar datos
Negar
registración
Datos incorrectos Datos verificados

Datos aceptado
Menú salir
Datos registrados correctamente
Datos almacenados en
Datos registrado
DB

Figura 4.7. Diagrama de estado de caso de uso: Registrar asistencia de actividad

 Diagrama de Estado de Caso de Uso: Modificar Asistencia de Actividad

Buscar datos Verificar datos


Menú opción
Modificar solicitados

Datos solicitados por


Buscar datos Datos encontrados
secretario de actas

Modificar datos
Verificar datos

Solicitar datos Datos no encontrados Datos modificado

Menú salir Actualizar DB


Los datos se guardaron correctamente
Datos almacenados en DB DB actualizada

Figura 4.8. Diagrama de estado de caso de uso: Modificar asistencia de actividad

55
 Diagrama de Estado de Caso de uso : Reporte de Socios Dados de Baja

Seleccionar Verificar datos


Menú opción
reporte
reportes

Seleccionar reporte Reporte seleccionado Datos mostrados

Presionar Botón
Verificar datos Imprimir

Seleccionar reporte
No existe ningún dato Reporte mostrado

Salir

Figura 4.9. Diagrama de estado de caso de uso: Reporte de socios dados de baja

 Diagrama de Estado de Caso de uso : Reporte de Directorio Gestión

Menú opción
reportes Seleccionar
reporte
Seleccionar reporte Formulario mostrado

Seleccionar reporte Ingresar los datos

Verificar datos
No existe ningún dato Datos ingresados

Presionar Botón
Salir Imprimir

Reporte mostrado

Figura 4.10. Diagrama de estado de caso de uso: Reporte de directorio gestión

56
4.2.1.2 Diagrama de Estado Secretario de Haciendas

 Diagrama de Estado de Caso de Uso: Registrar lecturación

Menú registrar Ingresar Registra nuevos


consumo lecturación datos
Lista de medidores mostrado Lecturación ingresado Registrar datos

Verificar datos
Negar
registración
Datos incorrectos Datos verificados

Datos aceptado
Menú salir
Datos registrados correctamente
Datos almacenados en DB Datos registrado

Figura 4.11. Diagrama de estado de caso de uso: Registrar lecturación de medidor

 Diagrama de Estado de Caso de Uso Modificar lecturación

Menú opción Buscar datos Verificar datos


Modificar consumo solicitados
Datos solicitados por
Buscar datos de medidor Datos encontrados
secretario de actas

Modificar datos
Verificar datos
Lecturación
Solicitar datos modificado
Datos no encontrados

Actualizar DB
Menú salir
Los datos se guardaron correctamente
Datos almacenados en DB DB actualizada

Figura 4.12. Diagrama de estado de caso de uso: Modificar lecturación de medidor

57
 Caso de Estado de Caso de Uso: Registrar Emite Recibo

Menú imprimir
recibo
Registrar recibo
Recibo mostrado con datos Recibo registrado

Verificar datos
Negar
registración
Datos incorrectos Datos verificados

Datos aceptado
Menú salir
Datos registrados correctamente
Datos almacenados en DB Datos registrado

Figura 4.13. Diagrama de estado de caso de uso: Registrar emite recibo

 Caso de Estado de Caso de Uso: Registrar Cobrar Consumo Agua

Menú cobrar Buscar datos Verificar datos


consumo solicitados
Datos solicitados por
Buscar datos Datos encontrados
secretario de haciendas

Verificar datos Cobrar consumo

Solicitar datos Datos no encontrados Consumo cobrado

Menú salir Actualizar DB


Los datos se guardaron correctamente
Datos almacenados en DB DB actualizada

Figura 4.14. Diagrama de estado de caso de uso: Registrar cobro consumo agua

58
 Caso de Estado de Caso de Uso : Registrar Cobro de Afiliación

Menú cobrar Buscar datos


Verificar datos
Afiliación solicitados
Datos solicitados por
Buscar datos Datos encontrados
secretario de haciendas

Verificar datos Cobrar afiliación

Solicitar datos Datos no encontrados Afiliación cobrado

Menú salir Actualizar DB


Los datos se guardaron correctamente
Datos almacenados en DB DB actualizada

Figura 4.15. Diagrama de estado de caso de uso: Registrar cobro de afiliación

 Caso de Estado de Caso de Uso :Registrar Egreso

Menú registrar Registra nuevos


Egreso Llenar datos
datos
Datos llenados por Secretario de
Formulario mostrado Registrar datos
haciendas

Verificar datos
Negar
registración
Datos incorrectos Datos verificados

Datos aceptado
Menú salir
Datos registrados correctamente
Datos almacenados en DB Datos registrado

Figura 4.16. Diagrama de estado de caso de uso: Registrar egreso

59
4.2.1.3 Diagrama de Estado Presidente

 Caso de Estado de Caso de Uso : Reporte de Ingreso y egresos

Menú arqueo Parámetros de fecha Verificar datos


de caja
Petición de parámetros de
Petición de reporte Datos mostrados
fecha

Presionar Botón
Verificar datos Imprimir

Solicitar datos
No existe ningún dato Reporte mostrado

Salir

Figura 4.17. Diagrama de estado de caso de uso: Reporte de ingresos y egresos

 Caso de estado de Caso de Uso : Reporte de Pago de Consumo de Agua

Menú arqueo Parámetros de fecha Verificar datos


de caja
Petición de parámetros
Petición de reporte Datos mostrados
de fecha

Verificar datos

Solicitar datos Verificar datos


No existe ningún dato

Salir
Presionar botón imprimir
Reporte mostrado Detalle consumo

Figura 4.18. Diagrama de estado de caso de uso: Reporte de pago de consumo de agua

60
 Caso de Estado de Caso de Uso : Reporte de Socios con Deuda Tipo Deuda

Seleccionar Verificar datos


Menú opción
reporte
reportes

Seleccionar reporte Petición de reporte Datos mostrados

Presionar Botón
Verificar datos Imprimir

Seleccionar reporte
No existe ningún dato Reporte mostrado

Menú salir

Figura 4.19. Diagrama de estado de caso de uso: Reporte de socios con deuda tipo deuda

4.2.2 Diagrama de Secuencia de los Casos de Uso

El diagrama de secuencia consta de objetos que representa de modo usual: rectángulo con
nombre subrayado, mensaje representado por líneas continúas con una punta de flecha y el
tiempo como una progresión vertical.

61
4.2.2.1 Diagrama de Secuencia Secretario de Actas

 Diagrama de Secuencia de Caso de Uso: Registrar socio

:Registrar socio :Manejador de BD :Mensaje

Usuario

Solicita registro del nuevo socio

Entrega formulario

Entrega formulario llenado


Verifica los datos
Enviar datos
Almacena los
Registrado correctamente datos

Muestra

Los datos fueron registrados correctamente

Figura 4.20. Diagrama de secuencia de caso de uso: Registrar socio

 Diagrama de Secuencia de Caso de Uso : Modificar Datos de Socio

:Modificar socio :Manejador de BD :Mensaje

Usuario
Solicita modificar los datos

Entrega lista de socios

Entrega socio seleccionado

Entrega formulario con datos

Entrega formulario modificados Envía los datos


Actualiza los
datos
Datos correctos

Muestra

Datos modificados correctamente

Figura 4.21. Diagrama de secuencia de caso de uso: Modificar datos de socio

62
 Diagrama de Secuencia de Caso de Uso de: Dar Baja Socio

:Dar baja socio :Manejador de BD :Mensaje

Usuario
Solicita dar de baja

Entrega lista de socios

Entrega socio seleccionado

Entrega formulario con datos

Acepta dar de baja Envía los datos


Actualiza los
datos
Datos correctos

Muestra

Los datos fueron dados de baja correctamente

Figura 4.22. Diagrama de secuencia de caso de uso: Dar baja socio

 Diagrama de Secuencia de Caso de Uso :Registrar Crear Tipo Cargo

:Registrar
:Registrar cargo
cargo :Manejador
:Manejador de
de BD
BD :Mensaje
:Mensaje

Usuario
Solicita crear tipo cargo

Entrega formulario

Entrega formulario llenado


Verifica los datos
Enviar datos
Almacena los
Registrado correctamente datos

Muestra

Cargo creado correctamente

Figura 4.23. Diagrama de secuencia de caso de uso: Registrar crear tipo cargo
63
 Diagrama de Secuencia de Caso de Uso : Modificar Tipo Cargo

:Modificar cargo :Manejador de BD :Mensaje

Usuario
Solicita modificar cargo

Entrega lista de cargos

Entrega cargo seleccionado

Entrega formulario con datos

Entrega formulario modificados Envía los datos


Actualiza los
datos
Datos correctos

Muestra

Datos modificados correctamente

Figura 4.24. Diagrama de secuencia de caso de uso: Modificar tipo cargo

 Diagrama de Secuencia de Caso de Uso: Dar de Baja Tipo Cargo

:Dar
:Dar baja
baja cargo
cargo :Manejador
:Manejador de
de BD
BD :Mensaje
:Mensaje

Usuario
Usuario
Solicita dar de baja

Entrega lista de cargos

Entrega cargo seleccionado

Entrega formulario con datos

Acepta dar de baja Envía los datos


Actualiza los
datos
Datos correctos

Muestra

Los datos fueron dados de baja correctamente

Figura 4.25. Diagrama de secuencia de caso de uso: Dar baja tipo cargo
64
 Diagrama de Secuencia de Caso de Uso: Registrar Asistencia de Actividad

:Registrar
:Manejador de BD :Mensaje
asistencia
Usuario
Solicita registrar asistencia
de actividad
Entrega lista de socios

Entrega lista tiqueado


Verifica los datos
Enviar datos
Almacena los
Registrado correctamente datos

Muestra

Se registro correctamente

Figura 4.26. Diagrama de secuencia de caso de uso: Registrar asistencia de actividad

 Diagrama de Secuencia de Caso de Uso: Modificar Asistencia de Actividad

:Modificar
:Modificar asistencia
asistencia :Manejador
:Manejador de
de BD
BD :Mensaje
:Mensaje

Usuario
Usuario
Solicita modificar asistencia
de actividad
Entrega lista de socios

Entrega socio seleccionado

Entrega formulario con datos

Entrega asistencia modificado Envía los datos


Actualiza los
datos
Datos correctos

Muestra

Datos modificados correctamente

Figura 4.27. Diagrama de secuencia de caso de uso: Modificar asistencia de actividad


65
 Diagrama de Estado de Caso de Uso: Reporte de Socios Dados de Baja

:Reporte de socios :Manejador de BD :Botón Imprimir

Usuario Solicita reporte de socios


Dados de baja
Entrega lista de menus

Entrega menu dados de baja


Verifica los datos
Enviar datos
Actualizar
Muestra reporte DB

Presionar

Configurar pagina de impresión

Figura 4.28. Diagrama de secuencia de caso de uso: Reporte de socios dados de baja

 Diagrama de Estado de Caso de Uso : Reporte de Directorio Gestión

:Reporte
:Reporte directorio
directorio :Manejador
:Manejador de
de BD
BD :Botón
:Botón Imprimir
Imprimir
Usuario
Usuario
Solicita reporte de directorio

Entrega lista de menús

Entrega menú seleccionado


Verifica los datos
Enviar datos
Actualizar
Muestra reporte DB

Presionar

Configurar pagina de impresión

Figura 4.29. Diagrama de secuencia de caso de uso: Reporte de directorio según gestión

66
4.2.2.2 Diagrama de Secuencia Secretario de Haciendas

 Diagrama de Secuencia de Caso de Uso: Registrar lecturación de medidor

:Registrar consumo :Manejador de BD :Mensaje

Usuario

Solicita registrar consumo

Entrega lista de socios

Entrega formulario llenado


Verifica los datos
Enviar datos
Almacena los
Registrado correctamente datos

Muestra

Se registro correctamente

Figura 4.30. Diagrama de secuencia de caso de uso: Registrar lecturación de medidor

 Diagrama de Estado de Caso de Uso: Modificar Lecturación de medidor

:Modificar
:Modificar consumo
consumo :Manejador
:Manejador de
de BD
BD :Mensaje
:Mensaje

Usuario
Usuario

Solicita Modificar consumo

Entrega formulario de busqueda

Entrega formulario con datos


Verifica los datos
Enviar datos

Modificado correctamente Actualiza DB

Muestra

Los datos fueron modificados correctamente

Figura 4.31. Diagrama de secuencia de caso de uso: Modificar lecturación de medidor

67
 Diagrama de Estado de Caso de Uso : Registrar Emite Recibo

:Registrar Recibo :Manejador de BD :Mensaje

Usuario

Solicita imprimir recibo

Entrega recibo con datos

Entrega formulario llenado


Verifica los datos
Enviar datos
Almacena los
Registrado correctamente datos

Muestra

Se registro correctamente

Figura 4.32. Diagrama de secuencia de caso de uso: Registrar emite recibo

 Diagrama de Estado de Caso de Uso: Registrar Cobro Consumo Agua

:Cobrar
:Cobrar consumo
consumo :Manejador
:Manejador de
de BD
BD :Mensaje
:Mensaje

Usuario
Usuario
Solicita cobrar de consumo

Entrega lista de cobros

Entrega cobro seleccionado


Verifica los datos
Enviar datos
Almacena los
Registrado correctamente datos

Muestra

Cobro realizado correctamente

Figura 4.33. Diagrama de secuencia de caso de uso: Registrar cobro de consumo de agua

68
 Diagrama de Estado de Caso de Uso: Registrar Cobro de Afiliación

:Cobrar
:Cobrar afiliación
afiliación :Manejador
:Manejador de
de BD
BD :Mensaje
:Mensaje

Usuario
Usuario
Solicita cobrar afiliación

Entrega lista de cobros

Entrega cobro seleccionado


Verifica los datos
Enviar datos
Almacena los
Registrado correctamente datos

Muestra

Cobro realizado correctamente

Figura 4.34. Diagrama de secuencia de caso de uso: Registrar cobro de afiliación

 Diagrama de Estado de Caso de Uso: Registrar Egreso

:Registrar egreso :Manejador de BD :Mensaje

Usuario

Solicita registro de egreso

Muestra formulario

Entrega formulario llenado


Verifica los datos
Enviar datos
Almacena los
Registrado correctamente datos

Muestra

Se registro correctamente

Figura 4.35. Diagrama de secuencia de caso de uso: Registrar egreso

69
4.2.2.3 Diagrama de Secuencia Presidente

 Diagrama de Secuencia de Caso de Uso : Reporte de Ingresos y Egresos

:Reporte
:Reporte ingreso
ingreso :Manejador
:Manejador de
de BD
BD :Botón
:Botón Imprimir
Imprimir
yy egreso
egreso

Usuario
Usuario Solicita reporte de ingreso y
egresos
Entrega lista de menus

Entrega reporte seleccionado


Verifica los datos
Enviar datos
Actualizar
Muestra reporte DB

Presionar

Configurar pagina de impresión

Figura 4.36. Diagrama de secuencia de caso de uso: Reporte de ingresos y egresos

 Diagrama de Secuencia de Caso de Uso: Reporte de Pago de Consumo Agua

:Reporte
:Reporte pago
pago :Manejador
:Manejador de
de BD
BD :Botón
:Botón Imprimir
Imprimir
consumo
consumo agua
agua

Usuario
Usuario Solicita reporte de pago
consumo
Entrega lista de menus

Entrega reporte seleccionado


Verifica los datos
Enviar datos
Actualizar
Muestra reporte DB

Presionar

Configurar pagina de impresión

Figura 4.37. Diagrama de secuencia de caso de uso: Reporte de pago de consumo de agua

70
 Diagrama de Estado de Caso de Uso: Reporte de Socios Tipo Deuda

:Reporte
:Reporte socios
socios :Manejador
:Manejador de
de BD
BD :Botón
:Botón Imprimir
Imprimir
con
con deudas
deudas

Usuario
Usuario
Solicita reporte de deuda

Entrega lista de menus

Entrega reporte seleccionado


Verifica los datos
Enviar datos
Actualizar
Muestra reporte DB

Presionar

Configurar pagina de impresión

Figura 4.38. Diagrama de secuencia de caso de uso: Reporte de socios tipo deuda

71
4.3 Diagrama de Clases
cobroReuni on
detal l e CODIGO_DET ALLE <fi 1> Integer
Rel ati onshi p_24
LOG_US <fi 3> Characters (50)
CODIGO_SOCIO <fi 2> Integer <M >
CODIGO_COBRO <pi > Seri al (10) <M >
NRO_ACUSE <fi 1> Integer <M >
FECHA_COBRO T i m estam p
LIST A Characters (2)
T OT AL_COBRO Characters (5)
CODIGO_DET ALLE <pi > Seri al (10) <M >
EST ADO Characters (10) CODIGO_COBRO <pi >
REGIST RAR <ai >
CODIGO_DET ALLE <pi >
Rel ati onshi p_3
REGIST RAR <ai 1> soci o
M ODIFICAR <ai 2>
CODIGO_SOCIO <pi > Seri al (3) <M >
APELLIDO_PAT ERNO Characters (30)
Rel ati onshi p_2
APELLIDO_M AT ERNO Characters (30)
NOM BRE_SOCIO Characters (30)
reuni on CI Characters (10)
NRO_ACUSE <pi > Seri al (10) <M > DIRECCION Characters (200)
FECHA Date SEXO Characters (7)
Rel ati onshi p_25 T ELEFONO Characters (10)
HORA_INICIO Time
HORA_FIN Time EST ADO Characters (10)
T IPO Characters (25) CELULAR Characters (10)
CONCEPT O Characters (150) FECHA_NACI Date
FECHA_RE T i m estam p FECHA_RE T i m estam p
FECHA_BAJA Characters (11)
NRO_ACUSE <pi >
REGIST RAR <ai 1> CODIGO_SOCIO <pi >
M ODIFICAR <ai 2> REGIST RAR <ai 1>
M ODIFICAR <ai 2>
preci o
DAR_BAJA <ai 3>
COD_PRECIO Seri al (10) <M > DAR_ALT A <ai 4>
PRECIO Characters (10)
EST ADO Characters (10) Rel ati onshi p_23
CONCEPT O Characters (40)
T IPO Characters (15)
m edi dor
COD_PRECIO <ai 1>
CODIGO_M EDIDOR <pi > Seri al (4) <M >
REGIST RAR <ai 2>
CODIGO_SOCIO <fi > Integer
DAR_BAJA <ai 3>
SERIE Characters (50)
Afi l i aci on Rel ati onshi p_27 M ARCA Characters (30)
DET ALLE Characters (200)
CODIGO_AFILIACION <pi > Seri al (10) <M >
CODIGO_M EDIDOR <fi > Integer CODIGO_M EDIDOR <pi >
Rel ati onshi p_21
PRECIO_AFILIACION Characters (5) REGIST RAR <ai 1>
M ODIFICAR <ai 2>
CODIGO_AFILIACION <pi >
DAR_BAJA <ai 3>
REGIST RAR <ai 1> Rel ati onshi p_26
DAR_ALT A <ai 4>
M ODIFICAR <ai 2>
Rel ati onshi p_20
Rel ati onshi p_28 cobroAfi l i caci on
CODIGO_COBRO <pi > Seri al (10) <M >
recargue LOG_US <fi 2> Characters (50) <M >
COD_RECARGUE <pi > Seri al (5) <M > CODIGO_AFILIACION <fi 1> Integer
DIAS Integer T OT AL_COBRO Characters (5)
FECHA_COBRO T i m estam p
COD_RECARGUE <pi >
REGIST RAR <ai 1> CODIGO_COBRO <pi >
M ODIFICAR <ai 2> REGIST RAR <ai >

consum o cobros

CODIGO_CONSUM O <pi > Seri al (10) <M > CODIGO_CONSUM O <fi 1> Integer
CODIGO_M EDIDOR <fi 1> Integer CODIGO_COBRO <pi > Seri al (10) <M >
LOG_US <fi 2> Characters (50) <M > FECHA_COBRO T i m estam p
LECT URA Characters (10) M ANT ENIM IENT O Characters (10)
LECT URA_ANT ERIOR Characters (10) Rel ati onshi p_15 RECARGUE Characters (10)
T OT AL Characters (10) T OT AL_CONSUM O Characters (10)
M ES Characters (20) GRAN_T OT AL Characters (10)
EST ADO Characters (7) CODIGO_COBRO <pi >
FECHA Date Rel ati onshi p_29 REGIST RAR <ai >
CODIGO_CONSUM O <pi >
trabaj adores
REGIST RAR <ai 1>
M ODIFICAR <ai 2> COD_T RABAJADOR <pi > Seri al (10) <M >
LOG_US <fi > Characters (50)
NOM BRE Characters (30)
Rel ati onshi p_16
APELLIDO_PAT ERNO Characters (30)
APELLIDO_M AT ERNO Characters (30)
usuari o FECHA_CONT RAT O Date
APELLIDO_PAT ERNO Characters (30) CARGO Characters (20)
APELLIDO_M AT ERNO Characters (30) NUM _CARNET Characters (10)
NOM BRE Characters (30) SUELDO Characters (10)
LOG_US <pi > Characters (50) <M > EST ADO Characters (7)
ID_T IPOUS <fi > Integer <M > FECHA_RE T i m estam p
PASSWORD_US Characters (40) SEXO Characters (8)
EDAD_US Characters (15) FECHA_BAJA Characters (11)
FOT O Characters (100) COD_T RABAJADOR <pi >
Rel ati onshi p_22
FECHA_CONT RAT A_US T i m estam p REGIST RAR <ai 1>
EST ADO Characters (7) M ODIFICAR <ai 2>
FECHA_BAJA Characters (11) DAR_BAJA <ai 3>
LOG_US <pi > DAR_ALT A <ai 4>
REGIST RAR <ai 1>
ti po_usuari o
M ODIFICAR <ai 2>
DAR_BAJA <ai 3> ID_T IPOUS <pi > Seri al (10) <M >
Rel
Rel ati ati onshi
onshi p_18 p_19
DAR_ALT A <ai 4> NOM BRE_T IPOUS Characters (30)
DET ALLE_T IPOUS Characters (200)
m ovi m i ento ID_T IPOUS <pi >
COD_M OVIM IENT O <pi > Seri al (10) <M >
FECHA Date detal l eM ovi m i ento
DET ALLE Characters (200) COD_M OVIM IENT O <fi 2> Integer <M >
M ONT O Characters (10) LOG_US <fi 1> Characters (50) <M >
Rel ati onshi p_1
T IPO Characters (20) CODIGO <pi > Seri al (11) <M >
CONCEPT O Characters (15)
CODIGO <pi >
COD_M OVIM IENT O <pi > REGIST RAR <ai >
REGIST RAR <ai >
di rectori o
ti po_cargo COD_DIRECT ORIO <pi > Seri al (10) <M >
COD_CARGO <pi > Seri al (5) <M > COD_CARGO <fi 2> Integer <M >
NOM BRE_CARGO Characters (30) CODIGO_SOCIO <fi 3> Integer <M >
EST ADO Characters (6) LOG_US <fi 1> Characters (50) <M >
DET ALLE Characters (200) EST ADO Characters (6)
Rel ati onshi p_17
Rel ati onshi p_9 FECHA_POSICIÓN T i m estam p
COD_CARGO <pi > Rel ati onshi p_14
GEST ION Characters (20)
REGIST RAR <ai 1>
M ODIFICAR <ai 2> COD_DIRECT ORIO <pi >
DAR_BAJA <ai 3> REGIST RAR <ai 1>
DAR_ALT A <ai 4> M ODIFICAR <ai 2>
DAR_BAJA <ai 3>
DAR_ALT A <ai 4>

72
4.4 DIAGRAMA DE BASES DE DATOS

Un diagrama de Base de Datos muestra tablas con cada uno de sus atributos, las relaciones
que existen entre estas y sus dependencias.

4.4.1 Modelo Conceptual Entidad-Relación

Modelo entidad-relación está enfocado al medio de las tablas que contendrán y manejaran
los datos en una base de datos; así como sus relaciones, las cuales realizaran a cabo por
medio de atributos y clave. Una entidad puede ser un lugar, cosa o persona, que tienen
características de interés sobre la que se desea guardar información.

73
Modelo Conceptual Entidad-Relación

cobroReuni on
CODIGO_DET ALLE <fi 1> Integer
detal l e Rel ati onshi p_24
COD_PRECIO <fi 2> Integer
CODIGO_SOCIO <fi 2> Integer <M> LOG_US <fi 3> Characters (50)
NRO_ACUSE <fi 1> Integer <M> CODIGO_COBRO <pi > Seri al (10) <M>
LIST A Characters (2) FECHA_COBRO T i mestamp
CODIGO_DET ALLE <pi > Seri al (10) <M> T OT AL_COBRO Characters (5)
EST ADO Characters (10) CODIGO_COBRO <pi >
Rel ati onshi p_3
CODIGO_DET ALLE <pi > soci o
CODIGO_SOCIO <pi > Seri al (3) <M>
Rel ati onshi p_2 APELLIDO_PAT ERNO Characters (30)
APELLIDO_MAT ERNO Characters (30)
reuni on NOMBRE_SOCIO Characters (30)
CI Characters (10)
NRO_ACUSE <pi > Seri al (10) <M>
Rel ati onshi p_25 DIRECCION Characters (200)
FECHA Date
SEXO Characters (7)
HORA_INICIO T i me
T ELEFONO Characters (10)
HORA_FIN T i me
EST ADO Characters (10)
T IPO Characters (25)
CELULAR Characters (10)
CONCEPT O Characters (150)
FECHA_NACI Date
FECHA_RE T i mestamp
FECHA_RE T i mestamp
NRO_ACUSE <pi > FECHA_BAJA Characters (11)
preci o CODIGO_SOCIO <pi >
COD_PRECIO <pi > Seri al (10) <M>
PRECIO Characters (10) Rel ati onshi p_23
EST ADO Characters (10)
CONCEPT O Characters (40) medi dor
T IPO Characters (15)
CODIGO_MEDIDOR <pi > Seri al (4) <M>
COD_PRECIO <pi > CODIGO_SOCIO <fi > Integer
Rel ati onshi p_27
Afi l i aci on SERIE Characters (50)
MARCA Characters (30)
CODIGO_AFILIACION <pi > Seri al (10) <M>
Rel ati onshi p_21 DET ALLE Characters (200)
CODIGO_MEDIDOR <fi > Integer Rel ati onshi p_26
PRECIO_AFILIACION Characters (5) CODIGO_MEDIDOR <pi >
Rel ati onshi p_28
CODIGO_AFILIACION <pi > cobroAfi l i caci on
recargue Rel ati onshi p_20 CODIGO_COBRO <pi > Seri al (10) <M>
COD_RECARGUE <pi > Seri al (5) <M> LOG_US <fi 2> Characters (50) <M>
DIAS Integer CODIGO_AFILIACION <fi 1> Integer
T OT AL_COBRO Characters (5)
COD_RECARGUE <pi >
FECHA_COBRO T i mestamp
consumo CODIGO_COBRO <pi >
CODIGO_CONSUMO <pi > Seri al (10) <M> cobros
CODIGO_MEDIDOR <fi 1> Integer
CODIGO_CONSUMO <fi 1> Integer
LOG_US <fi 2> Characters (50) <M>
CODIGO_COBRO <pi > Seri al (10) <M>
LECT URA Characters (10)
COD_PRECIO <fi 2> Integer
LECT URA_ANT ERIOR Characters (10)
FECHA_COBRO T i mestamp
T OT AL Characters (10)
Rel ati onshi p_15 MANT ENIMIENT O Characters (10)
MES Characters (20)
Rel ati onshi p_29
Rel ati RECARGUE
onshi p_17 Characters (10)
EST ADO Characters (7)
T OT AL_CONSUMO Characters (10)
FECHA Date
GRAN_T OT AL Characters (10)
CODIGO_CONSUMO <pi >
CODIGO_COBRO <pi >

Rel ati onshi p_16 trabaj adores


COD_T RABAJADOR <pi > Seri al (10) <M>
usuari o LOG_US <fi > Characters (50)
NOMBRE Characters (30)
APELLIDO_PAT ERNO Characters (30)
APELLIDO_PAT ERNO Characters (30)
APELLIDO_MAT ERNO Characters (30)
APELLIDO_MAT ERNO Characters (30)
NOMBRE Characters (30)
FECHA_CONT RAT O Date
LOG_US <pi > Characters (50) <M>
CARGO Characters (20)
ID_T IPOUS <fi > Integer <M> Rel ati onshi p_22 NUM_CARNET Characters (10)
PASSWORD_US Characters (40)
SUELDO Characters (10)
EDAD_US Characters (15)
EST ADO Characters (7)
FOT O Characters (100)
FECHA_RE T i mestamp
FECHA_CONT RAT A_US T i mestamp
SEXO Characters (8)
EST ADO Characters (7)
Rel ati onshi p_19 FECHA_BAJA Characters (11)
FECHA_BAJA Characters (11)
COD_T RABAJADOR <pi >
LOG_US <pi >
ti po_usuari o
movi mi ento
ID_T IPOUS <pi > Seri al (10) <M>
COD_MOVIMIENT O <pi > Seri al (10) <M> Rel ati onshi p_18
NOMBRE_T IPOUS Characters (30)
FECHA Date
DET ALLE_T IPOUS Characters (200)
DET ALLE Characters (200)
MONT O Characters (10) ID_T IPOUS <pi >
T IPO Characters (20) detal l eMovi mi ento
CONCEPT O Characters (15)
Rel ati onshi p_1 COD_MOVIMIENT O <fi 2> Integer <M>
COD_MOVIMIENT O <pi > LOG_US <fi 1> Characters (50) <M>
ti po_cargo CODIGO <pi > Seri al (11) <M>
COD_CARGO <pi > Seri al (5) <M> CODIGO <pi >
NOMBRE_CARGO Characters (30) di rectori o
EST ADO Characters (6)
COD_DIRECT ORIO <pi > Seri al (10) <M>
DET ALLE Characters (200)
Rel ati onshi p_14 COD_CARGO <fi 2> Integer <M>
COD_CARGO <pi > CODIGO_SOCIO <fi 3> Integer <M>
Rel ati onshi p_9 LOG_US <fi 1> Characters (50) <M>
EST ADO Characters (6)
FECHA_POSICIÓN T i mestamp
GEST ION Characters (20)
COD_DIRECT ORIO <pi >

74
4.4.2 Modelo Físico

cobroReuni on
CODIGO_DET ALLE
detal l e COD_PRECIO
CODIGO_SOCIO Rel ati onshi p_24 LOG_US
NRO_ACUSE CODIGO_COBRO
LIST A FECHA_COBRO
CODIGO_DET ALLE T OT AL_COBRO
EST ADO

soci o
Rel ati onshi p_2 CODIGO_SOCIO
APELLIDO_PAT ERNO
APELLIDO_M AT ERNO
reuni on NOM BRE_SOCIO
Rel ati onshi p_25 CI
NRO_ACUSE
Rel ati onshi p_3 DIRECCION
FECHA
SEXO
HORA_INICIO
T ELEFONO
HORA_FIN
EST ADO
T IPO
CELULAR
CONCEPT O
FECHA_NACI
FECHA_RE
FECHA_RE
FECHA_BAJA
preci o
COD_PRECIO Rel ati onshi p_23
PRECIO
EST ADO
CONCEPT O m edi dor
T IPO
CODIGO_M EDIDOR
CODIGO_SOCIO
Afionshi
Rel ati p_27
l i aci on SERIE
M ARCA
CODIGO_AFILIACION Rel ati onshi p_26
RelALLE
DET ati onshi p_28
CODIGO_M EDIDOR
PRECIO_AFILIACION
cobroAfi l i caci on
recargue CODIGO_COBRO
Rel ati onshi p_20
COD_RECARGUE LOG_US
DIAS Rel ati onshi p_21 CODIGO_AFILIACION
T OT AL_COBRO
FECHA_COBRO
consum o
CODIGO_CONSUM O cobros
CODIGO_M EDIDOR
CODIGO_CONSUM O
LOG_US CODIGO_COBRO
LECT URA
COD_PRECIO
LECT URA_ANT ERIOR Rel ati onshi p_15 FECHA_COBRO
T OT AL
M ANT ENIM IENT O
M ES Rel ati onshi p_29
Rel ati onshi p_17 RECARGUE
EST ADO
T OT AL_CONSUM O
FECHA
GRAN_T OT AL

Rel ati onshi p_16 trabaj adores


COD_T RABAJADOR
usuari o LOG_US
NOM BRE
APELLIDO_PAT ERNO
APELLIDO_PAT ERNO
APELLIDO_M AT ERNO
APELLIDO_M AT ERNO
NOM BRE
FECHA_CONT RAT O
LOG_US Rel ati onshi p_22
CARGO
ID_T IPOUS
NUM _CARNET
PASSWORD_US
SUELDO
EDAD_US EST ADO
FOT O
FECHA_RE
FECHA_CONT RAT A_US
SEXO
EST ADO Rel ati onshi p_19
FECHA_BAJA
FECHA_BAJA

ti po_usuari o
m ovi m i ento
Rel ati onshi p_18 ID_T IPOUS
COD_M OVIM IENT O
NOM BRE_T IPOUS
FECHA
DET ALLE_T IPOUS
DET ALLE
Rel ati onshi p_1
M ONT O Rel ati onshi p_9
T IPO detal l eM ovi m i ento
CONCEPT O
COD_M OVIM IENT O
LOG_US
ti po_cargo CODIGO

COD_CARGO
NOM BRE_CARGO di rectori o
EST ADO
COD_DIRECT ORIO
DET ALLE
Rel ati onshi p_14 COD_CARGO
CODIGO_SOCIO
LOG_US
EST ADO
FECHA_POSICIÓN
GEST ION

75
4.5 Diseño de Interfaz

 Ingresar al sistema

La pantalla principal del sistema le permite ingresar al sistema al usuario asignado, teniendo
en cuenta que debe ingresar login y password ver: (figura 4.39).

Figura 4.39. Ingreso al sistema de información

Una vez ingresado usuario y contraseña presionar el botón Aceptar.


Si los datos ingresados son incorrectos muestra el siguiente mensaje:

76
Si los datos ingresados son correctos muestra la pantalla principal de usuario.
Secretario de Actas ver (figurar 4.40).

Figura 4.40. Pantalla principal de secretario de actas

Pantalla principal de Secretario de Haciendas ver (figura 4.41).

Figura 4.41. Pantalla principal de secretario de haciendas


77
Pantalla Principal de Presidente ver (figura.4.42).

Figura 4.42. Pantalla principal de presidente

Pantalla Principal de Administrador del Sistema ver (figura.4.43).

Figura 4.43. Pantalla principal de administrador de sistemas


78
CAPITULO 5: IMPLEMENTACIÓN
5.1 INTRODUCCIÓN

La fase de implementación empieza, a partir de la culminación del diseño, que en los


anteriores capítulos se realizó la explicación del sistema, análisis del usuario y de la
información. Para definir la estructura en el diseño del sistema.
En este capítulo se plasma el diseño realizado en código para la funcionalidad del sistema
utilizando un lenguaje de programación y las herramientas necesarias dando mayor
seguridad en que el sistema debe ofrecer al usuario.

5.2 ELECCIÓN DE HERRAMIENTAS DE DESARROLLO UTILIZADAS

5.2.1 Elección del Lenguaje de Programación

Se realizó un previo análisis tomando en cuenta los diferentes aspectos, con relación a otros
lenguajes de programación y una base de datos apropiada para este lenguaje de
programación. A continuación se muestra la (tabla 5.1) una comparación entre PHP,
ASP.NET, JAVA, Python y Ruby ver tabla 5.1.

79
Concepto ASP .NET PHP Java Python Ruby
Costo de Alto Gratuito Gratuito Gratuito Gratuito
servidor
Sintaxis de VB y C# C / C++ C/ C++ C/ C++ Perl, Smalltalk,
lenguaje base Eiffel, Ada, y
Lisp
Orientado a Si No Si Si Si
objetos completamente
Sistemas Windows y Linux o Linux o Linux o Linux o
operativos Linux pero Windows Windows Windows Windows
usando el
proyecto Mono
( pero solo con
C# )[5]
Servidor IIS o Mono Apache, Apache, Tomcat Apache, Apache,
compilador y Glassfish compilador compilador
propio propio propio
Empresa Microsoft y The PHP Group Oracle Python software Grupo Ruby
Xamarin ( para ( open source) (open source) foundation (open source)
Mono) (open source)
Base de datos MsSQLServer Mysql Oracle, mysql Mysql y Mysql y
(principalmente) PostgreSQL PostgreSQL
Rapidez de 3er lugar 4to lugar Último lugar 1er lugar 2do lugar
ejecución
Generación de
página web[4,12,7,
13].
Propósito Generar Generar Generar Enfatiza la Código
dinámicamente dinámicamente dinámicamente productividad y “divertido” y fácil
páginas web páginas web páginas web la lectura fácil de modificar por
del código parte del
desarrollador.
Apoyo de Sitio web, Mucha, pero Mucha, pero Mucha, pero Menos, pero
aprendizaje foros, descentralizada. descentralizada. descentralizada. descentralizada.
documentos No hay una No hay una No hay una No hay una
proporcionados entidad que de entidad que de entidad que de entidad que de
por Microsoft. forma oficial forma oficial forma oficial forma oficial
En general centralice la centralice la centralice la centralice la
buen soporte. ayuda ayuda ayuda ayuda
Muy
centralizada
Soporte a Native: Native: android
móviles Windows
(todos por medio phone
de un browser)
Ambiente de Ms Visual Eclipse y otras Eclipse, Eclipse, Eclipse,
desarrollo Studio à costo herramientas netbeans y netbeans y netbeans y
Y herramientas open source otras otras otras
open source[14] herramientas herramientas herramientas
open source open source open source

Tabla 5.1. Tabla de comparación de lenguajes de programación

Fuente: http://deprofesoramaestro.blogspot.com/2012/11/comparativa-de-lenguajesweb.html

80
5.2.2 Elección del Manejador de Base de Datos

El manejador de base de datos para el desarrollo de este sistema se eligió MYSQL


tomando en cuenta que le lengua de programación elegido anteriormente es compatible y
apropiado y libre.

5.2.3 Elección del Sistema Operativo

Para el trabajo y funcionamiento de este sistema de información desarrollado se eligió el


Windows 7, ya que es un Sistema Operativo Estándar, vale decir que una mayoría de las
instituciones manejan esta plataforma de trabajo, por su fácil utilización.

5.2.4 Elección del Ciclo de Vida

Para el desarrollo del presente proyecto se eligió el ciclo de vida evolutivo incremental la
cual nos permite desarrollar versiones cada vez más completas controlando la complejidad y
los riegos, desarrollando una parte del producto software reservando el resto de aspectos
para el futuro obteniendo una versión funcional del producto, de esta forma el sistema se
desarrolla poco a poco en la que cada incremento que se realiza en las diferentes etapas de
desarrollo de software, empezara por el análisis y terminara con la implementación y
aceptación del sistema.

5.2.5 Herramientas de Apoyo para el Desarrollo de Software

Las herramientas de apoyo son:


 Adobe PhotoShop CS5
 Adobe Dreamweaver CC
 Macromedia Fireworks 8
 PowerDesigner 16.1

81
CAPITULO 6: PRUEBAS Y VALIDACIÓNES DEL SISTEMA

6.1 INTRODUCCIÓN

Una estrategia de pruebas del software integra las técnicas de diseño de casos de la prueba
en una serie de pasos bien planificado que dan como resultado una correcta construcción del
software, La estrategia describe los pasos que hay que llevar acabo como parte de la
prueba, cuando se deben planificar y realizar esos pasos para ello que recursos se van a
necesitar. Por lo tanto cualquier estrategia de prueba debe incorporar la planificación14
En este capítulo muestra todas las pruebas y validaciones realizadas al sistema de
Información desarrollado.

6.2 TIPOS DE PRUEBAS

6.2.1 Pruebas en los Sistemas Operativos

Se realizaron las pruebas en los Sistemas Operativos Windows 7 en sus distintas versiones
de arquitectura (32 bits y 64 bits) y Windows XP y Sistema operativo Linux Ubuntu.

6.2.2 Pruebas de Robustez

Estas pruebas se realizan para que cada módulo esté libre de errores, tomando en cuenta
los posibles errores de los usuarios, desplegando de esta manera un mensaje de Alerta
enviada por el sistema para su respectiva corrección.
Tenemos el siguiente caso de prueba: Se requiere registrar socio, en la (figura 6.1)
mostraremos el formulario de registro de socio, donde existen 13 campos en las cuales debe
llenar los datos del socio. Ver (figura 6.1).

14
Pressman, “Ingeniería de Software” Un enfoque practico, 5 a ed. McGraw-Hill, 2001
82
Figura 6.1. Formulario Registro de socio

Prueba de Funcionalidad:

Se realiza el siguiente caso de prueba: Se requiere registrar socio con los siguientes
características ver (figura 6.2).

Figura 6.2. Formulario registro socio


83
Una vez llenado el formulario se verifica en la base de datos, mediante una consulta
realizado en PHP a la base de datos, si los datos ingresados son nuevos se almacena, Ver
(figura 6.3).

Figura 6.3. Datos almacenados en la Base de Datos

Así como también puede observar en la lista de socios registrados en lo cual realiza una
consulta a la base de datos ver figura (6.4).

Figura 6.4. Datos registrados

84
6.2.3 Grado de Flexibilidad de Interfaz

Se realizó pruebas con distintos usuarios, obteniendo como resultado una gran aceptación a
las interfaces, podemos concluir que el grado de flexibilidad de las interfaces es óptimo.

85
CAPITULO 7: CONCLUSIONES Y RECOMENDACIÓNES

7.1 CONCLUSIONES RESPECTO A LOS ABJETIVOS

Sea culminado satisfactoriamente el desarrollo del Sistema de Información Administrativo


para la asociación de Agua Potable “San Haniel” de la Comunidad Campesina Pucarita
Chica cumpliendo los requerimientos planteados. Lo cual fue un aporte tecnológico para la
institución.

7.2 CONCLUSIONES RESPECTO A LA METODOLOGÍA USADA

La metodología usada RUP, para el desarrollo de este proyecto fue muy exitoso dado que
las fases que divide se adaptan al contexto de las necesidades y características del
proyecto. Esta metodología es bien definida para realizar cualquier proyecto de desarrollo de
un sistema de información.

7.3 CONCLUSIONES RESPECTO A LAS HERRAMIENTAS DE DESARROLLO

El lenguaje de programación PHP está desarrollado en políticas de código abierto, por lo


tanto PHP es un lenguaje que reúne propiedades que permiten sin mucha dificultad
desarrollar rápidamente sistemas de información, conectarse con bases de datos y además
se pueden encontrar un sinfín de código fuente que complementen un mejor desarrollo.
PHP, Mysql y Apache Utilizado, es el mejor trió, debido a su armonía complementación e
interacción entre ellos, por lo cual estas herramientas permitieron el desarrollo eficiente del
sistema de información. Para la asociación de Agua Potable “San Haniel” de la Comunidad
Campesina Pucarita Chica.

7.4 RECOMENDACIONES EN GENERAL

Se recomienda una buena planificación del tiempo en el desarrollo de los sistemas de


información así como también tomar mayor interés y seriedad en la elaboración de sus
proyectos a los futuros tesistas ya que los proyectos que se desarrollaran son en beneficio
de la propia institución y por ende a la sociedad.
86
Se recomienda a la Institución de no temer de la utilización de herramientas informáticas y
tecnológicas, ya que estos son herramientas de apoyo que facilitan de gran manera realizar
sus tareas.

7.5 EXTECIONES FUTURAS DEL SISTEMA DE INFORMACIÓN

El sistema de información Administrativo desarrollado, da lugar que en un futuro se puedan


acoplar nuevos módulos correspondientes a la Institución, dado que este sistema es flexible
y por lo cual soporta extensiones futuras.

87
BIBLIOGRAFIA

Libros Consultados

 HARWRYSZKIEWYCZ, T. “Análisis y Diseño de Base de Datos”. Tercera Edición.


Editorial Megabyte. México, 1994.
 Raga, C. “Aplicación Web”, 2002.
 MARCA B. Waldo Investigación Educativa y Tesis de Grado, La Paz, 1999.
 Aprendiendo .UML.en.24.horas/Autor:Joseph Schmuller/Editorial: Prentice.Hall.-.
 Modelado de Sistemas com UML/´por/Popkin Software and Systems.
 Libro de Acta de fundación de Asociación de Agua Potable “San Haniel (25 de febrero
de 1995).
 Libro de Actas de reglamentos internos de Asociación de Agua Potable San Haniel
(25 de enero de 2014).

Consultas web

 http://aposta.uv.es/givaro/modulo/Ciclo.htm
 http://apachejcl.blogspot.com/2008/09/apache-concepto.html
 http://indira-informatica.blogspot.com/2007/09/qu-es-mysql.html
 http://www.tiposde.org/internet/113-tipos-de-navegadores/
 http://jorgetrejos.blogspot.com/2010/08/modelo-evolutivo.html
 http://ingenexescom.blogspot.com/2012/02/modelo-incremental.html
 http://www.monografias.com/trabajos40/administracion-bases-datos/administracion-
bases-datos2.shtml#admin#ixzz32YP0c1vC
 http://www.monografias.com/trabajos7/sisinf/sisinf.shtml#ei#ixzz32YIRLWMz
 http://www.monografias.com/trabajos7/sisinf/sisinf.shtml
 http://www.monografias.com/trabajos24/arquitectura-cliente-servidor/arquitectura-
cliente-servidor.shtml
 http://www.ayudaenlaweb.com/navegadores/que-es-google-chrome/
 http://www.sociedadelainformacion.com/12/tecnologiasweb.pdf

88
ANEXOS

89
Se realizó la entrevista a 3 miembros del directorio y 184 socios afiliados a la Asociación de
Agua Potable “San Haniel”. Para resolver el cuestionario.
Objetivo: El siguiente cuestionario tiene el propósito de recoger las necesidades y problemas
por los que atraviesa la institución.

El siguiente cuestionario estaba basado en el siguiente formato:

CUESTIONARIO

1. ¿Existe registro de control de asistencia de reuniones ordinarias y extraordinarias?


Sí No

2. ¿En caso de existir registro este es?


Manual Computarizada Informático

3. ¿Qué datos se toma a los socios en el momento de afiliación?


Datos personales Nro. De familias Todos

4. ¿De qué manera se registra al personal de apoyo una vez contratado?


Manual Computarizada Informático

5. ¿De qué manera se registra al personal de la mesa directiva de la asociación?


Manual Computarizada Informático

6. ¿Existe dificultad en el control de socios activos y pasivos?


Sí No

7. ¿De qué manera se realiza el cobro de consumo de agua?


Manual Computarizada Informático

90
8. ¿Cuándo se realiza el pago de consumo de agua, cuota de afiliación, multa por falta
de asistencia a trabajos comunitarios o reuniones ordinarias y extraordinarias se
registra en?
Libro Factura Recibo Ninguno

9. ¿Cuándo se realizan egresos económico por algún concepto se registra en?


Libro Factura Recibo Ninguno

10. ¿Existe dificultad en el control de socio con deuda según tipo de deuda?
Sí No

11. ¿Al momento de cancelar algún concepto se extiende comprobante de pago?


Sí No De vez en cuando

12. ¿Existe conformidad con el informe económico que realiza el directorio?


Sí No

13. ¿Se realiza los pagos de consumo en la fecha límite de pago?


Sí No

14. ¿Está de acuerdo con la sistematización computarizada de la Asociación de Agua


Potable “San Haniel”, para el buen control y administración de sus recursos
económicos?
Sí No

91
TABULACIÓN

Preguntas Respuestas Cantidad


Si 170
Pregunta 1.
No 17
Manual 187
Pregunta 2. Computarizada 0
Informático 0
Datos personales 150
Pregunta 3. No dependientes 0
Todos 37
Manual 187
Pregunta 4. Computarizada 2
Informático 0
Manual 187
Pregunta 5. Computarizada 0
Informático 0
Si 147
Pregunta 6.
No 40
Manual 187
Pregunta 7. Computarizada 0
Informático 0
Libro 132
Factura 0
Pregunta 8.
Recibo 14
Ninguno 40
Libro 108
Factura 0
Pregunta 9.
Recibo 53
Ninguno 26
Si 173
Pregunta 10.
No 14
Si 40
Pregunta 11. No 67
De vez en cuando 80
Si 181
Pregunta 12.
No 6
Si 164
Pregunta 13.
No 23
Si 179
Pregunta 14.
No 8

Informe: Dado el resultado de la encuesta de la Asociación de Agua Potable “SAN HANIEL”


se pudo evidenciar que en la actualidad no tiene un buen control de la información y
administración de sus recursos económicos.
Consecuentemente es necesario la construcción de un Sistema de Información
Administrativo, que facilitara el control y movimiento de sus recursos económicos, La
búsqueda de los reportes será eficaz en el momento que la requiera la directiva o los socios,
y por lo tanto garantizara la seguridad de la información.

92
SISTEMA ACTUAL DE LA ASOCIACIÓN DE AGUA POTABLE “SAN HANIEL”

93
.
.
SISTEMA NUEVO DE LA ASOCIACIÓN DE AGUA POTABLE “SAN HANIEL”

94
CRONOGRAMA DE TRABAJO DE CODIFICIÓN

95
MANUAL
DE USUARIO

96

Potrebbero piacerti anche