Caso1 - INFORME FINAL PDF

INSTITUTO TECNOLGICO DE OAXACA
DEPARTAMENTO DE SISTEMAS Y COMPUTACIN
LICENCIATURA EN INFORMTICA
SISTEMA DE ENLACE DE CONVENIOS

MUNICIPALES PARA EL INSTITUTO CATASTRAL
DEL ESTADO DE OAXACA
ALUMNOS:
CONTRERAS DAMIN IVETTE ANAHI
09161426
RAMIREZ GIL JESS BERNARDINO
09161468
OAXACA DE JUAREZ, OAX. A 11 DEAGOSTO DE 2015
INDICE
INTRODUCIN ....................................................................................................... 1
CAPITULO I
MARCO CONTEXTUAL
1.1 Antecedentes de la institucin........................................................................ 4

1.2 Misin y visin ................................................................................................ 5
1.3 Organigrama de la institucin......................................................................... 6
1.4 Croquis de ubicacin ...................................................................................... 7
1.5 Planteamiento del problema ........................................................................... 8
1.6 Justificacin ................................................................................................... 9
1.7 Objetivos ...................................................................................................... 11
1.7.1 Objetivo general ................................................................................. 11
1.7.2 Objetivos especficos ......................................................................... 11
1.8 Alcances y limitaciones ................................................................................ 12
1.8.1 Alcances ............................................................................................ 12
1.8.2 Limitaciones del problema ................................................................. 13
CAPITULO II
MARCO TERICO
2.1 Concepto de sistema.................................................................................... 15

2.2 Concepto de sistema de informacin ........................................................... 16
2.3 Usuarios de los sistemas ............................................................................. 16
2.3.1 Actores de los sistemas ..................................................................... 17
2.4 Modelos de ciclo de vida .............................................................................. 18
2.4.1 Concepto de modelo de ciclo de vida ............................................... 18
2.4.2 Proceso de desarrollo unificado (UP) ............................................... 19
2.5 Lenguajes de programacin ......................................................................... 21
2.5.1 Concepto de lenguaje de programacin ........................................... 21
2.5.2 Lenguaje mquina ............................................................................ 21
2.5.3 Lenguaje de alto nivel ....................................................................... 22
2.5.4 Paradigma de programacin ............................................................. 23

2.5.4.1 Programacin orientada a objetos (OO) ............................... 23
2.5.5 Arquitectura Modelo-Vista-Controlador ............................................. 25
2.5.5.1 Definicin de las partes del Modelo-Vista-Controlador ......... 26
2.5.5.2 Ciclo de vida del Modelo-Vista-Controlador ......................... 27
2.6 Framework ................................................................................................... 28
2.7 Seleccin del lenguaje de programacin...................................................... 28
2.8 Base de datos .............................................................................................. 30
2.8.1 Definicin ........................................................................................... 30
2.8.2 Componentes..................................................................................... 30
2.8.3 Objetivos de un SGBD ....................................................................... 32
2.8.4 Modelos de datos............................................................................... 34
2.8.4.1 Modelo Entidad-Relacin ..................................................... 34
2.8.4.2 Modelo Relacional ................................................................ 36
2.8.5 Lenguaje de base de datos SQL........................................................ 38
2.8.6 Estructura de un sistema de bases de datos ..................................... 39
2.8.6.1 Normalizacin de bases de datos ........................................ 39
2.8.6.2 Grados de normalizacin...................................................... 40
2.9 Seleccin del sistema gestor de bases de datos ......................................... 42
CAPITULO III
MARCO METODOLGICO
3.1 Fase de inicio ............................................................................................... 45

3.1.1 Documento de visin ......................................................................... 46
3.1.2 Especificacin de requerimientos ...................................................... 46
3.1.2.1 Actores primarios ................................................................. 46
3.1.2.2 Requerimientos funcionales ................................................. 47
3.1.2.2.1 Requerimientos funcionales primarios ................... 47
3.1.2.2.2 Actores .................................................................. 48
3.1.2.2.3 Casos de uso......................................................... 49
3.1.2.2.4 Requisitos detallados de casos de uso ................. 50
3.1.2.3 Requerimientos no funcionales ............................................ 52
3.2 Fase de elaboracin ..................................................................................... 55

3.2.1 Especificacin de casos de uso ......................................................... 55
3.2.2 Diagramas de casos de uso............................................................... 65
3.2.3 Diseo de la base de datos................................................................ 68
3.2.3.1 Modelo entidad - relacin .................................................... 68
3.2.3.2 Modelo relacional ................................................................ 69
3.2.3.3 Diccionario de datos ............................................................ 70
3.3 Fase de construccin ................................................................................... 74
3.3.1 Diagramas de actividad...................................................................... 74
3.3.2 Codificacin del sistema .................................................................... 79
3.4 Fase de transicin ........................................................................................ 79
Conclusiones...................................................................................................... 80
Glosario .............................................................................................................. 82
Bibliografa ......................................................................................................... 86
INDICE DE FIGURAS
Figura No. 1 Estructura organizacional del Instituto Catastral del Estado de

Oaxaca ............................................................................................ 6
Figura No. 2 Croquis de ubicacin del ICEO........................................................ 7
Figura No. 3 Diagrama general del modelo de desarrollo unificado ................... 20
Figura No. 4 Arquitectura MVC .......................................................................... 25
Figura No. 5 Arquitectura MVC en Web ............................................................. 27
Figura No. 6 Ciclo de vida del MVC ................................................................... 28
Figura No. 7 Notacin grfica para diagramas segn el modelo E-R ................ 35
Figura No. 8 Ejemplo de diagrama E-R.............................................................. 36
Figura No. 9 Ejemplo de modelo relacional........................................................ 37
Figura No. 10 Nomenclatura modelo relacional ................................................. 38
Figura No. 11 Fases del Proceso Unificado (UP)............................................... 45
Figura No. 12 Caso de uso #1 Convenios municipales ...................................... 65
Figura No. 13 Caso de uso #2 Planes de trabajo ............................................... 66
Figura No. 14 Caso de uso #3 Boletas de pago ................................................ 67
Figura No. 15 Diagrama entidad relacin de la aplicacin .............................. 68
Figura No. 16 Diagrama relacional de la aplicacin ........................................... 69
Figura No. 17 Diagrama de actividad: Registro de convenios municipales ........ 74
Figura No. 18 Diagrama de actividad: Baja de convenios municipales .............. 75
Figura No. 19 Diagrama de actividad: Consultar informacin ............................ 76
Figura No. 20 Diagrama de actividad: Control de impresin de boletas ............ 77
Figura No. 21 Diagrama de actividad: Crear agendas y planes de trabajo ........ 78
INTRODUCCIN
El presente trabajo contiene todo los elementos que
intervinieron
elaboracin del Sistema de Enlace de Convenios Municipales
en la
tales como
eleccin de todos los componentes utilizados para implementacin del sistema,

entre estos se puede destacar: lenguaje de programacin, sistema gestor de base
de datos, metodologa utilizada, codificacin, entre otros.
En el Captulo I denominado Marco Contextual se abordan datos referentes a la
institucin para la cual se realiz este proyecto, as como el planteamiento del
problema, justificacin, objetivos, alcances y limitaciones.
Para sustentar la necesidad de la creacin del sistema, es necesario mencionar
los motivos de los problemas existentes. Uno de estos es el inexistente
seguimiento de relacin con los municipios, ya que indebidamente llamaremos a
estos clientes del Instituto Catastral del Estado de Oaxaca. Esto se entiende
como la falta de control de toda actividad que se lleva acabo con un municipio,
provocando que cada vez que se requiera entablar comunicacin inicie de 0.
Otro punto para decidir elaborar el proyecto, fue la lenta o ineficiente comunicacin
que existe entre departamentos, especficamente en el tema de los convenios
municipales, que por diversos motivos, la informacin requerida no se transmite
adecuadamente.
En el Captulo II Marco terico, se desarrolla la teora que va a fundamentar el
proyecto con base al planteamiento del problema que se ha realizado, se abordan
conceptos referentes a sistemas, lenguajes de programacin, bases de datos,
entre otros.
En el Captulo III denominado Marco metodolgico, se muestran todos los

aspectos referentes al diseo del sistema, procesos a seguir, actores del sistema,
diseo de la base de datos a ser utilizada, entre otros.
Se realizaron varias entrevistas con los diversos encargados de las reas
involucradas as como personal que labora en las mismas, esto con el fin de
conocer los requerimientos adecuados para la construccin del sistema.
Se
elaboraron diferentes documentos para ser presentados al cliente para que tuviese
conocimiento de las funcionalidades, alcances y limitaciones que tendra el
sistema. Posteriormente se dio a la tarea de seleccionar los elementos tales como
lenguaje de programacin y sistema gestor de base de datos, que mejor se
adecuarn al proyecto a realizar.
Por la metodologa usada se entregaron varias iteraciones antes de obtener el
producto final y cada una de ellas era de forma incremental, as presentado un
producto ms completo en cada una de ellas.
El objetivo de dicho proyecto es el crear un sistema que permita tener

comunicadas e informadas todas las reas del ICEO, para que el acceso a la
informacin sea eficiente y en el momento que se requiera. Otro es el de llevar un
control adecuado de las actividades realizadas para con los diversos municipios
del Estado. Para elaborar un historial de la relacin Municipio ICEO.
Durante la elaboracin del proyecto se presentaron ciertos obstculos, uno de

ellos fue el poco conocimiento que se tena en el lenguaje de programacin
elegido, as como la implementacin de las APIS que se utilizaron.
CAPTULO I
MARCO CONTEXTUAL
CAPITULO I
MARCO CONTEXTUAL
1.1
Antecedentes de la institucin
El catastro moderno tiene inicio con el siglo XX periodo en que el pas viva un
movimiento social con races esencialmente agrarias; esto propicio que en 1902
se decretara la derogacin de la clasificacin de terrenos de la nacin,
respetndose solo la de los baldos los cuales el ejecutivo podra deslindar a
travs de comisiones oficiales; se anularon las disposiciones que autorizaban la
separacin de baldos por empresas deslindadoras y se preservo el gran registro
de la propiedad.
Todos estos hechos modifican la estructura y organizacin de la propiedad de la
tierra en Mxico y el presidente Venustiano Carranza considero urgente
reorganizar el catastro en toda la repblica y en 1914 decreto un proyecto de Ley
Agraria fijando las bases para la conformacin del catastro; en esta ley se
establece una junta calificadora en cada municipio para registrar la propiedad raz,
fijar su avalu y el monto de los capitales.
En 1915 se dict la Ley Agraria normando la aplicacin de procedimientos en la
restitucin de tierras, establecimiento de lmites y dotacin de tierras a
comunidades agrcolas y para que estas fueran aplicadas el mismo Venustiano
Carranza instituye la Comisin Nacional Agraria la cual fijo la extensin del ejido
en 4,190 metros por lado. Al ao siguiente se crea la Secretaria de Agricultura y
Fomento con la finalidad de recuperar las propiedades de la nacin y
reglamentando el otorgamiento y posesin provisional, previa autorizacin del
poder ejecutivo.
Con la tercera Constitucin Poltica de los Estados Unidos Mexicanos de 1917, se
otorga la legitimidad necesaria para una distribucin justa de la tierra crendose el
ejido de Mxico, que con la reforma del artculo 27 constitucional se determina que
la nacin es la misma propiedad de tierras y aguas comprendidas dentro del
territorio nacional, y se reserva el derecho a transmitir de dominio a particulares y
legisla sobre la tenencia de la tierra, sobre todo los ncleos de poblacin comunal
y con la pequea propiedad.
1.2
Misin y Visin
Misin: Entidad que se encarga de obtener y mantener un padrn catastral

confiable, eficiente y de uso multifinalitario brindando atencin y servicios de
calidad a las diferentes instituciones pblicas, privadas y a la poblacin en general.
Visin: Identificacin, Descripcin, Delimitacin y Valuacin de los bienes

inmuebles ubicados en el territorio del Estado, para la integracin y actualizacin
permanente de la informacin relativa a los registros.
1.3
Organigrama de la institucin
Figura No. 1
Estructura organizacional del Instituto Catastral del Estado de Oaxaca
1.4
Croquis de ubicacin
El Instituto Catastral del Estado de Oaxaca (ICEO), se encuentra ubicado en H.

Escuela Naval Militar No. 517 Esq. Heroico Colegio Militar, Col. Reforma, Oaxaca
de Jurez Oaxaca.
Figura No. 2
Croquis de ubicacin del ICEO
1.5
Planteamiento del problema
En el Instituto Catastral del Estado de Oaxaca no existe un seguimiento o control

adecuado de la relacin institucional con los municipios, representados por el
presidente municipal y autoridades municipales. En muchas ocasiones no se tiene
conocimiento oportuno de todos los datos relevantes de los municipios, tales
como: datos de las autoridades, convenios anteriormente celebrados, entrega de
boletas prediales, estado de las zonas de valor, aprobacin de Ley de Ingresos
Municipal, entre otros.
La prioridad de la Coordinacin de Enlace Municipal es mantener la informacin
actualizada de la relacin que existe entre los Municipios del Estado de Oaxaca
con el Instituto, y que a la vez sta pueda ser entregada de manera gil y
oportuna, segn las necesidades de los departamentos que la solicitan.
El Departamento de Atencin y Apoyo a Municipios, dependiente de la
Coordinacin de Enlace Municipal, concentra la informacin referente a convenios;
actualmente se maneja de forma manual e independiente de cada rea que hace
uso de la misma, dando como resultado la siguiente problemtica a resolver: los
datos que se generan en las diferentes reas se encuentran aislados y no pueden
ser consultados cuando se requiere.
Adems el informe sobre los convenios es necesario para otros departamentos,
los cuales son: la Unidad Jurdica, el Departamento Tcnico, la Coordinacin de
Gestin Territorial especficamente los Departamentos de Valores Unitarios y de
Valuacin; pero no tienen acceso directo a esto, en su lugar, se realizan
solicitudes de forma verbal al encargado del departamento de Atencin y Apoyo a
Municipios y este a su vez los proporciona mediante el chat interno, una hoja
impresa o de algn otro medio, provocando que el proceso de emisin del
requerimiento sea lento y poco efectivo.
Se debe tomar en cuenta que los convenios celebrados con los municipios poseen
una vigencia, por lo que al cabo de cierto tiempo finalizan; haciendo necesaria una
actualizacin automtica, as como informar a los coordinadores y jefes de rea
encargados de cada departamento del vencimiento y tomar medidas en caso de

requerirse.
Por otra parte, no se cuenta con un entorno colaborativo de ejecucin de
procesos, esto se debe a que no se lleva un seguimiento adecuado de las
actividades de cada rea, ya que en ocasiones no existe comunicacin constante
entre los coordinadores, jefes de rea y personal operativo, o las autoridades
municipales; dando como resultado que se desconozca el estado de la relacin
institucional. Lo anterior da origen a otra problemtica, ya que cada persona que
tiene parte en este proceso lleva su propio control de actividades, haciendo que
los dems actores no estn enterados o no exista un rastreo, provocando un flujo
lento de trabajo. La misma situacin se presenta en las reuniones y capacitaciones
de parte del Instituto donde se discuten diferentes cuestiones en carcter de Ley
de ingresos municipales o asesoras.
Adems no se cuenta con un medio electrnico que controle la captura, emisin y
entrega oportuna de las boletas prediales de los municipios que firman convenio
con el Instituto.
1.6
Justificacin
El presente proyecto de sistema ofrece una alternativa de solucin a la necesidad

de un seguimiento de actividades por parte de la Coordinacin de Enlace
Municipal y la Coordinacin de Gestin Territorial, as como los departamentos
que dependen de ellas,
pertenecientes al Instituto Catastral del Estado de
Oaxaca; en las cuales se concentra la informacin de diferentes mbitos respecto

a la relacin de trabajo entre el ICEO1 y los municipios del Estado.
En la actualidad los datos correspondientes a los convenios que maneja el ICEO
se encuentran almacenados en hojas de Excel, las cuales se actualizan
peridicamente; este sistema actual de trabajo no permite un flujo eficaz de
informacin, tampoco cuenta con un mtodo de filtrado y bsqueda adecuada para
1
Instituto Catastral del Estado de Oaxaca
el procesamiento de los datos. Adems, este mecanismo no permite obtener de

manera simple un anlisis de algn municipio determinado.
El sistema de Enlace de Convenios Municipales permitir a las reas operativas
del ICEO, mediante diferentes funciones, mejoren su desempeo y el intercambio
de informacin sobre las relaciones que el Instituto sostiene con los municipios.
El desarrollo del proyecto se realizar en un entorno Web, mediante el uso del
Framework Grails que est desarrollado en el lenguaje Groovy, el cual a su vez se
basa en la plataforma tecnolgica Java.
La captura de la informacin se realizar por medio de una interfaz grfica de
usuario amigable conectada a una Base de Datos; esto permitir que la captura
sea fcil y clara, ya que se dar una presentacin agradable a la vista, adems se
atendern los estndares de W3C2.
Dado que este sistema ser plataforma Web, los encargados de cada rea y el
personal que requiera el informe municipal, podr acceder al sistema para realizar
consultas, siempre y cuando este registrado.
Se emitirn alertas cuando un convenio haya concluido, estas alertas se podrn
visualizar en el sistema.
Para poder realizar la implementacin del mapa, se har uso del API 3 de Google
Maps, lo cual permitir a los encargados acceder a la informacin de los
municipios del Estado de Oaxaca a travs de una interfaz geogrfica.
La gestin de citas, reuniones, capacitaciones, procesos de elaboracin de tablas
de valor para los diferentes tipos de suelo y aprobaciones de leyes municipales se
har a travs de calendarios, esto se lograr con librerias que posee el lenguaje
de programacion seleccionado. Con lo anterior se lograr que las citas y dems
actividades sean eficientes, as tambin se realicen en tiempo y forma.
El sistema tambin permitir crear y gestionar proyectos municipales, los cuales
servirn para dar la atencin colaborativa a los municipios y, a la vez, en los
2
3
World Wide Web Consortium

Application Programming Interface (Interfaz de programacin de aplicaciones)
10
proyectos se podrn crear tareas y asignar responsables, quienes sern los

encargados de llevarlas a cabo.
1.7
Objetivos
1.7.1 Objetivo general

Desarrollar un sistema Web capaz de gestionar la relacin entre el Instituto
Catastral y los Municipios del Estado de Oaxaca, administrando los convenios de
colaboracin, adems de informacin con respecto a proyectos de elaboracin de
tablas de valores, publicacin de Ley de Ingresos Municipal, registro de fechas de
capacitacin y entrega de boletas prediales.
1.7.2 Objetivos especficos
El sistema a desarrollar estar constituido en su esencia por una plataforma

Web y una base de datos
Proveer acceso a la informacin de los convenios mediante consultas de

acuerdo a:
o Tipo de convenio
o Delegacin catastral
o Estado del convenio
o Si existe o no cobro de traslado de dominio
Generar reportes de acuerdo a:

o Tipo de convenio
o Delegacin catastral
o Estado del convenio
o Si existe o no cobro de traslado de dominio
Localizar en un mapa los municipios del Estado, donde se podr acceder a los
datos correspondientes del mismo o la agenda de trabajo que se tiene para
ese municipio.
11
Mostrar alertas a las reas pertinentes, cuando un convenio haya finalizado y

cuando se aproxime la fecha de una reunin o capacitacin.
Facilitar la interaccin entre el sistema y los usuarios a travs del uso de

mens y el diseo de una interfaz amigable e intuitiva, mediante los
estndares del W3C.
Gestionar las reuniones, capacitaciones, asesoras con las autoridades

municipales mediante agendas de trabajo, generando un entorno colaborativo,
donde se definirn tareas y asignarn responsables.
1.8
Alcances y limitaciones
1.8.1 Alcances
Desarrollar un sistema Web que permitir la gestin de la relacin que existe

entre los 570 Municipios del Estado con el Instituto Catastral del Estado de
Oaxaca.
La Coordinacin de Enlace Municipal se ver beneficiada ya que podrn

agilizar los procesos de intercambio y obtencin de informacin con las
dems reas del Instituto.
Contar con el historial de los municipios que han firmado convenios con el
Instituto.
Con la puesta en marcha del sistema se pretende mostrar un entorno de fcil

acceso a la informacin.
Se llevar un seguimiento adecuado de los municipios creando una relacin

colaborativa entre ellos y el ICEO.
Toda la informacin mostrada de los municipios ser veraz y oportuna.
Se podrn crear proyectos de trabajo colaborativo donde participen las

diferentes reas del ICEO.
12
1.8.2 Limitaciones del problema
El sistema ser para uso exclusivo del Instituto Catastral del Estado de
Oaxaca.
Ser necesario el uso de Internet para su funcionamiento.
El Instituto no cuenta con un servidor SMTP4 propio, ya que este depende de

la Secretaria de Administracin del Gobierno del Estado.
Los usuarios solo podrn ser dados de alta por un administrador y podrn
tener acceso solo dentro de la red del Instituto.
Simple Mail Transfer Protocol (Protocolo para la transferencia simple de correo electrnico)
13
C A P T U L O II
MARCO TERICO
14
CAPITULO II
MARCO TERICO
En ste captulo se abordarn los conceptos relacionados a la rama de la

informtica, cuya aplicacin es necesaria para todo desarrollo de software y que
han sido utilizadas para el presente proyecto. Entre los temas descritos en este
captulo estn: el diseo de sistemas; la definicin del ciclo de vida para el
desarrollo de sistemas, que forma parte de una de las estrategias importantes a
tomar en cuenta para el desarrollo de sistemas; adems se definen los conceptos
de base de datos y normalizacin que nos permiten definir el diseo lgico para su
posterior codificacin.
2.1
Concepto de sistema
El diccionario de la Real Academia de la Lengua Espaola define el vocablo

sistema como un conjunto de cosas que ordenadamente relacionadas entre
s contribuyen a un determinado objetivo.
Por su parte, la Teora General de Sistemas o enfoque sistmico, por sistema
entiende un conjunto de elementos en interaccin dinmica organizada para
la consecucin de un objetivo. 5
Es decir, un sistema es un grupo de componentes interrelacionados que trabajan
juntos hacia un fin comn, aceptando inputs y produciendo outputs en un proceso
de transformacin organizado.
De Pablos, C., Lpez, J. J., Hermoso Santiago, M., & Medina, S. (2004). Informtica y comunicaciones en la
empresa. Madrid: ESIC Editorial.
15
2.2
Concepto de sistema de informacin
El concepto de sistema de informacin (SI), se puede definir como un conjunto

de
recursos
tcnicos,
humanos
econmicos,
interrelacionados
dinmicamente, y organizados en torno al objetivo de satisfacer
las
necesidades de informacin de una organizacin empresarial para la gestin

y la correcta adopcin de decisiones.6
Un sistema de informacin se puede definir tcnicamente como un conjunto de
componentes relacionados que recolectan (o recuperan), procesan, almacenan y
distribuyen informacin para apoyar la toma de decisiones y el control en una
organizacin.
Existen tres actividades en un SI que producen la informacin que esas
organizaciones necesitan para tomar decisiones, controlar operaciones, analizar
problemas y crear nuevos productos o servicios.7
Estas actividades son:
Entrada: captura o recolecta datos en bruto tanto del interior de la

organizacin como de su entorno.
Procesamiento: convierte esa entrada de datos en una forma ms

significativa.
Salida: transfiere la informacin procesada a la gente que la usar o a las

actividades para las que se utilizar.
2.3
Usuarios de los sistemas
En el mbito de la informtica, James A. Senn dice que los usuarios de los

sistemas son aquellos que se encargan de crear, utilizar, procesar, administrar o
intercambiar informacin o bien, trmino que se refiere a aquellos que utilizan la
informacin y los sistemas de informacin.
6
De Pablos, C., Lpez, J. J., Hermoso Santiago, M., & Medina, S. (2004). Informtica y comunicaciones en la
empresa. Madrid: ESIC Editorial.
7
Instituto Tcnologico de Sonora. (s.f.). Recuperado el 4 de Noviembre de 2014, de
http://biblioteca.itson.mx/oa/dip_ago/introduccion_sistemas/p3.htm#
16
La informacin est compuesta de datos que se han procesado y colocado en un

contexto significativo y til y se ha comunicado a un receptor, quien la utiliza para
la toma de decisiones. Se puede presentar a travs de imgenes, textos,
documentos y voz, organizados en un contexto significativo y sirve para influir
sobre los individuos.
2.3.1 Actores de los sistemas

Los actores del sistema son los que hacen posible el proceso de transformacin
que se lleva a cabo en un sistema son:
Dueos del sistema: Para cualquier sistema de informacin grande o pequeo

habr uno o ms dueos del sistema, ellos tienden a estar interesados en:
cunto costara el sistema?, cul ser el costo/beneficio?, cundo
recuperaran la inversin y como la recuperaran?, etc. este grupo es el que
paga por el sistema.
Usuario del sistema: Los usuarios del sistema son los que definen los
requerimientos del negocio y las expectativas del sistema. Ellos ven a un
sistema de informacin en trminos de la funcionalidad que provee a sus
trabajos, en que sea fcil de aprender y de utilizar.
a. Usuarios Internos: Son aquellos empleados del negocio para el cual se
est construyendo el sistema y son el mayor porcentaje de usuarios de
un sistema.
b. Usuarios Externos: son aquellos usuarios que se vern beneficiados por
el sistema, por ejemplo los clientes, proveedores, empleados, socios, etc.
Diseadores del sistema: Son tcnicos especializados que traducen los

requerimientos de los usuarios del negocio en soluciones tcnicas. Ellos
disean: bases de datos, entradas y salidas del sistema, pantallas, redes y
software que se puede adaptar a los requerimientos del usuario.
17
Constructores del sistema: Su rol es la construccin del sistema de acuerdo a

las especificaciones dadas por el diseador de sistemas. Un constructor del
sistema puede pertenecer a algunas de las siguientes especialidades:
a. Programador de Aplicaciones: son especialistas que convierten los
requerimientos de la empresa en lenguajes de programacin. Ellos
desarrollan y prueban programas de computacin que capturan y
almacenan datos.
b. Programadores de Sistemas: son especialistas que desarrollan, prueban
e implementan software a nivel de sistema operativo.
c. Programadores de Bases de Datos: son especialistas en tecnologas y
lenguajes de bases de datos, que construyen, modifican y prueban las
estructuras de las bases de datos as como los programas que se utilizan
para darles mantenimiento a las mismas.
Analista de sistemas: Es un especialista que estudia los problemas y

necesidades de una organizacin para determinar cmo las personas, datos,
procesos y la tecnologa de la informacin pueden en conjunto mejorar un
negocio. El analista de sistemas evala de manera sistemtica el
funcionamiento de un negocio mediante el examen de la entrada, el
procesamiento de datos y su consiguiente produccin de informacin, con el
propsito de mejorar los procesos de una organizacin.
2.4
Modelos de ciclo de vida
2.4.1 Concepto de modelo de ciclo de vida

Un modelo de ciclo de vida de software es una vista de las actividades que
ocurren durante el desarrollo de software; este intenta determinar el orden de las
etapas involucradas y los criterios de transicin asociadas entre estas etapas.
Un modelo de ciclo de vida del software:
Describe las fases principales de desarrollo de software.
18
Define las fases esperadas a ser ejecutadas.
Ayuda a administrar el progreso del desarrollo.
Provee un espacio de trabajo para la definicin de un detallado proceso de

desarrollo de software.
En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer

una serie de objetivos, tareas y actividades que lo caracterizan. As, los modelos
por una parte suministran una gua para los ingenieros de software con el fin de
ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran
un marco para la administracin del desarrollo y el mantenimiento, en el sentido en
que permiten estimar recursos, definir puntos de control intermedios, monitorear el
avance, etc. 8
2.4.2 Proceso de desarrollo unificado (UP)

El proceso unificado conocido como UP9, es un modelo de software que permite
el desarrollo a gran escala, mediante un proceso continuo de pruebas y
retroalimentacin, garantizando el cumplimiento de ciertos estndares de
calidad. Aunque con el inconveniente de generar mayor complejidad en los
controles de administracin del mismo. El proceso de desarrollo constituye un
marco metodolgico que define en trminos de metas estratgicas, objetivos,
actividades y documentacin requeridos en cada fase de desarrollo. Esto permite
enfocar esfuerzo de los recursos humanos en trminos de habilidades,
competencias y capacidades a asumir roles especficos con responsabilidades
bien definidas.10
Instituto Nacional de Tecnologas de la Comunicacin. (Marzo de 2009). Recuperado el 4 de

Noviembre de 2014, de https://www.incibe.es/file/N85W1ZWFHifRgUc_oY8_Xg
9
Proceso de Desarrollo Unificado
10
Flores Lpez , M., & Santiago, M. (s.f.). Universidad Tecnologica del Valle del Mezquital.
Recuperado el 4 de Noviembre de 2014, de
http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm
19
Las fases del ciclo de vida del proceso de desarrollo unificado son:
1. Fase de concepcin: Tiene como propsito definir y acordar el alcance del
proyecto, identificar los riesgos potenciales asociados, proponer una visin
general de la arquitectura de software y producir el plan de las fases y el de
iteraciones.
2. Fase de elaboracin: Se seleccionan los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificacin de los casos de uso seleccionados y el primer anlisis del
dominio del problema, se disea la solucin preliminar.
3. Fase de construccin: Se completa la funcionalidad del sistema, para ello se
deben clarificar los requerimientos pendientes, administrar los cambios de
acuerdo a las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
4. Fase de transicin: Asegura que el software est disponible para los usuarios
finales, ajustar los errores y defectos encontrados en las pruebas de
aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario.
Para fines del proyecto ser utilizada esta metodologa de desarrollo, debido a que
se considera la ms completa y a que es utilizada en la Institucin para la cual se
desarrolla el sistema.
Figura No. 3
Diagrama general del modelo de desarrollo unificado
20
2.5
Lenguajes de programacin
2.5.1 Concepto de lenguaje de programacin

Un lenguaje de programacin es definido como un Lenguaje artificial que se
utiliza para expresar programas de computadora.
Cada computadora, segn su diseo entiende un conjunto de instrucciones
elementales (lenguaje mquina). No obstante, para facilitar la tarea del
programador, se dispone tambin de lenguajes de alto nivel ms fciles de
manejar y que no dependen del dselo especfico de cada computadora. Los
programas escritos en un lenguaje de alto nivel no podrn ser ejecutados por una
computadora mientras sean traducidos al lenguaje propio de esta.
11
Para definir un lenguaje de programacin es necesario especificar:
Conjunto de smbolos y palabras clave utilizables.
Reglas gramaticales para construir sentencias (instrucciones, ordenes)

sintctica y semnticamente correctas.
a. Sintaxis: conjunto de normas que determinan como escribir las
sentencias del lenguaje.
b. Semntica: interpretacin de las sentencias. Indica el significado de las
mismas.
2.5.2 Lenguaje mquina.

Los lenguajes mquina son aquellos cuyas instrucciones son directamente
entendibles por las computadoras y no necesitan traduccin posterior para que
la CPU12 pueda comprender y ejecutar el programa. Las instrucciones en lenguaje
mquina se expresan en trminos de la unidad de memoria ms pequea, el bit
(dgito binario 0, o bien 1), en esencia una secuencia de bits especifica la
11
Rodrguez Sala, J. J., Santamara Arana, L., Rabasa Dolado, A., & Martnez Bonastre, O. (s.f.). Introduccion a
la programacion teoa y prctica. Alicante: Editorial Club Universitario.
12
Unidad Central de Proceso
21
operacin y las celdas de memoria implicadas en una operacin. Una serie de

instrucciones en lenguaje mquina son:
0010 0000 0000 1001
1001 0001 1001 1110
Como se puede observar, estas instrucciones sern fciles de leer la computadora
y difciles por un programador. Esta razn hace difcil escribir programas en cdigo
o lenguaje mquina y requiere buscar otro lenguaje para comunicarse con la
computadora, pero que sea ms fcil de escribir y leer por el programador.
2.5.3 Lenguaje de alto nivel

Los lenguajes de programacin de alto nivel son aquellos en los que las
instrucciones o sentencias a la computadora son escritas con palabras
similares a los lenguajes humanos, lo que facilita la escritura y la fcil
comprensin por el programador. Los lenguajes de programacin son en
general transportables, esto significa que un programa escrito en un lenguaje de
alto nivel se puede escribir con poca o ninguna modificacin en diferentes tipos de
computadoras. Los programas escritos en lenguaje de alto nivel no son
entendibles directamente por la mquina, necesitan ser traducidos a instrucciones
en lenguaje mquina que entiendan las computadoras. Los programas que
realizan esta traduccin se llama compiladores, y los programas escritos en un
leguaje de alto nivel se llaman programas fuente. El compilador traduce el
programa fuente en un programa llamado programa objeto. Este programa
objeto se utiliza en la fase de ejecucin del programa. El proceso de traduccin de
un programa fuente se denomina compilacin y tras la fase de enlace se obtiene
un programa ejecutable directamente por la computadora.
13
13
22
2.5.4 Paradigma de programacin

El diccionario de la Real Academia de la Lengua Espaola presenta la palabra
paradigma como derivada de las palabras griegas mostrar y manifestar y la
define como el ejemplo a seguir o entidad ejemplar de un conjunto.
Un paradigma de programacin es una coleccin de patrones conceptuales
que moldean la forma de razonar sobre problemas de formular soluciones y
de estructurar programas.
14
Es un modelo bsico de construccin de programas, que permite producir

programas conforme con unas directrices especficas, tales como disear un
programa mediante una secuencia de instrucciones que operan sobre los datos de
entrada y producen un resultado de salida. Un paradigma de programacin es,
pues, una coleccin de modelos conceptuales que juntos modelan el proceso de
construccin de un programa y determinan, al final, su estructura.
Esa estructura conceptual de modelos est diseada de forma que los modelos:15
1. Controlan la manera en que pensamos como solucionar un problema.
2. Definen el modo en que la solucin se formaliza.
3. Determinan la forma correcta de los programas e incluso si alcanzamos la
solucin.
En este sistema el paradigma de programacin a utilizar es el Orientado a
Objetos, el cual ser explicado a continuacin.
2.5.4.1
Programacin orientada a objetos (POO)
Vivimos en un mundo de objetos; estos objetos existen en la naturaleza, en

entidades y en los productos que usamos. Los objetos pueden ser clasificados,
descritos, organizados, combinados, manipulados y creados. Es por esto que se
14
15
Alonso Amo, F., Martnez Normand, L., & Segovia Prez, F. J. (2005). Introduccin a la Ingeniera
de Software, Modelos de desarrollo de programas. Madrid, Espaa: Delta publicaciones.
23
propuso un anlisis y desarrollo orientado a objetos, que nos permita aprovechar

las caractersticas, individualidad y facilidad de manipulacin que ofrecen los
objetos.
El paradigma orientado a objetos (OO) se refiere a un estilo de
programacin. Lo que caracteriza un lenguaje de programacin orientado a
objetos. Lo que caracteriza un LOO16 es la forma de manejar la informacin que
est basada en tres conceptos. 17
Es as que al estar hablando de objetos es importante describir las ideas
fundamentales implcitas en la tecnologa orientada a objetos incluyen:
Objeto: Un objeto es cualquier cosa, real o abstracta, acerca de la cual

almacenamos datos y aquellos mtodos que los manipulan.
Clase: Una clase es la implementacin de un tipo de objeto. Especifica la

estructura de datos y los mtodos operacionales permitidos que se aplican
a cada uno de sus objetos.
Mtodo: Especifica la manera en la cual los datos de un objeto son

manipulados. Los mtodos en un tipo de objeto hacen solamente referencia
a la estructura de datos de ese tipo de objeto. No deben de accesar
directamente a la estructura de datos de otro objeto.
Peticin: Una peticin solicita una operacin especfica debe ser invocada
usando uno o varios objetos como parmetros.
Una vez que se han mencionado las ideas fundamentales del modelo orientado a
objetos, es importante saber que existen tres conceptos importantes que
diferencian el enfoque Orientado a Objetos de la ingeniera del software
convencional:
1. Encapsulamiento: Empaqueta los datos y las operaciones que manejan
estos datos en un objeto simple con denominacin.
16
Lenguaje Orientado a Objetos

17
24
2. Herencia: Permite que los atributos y operaciones de una clase sean

heredados por todas las subclases y objetos que se instancian de ella.
3. Polimorfismo: Permite que una cantidad de operaciones diferentes posean
el mismo nombre, reduciendo la cantidad de lneas de cdigo necesarias
para implementar un sistema y facilita los cambios en caso que se
produzcan.
Los objetos estn compuestos por atributos los cuales describen un objeto;
que en esencia, son los que definen al objeto, a la vez que clarifican lo que
se representa con el objeto en el contexto del espacio del problema. Para
poder manipular los atributos de los objetos existen los algoritmos que los
procesan, los cuales son llamados operaciones, mtodos o servicios y pueden ser
vistos como mdulos en un sentido convencional. Cada una de las operaciones
encapsuladas por un objeto proporciona una representacin de uno de los
comportamientos del objeto. Las operaciones definen el comportamiento de un
objeto y cambian, de alguna manera, los atributos de dicho objeto.
2.5.5 Arquitectura modelo vista - controlador

La arquitectura MVC18 fue diseada para reducir el esfuerzo de programacin
necesario en la implementacin de sistemas. Sus caractersticas principales
son que el Modelo, las Vistas y los
Controladores
se
tratan
como
entidades separadas; esto hace que

cualquier
cambio
producido en
el
Modelo se refleje automticamente en

cada una de las Vistas. 19
Figura No. 4
Arquitectura MVC
Modelo-Vista-Controlador
19
Jaramillo Valvuena, S., Cardona, S. A., & Villa Zapata, D. A. (2008). Programacin avanzada en Java.
Colombia: Ediciones Elizcom.
18
25
Este modelo de arquitectura presenta varias ventajas:
La implementacin se realiza de forma modular.
Sus vistas muestran informacin actualizada siempre. El programador no

debe preocuparse de solicitar que las vistas se actualicen, ya que este
proceso es realizado automticamente por el modelo de la aplicacin.
Cualquier modificacin que afecte al dominio, como aumentar mtodos o

datos contenidos, implica una modificacin slo en el modelo y las
interfaces del mismo con las vistas, no todo el mecanismo de comunicacin
y de actualizacin entre modelos.
Las modificaciones a las vistas no afectan al modelo de dominio,

simplemente se modifica la representacin de la informacin, no su
tratamiento.
Facilita agregar nuevos tipos de datos segn sea requerido por la aplicacin
ya que son independientes del funcionamiento de las otras capas.
Crea independencia de funcionamiento.
Facilita el mantenimiento en caso de errores.
Ofrece maneras ms sencillas para probar el correcto funcionamiento del

sistema.
Permite el escalamiento de la aplicacin en caso de ser requerido.
2.5.5.1
Definicin de las partes del modelo vista - controlador
El Modelo: Esta es la representacin de los datos y reglas de negocio (mundo

del problema). Es el encargado de manejar un registro de las vistas y de los
controladores que existen en el sistema.
La Vista: Permite mostrar la informacin del modelo en un formato adecuado

que permita que se d la interaccin. Adems de poseer un registro acerca del
controlador asociado.
26
El Controlador: Responde a los eventos provocados por el usuario que

implican cambios en el modelo y la vista, dando una correcta gestin a las
entradas del usuario. 20
La siguiente figura muestra cmo funciona esta Arquitectura en web.
Figura No. 5
2.5.5.2
Arquitectura MVC en Web
Ciclo de vida del modelo vista - controlador
El ciclo de vida de MVC es normalmente representado por las 3 capas

presentadas anteriormente y el cliente (tambin conocido como usuario).
El primer paso en el ciclo de vida empieza cuando el usuario hace una solicitud al
controlador con informacin sobre lo que el usuario desea realizar. Entonces el
Controlador decide a quin debe delegar la tarea y es aqu donde el Modelo
empieza su trabajo. En esta etapa, el Modelo se encarga de realizar operaciones
sobre la informacin que maneja para cumplir con lo que le solicita el Controlador.
Una vez que termina su labor, le regresa al Controlador la informacin resultante
de sus operaciones, el cual a su vez redirige a la Vista. La Vista se encarga de
transformar los datos en informacin visualmente entendible para el usuario.
Finalmente, la representacin grfica es transmitida de regreso al Controlador y
20
Lafosse, J. (2010). Struts 2 El framework de desarrollo de aplicaciones Java EE. Barcelona: Ediciones ENI.
27
ste se encarga de transmitrsela al usuario.

El ciclo entero puede empezar nuevamente
si el usuario as lo requiere.
2.6
Un
Framework
framework
es
un
conjunto
de
bibliotecas, herramientas y normas a

seguir
que
ayudan
desarrollar
Figura No. 6
Ciclo de vida del MVC
aplicaciones. Est compuesto por varios

segmentos/componentes que interactan los unos con los otros. Las aplicaciones
pueden escribirse de manera ms eficaz utilizando un framework adaptado al
proyecto.21
Estos permiten la reutilizacin de cdigo, la estandarizacin del desarrollo y la
utilizacin del ciclo de desarrollo de tipo incremental (especificacin, codificacin,
mantenimiento y evolucin).
2.7
Seleccin del lenguaje de programacin
El lenguaje de programacin a utilizar es Groovy juntamente con el Framework

para aplicaciones web Grails desarrollado en este mismo lenguaje; debido a que,
Groovy & Grails es un lenguaje de programacin orientado a objetos
implementado sobre la plataforma Java, usa una sintaxis muy parecida este
y se puede acceder directamente a todas las API existentes de este lenguaje.
El bytecode generado en el proceso de compilacin es totalmente compatible con
el generado por el lenguaje Java para la Java Virtual Machine (JVM), por tanto
puede usarse directamente en cualquier aplicacin Java. Todo lo anterior unido a
que la mayor parte de cdigo escrito en Java es totalmente vlido en Groovy hace
21
Lafosse, J. (2010). Struts 2 El framework de desarrollo de aplicaciones Java EE. Barcelona: Ediciones ENI.
28
que este lenguaje sea de muy fcil adopcin para programadores en este
lenguaje. 22
A continuacin se mencionan algunas caractersticas que este lenguaje de
programacin tiene:
Lenguaje gil y dinmico para la mquina virtual de Java.
Maneja la arquitectura MVC.
Se basa en los puntos fuertes de Java, pero tiene caractersticas de

potencia adicionales inspiradas en lenguajes como Python, Ruby y
Smalltalk.
Soporta lenguajes especficos de dominio y otra sintaxis compacta por lo

que su cdigo se convierte en fcil de leer y mantener
Aumenta la productividad de los desarrolladores mediante la reduccin de

cdigo en el desarrollo web, interfaz grfica de usuario, bases de datos o
aplicaciones de consola
Se integra perfectamente con todas las clases y las bibliotecas Java

existentes.
Por otro lado, el framework Grails es una herramienta poderosa basada en el

lenguaje Groovy que agiliza y simplifica el desarrollo de aplicaciones web en
JEE23.
Grails utiliza GORM (Grails Object Relational Mapping)24, un gestor de
persistencia escrito en Groovy, para controlar el ciclo de vida de las entidades y
proporcionar una serie de mtodos, dinmicos (se crea en tiempo de ejecucin
para cada entidad) que facilitan las bsquedas.
GORM est construido sobre Hibernate, una herramienta de mapeo objetorelacional, que se encarga de relacionar las entidades de la clase con tablas de
22
Barclay, K., & Savage, J. (2007). Groovy Programming an introduction for Java Developers. San Francisco,
CA: Elsevier.
23
Java Enterprise Edition: Plataforma de programacinparte de la Plataforma Javapara desarrollar y
ejecutar software de aplicaciones en el lenguaje de programacin Java.
24
Mapeo Objeto-Relacional Grails
29
una base de datos, y las propiedades de las entidades con campos en las tablas.
Cada operacin que se realice sobre los objetos del modelo de datos ser
traducido por Hibernate en las sentencias SQL25 necesarias para quedar reflejado
en la base de datos. 26
2.8
Base de Datos
2.8.1 Definicin
Una base de datos es un conjunto de datos almacenados sin redundancias
innecesarias en un soporte informtico y accesible simultneamente por
distintos usuarios y aplicaciones. Los datos deben de estar estructurados y
almacenados de forma totalmente independiente a las aplicaciones que la
utilizan.27
2.8.2 Componentes
Datos: Es el componente fundamental de la base de datos. Los datos por si

mismos no aportan conocimiento hay que procesarlos y transformarlos.
Software SGBD28: Es un software o conjunto de programas que permite crear

y mantener una base de datos. El SGBD acta como una interfaz entre los
programas de aplicacin (usuarios) y el sistema operativo. Su objetivo
principal es proporcionar un entorno eficiente a la hora de almacenar y
recuperar la informacin de la base de datos. Facilitando el proceso de definir,
construir y manipular bases de datos para diversas aplicaciones.
25
Lenguaje de consulta estructurado o SQL (por sus siglas en ingls Structured Query Language) es un
lenguaje declarativo de acceso a bases de datos.
26
Brito, I. (2009). Manual de desarrollo web con GRAILS. Madrid, Espaa: Ediciones giles.
27
Cobo Yera, . (2007). Diseo y programacion de Bases de Datos. Madrid: Vision Libros.
28
Sistema de Gestin de Base de Datos
30
a. Definir una base de datos consiste en especificar los tipos, las

estructuras y las restricciones de los datos.
b. Construir una BD29 es el proceso de almacenar los datos en algn
medio de almacenamiento controlado por el SGBD, una vez definida la
base de datos.
c. Manipular la BD es: Consultar los datos para obtener cierta informacin,
actualizar la base de datos (modificar o eliminar datos, o introducir
nuevos) y generar informes a partir de los datos almacenados.
Usuarios: existen diferentes 2 tipos de usuarios:

a. Habituales: suelen hacer consultas y/o actualizaciones en la base de
datos como parte habitual de su trabajo. Utilizan en general mens, de
forma que se facilite su interrelacin con la computadora.
b. Espordicos: Es un tipo de usuario muy parecido al anterior en la
medida en que necesitan la computadora a fin de que les preste una
ayuda en su trabajo, pero en cambio no la utilizan habitualmente porque
el tipo de actividad que realizan no lo exige. 30
Administrador de la Base de Datos: (en ingls DBA: Data Base Administrator)

son la persona o grupos de personas encargadas del control del sistema. Las
funciones del DBA incluyen las siguientes:
a. Definir y modificar el esquema de la base de datos y las restricciones
de los datos.
b. Crear y modificar las estructuras de almacenamiento fsicas y los
mtodos de acceso.
c. Autorizar el acceso a la BD de los usuarios.
d. Garantizar el funcionamiento correcto del sistema y prestar servicio
tcnico: se ocupa de los problemas de violacin de la seguridad del
sistema de BD, o de respuesta lenta del sistema.
29
Base de Datos
Castao, A., & Piattini Velthuis, M. G. (s.f.). Fundamentos y modelos de bases de datos. Madrid:
Alfaomega.
30
31
e. Realizar copias de seguridad (backups) del contenido de la BD31
2.8.3 Objetivos de un SGBD

1. Abstraccin de la informacin: El primer objetivo de un SGBD es proporcionar
a los usuarios una visin abstracta de la informacin, es decir, el sistema
ahorra al usuario la necesidad de conocer los detalles de cmo se
almacenan los datos.
2. Independencia: Capacidad para modificar un esquema de definicin sin
afectar a los programas de aplicacin. Existen dos niveles de independencia:
Independencia fsica: es posible modificar el esquema fsico sin afectar

a las aplicaciones que los utilizan.
Independencia lgica: cuando es posible modificar el esquema

conceptual sin obligar a escribir de nuevo las aplicaciones.
3. Redundancia mnima: Evita el almacenamiento mltiple de la misma

informacin para uso de distintas aplicaciones.
4. Consistencia:
Impide
que
exista
informacin
inconsistente
contradictoria en la base de datos. La inconsistencia surge cuando existen

varias copias del mismo dato y tras la modificacin de una de ellas, las dems
no son actualizadas, o si lo son pero de forma incorrecta. Si existen datos
duplicados, en la actualizacin, el SGBD debe garantizar la adecuada
actualizacin de estos en todos los archivos donde se encuentre.
5. Seguridad: EL SGBD deber garantizar la proteccin de la informacin
controlando el acceso y la manipulacin de las distintas aplicaciones y
usuarios. EL SGBD debe disponer de un robusto subsistema de seguridad y
autorizacin, mediante el cual el administrador pueda:
31
32
Crear cuentas de usuario protegidas con contraseas (para asegurar

que slo acceden a los datos los usuarios que tengan permisos para
ello).
Crear restricciones para cada usuario de forma que se controle a que

datos tiene acceso el usuario, el tipo de operaciones que puede realizar
sobre esos datos (es decir, si puede verlos o modificarlos, eliminarlos o
crear nuevos).
6. Integridad: Es asegurar que la informacin almacenada y utilizada por una

aplicacin es correcta, es decir, refleja fielmente la realidad. No existe
integridad de datos cuando:
Existe inconsistencia
Existe informacin imposible (El dato no es correspondiente a la

realidad)
7. Respaldo y recuperacin: Todo SGBD debe contar con recursos para

conservar copias de seguridad de cada archivo en prevencin de fallos
de hardware o de software.
El proceso de copiar un archivo de forma peridica se llama respaldo

(backup). Estas copias deben de realizarse regularmente y guardarse
en un lugar seguro.
El proceso contrario, recuperar la informacin original se llama

recuperacin.
Si el fallo ocurre mientras estaba en marcha un programa que actualizaba

gran cantidad de datos, el subsistema de recuperacin debe asegurar que:
a) La base de datos se restaurar al estado en que estaba justo antes de
comenzar el programa.
b) El programa contina su ejecucin por el punto en donde la dejo
cuando se produjo el fallo y finaliza su trabajo correctamente.
8. Control de concurrencia: Permite que mltiples procesos sean ejecutados
al mismo tiempo sin interferir entre s. Mientras se ejecutan, las
33
transacciones utilizan recursos de datos sin adquirir bloqueos en esos

recursos. 32
2.8.4 Modelos de datos

Bajo la estructura de la base de datos se encuentra el modelo de datos: una
coleccin de herramientas conceptuales para describir los datos, las relaciones, la
semntica y las restricciones.
2.8.4.1
Modelo entidad - relacin
El modelo de datos entidad-relacin (E-R) est basado en una percepcin del

mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y
de relaciones entre estos objetos. La estructura lgica general de una base de
datos se puede expresar grficamente mediante un diagrama ER, que consta
de los siguientes componentes:
Rectngulos, representan conjuntos de entidades.
Elipses, representan atributos.
Rombos, representan relaciones entre conjuntos de entidades.
Lneas, unen los atributos con los conjuntos de entidades y los conjuntos de
entidades con las relaciones.
Cada componente se etiqueta con la entidad o relacin que representa.

En su forma ms simple, la modelizacin semntica con esta tcnica supone la
identificacin de los objetos de inters de nuestra organizacin (que se denominan
entidades), las propiedades relevantes de dichos objetos (que se denominan
atributos) y como estos se relacionan entre s (relaciones o conexiones).
Los objetivos que persigue el modelo E-R son fundamentalmente, dos:
32
34
1. Ofrecer un modelo que refleje fielmente las necesidades de informacin de

una organizacin, el cual ser usado como base para el desarrollo de un
sistema.
2. Ofrecer un modelo independiente del posterior almacenamiento de los
datos y sus mtodos de acceso, lo que permitir tomar decisiones objetivas
a cerca de la implementacin idnea.
Figura No. 7
Notacin grafica para diagramas segn el

modelo E-R
Adems de entidades y relaciones, el modelo E-R representa ciertas restricciones

que los contenidos de la base de datos deben cumplir. Una restriccin importante
es la correspondencia de cardinalidades, que expresa el nmero de entidades con
las que otra entidad se puede asociar a travs de un conjunto de relaciones.33
En el caso de las relaciones binarias (conectan dos conjuntos de entidades), la
cardinalidad puede ser:
Uno a uno (1:1): Una entidad del primer conjunto solo puede relacionarse
con una entidad del segundo conjunto y viceversa.
33
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2002). Fundamentos de Bases de Datos. Madrid: McGrawHill Inc.
35
Uno a muchos (1: N): Una entidad del primer conjunto puede relacionarse
con cualquier nmero de entidades del segundo, pero una entidad del
segundo conjunto solo puede relacionarse con una entidad del primero.
Muchos a muchos (N: N): una entidad el primer conjunto puede

relacionarse con cualquier nmero de entidades del segundo y viceversa.34
Figura No. 8
2.8.4.2
Ejemplo de diagrama E-R
Modelo relacional
En el modelo relacional se utiliza un grupo de tablas para representar los

datos y las relaciones entre ellos.
Cada tabla est compuesta por varias
columnas, y cada columna tiene un nombre nico.35

Est constituido por una coleccin de tablas denominadas relaciones, que van
identificadas por un nombre, y cuyas filas, denominadas tuplas, estn constituidas
34
Pons Capote, O., Marn Ruz, N., Medina Rodrguez, J. M., Acid Carrillo, S., & Vila Miranda, M. A. (2009).
Introduccin a las Bases de Datos, el Modelo Relacional. Madrid, Espaa: Thomson.
35
36
por un conjunto de valores que representan toda la informacin concerniente a

una entidad concreta. La estructura fundamental del modelo relacional es
precisamente esa, "relacin", es decir una tabla bidimensional constituida por
lneas (tuplas) y columnas (atributos). Las relaciones representan las entidades
que se consideran interesantes en la base de datos. Cada instancia de la entidad
encontrar sitio en una tupla de la relacin, mientras que los atributos de la
relacin representarn las propiedades de la entidad.
Para distinguir una tupla de otra, se recurre al concepto de "llave primaria", o sea
a un conjunto de atributos que permiten identificar unvocamente una tupla
en una relacin. Naturalmente, en una relacin puede haber ms combinaciones
de atributos que permitan identificar unvocamente una tupla ("llaves candidatas"),
pero entre stas se elegir una sola para utilizar como llave primaria. Los atributos
de la llave primaria no pueden asumir el valor nulo (que significa un valor no
determinado), en tanto que ya no permitiran identificar una tupla concreta en una
relacin.
Esta propiedad de las relaciones y de sus llaves primarias est bajo el nombre de
integridad
de
las
entidades
(entity integrity).
Cada atributo de una relacin se
caracteriza por un nombre y por
un dominio. El dominio indica
qu
valores
pueden
ser
asumidos por una columna de la

relacin.
Figura No. 9
37
Ejemplo de modelo relacional
2.8.5 Lenguaje de base de datos SQL

El SQL36 es el lenguaje estndar ANSI/ISO de definicin, manipulacin y
control de bases de datos relacionales. Es un lenguaje declarativo: slo hay
que indicar qu se quiere hacer. Una de sus caractersticas es el manejo del
lgebra y el clculo relacional que permiten efectuar consultas con el fin de
recuperar de forma sencilla informacin de inters de bases de datos, as como
hacer cambios en ellas.
El modelo relacional tiene como estructura de almacenamiento de los datos las
relaciones. La intensin o esquema de una relacin consiste en el nombre dado a
la relacin y un conjunto de atributos. La extensin de una relacin es un conjunto
de tuplas. Al trabajar con SQL,
esta
nomenclatura
cambia,
como se puede apreciar en la

siguiente figura.
Se hablar de tablas en lugar de
relaciones,
de columnas en
lugar de atributos y de filas en

lugar de tuplas. Sin embargo, a
pesar de que la nomenclatura
utilizada
sea
diferente,
conceptos son los mismos.
los
37
Figura No. 10 Nomenclatura modelo relacional
El lenguaje SQL tiene varios componentes: 38
Lenguaje de definicin de datos (LDD): El LDD de SQL proporciona

rdenes para la definicin de esquemas de relacin, borrado de relaciones,
creacin de ndices y modificacin de esquemas de relacin.
36
SQL significa Structured Query Language, o su equivalente en espaol Lenguaje Estructurado de Consultas.
Martn Escofet, C. (s.f.). Universitat Oberta de Catalunya OpenCourseWare. Recuperado el 2014 de
Noviembre de 2014, de El lenguaje SQL: http://ocw.uoc.edu/computer-science-technology-andmultimedia/bases-de-datos/bases-de-datos/P06_M2109_02149.pdf
38
Castao, A., & Piattini Velthuis, M. G. (s.f.). Fundamentos y modelos de bases de datos. Madrid: Alfaomega.
37
38
Lenguaje interactivo de manipulacin de datos (LMD): El LMD de SQL

incluye un lenguaje de consultas, basado tanto en el lgebra relacional
como en el clculo relacional de tuplas. Incluye tambin rdenes para
insertar, borrar y modificar tuplas de la base de datos.
Definicin de vistas: El LDD de SQL incluye rdenes para la definicin de

vistas.
SQL incorporado y SQL dinmico: SQL dinmico e incorporado define

como se pueden incorporar las instrucciones SQL en lenguaje de
programacin de propsito general, tales como C, C++, Java, etc.
Integridad: El LDD de SQL, incluye rdenes para la especificacin de las

restricciones de integridad que deben satisfacer los datos almacenados en
la base de datos. Las actualizaciones que violen las restricciones de
integridad se rechazan.
Autorizacin: El LDD de SQL incluye rdenes para especificar derechos de

acceso para las relaciones y vistas.
2.8.6 Estructura de un sistema de bases de datos
2.8.6.1
Normalizacin de bases de datos
La normalizacin es el proceso mediante el cual se transforman datos

complejos a un conjunto de estructuras de datos ms pequeas, que adems
de ser ms simples y ms estables, son ms fciles de mantener. Tambin se
puede entender la normalizacin como una serie de reglas que sirven para ayudar
a los diseadores de bases de datos a desarrollar un esquema que minimice los
problemas de lgica. Cada regla est basada en la que le antecede.
Las guas que la normalizacin provee crean el marco de referencia para
simplificar una estructura de datos compleja. Una ventaja de la normalizacin de
base de datos es el consumo de espacio. Una base de datos normalizada ocupa
39
menos espacio en disco que una no normalizada. Hay menos repeticin de datos,
lo que tiene como consecuencia un mucho menor uso de espacio en disco. El
proceso de normalizacin tiene un nombre y una serie de reglas para cada fase. 39
2.8.6.2 Grados de normalizacin

Existen bsicamente tres niveles de normalizacin: Primera Forma Normal (1NF),
Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas
formas tiene sus propias reglas. Cuando una base de datos se conforma a un
nivel, se considera normalizada a esa forma de normalizacin.
En la tabla siguiente se describe brevemente en que consiste cada una de las

reglas, y posteriormente se explican con ms detalle.
Regla
Primera Forma
Normal (1FN)
Segunda Forma
Normal (2FN)
Descripcin
Incluye la eliminacin de todos los grupos repetidos.
Asegura que todas las columnas que no son llave sean
completamente dependientes de la llave primaria (PK).
Elimina
cualquier
dependencia
transitiva.
Una
Tercera Forma
dependencia transitiva es aquella en la cual las
Normal (3FN)
columnas que no son llave son dependientes de otras

columnas que tampoco son llave.
Primera Forma Normal (1FN): Se dice que una relacin est en 1FN si y solo si
cada uno de los atributos tiene un nico valor para un registro determinado,
es decir, los dominios de esta relacin tienen valores nicos. Si una relacin
no est en primera forma normal hay que eliminar de ella los atributos que tienen
39
40
mltiples valores para cada tupla de la relacin. Estos se eliminan metindolos en

otra relacin y relacionndolos mediante la clave primaria de la relacin en la que
se encontraban.
Segunda Forma Normal (2FN): la segunda forma normal se basa en el concepto

de dependencia funcional total y compara todos y cada uno de los atributos de la
relacin con la clave primaria. Si todos los atributos dependen directamente de
esta clave se dice que la relacin est en segunda forma normal. La 2FN se
aplica a aquellas relaciones que tienen claves primarias compuestas por dos
o ms atributos. Si una relacin no est en 2FN hay que eliminar las
dependencias parciales de la clave primaria. Para ello se eliminan los atributos
que son funcionalmente dependientes y se ponen en una nueva relacin con una
copia de su determinante (los atributos de la clave primaria de los que dependen).
La regla de la Segunda Forma Normal establece que todas las dependencias
parciales se deben eliminar y separar dentro de sus propias tablas. Una
dependencia parcial es un trmino que describe a aquellos datos que no
dependen de la llave primaria de la tabla para identificarlos. Una vez alcanzado el
nivel de la Segunda Forma Normal, se controlan la mayora de los problemas de
lgica. Podemos insertar un registro sin un exceso de datos en la mayora de las
tablas.
Tercera Forma Normal (3FN): La tercera forma normal se basa en el concepto de

dependencia transitiva (ocurre cuando un atributo es funcionalmente dependiente
de otro y ningn de las dos formas parte de la clave) y se dice que una relacin
est en 3FN si y solo si los atributos de la relacin dependen nicamente de
la clave primaria, es decir, los atributos de la tabla no dependen unos de
otros. Para pasar una relacin 2FN a 3FN deben de eliminarse las posibles
dependencias transitivas eliminando los atributos que dependen transitivamente y
se ponen en una nueva relacin con una copia del atributo o atributos no clave de
41
los que dependen. Cuando las tablas estn en la Tercera Forma Normal se
previenen errores de lgica cuando se insertan o borran registros. Cada columna
en una tabla est identificada de manera nica por la llave primaria, y no debe
haber datos repetidos. Esto provee un esquema limpio y elegante, que es fcil de
trabajar y expandir.40
2.9 Seleccin del sistema gestor de base de datos

El SGBD a utilizar en el Sistema de Enlace de Convenios Municipales es
PostgreSQL; a solicitud del Instituto, ya que es uno de los manejadores utilizan.
La razn principal que motivo a elegir este manejador de BD es debido a que es
un Sistema de gestin de bases de datos relacional orientado a objetos y usado
en entornos de software libre, distribuido bajo la licencia BSD 41, lo que permite su
uso, redistribucin, modificacin con la nica restriccin de mantener el copyright
del software a sus autores, en concreto el PostgreSQL Global Development Group
y la Universidad de California.
Este manejador de BD cuenta con las siguientes caractersticas:
Funciona en mltiples plataformas (en general, en todas las modernas

basadas en Unix), tambin en Windows de forma nativa. Para las versiones
anteriores existen versiones binarias para este sistema operativo, pero no

tienen respaldo oficial.
La API de acceso al SGBD se encuentra disponible en C, C++, Java, Perl,

PHP, Python y TCL, entre otros.
Cuenta con un amplio conjunto de tipos de datos, permitiendo adems su

extensin mediante tipos y operadores definidos y programados por el
usuario.
Su administracin se basa en usuarios y privilegios.
40
41
Berkeley Software Distribution (en espaol, Distribucin de Software Berkeley)
42
Sus opciones de conectividad abarcan TCP/IP42, sockets Unix y sockets

NT, adems de soportar completamente ODBC43.
Soporte para vistas, claves forneas, integridad referencial, disparadores,

procedimientos almacenados, subconsultas y casi todos los tipos y
operadores soportados en SQL92 y SQL99.
Implementacin de algunas extensiones de orientacin a objetos (herencia).
Alta concurrencia: Mediante un sistema denominado MVCC 44, PostgreSQL

permite que mientras un proceso escribe en una tabla, otros accedan a la
misma tabla sin necesidad de bloqueos.45
42
Transmission Control Protocol (TCP) / Internet Protocol (IP).

Open DataBase Connectivity
44
Acceso concurrente multiversin
45
Worsley, J., & Drake, J. (2002). Practical PostgreSQL. Estados Unidos de America : OReilly.
43
43
C A P T U L O III
MARCO METODOLGICO
44
CAPITULO III
MARCO METODOLGICO
En ste captulo se abordarn los aspectos referentes a la metodologa utilizada

para el desarrollo del Sistema de Enlace de Convenios Municipales, la cual es
UP (Unified Process).46
En relacin con los conceptos planteados en el Marco Terico, dicha metodologa
se compone de las siguientes fases:
Modelo de negocio (Business
modeling)
Fase De Concepcin
Requisitos funcionales
(Requirements)
UP
(UNIFIED PROCESS)
Fase De Elaboracin
Analisis y diseo (Analysis and Desing)
Fase De Construccin
Implementacin (Implementation)
Pruebas (Test)
Fase De Transicion
Configuracion y administracion de
cambios (Configuration & change
manage)
Instalacin (Deployment)
Figura No. 11 Fases del Proceso Unificado (UP)
3.1
Fase de inicio
Durante la primera fase del desarrollo se contemplan las siguientes herramientas:
Documento de visin
46
Modelo de software que permite el desarrollo a gran escala, mediante un proceso continuo de pruebas y
retroalimentacin. Desarrollado por la empresa Rational Software, actualmente propiedad de IBM. La
primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten.
45
Especificacin de requerimientos
3.1.1 Documento de visin

El documento de visin es en esencia el equivalente a lo planteado en el Captulo
1 de este documento.
3.1.2 Especificacin de requerimientos
Para realizar el levantamiento de requerimientos, se realiz el documento de
Especificacin de Requerimientos del Sistema (SRS) en el cual se describe los
requisitos de alto nivel y las especificaciones funcionales.
3.1.2.1
Actores primarios
La siguiente es una lista de clientes interesados en diferentes reas dentro del

proyecto y los cuales harn uso del sistema y la informacin que proporcione.
rea
Actores Primarios
Unidad Jurdica
Lic. Iras T. Ruz Aquino
Unidad Tcnica
Coordinacin de
Enlace Municipal
Actores Secundarios
I.C. Christian M. Arvea

Reyes
Ing. Mateo Bentez Prez
I.C. Christian M. Arvea Reyes

Lic. Roberto Garca Hdz.
Coordinacin de
Arq. Erika Gisela Len
Arq. Jos Francisco Medina
Gestin Territorial
Aracn
Esteva
Departamento de
Atencin y Apoyo a
Municipios
Lic. Roberto G. Garca

Hernndez
Departamento de
Arq. Luz Marina Ortega
Valuacin
Martnez
Departamento de
Arq. Jos Francisco Medina
Valores Unitarios
Esteva
46
3.1.2.2 Requerimientos funcionales
3.1.2.2.1 Requerimientos funcionales primarios

Requerimientos esenciales
El sistema ser un portal Web.
El sistema proveer de informacin municipal dependiendo las necesidades

del solicitante.
El sistema proveer agendas de trabajo.
El sistema mostrar calendario de actividades y planes de trabajo a seguir.
El sistema generar reportes, los cuales podrn ser impresos.
El sistema dar aviso a los actores de alguna actividad en conjunto con los
municipios.
Requerimientos de alto valor
Mediante el portal web, las autoridades municipales podrn tener acceso a la

informacin del estado de colaboracin con el ICEO y conocer informacin
relevante para ellos.
Requerimientos opcionales
Se mostrar mediante una interfaz, los diferentes municipios e informacin

pertinente sobre ellos y las autoridades municipales.
47
3.1.2.2.2 Actores
Actor
Descripcin
Encargado de elaborar los diferentes convenios con los municipios
Jefe de la
del estado, dentro un marco jurdico. Adems de que ser la
Unidad Jurdica
encargada de dar solucin a todo problema jurdico que se

presente.
Jefe de la
Unidad Tcnica
Coordinador de
Enlace
Municipal
Jefe del Depto.

De Atencin y
Apoyo a
Municipios
Jefe del Depto.

de Valores
Unitarios
Tiene a cargo la impresin de las boletas de pago predial. Este

lleva un control de los folios de las boletas y a que municipio se
encuentran destinados.
Tiene a cargo toda la relacin que sostiene el ICEO con los
municipios, este elabora diversos proyectos municipales, adems
de crear citas para las diferentes actividades a realizar en conjunto
con las autoridades municipales.
Encargado de concentrar toda la informacin respecto a convenios
y actividades que cuenta el ICEO con los municipios del Estado de
Oaxaca. Adems de ser la encargada de establecer los vnculos
para que el Coordinador de Enlace Municipal lleve a cabo sus
actividades junto con las autoridades municipales.
Provee a los municipios diversos servicios catastrales, tales como
la zonificacin del territorio municipal para los diferentes valores de
uso de suelo, creacin de tablas de valor adems de
capacitaciones en materia catastral.
Provee la informacin necesaria para los cobros de impuestos en
Jefe del Depto.
movimientos de bienes inmuebles que maneja el ICEO y estos
de Valuacin
dependen de los convenios con los municipios, de acuerdo a su

impuesto de traslado de dominio.
Coordinador de
Encargado de llevar un control de actividades que realiza el ICEO
Gest. Territorial
en materia territorial.
48
3.1.2.2.3 Casos de uso

Nombre del caso
de uso
Prioridad
Nm
Descripcin
El usuario encargado del rea de Atencin y
Creacin de
Convenios
apoyo a municipios podr dar de alta los

datos correspondientes a la celebracin de
un convenio.
Las reas pertinentes podrn calendarizar
Calendarizacin
de Actividades
diferentes
programadas
actividades
con
que
cualquiera
tengan
de
los
municipios del estado.

Baja de
Convenios
Creacin de
Planes de Trabajo
deber ser dado de baja del sistema.

Las
reas
correspondientes
tendrn
la
posibilidad de crear planes de trabajo con

municipios.
Localizacin de
Municipios en
Cuando un convenio termine su vigencia
Mediante un mapa se podrn localizar los

F
mapa
municipios correspondientes al estado de

Oaxaca.
El departamento tcnico podr conocer a
Control de
impresin de
que municipios les fueron entregadas boletas

H
Boletas
de pago, cuando y cuantas fueron impresas,

as como los folios contenidos en los
paquetes entregados.
Consulta de
informacin
Los usuarios podrn realizar consultas en

cualquier momento que lo necesiten.
49
3.1.2.2.4
Requisitos detallados de casos de uso
Administracin de convenios municipales

Cdigo
Descripcin del requerimiento
Req.
El usuario encargado del rea de Atencin y Apoyo a municipios podr dar

E1-1
de alta los datos correspondientes a la celebracin de un convenio y

actualizar los datos.
E1-2
Un municipio puede tener un tipo de convenio en especfico, de lo cual

depender su vigencia.
El jefe del Departamento de Atencin y apoyo a municipios dar de alta
E1-3
datos a cerca de un convenio: Delegacin, clave del municipio, municipio,

tipo d convenio, integraciones gratuitas, % de cobro de traslado de dominio,
% al estado y vigencia.
F3-1
Al momento de que un convenio termine su vigencia deber ser dado de

baja del sistema.
Cuando
F3-2
el
convenio
culmine
deber
ser
notificado
las
reas
correspondientes que hacen uso de la informacin, esto mediante una alerta

o correo electrnico.
F3-3
H6-1
E7-1
Cuando se realicen consultas de aquellos municipios que cuentan con

convenio no debern aparecer aquellos que ya vencieron.
De acuerdo al tipo de convenio con que cuente un municipio podr realizar
la impresin de Boletas de Pago
Los actores podrn realizar consultas en cualquier momento que lo
necesiten.
Se obtendr acceso a la informacin de los convenios mediante consultas
E7-2
de acuerdo a: Tipo de convenio, Delegacin catastral, Estado del convenio y

si realiza o no cobro de Traslado de Dominio.
50
Agendas de trabajo con municipios

Cdigo
Req.
E2-1
Las diferentes reas podrn calendarizar diferentes actividades que tengan

programadas con cualquiera de los municipios del estado.
Gestionar las reuniones, capacitaciones, asesoras con las autoridades
E2-2
municipales
mediante
agendas
de
trabajo,
generando
un
entorno
colaborativo, para que todo cambio en un plan de trabajo se d a conocer a

los participantes del mismo.
E2-3
F5-1
F5-2
E7-1
Gestionar proyectos municipales, en los cuales se definirn tareas y

asignarn responsables de las mismas.
Mediante un mapa se podrn localizar los municipios correspondientes al
estado de Oaxaca.
Localizar en un mapa los municipios del Estado, donde se podr acceder a
los datos correspondientes del mismo.
Los actores podrn realizar consultas en cualquier momento que lo
necesiten.
51
3.1.2.3
Requerimientos no funcionales
Rendimiento: Este sistema no requerir importantes demandas en el hardware.
Cdigo
Req.

En relacin con la creacin de convenios, por lo general la demanda de
estos se realiza en los primeros meses del ao, y como estos se llevan
E1 101
reuniones para su celebracin, pueden celebrarse 1 o 2 al da a lo mucho,

esto implica que el sistema no sea demandado en cuestin de registros de
convenios, ya que pueden no realizarse muchos durante el ao.
E4 101
E1 102
Los Planes de trabajo con municipios solo permitirn que un usuario a la

vez cree, modifique o elimine alguna actividad programada.
La captura de convenios no debe ser muy tardada, ya que se contara con
una interfaz que facilite la actividad por parte del encargado del rea.
Escalabilidad: En un futuro este sistema permitir a los municipios poder crear

eventos para el trabajo en conjunto con el Instituto. Ya que por el momento solo
podrn visualizar informacin de los calendarios de actividades y agendas.
Cdigo
Req.
E4 -104

Los Planes de trabajo con municipios debern soportar al menos 20 usuarios
a la vez, eso incluyendo conexiones fuera del instituto.
52
Disponibilidad
Cdigo
Req.
Los Planes de trabajo con municipios estarn disponibles las 24 horas los
E4 101
365 das del ao. Solo se apagara si se necesita algn tipo de

mantenimiento o si existiera alguna falla elctrica.
Confiabilidad
Cdigo
Req.
Para la creacin de actividades dentro de los Planes de trabajo con

E4 102
municipios, se controlar que solo los Coordinadores puedan crear,

modificar o eliminar alguna actividad.
Reglas de Integridad de Datos:
E1 103
Un convenio debe estar asociado a un municipio.
Un convenio no puede tener datos faltantes.
En el control de impresin de boletas de pago predial, solo se podrn

H6 101 imprimir estas, cuando un municipio tenga este tipo de servicio por parte del
Instituto.
Para un control de los convenios, se creara una clave compuesta la cual
E1 104
contendr: siglas significativas que representen el tipo de convenio, nmero

de municipio y ao de celebracin del convenio, evitando duplicidad.
E1 105
Solo se podrn crear convenios con cualquiera de los 570 municipios del
Estado de Oaxaca.
53
Seguridad
Cdigo
Req.
Para ingresar al sistema el usuario tendr que iniciar sesin mediante su

E7 101
RFC, el cual se validara haciendo una consulta a la base de datos utilizado

por el usuario ser autenticado por el mismo nombre de usuario y
contrasea.
La Administracin de convenios municipales deber configurar sus mens
para aclarar que las caractersticas del sistema son accesibles para la
E7 102
funcin del usuario actual. Esto se har mediante la desactivacin de

caractersticas GUI (como elementos de men y botones) que no estn
autorizados para la funcin del usuario actual.
E7 103
E4 103
Solo el administrador del sistema podr crear nuevos usuarios con sus
respectivos privilegios.
La Agenda de trabajo con los municipios, se registrara quien y la fecha con
la que se haya creado un evento, reunin y dems actividades.
Capacidad de administracin
Cdigo
Req.
E4 104
E1 106
F3 101
E7 104
La Agenda de trabajos con los municipios ser lanzado mediante

plataforma Web.
La Administracin de convenios municipales ser lanzado mediante
plataforma Web.
54
Usabilidad
Cdigo
Req.
E1 107
La interfaz de Administracin de convenios municipales se basara en los

estndares establecidos por el W3C.
F5 101
Para la localizacin de los municipios se utilizara el API de Google Maps.
H2 101
Para el calendario de actividades se utilizara una librera de Groovy &
E4 105
Grails.
3.2 Fase de elaboracin

Durante la fase de elaboracin se contemplan las siguientes herramientas:
Especificacin de casos de uso
Diagramas de caso de uso
Diseo de la base de datos
3.2.1 Especificacin de casos de uso

Por medio de esta herramienta de modelado, se obtendr una mejor visin del
proceso.
Administracin de convenios municipales

Id caso de uso
E1- Registro de convenios municipales
y nombre
Descripcin
Actores
Prioridad
Pre-condicin
Caso de uso para realizar el registro de los datos de un convenio

celebrado entre el Instituto y un Municipio.
Primario: Jefe del Departamento de Atencin y Apoyo a Municipios
Esencial
El Jefe del Depto. De atencin y apoyo a municipios acceder al
sistema mediante un usuario y contrasea para hacer el registro de
55
un convenio.
Evento
disparador
Celebracin de un convenio entre el ICEO y un municipio del Estado

de Oaxaca.
1. Despus de iniciar sesin en el sistema acceder al men donde
se encontrara la opcin de Nuevo convenio.
2. Se dirigir a una nueva interfaz donde se seleccionar mediante
una lista desplegable el municipio o en su defecto har una
bsqueda por nombre del municipio.
3. El sistema validar si existe un convenio vigente en el municipio
seleccionado.
Flujo de
eventos
4. En caso de no existir podr realizar el registro del convenio,

mediante la opcin Registrar convenio.
5. El usuario seleccionar el tipo de convenio, el cual habilitara los
campos de registro dependiendo de los datos necesarios para
dicho convenio seleccionado.
6. Posteriormente una vez registrados los datos deber dar clic en
la opcin Guardar para que los registros del convenio sean
agregados a la base de datos.
7. El sistema mostrara un mensaje, el cual indicara que los datos
has sido guardados correctamente.
a) El usuario puede realizar la captura de otro convenio si existiera
Flujo
alternativo
u otra actividad a la que tenga acceso durante su sesin.

b) En cualquier momento puede salir del sistema, mediante un
botn Salir.
Postcondiciones
Se mostrara la pantalla principal del sistema, para una nueva accin,

si as se requiere.
Requerimientos
E1-1
funcionales
E1-3
Requerimientos
E1 101 (Rendimiento)
no funcionales
E1 102 (Rendimiento)
56
E1-2
E1 103 (Confiabilidad)
Id caso de uso
E2 - Baja de convenios municipales
y nombre
Descripcin
Actores
Prioridad
Pre-condicin
Evento
disparador
Caso de uso para realizar la cancelacin o baja de un convenio.

Esencial
El Jefe del Depto. De atencin y apoyo a municipios acceder al sistema
mediante un usuario y contrasea para realizar la baja de un convenio.
Cancelacin o vencimiento de un convenio entre el ICEO y un municipio
del Estado de Oaxaca.
1. Despus de entrar al sistema acceder al men donde se encontrara
la opcin de Cancelar convenio.
2. Mediante la bsqueda ya sea por:
a. Tipo de convenio
b. Delegacin catastral
Flujo de
eventos
c. Si cobra o no Traslado de Dominio

El Jefe del Depto. Podr localizar el convenio a ser cancelado.
3. Posteriormente deber dar clic en la opcin Dar de baja para que
los registros del convenio sean eliminados de la base de datos.
4. El sistema mostrara un mensaje pidiendo la confirmacin para poder
eliminar.
5. El sistema mostrara un mensaje emergente donde indicara que el
convenio se ha dado de baja correctamente.
a) El convenio puede ser dado de baja sin necesidad de que el Jefe del
Flujo
alternativo
Depto. realice la eliminacin del mismo, ya que cuando vence se

elimina automticamente.
b) En cualquier momento puede salir del sistema, mediante un botn
Salir.
Postcondiciones
Se mostrar la pantalla principal del sistema para una nueva accin, si

as se requiere.
F3-1
Requerimientos
F3-2
funcionales
F3-3
E7-1
57
Id caso de uso
E3 - Consulta de informacin
y nombre
Caso de uso para realizar consulta de informacin por parte de las

Descripcin
diferentes reas que necesitan de la misma, de los convenios

celebrados entre el ICEO y los municipios del Estado.
Secundarios:
Coordinacin de enlace municipal.
Actores
Unidad jurdica.
Departamento Tcnico
Coordinacin de gestin territorial
Departamento de valuacin
Prioridad
Esencial
Los usuarios correspondientes accedern al sistema mediante un
Pre-condicin
usuario y contrasea para hacer la consulta de informacin que

necesiten.
Evento
disparador
Consultar informacin o datos especficos de un convenio por parte

de las diferentes reas del ICEO, que resulta relevante para llevar a
cabo sus actividades.
1. Despus de acceder al mismo acceder al men donde se
encontrara la opcin de Consulta de informacin.
2. Mediante la bsqueda ya sea por:
a. Tipo de convenio
Flujo de
b. Delegacin catastral
eventos
c. Si cobra o no Traslado de Dominio

3. Posteriormente
deber
dar clic en
la
opcin
Consultar
informacin.
4. Mostrar la informacin mediante una interfaz amigable, donde el
usuario podr visualizar los datos o generar un reporte.
Flujo
a) El usuario durante su sesin podr realizar diferentes consultas o
58
alternativo
actividades segn sean sus permisos de usuario.

b) En cualquier momento puede salir del sistema, mediante un
botn Salir.
Postcondiciones
La informacin ser mostrada mediante una interfaz amigable,

donde el usuario podr visualizar los datos.
Se mostrar la pantalla principal del sistema para una nueva

accin, si as se requiere.
Requerimientos
E7-1
funcionales
E7-2
Requerimientos
E7 101 (Seguridad)
no funcionales
E7 102 (Seguridad)
59
Id caso de
H4 - Control de impresin de boletas
uso y nombre
El departamento tcnico podr llevar el control de a que municipios ya

Descripcin
les fueron entregadas las boletas de pago, cuando y cuantas fueron

impresas.
Principal: Encargado del rea Tcnica.
Actores
Secundarios:
Personal del rea tcnica
Encargados del control e impresin de boletas
Prioridad
Pre-condicin
Evento
disparador
Alto Valor
El encargado ha iniciado sesin y tiene permiso para la entrega y
control de boletas
Las autoridades municipales solicitan la impresin de boletas de pago
predial de su municipio.
1. En encargado del rea, dentro de la interfaz del sistema, podr
consultar que municipios cuentan con este servicio.
2. El usuario seleccionar de la lista de municipios, el municipio del
cual se imprimirn las boletas. Y le dar clic en la opcin Iniciar.
3. Se mostrara una nueva interfaz llamada Corte de Folios, el
usuario podr ingresar los diferentes rangos de valores que
tendrn los folios de las boletas que sern impresas, Y dar clic
Flujo de
eventos
en Guardar Folios.
4. En la parte inferior de la interfaz se irn acumulando la cantidad
de boletas que se han impreso y mostrar el total de las mismas.
5. Una vez terminado el proceso de captura de folios, el usuario le
dar Guardar
6. El sistema regresara a la interfaz inicial.
7. En la opcin llamada Empaquetamiento, el usuario deber
ingresar el ID de la actividad. Y dar clic en Empaquetar.
8. En una nueva interfaz el usuario podr ingresar mediante un
60
formulario cuantos paquetes de boletas se han empaquetado,

cuantas boletas contiene cada paquete y los rangos de folios de
cada uno. El usuario dar clic al botn Guardar para finalizar
este proceso.
9. El sistema regresar al men principal.
10. El usuario dar clic a la opcin de Generar Oficio de Entrega.
11. Dentro de esta interfaz el usuario podr crear un oficio de entrega
con los datos pertinentes para la entrega, tales como nombre de
quien recibe, municipio y dems datos.
12. Dar clic al botn de imprimir para generar dicho oficio.
13. El sistema mostrara una interfaz donde se podr visualizar el
oficio antes del imprimirlo.
Flujo
alternativo
Req. funcional
Req. no
funcio.
Si el encargado quiera solicitar la impresin de boletas de un

municipio que no cuente con el servicio de impresin, el sistema lo
alertara y solo tendr habilitado el botn de salir.
H6-1
H6 101 ( Confiabilidad )
61
Id caso de uso
E5 - Creacin de agendas y planes de trabajo
y nombre
Descripcin
Las reas pertinentes tendrn la posibilidad de crear agendas y

planes de trabajo detalladas para el trabajo en los municipios.
Principal: Coordinador de Enlace Municipal, Coordinador de Gestin
Territorial
Actores
Secundarios:
Jefe de Departamento de Apoyo y Atencin de Municipios,
Jefe de Departamento de Valores Unitarios
Jefe de Departamento Tcnico.
Prioridad
Pre-condicin
Evento
disparador
Esencial
El usuario a iniciado sesin, y este tiene permiso para crear agendas
y planes de trabajo.
Se necesita crear un plan de trabajo con un municipio del estado
para poder entablar una relacin con este.
1. El sistema mostrar un men donde habr varias opciones, el
usuario le dar clic al botn de Crear.
2. Esta opcin mostrar una interfaz, donde el usuario podr
ingresar el nombre del plan de trabajo, mediante una opcin
podr seleccionar cuantos participantes habr en dicho plan de
trabajo, se le dar el botn de Siguiente.
Flujo de
eventos
3. En la siguiente interfaz se ingresara la descripcin de las

actividades y el nmero que se van a realizar. Una vez llenados
estos campos, el usuario le dar clic al botn Siguiente.
4. En la siguiente interfaz aparecern las actividades y mediante
un Combo Box se podrn asignar los diferentes actores
(personas que desarrollarn la actividad), as como la fecha de
inicio y duracin de la misma.
5. Ya finalizado el paso anterior, el usuario le dar clic en Guardar
6. El sistema pedir una confirmacin, donde solicitara el usuario
62
que revise la informacin.

7. El usuario confirmara que la informacin sea la correcta y le dar
clic al mensaje emergente.
El usuario podr darle el botn de Cancelar cuando quiera en el
Flujo
proceso de la creacin del plan de trabajo, pero al hacer esto
alternativo
aparecer un mensaje emergente indicando si est seguro de

cancelar.
El sistema guardar el nuevo evento, lo asociar con quien lo crea,
Post-
sus participantes, mostrar una descripcin del evento y las
condiciones
diferentes actividades a realizar y quienes han sido asignados a las

mismas.
Requerimientos
no funcionales
E4 101 ( Disponibilidad )
E4 102 ( Confiabilidad )
E4 103 ( Seguridad )
E4 104 ( Capacidad de Administracin)
E4 105 ( Usabilidad )
63
Id caso de uso
E6 - Consulta de informacin
y nombre
Caso de uso para realizar consulta de informacin por parte de las

Descripcin
diferentes reas que necesitan de la misma, de los convenios

celebrados entre el ICEO y los municipios del Estado.
Primario: Coordinador de Enlace Municipal, Coordinador de Gestin
Territorial
Actores
Prioridad
Pre-condicin
Evento
disparador
Secundarios:
Jefe de Departamento de Apoyo y Atencin de Municipios
Jefe de Departamento de Valores Unitarios
Jefe de Departamento Tcnico.
Esencial
El usuario se ha loggeado en el sistema y entrado a la aplicacin de
Agendas de Trabajo con Municipios.
El usuario necesita conocer algn plan de trabajo con algn municipio
que se tiene inters.
1. El usuario una vez loggeado, seleccionara el botn Visualizar
informacin
Flujo de
eventos
2. Una vez dentro, en la interfaz se podr visualizar las diferentes

agendas y planes de trabajo creadas.
3. El usuario seleccionara la agenda o plan que desee y podr
visualizar
actividades, fechas y duracin de agenda o plan
seleccionado
Flujo
alternativo
El usuario puede salir al men principal del sistema, mediante el

botn Salir.
Post-
El usuario tendr conocimiento de las actividades que se han
condiciones
realizado, las que se estn realizando en este momento y las futuras.
Requerimientos
E7-1
funcionales
E7-2
Requerimientos
E7 101 (Seguridad)
no funcionales
E7 102 (Seguridad)
64
3.2.2 Diagramas de casos de uso

A continuacin se muestran los diagramas de casos de uso del sistema a desarrollar.
Figura No. 12 Caso de uso #1 Convenios municipales
65
Figura No. 13 Caso de uso #2 Planes de trabajo
66
Figura No. 14 Caso de uso #3 Boletas de pago
67
3.2.3 Diseo de la base de datos

3.2.3.1
Modelo entidad - relacin
Figura No. 15 Diagrama entidad-relacin de la aplicacin
68
3.2.3.2
Modelo relacional
Figura No. 16 Diagrama relacional de la aplicacin
69
3.2.3.3
Diccionario de datos
NOMBRE DE
LA TABLA
ACTIVIDAD
AREA
AUTORIDAD_MPAL
BITACORA
CARGO
CONV_MUN
NOMBRE DEL
ATRIBUTO
Id_actividad
Nombre_act
Descripcion
Tipo
Id
Area
Id
Rfcaut
Nombre
A_paterno
A_materno
Telfono
Idcargo
Email
Status
Clave_mpio
Fecha_nacimiento
Fecha_inicio
Fecha_fin
Id
Version
Accion
Empleado_id
Fecha
Id
Cargo
Claveconvenio
CONTENIDO
El identificador de la actividad
Nombre de la actividad
Descripcin de la actividad
El tipo de actividad que es
El identificador del rea de adscripcin
El nombre del rea de adscripcin
El identificador de la autoridad municipal
RFC de la autoridad municipal
Nombre de la autoridad municipal
Apellido paterno de la autoridad municipal
Apellido materno de la autoridad municipal
Telefono de la autoridad municipal
Cargo que desempea la autoridad mpal
Correo electrnico de la autoridad mpal
Estado ( Activo o Inactivo ) de la autoridad
Clave del municipio que rige la autoridad
Fecha de nacimiento de la autoridad
Fecha de inicio del cargo
Fecha del fin del cargo
Identificador de la actividad en bitcora
Numero de modificaciones del registro
Accion que se ha realizado
Identificador del empleado
Fecha del registro
El identificador del cargo
El nombre del cargo o puesto de una
autoridad municipal
Clave del convenio celebrado
70
TIPO
Serial
Varchar (50)
Varchar (250)
Int
Serial
Varchar (100)
Serial
Varchar (10)
Varchar (30)
Varchar (30)
Varchar (30)
Varchar (10)
Int
Varchar (50)
Boolean
Varchar (3)
Date
Date
Date
Bigint
Bigint
Varchar (25)
Int
Timestamp
Serial
Varchar (100)
Varchar (10)
PK
O
FK
PK
FK
PK
TABLA DE
REFERENCIA
Tipo_Actividad
PK
FK
Cargo
FK
Municipio
PK
FK
Empleado
PK
FK
Convenio
CONVENIO
DELEGACIONCAT
EMPLEADO
ETIQUETA
MUNICIPIO
Clave_mpio
Fecha_inicio
Fecha_fin
Indeterminado
Status
Claveconvenio
Tipoconvenio
Trasladodominio
Integracionesgrat
Porcentajetd
Porcentajeedo
Clave_delgcat
Nombre_delgcat
Clave del municipio

Fecha de inicio del convenio
Fecha de fin del convenio
Si el convenio no tiene vigencia
Status del convenio
Clave del convenio celebrado
Tipo de convenio
Impuesto traslativo de dominio
Permiso para integraciones gratuitas
Porcentaje que se paga por traslado de dom
Porcentaje que se paga al estado
Clave de la delegacin catastral
Nombre de la delegacin catastral
Varchar (3)
Date
Date
Boolean
Boolean
Varchar (100)
Int
Boolean
Boolean
Double
Double
Serial
Varchar (50)
Nue
Rfc_empleado
Nombre
A_paterno
A_materno
Fecha_nacimiento
Id_area
Email_emp
Telfono
Status
Id
Version
Cabecera
Dir_catastro
Jefe_unidad_tecnica
Lic_boletas
Pie_pagina
Sec_finanzas
Clave_mpio
Nombrempio
Rfcmpio
Numero nico de empleado

Rfc del empleado
Nombre del empleado
Apellido paterno del empleado
Apellido materno del empleado
Fecha de nacimiento del empleado
Identificador del rea de adscripcin
Correo electrnico del empleado
Telefono del empleado
Status del empleado dentro del instituto
Identificador de la etiqueta
Version de modificacin
Cabecera del documento
Director de catastro
Jefe de la unidad tcnica
Licenciado encargado de las boletas
Pie de pgina del documento
Secretario de finanzas
Clave del municipio
Nombre del municipio
Rfc del municipio
Serial
Varchar (10)
Varchar (30)
Varchar (30)
Varchar (30)
Date
Int
Varchar (50)
Varchar (10)
Boolean
Bigint
Bigint
Varchar (255)
Varchar (255)
Varchar (255)
Varchar (255)
Varchar (255)
Varchar (255)
Varchar (3)
Varchar (100)
Varchar (13)
71
FK
Municipio
PK
FK
Tipo_convenio
PK
PK
FK
PK
PK
Area
OBSERVACION
PAQUETE
PAQUETE_MPIO
PLAN_ACT_EMP
Clave_delgcat
Id_region
Id
Version
Actividad_id
Comentario
Empleado_id
Escritor_id
Fecha
Plan_municipal_
municipio_id
Plan_municipal_plan_
id
Id_paquete
Fecha_empaquetamie
nto
Ejercicio
Clave_mpio
Id_paquete
Fecha_entrega
Observacin
Pr_nombre
Pr_apaterno
Pr_amaterno
Nue
Id_actividad
Fecha_inicio
Fecha_fin
Status
Hr_inicio
Hr_fin
Tipo
Plan_municipal_munici
pio_id
Plan_municipal_plan_i
d
Identificador de la delegacin catastral

Identificador de la region
Identificador de la observacin
Version de modificacin
Identificador de la actividad
Comentario acerca de la actividad
Identificador del empleado
Identificador del escritor
Fecha de la observacin
Identificador del municipio
Int
Int
Bigint
Version
Int
Varchar (1000)
Int
Int
Date
Varchar (3)
FK
FK
Identificador del plan municipal
Varchar (15)
FK
Identificador del paquete

Fecha en que sea crea el paquete y se
ingresan la serie
Ao en curso de la creacin
Clave del municipio
Fecha de entrega del paquete
Observacin de la entrega
Nombre de la persona que recibe
Apellido paterno de la persona que recibe
Apellido materno de la persona que recibe
Numero nico de empleado
Identificador de la actividad
Fecha de inicio de la actividad
Fecha de fin de la actividad
Status de la actividad en curso
Hora de inicio de la actividad
Hora de fin de la actividad
Tipo de la actividad que se est realizando
Identificador del municipio
Int
Date
PK
Int
Varchar (3)
Int
Date
Varchar (200)
Varchar (30)
Varchar (30)
Varchar (30)
Int
Int
Date
Date
Boolean
Time
Time
Int
Varchar (3)
FK
Plan_municipal
Varchar (15)
FK
Plan_municipal
72
FK
FK
FK
FK
Delegacioncat
Region
Plan_act_emp
Plan_act_emp
Empleado
Plan_act_emp
Plan_act_emp
FK
FK
Municipio
Paquete
FK
FK
Empleado
Actividad
PLAN_MUNICIPAL
PLAN_TRABAJO
REGION
ROLE
SERIE
TIPO_ACTIVIDAD
TIPOCONVENIO
USER_ROLE
USUARIO
Id
Clave_mpio
Id_plan
Fecha_inicio
Fecha_fin
Id_plan
Nombre_plan
Descripcin
Fecha_creacion
Ejercicio
Id
Region
Id
Version
Authority
Descripcion
Id
Folio_inicial
Folio_final
Id_paquete
Id
Tipo
Id
Tipo
Role_id
User_id
Id
Version
Account_expired
Account_locked
Enabled
Password
Password_expired
Username

Clave del municipio
Identificador del plan al que pertenece
Fecha de inicio del plan municipal
Fecha de fin del plan municipal
Identificador del plan
Nombre del plan
Descripcin del plan
Fecha de creacin del plan
Ao que se realizara el plan
Identificador de la regin
Nombre de la regin
Identificador del rol
Versin de modificacin del rol
Tipo de autorizacin
Descripcin del rol
Identificador de la serie
Folio inicial de las boletas
Folio final de las boletas
Identificador del tipo de actividad
Nombre del tipo de la actividad
Identificador del tipo del convenio
Nombre del tipo de convenio
Identificar del rol
Identificador del usuario
Identificador del usuario
Version de modificacin del usuario
Si el usuario puede expirar
Si el usuario puede estar bloqueado
Si el usuario est habilitado
Contrasea del usuario
Si la contrasea del usuario expira
Nombre del usuario
73
Int
Varchar (3)
Varchar (15)
Date
Date
Varchar (15)
Varchar (50)
Varchar (500)
Date
Int
Int
Varchar (40)
Bigint
Bigint
Varchar (255)
Varchar (255)
Int
Bigint
Bigint
Int
Int
Varchar (50)
Int
Varchar (80)
Bigint
Bigint
Bigint
Bigint
Boolean
Boolean
Boolean
Varchar (255)
Boolean
Varchar (255)
PK
FK
FK
Municipio
Plan_Trabajo
PK
PK
PK
PK
FK
PK
Paquete
PK
FK
FK
PK
Role
User
3.3
Fase de construccin
Durante esta fase se contemplan las siguientes herramientas:
Diagramas de actividad
Codificacin del sistema
3.3.1 Diagramas de actividad
Figura No. 17 Diagrama de actividad: Registro de convenios municipales
74
Figura No. 18 Diagrama de actividad: Baja de convenios municipales
75
Figura No. 19 Diagrama de actividad: Consultar informacin
76
Figura No. 20 Diagrama de actividad: Control de impresin de boletas
77
Figura No. 21 Diagrama de actividad: Crear agendas y planes de trabajo
78
3.3.2 Codificacin del sistema

La codificacin del sistema ser realizada con Groovy & Grails, siendo Grails un
framework para aplicaciones web libre desarrollado sobre el lenguaje de
programacin Groovy, basado en la plataforma Java. Para el almacenamiento de
datos ser utilizado el SGBD PostgreSQL.
As tambin se utilizaran:
Diferentes libreras que provee el lenguaje de programacin seleccionado.
El framework Bootstrap, el cual ser de gran ayuda para facilitar el diseo

de la interfaz y esta sea lo ms amigable para el usuario final,
JVectorMap, un pluggin para construir mapas interactivos.
API de Google Maps, que ser utilizada para la localizacin de los

municipios mediante marcadores.
3.4
Fase de transicin
Durante esta fase y para comprobar el funcionamiento del cdigo del sistema se
tomaran en cuenta las siguientes pruebas:
Prueba de integracin: Consisten en una progresin ordenada de pruebas

para los cuales los distintos mdulos van siendo ensamblados y probados
hasta haber integrado el sistema completo.
Pruebas de
sistema:
Se
realizan
una vez integrados todos los
componentes. Su objetivo es ver la respuesta del sistema en su conjunto,

frente a distintas situaciones.
Pruebas de aceptacin: Se realizan sobre el producto terminado e

integrado; estn concebidas para que sea un usuario final quien detecte los
posibles errores.
Pruebas de carga: Se realiza para observar el comportamiento de

una aplicacin bajo una cantidad de peticiones esperada.
79
CONCLUSIONES
Como resultado de la elaboracin del Sistema de Enlace de Convenios

Municipales, se tiene la seguridad que ayudar ampliamente al Instituto Catastral
del Estado de Oaxaca, debido a la automatizacin del control de la informacin
que se maneja dentro del ICEO en materia de Convenios Municipales, gracias a
este ya no ser necesario que el encargado del rea de convenios est presente,
logrando que se pueda consultar la informacin necesaria, esto repercutir mucho
al inicio de ao, debido a que muchos convenios expiran el primer da del ao,
gracias a que el sistema dar de baja automticamente los convenios vencidos,
ser mucho ms sencillo el saber cules siguen activos y as acelerar la
elaboracin de rdenes de pago. Otro punto importante de este sistema es que al
tener la informacin de los convenios, elimina la tediosa tarea de elaborar
memorndums o documentos por escrito para dar a conocer la informacin.
La agenda que se implement ser de gran ayuda para darle un seguimiento

adecuando a la relacin del ICEO con los diferentes municipios del estado. Ya que
permite que los Coordinadores creen y asignen actividades a los diferentes
empleados para que estos las lleven a cabo, logrando un control adecuado. Esto a
futuro ser de gran beneficio, se olvidaran de las agendas convencionales, y al
estar en el sistema todas las actividades que se han realizado, se evitara volver a
realizar la misma actividad, logrando una mejor atencin para el municipio.
En un futuro se pretende extender la funcionalidad del sistema as como su

alcance, ya que el Instituto tiene ms necesidades que pueden ser superadas
mediante herramientas como esta.
El realizar la Residencia Profesional, fue una experiencia enriquecedora y de gran

aprendizaje, porque para realizar el trabajo es necesario adaptarse a lo que se
80
solicita, y eso impulsa a la bsqueda y auto aprendizaje. Debido a que muchas

veces como residente es necesario aprender nuevos lenguajes de programacin,
frameworks, diferentes manejadores de base de datos, entre otros conocimientos;
que muchas veces no son adquiridas en el aula de estudio. Para fines de este
proyecto fue necesario el aprendizaje del lenguaje Groovy juntamente con el
framework Grails, as tambin las libreras con las que cuenta y que seran de
ayuda para el sistema.
Por ltimo, la residencial profesional ayuda a conocer el ambiente laboral, ser

responsable y tener mente abierta para la solucin de los diferentes retos que
implica este ambiente.
81
GLOSARIO
API: API es la abreviatura de Aplication Programming Interface. Un API no es ms

que una serie de servicios o funciones que el Sistema Operativo ofrece al
programador, como por ejemplo, imprimir un carcter en pantalla, leer el teclado.
Visto desde la perspectiva del cdigo mquina, el API aparece como una serie de
llamadas, mientras que si lo vemos desde la de un lenguaje de alto nivel, el API
aparece como un conjunto de procedimientos y funciones.
Backup: Palabra inglesa que en mbito de la tecnologa y de la informacin, es
una copia de seguridad o el proceso de copia de seguridad. Backup se refiere a la
copia y archivo de datos de la computadora de modo que se puede utilizar para
restaurar la informacin original despus de una eventual prdida de datos.
Bit: Se utiliza para nombrar a una unidad de medida de informacin que equivale
a la seleccin entre dos alternativas que tienen el mismo grado de probabilidad.
Bytecode: Es un archivo binario que contiene un programa ejecutable, Java utiliza

este tipo de tecnologa, los bytecode son interpretados por la JVM (Java Virtual
Machine o Mquina Virtual de Java), tambin conocido como Java Runtime
Enveroment, la cual est disponible para diferentes sistemas.
CPU: El CPU o Central Processing Unit (Unidad de Procesamiento Central en

espaol) es la parte central de toda computadora ya que es la que cumple la tarea
de procesamiento de todas las funciones as como tambin de almacenamiento de
la informacin. Es un circuito electrnico que ha existido desde siempre en las
computadoras sin importar su modelo y es por eso que es considerado uno de los
elementos bsicos de cualquier computador.
82
Framework: Un Framework ofrece componentes como una librera, pero adems

provee de plantillas o esqueletos que definen el funcionamiento de las
aplicaciones.
Groovy: Lenguaje de programacin orientado a objetos para la plataforma Java.
Es un lenguaje dinmico con caractersticas similares a las de Python, Ruby, Perl
y Smalltalk. Puede ser utilizado como un lenguaje de programacin para la
plataforma Java..
Hardware: La Real Academia Espaola define al hardware como el conjunto de

los componentes que conforman la parte material (fsica) de una computadora. En
el caso de la informtica y de las computadoras personales, el hardware permite
definir no slo a los componentes fsicos internos (disco duro, placa madre,
microprocesador, circuitos, cables, etc.), sino tambin a los perifricos (escner,
impresoras).
Input: Conjunto de dispositivos y seales que permiten la introduccin de
informacin en un sistema y los datos y programas que se introducen.
Iteracin: La iteracin consiste en reiterar o repetir un conjunto de instrucciones o
acciones con uno o varios objetivos
Java: Java es una tecnologa que se usa para el desarrollo de aplicaciones que
convierten a la Web en un elemento ms interesante y til. Java no es lo mismo
que JavaScript, que se trata de una tecnologa sencilla que se usa para crear
pginas web y solamente se ejecuta en el explorador.
Output: Este trmino es de uso frecuente en el mbito de la informtica para

referirse a los datos resultantes de un proceso. Un output o salida est constituido
83
por la informacin que es emitida por un sistema informtico. Esto quiere decir que
los datos en cuestin salen del sistema, ya sea a travs de un formato digital.
Sistema de Informacin: Un sistema de informacin se puede definir tcnicamente
como un conjunto de componentes relacionados que recolectan (o recuperan),
procesan, almacenan y distribuyen informacin para apoyar la toma de decisiones
y el control en una organizacin.
Sistema Operativo: El conjunto de programas informticos que permite la
administracin eficaz de los recursos de una computadora es conocido como
sistema operativo o software de sistema. Estos programas comienzan a trabajar
apenas se enciende el equipo, ya que gestionan el hardware desde los niveles
ms bsicos y permiten adems la interaccin con el usuario.
Sistema: Conjunto de elementos relacionados entre s y que funcionan como un

todo. Procede del latn systma, y este del griego (systema, identificado
en espaol como 'unin de cosas de manera organizada').
Software: Conjunto de programas, instrucciones y reglas informticas que

permiten ejecutar distintas tareas en una computadora. Se considera que el
software es el equipamiento lgico e intangible de una computadora. En otras
palabras, el concepto de software abarca a todas las aplicaciones informticas,
como los procesadores de textos, las planillas de clculo y los editores de
imgenes.
Usuario: El diccionario de la Real Academia Espaola (RAE) define el concepto
de usuario con simpleza y precisin: un usuario es quien usa ordinariamente algo.
El trmino, que procede del latn usuarius, hace mencin a la persona que utiliza
algn tipo de objeto o que es destinataria de un servicio, ya sea privado o pblico.
84
Web: El concepto se utiliza en el mbito tecnolgico para nombrar a una red

informtica y, en general, a Internet (en este caso, suele escribirse como Web, con
la W mayscula). Es importante establecer que este trmino adems forma parte
de lo que se conoce como World Wide Web que es la red informtica que se
emplea en todo el mundo.
85
BIBLIOGRAFIA
a. Libros
[ALON05]. Alonso Amo, F., Martnez Normand, L., & Segovia Prez, F. J.;
Introduccin a la Ingeniera de Software, Modelos de desarrollo de programas.
Delta publicaciones, Madrid (2005), pp. 31-33; 84-7356-375-1.
[BARC07]. Barclay, K., & Savage, J.; Groovy Programming an introduction for
Java Developers. Elsevier , San Francisco, CA (2007), pp. 1-3; 978-0-12-372507
[BRIT09]. Brito, I.. Manual de desarrollo web con GRAILS. Ediciones giles ,
Madrid (2009), pp. 1, 40-47 ; 978-84-613-2651
[CAST00]. Castao, A., & Piattini Velthuis, M. G.; Fundamentos y modelos

de bases de datos. Alfaomega, Madrid (1999); 970-15-0500X
[COBO07]. Cobo Yera, . Diseo y programacion de Bases de Datos. Vision

Libros , Madrid (2007), pp. 7-17, 23-27; 978.84-9821-459-8
[DEPA04]. De Pablos, C., Lpez, J. J., Hermoso Santiago, M., & Medina, S..
Informtica y comunicaciones en la empresa. ESIC Editorial, Madrid (2004) , pp.
31-36 ; 84-7356-375-1
[GESC02]. Geschwinde, E., & Jrgen Schnig, H. PostgreSQL Developers

Handbook. Sams Publishing, Estados Unidos (2002), pp. 7-40; 0-672-32260-9
86
[LAFO10]. Lafosse, J.; Struts 2 El framework de desarrollo de aplicaciones Java

EE. Ediciones ENI , Barcelona(2010), pp. 11-14, 25-28 ;978-2-7460-5542-1
[PONS09]. Pons Capote, O., Marn Ruz, N., Medina Rodrguez, J. M., Acid
Carrillo, S., & Vila Miranda, M. A. Introduccin a las Bases de Datos, el Modelo
Relacional. Editorial Thomson, Madrid (2009), pp. 6-25, 33-43, 97- 105, 143-160;
978-84-9732-396-3
[RODR]. Rodrguez Sala, J. J., Santamara Arana, L., Rabasa Dolado, A., &
Martnez Bonastre, O. Editorial Club Universitario, Alicante, pp. 1-5, ; 84-8454274-2
[SILB02].Silberschatz, A., Korth, H. F., & Sudarshan, S. Fundamentos de Bases
de Datos. McGraw-Hill Inc , Madrid (2002), pp. 19-47, 87-114, 161-178 ; 84-4813654-3
[SORD05]. Sordo Touza, M., Cotos Yez, J. M., Taboada Gonzlez, J., &
Varela Pet, J. Sistemas de informacion medioambiental. Gesbiblo, Espaa (2005),
pp. 5-8, 17-30 34-39; 84-9745-056-6
[WORS02]. Worsley, J., & Drake, J.. Practical PostgreSQL. OReilly, Estados
Unidos de America (2002) , pp. 1-8;1-56592-846-6
b. Artculos Web
[FLOR14]. Flores Lpez , M., & Santiago, M. (s.f.). "Desarrollando aplicaciones

informticas
con el Proceso de Desarrollo Unificado (RUP)". Universidad
87
Tecnologica del Valle del Mezquital. Recuperado el 4 de Noviembre de 2014, de

http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm
[INST14a]. Instituto Nacional de Tecnologas de la Comunicacin. (Marzo de

2009).
Recuperado
el
de
Noviembre
de
2014,
de
https://www.incibe.es/file/N85W1ZWFHifRgUc_oY8_Xg
[INST14b] "Introduccin a los Sistemas de Informacin. Instituto Tcnologico de
Sonora.
(s.f.).
Recuperado
el
de
Noviembre
de
2014,
de
http://biblioteca.itson.mx/oa/dip_ago/introduccion_sistemas/p3.htm#
[MART14]. Martn Escofet, C. (s.f.). "El Lenguaje SQL". Universitat Oberta de
Catalunya OpenCourseWare. Recuperado el 2014 de Noviembre de 2014, de
http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-dedatos/bases-de-datos/P06_M2109_02149.pdf
88

Caso1 - INFORME FINAL PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Caso1 - INFORME FINAL PDF

Uploaded by

Copyright:

Available Formats

INSTITUTO TECNOLGICO DE OAXACA

DEPARTAMENTO DE SISTEMAS Y COMPUTACIN

SISTEMA DE ENLACE DE CONVENIOS

OAXACA DE JUAREZ, OAX. A 11 DEAGOSTO DE 2015

1.1 Antecedentes de la institucin........................................................................ 4

2.1 Concepto de sistema.................................................................................... 15

2.5.4 Paradigma de programacin ............................................................. 23

3.1 Fase de inicio ............................................................................................... 45

3.2 Fase de elaboracin ..................................................................................... 55

Figura No. 1 Estructura organizacional del Instituto Catastral del Estado de

El presente trabajo contiene todo los elementos que

elaboracin del Sistema de Enlace de Convenios Municipales

eleccin de todos los componentes utilizados para implementacin del sistema,

En el Captulo III denominado Marco metodolgico, se muestran todos los

El objetivo de dicho proyecto es el crear un sistema que permita tener

Durante la elaboracin del proyecto se presentaron ciertos obstculos, uno de

Misin: Entidad que se encarga de obtener y mantener un padrn catastral

Visin: Identificacin, Descripcin, Delimitacin y Valuacin de los bienes

Estructura organizacional del Instituto Catastral del Estado de Oaxaca

El Instituto Catastral del Estado de Oaxaca (ICEO), se encuentra ubicado en H.

Croquis de ubicacin del ICEO

Planteamiento del problema

En el Instituto Catastral del Estado de Oaxaca no existe un seguimiento o control

encargados de cada departamento del vencimiento y tomar medidas en caso de

El presente proyecto de sistema ofrece una alternativa de solucin a la necesidad

pertenecientes al Instituto Catastral del Estado de

Oaxaca; en las cuales se concentra la informacin de diferentes mbitos respecto

Instituto Catastral del Estado de Oaxaca

el procesamiento de los datos. Adems, este mecanismo no permite obtener de

World Wide Web Consortium

proyectos se podrn crear tareas y asignar responsables, quienes sern los

1.7.1 Objetivo general

1.7.2 Objetivos especficos

El sistema a desarrollar estar constituido en su esencia por una plataforma

Proveer acceso a la informacin de los convenios mediante consultas de

Generar reportes de acuerdo a:

Mostrar alertas a las reas pertinentes, cuando un convenio haya finalizado y

Facilitar la interaccin entre el sistema y los usuarios a travs del uso de

Gestionar las reuniones, capacitaciones, asesoras con las autoridades

Desarrollar un sistema Web que permitir la gestin de la relacin que existe

La Coordinacin de Enlace Municipal se ver beneficiada ya que podrn

Con la puesta en marcha del sistema se pretende mostrar un entorno de fcil

Se llevar un seguimiento adecuado de los municipios creando una relacin

Toda la informacin mostrada de los municipios ser veraz y oportuna.

Se podrn crear proyectos de trabajo colaborativo donde participen las

1.8.2 Limitaciones del problema

Ser necesario el uso de Internet para su funcionamiento.

El Instituto no cuenta con un servidor SMTP4 propio, ya que este depende de

En ste captulo se abordarn los conceptos relacionados a la rama de la

El diccionario de la Real Academia de la Lengua Espaola define el vocablo

Concepto de sistema de informacin

El concepto de sistema de informacin (SI), se puede definir como un conjunto

dinmicamente, y organizados en torno al objetivo de satisfacer

necesidades de informacin de una organizacin empresarial para la gestin

Entrada: captura o recolecta datos en bruto tanto del interior de la

Procesamiento: convierte esa entrada de datos en una forma ms

Salida: transfiere la informacin procesada a la gente que la usar o a las

Usuarios de los sistemas

En el mbito de la informtica, James A. Senn dice que los usuarios de los

La informacin est compuesta de datos que se han procesado y colocado en un

2.3.1 Actores de los sistemas

Dueos del sistema: Para cualquier sistema de informacin grande o pequeo

Diseadores del sistema: Son tcnicos especializados que traducen los