Universidad Mayor de San Andres: Facultad de Ciencias Puras Y Naturales Carrera de Informática

UNIVERSIDAD MAYOR DE SAN ANDRES
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
PROYECTO DE GRADO
“SISTEMA WEB PARA EL REGISTRO Y CONTROL DE MASCOTAS”
CASO: UNIDAD DE PROTECCION ANIMAL Y ZOONOSIS
PARA OPTAR AL TITULO DE LICENCIATURA EN INFORMATICA

MENCION: INGENIERIA DE SISTEMAS INFORMATICOS
POSTULANTE: LORENA ALVAREZ VACAFLORES
TUTOR METODOLOGICO: M. Sc. ALDO RAMIRO VALDEZ ALVARADO
ASESOR: M. Sc. CARLOS MULLISACA CHOQUE
LA PAZ – BOLIVIA
2014
UNIVERSIDAD MAYOR DE SAN ANDRÉS
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
UNIVERSIDAD MAYOR DE SAN ANDRÉS
Proyecto de Grado:
“Sistema Web para el Registro y Control de Mascotas”

Caso: Unidad de Protección Animal y Zoonosis
Presentado por:
Lorena Alvarez Vacaflores
Para obtener el grado académico de Licenciatura en Informática mención Ingeniería de

Sistemas Informáticos
Nota Numeral: ……………………………………..………………………………
Nota Literal: …………………..………………………………………................
Ha sido Aprobado…………………………….…………………………….
Director de Carrera: M. Sc. Edgar Clavijo Cárdenas …………………........
Tutor: M. Sc. Aldo Ramiro Valdez Alvarado ……………………….
Asesor: M. Sc. Carlos Mullisaca Choque ……………………….
Tribunal: .…………………………………………...………………………...
DEDICATORIA
A mis padres Carla Vacaflores e Ismael
Alvarez por guiarme en el transcurso de
mi vida con amor y comprensión.
A mi hermosa True por su compañía y
amor incondicional, asimismo a todas
aquellas personas que Dios puso en mi
camino y que algún día me aconsejaron y
brindaron su apoyo.
AGRADECIMIENTOS
En primer lugar a Dios porque siempre me dio las ganas y la
fuerza que necesitaba para seguir adelante.
A mis padres por no dejarme sola aunque vivimos separados
siempre los llevo en mi corazón y sigo adelante por mí y por
ustedes, también a mi hermanita Romina por todo su cariño.
A mi tutor M. Sc. Aldo Ramiro Valdez Alvarado, por su apoyo,
comprensión y paciencia en el seguimiento otorgado al presente
proyecto.
A mi asesor M. Sc. Carlos Mullisaca Choque por la entrega de
conocimiento y colaboración otorgada para la culminación del
proyecto.
A mi familia a la que está cerca y a la que no, porque por lo
menos con una llamada sé que me estiman, también a mis
amigos que siempre con un sencillo consejo me levantaron, en
especial a Rodrigo López por su apoyo incondicional.
Finalmente agradecer a la Universidad Mayor de San Andrés
por su recibimiento durante el transcurso de estos años y a la
estimada Carrera de Informática.

ÍNDICE CONTENIDO
CAPÍTULO I ................................................................................................................................1
MARCO INTRODUCTORIO ......................................................................................................1
1.1. INTRODUCCIÓN ..............................................................................................................1
1.2. ANTECEDENTES .............................................................................................................2
1.2.1. Antecedentes Institucionales ...............................................................................................2
1.2.2. Proyectos Similares .............................................................................................................3
1.3. PLANTEAMIENTO DEL PROBLEMA ............................................................................4
1.3.1. Problema General ...............................................................................................................4
1.3.2. Problemas Específicos ........................................................................................................4
1.4. OBJETIVOS .......................................................................................................................4
1.4.1. Objetivo General .................................................................................................................4
1.4.2. Objetivos Específicos..........................................................................................................5
1.5. JUSTIFICACION ...............................................................................................................6
1.5.1. Justificación Social .............................................................................................................6
1.5.2. Justificación Económica .....................................................................................................6
1.5.3. Justificación Técnica ...........................................................................................................6
1.6. ALCANCES, LIMITES Y APORTES ...............................................................................6
1.6.1. Alcances .............................................................................................................................6
1.6.2. Límites ................................................................................................................................7
1.6.3. Aportes ...............................................................................................................................8
1.7. METODOLOGÍA APLICADA ..........................................................................................9
CAPÍTULO II ............................................................................................................................. 10
MARCO TEÓRICO .................................................................................................................... 10
2.1. INGENIERIA DE SOFTWARE ....................................................................................... 10
2.2. CICLO DE VIDA DE LA INGENIERÍA DE SOFTWARE ............................................. 11

2.3. METODOLOGÍAS DE DESARROLLO DE SOFTWARE ............................................. 12
2.3.1. Modelo en Cascada ........................................................................................................... 13
2.3.2. Modelos Iterativos e Incrementales ................................................................................... 14
2.3.3. Modelos Evolutivos .......................................................................................................... 15
2.3.4. Modelo en Espiral ............................................................................................................. 16
2.4. Modelos Agiles ................................................................................................................. 18
2.4.1. Manifiesto Ágil ................................................................................................................. 19
2.4.2. Principios del Manifiesto Ágil .......................................................................................... 20
2.5. METODOLOGIA DE DESARROLLO SCRUM ............................................................. 21
2.5.1. Revisión de las iteraciones ................................................................................................ 22
2.5.2. Desarrollo incremental ...................................................................................................... 22
2.5.3. Desarrollo Evolutivo ......................................................................................................... 22
2.5.4. Auto-organización ............................................................................................................ 22
2.5.5. Colaboración ..................................................................................................................... 23
2.5.6. Roles de SCRUM.............................................................................................................. 23
2.5.6.1. Roles Principales ......................................................................................................... 23
2.5.6.2. Roles Auxiliares........................................................................................................... 24
2.5.7. Sprints ............................................................................................................................... 24
2.5.8. Elementos de SCRUM ...................................................................................................... 25
2.5.8.1. Product backlog ........................................................................................................... 25
2.5.8.2. Sprint backlog .............................................................................................................. 26
2.5.9. Fases de SCRUM .............................................................................................................. 26
2.6. SCRUM APLICADO AL DESARROLLO DE SOFTWARE .......................................... 29
2.6.1. Ciclo de Vida de Scrum .................................................................................................... 30
2.6.1.1. Pre-Juego: Planeamiento y Montaje (Staging) ............................................................. 30
2.6.1.2. Juego o Desarrollo ....................................................................................................... 30
2.6.1.3. Post-Juego: Liberación ................................................................................................ 30

2.7. INGENIERIA WEB ......................................................................................................... 31
2.8. METODOLOGÍA DE DESARROLLO DE APLICACIONES WEB .............................. 32
2.9. INGENIERIA WEB BASADA EN UML (UWE) ............................................................ 33
2.9.1. Fases UWE ....................................................................................................................... 33
2.9.2. Modelo de Caso de Uso .................................................................................................... 34
2.9.3. Modelo de Contenido ........................................................................................................ 35
2.9.4. Modelo de Navegación ..................................................................................................... 36
2.9.5. Modelo de Presentación .................................................................................................... 36
2.9.6. Modelo de Proceso............................................................................................................ 38
2.9.6.1. Modelo de Estructura del Proceso ................................................................................ 38
2.9.6.2. Modelo de Flujo de Proceso......................................................................................... 39
2.10. UNIDAD DE PROTECCION ANIMAL Y ZOONOSIS .................................................. 39
2.10.1. Misión .......................................................................................................................... 41
2.10.2. Visión .......................................................................................................................... 41
2.10.3. Organigrama de la Unidad de Protección Animal y Zoonosis ..................................... 41
2.10.4. Precedentes de la Unidad de Protección Animal y Zoonosis ....................................... 44
2.11. HERRAMIENTAS ........................................................................................................... 45
2.11.1. Apache ......................................................................................................................... 45
2.11.2. PHP (Hyper Text Preprocessor) ................................................................................... 46
2.11.3. MySQL ........................................................................................................................ 46
CAPÍTULO III ............................................................................................................................ 48
MARCO APLICATIVO ............................................................................................................. 48
3.1. INTRODUCCION ............................................................................................................ 48
3.2. PRE-GAME ...................................................................................................................... 49
3.2.1. Recopilación de requerimientos ........................................................................................ 49
3.2.2. Definición de “Hecho” ...................................................................................................... 50
3.2.3. Análisis de riesgo .............................................................................................................. 50

3.3. GAME .............................................................................................................................. 51
3.3.1. Primera iteración ............................................................................................................... 52
3.3.2. Segunda iteración .............................................................................................................. 53
3.3.3. Tercera iteración ............................................................................................................... 54
3.3.4. Cuarta iteración ................................................................................................................. 55
3.3.5. Modelo de Casos de Uso................................................................................................... 56
3.3.5.1. Diagrama de Casos de Uso General ............................................................................. 56
3.3.5.2. Descripción de Casos de Uso ....................................................................................... 57
3.3.6. Modelado de la Base de Datos .......................................................................................... 60
3.3.7. Modelo de Contenidos ...................................................................................................... 63
3.3.8. Modelo de Navegación ..................................................................................................... 64
3.3.9. Modelo de Presentación .................................................................................................... 65
3.3.10. Modelo de Procesos ..................................................................................................... 66
3.4. POST-GAME ................................................................................................................... 69
3.4.1. Identificación de Roles ..................................................................................................... 69
3.5. PANTALLAS DEL SISTEMA......................................................................................... 70
CAPÍTULO IV ........................................................................................................................... 76
METRICAS DE CALIDAD Y SEGURIDAD ............................................................................ 76
4.1. METRICAS DE CALIDAD ............................................................................................. 76
4.1.1. Operación del producto - Facilidad de Uso ....................................................................... 80
4.2. SEGURIDAD ................................................................................................................... 81
4.2.1. Integridad .......................................................................................................................... 82
4.2.2. Confidencialidad ............................................................................................................... 82
4.2.3. Disponibilidad................................................................................................................... 83
4.2.4. Irrefutabilidad ................................................................................................................... 83
CAPÍTULO V .............................................................................................................................84
ANALISIS DE COSTO/BENEFICIO ........................................................................................84

5.1. INTRODUCCION ............................................................................................................ 84
5.1.1. Estudio de Factibilidad ..................................................................................................... 84
5.1.2. Factibilidad Técnica. ......................................................................................................... 85
5.1.3. Requerimientos de Hardware ............................................................................................ 86
5.1.4. Requerimientos de Software. ............................................................................................ 87
5.1.5. Factibilidad Operativa. ...................................................................................................... 88
5.1.6. Costos ............................................................................................................................... 88
5.1.6.1. Costo Laboral en el Ciclo de Ejecución ....................................................................... 88
5.2. APLICACIÓN DE COCOMO. ......................................................................................... 91
5.2.1. Modelo de Composición de Aplicaciones ......................................................................... 91
5.2.2. Complejidad Asociada a las Instancias de Objetos ........................................................... 93
5.2.3. Pesos Asociados a los Niveles de Complejidad ................................................................ 93
5.2.4. Duración y Personal del Proyecto ..................................................................................... 94
5.3. COSTOS ........................................................................................................................... 95
5.3.1. Costos del Anterior Sistema .............................................................................................. 95
5.3.2. Costos del Nuevo Sistema................................................................................................. 96
5.4. CONCLUSIÓN DE ESTIMACIÓN DE COSTO Y BENEFICIO .................................... 96
CAPÍTULO VI ........................................................................................................................... 97
CONCLUSIONES Y RECOMENDACIONES .......................................................................... 97
6.1. CONCLUSIONES ............................................................................................................ 97
6.2. RECOMENDACIONES ................................................................................................... 98
BIBLIOGRAFIA ........................................................................................................................ 99
ANEXOS .................................................................................................................................. 101

ÍNDICE DE FIGURAS
FIGURA 2. 1. MODELO EN CASCADA ............................................................................ 14

FIGURA 2. 2. MODELO ITERATIVO E INCREMENTAL ...................................................... 15
FIGURA 2. 3. DESARROLLO EVOLUTIVO ....................................................................... 16
FIGURA 2. 4. CICLO DE VIDA EN ESPIRAL ..................................................................... 17
FIGURA 2. 5. FUNCIONALIDADES Y ELEMENTOS DE SCRUM ....................................... 26
FIGURA 2. 6. CICLO DE VIDA DE SCRUM..................................................................... 31
FIGURA 2. 7. FASES DE UWE ....................................................................................... 34
FIGURA 2. 8. MODELO SIMPLE DE CASO DE USO ........................................................... 35
FIGURA 2. 9. MODELO DE CONTENIDO.......................................................................... 35
FIGURA 2. 10. REPRESENTACIÓN PARA EL MODELO DE NAVEGACIÓN........................... 36
FIGURA 2. 11. REPRESENTACIÓN PARA EL MODELO DE PRESENTACIÓN ........................ 37
FIGURA 2. 12. REPRESENTACIÓN DE LA ESTRUCTURA DE PROCESOS ........................... 38
FIGURA 2. 13. REPRESENTACIÓN DE FLUJO DE PROCESO ............................................. 39
FIGURA 2. 14. ORGANIGRAMA DE LA UNIDAD ............................................................. 43
FIGURA 3. 1. ADAPTACIÓN DE SCRUM Y UWE .......................................................... 48
FIGURA 3. 2. DIAGRAMA DE CASOS DE USO GENERAL ................................................. 57
FIGURA 3. 3. MODELO LÓGICO DE LA BASE DE DATOS ................................................ 61
FIGURA 3. 4. MODELO FÍSICO DE LA BASE DE DATOS .................................................. 62
FIGURA 3. 5. MODELO DE CONTENIDOS ....................................................................... 63
FIGURA 3. 6. MODELO DE NAVEGACIÓN ...................................................................... 64
FIGURA 3. 7. MODELO DE PRESENTACIÓN .................................................................... 65
FIGURA 3. 8. MODELO DE ESTRUCTURA DE PROCESOS ................................................ 66
FIGURA 3. 9. PROCESO DE AGREGAR PROPIETARIO Y SU MASCOTA.............................. 67
FIGURA 3. 10. PROCESO DE AGREGAR DENUNCIA ........................................................ 67
FIGURA 3. 11. PROCESO DE MODIFICACIÓN O BORRADO ............................................... 68
FIGURA 3. 12. CLASIFICACIÓN E IDENTIFICACIÓN DE ROLES......................................... 70
FIGURA 3. 13. MENÚ PRINCIPAL DE SISTEMA ............................................................... 71
FIGURA 3. 14. PANTALLA DE INICIO DE SESIÓN AL SISTEMA ......................................... 71
FIGURA 3. 15. LISTA DE LOS REPORTES DEL ADMINISTRADOR ...................................... 72
FIGURA 3. 16. NOTICIAS PUBLICADAS POR EL ADMINISTRADOR ................................... 72
FIGURA 3. 17. REPORTE GENERADO EN PDF ................................................................ 73
FIGURA 3. 18. LISTADO Y REGISTRO DE PROPIETARIOS................................................. 73
FIGURA 3. 19. FORMULARIO DE REGISTRO DE MASCOTA .............................................. 74
FIGURA 3. 20. FICHA DE UN PERRO REGISTRADO .......................................................... 74
FIGURA 3. 21. FORMULARIO DE REGISTRO DE DENUNCIA ............................................. 75
FIGURA 3. 22. MASCOTAS DESAPARECIDAS O ENCONTRADAS ...................................... 75
ÍNDICE DE TABLAS
TABLA 3. 1. REQUERIMIENTOS ..................................................................................... 50

TABLA 3. 2. ANÁLISIS DE RIESGOS ............................................................................... 51
TABLA 3. 3. PRIMERA ITERACIÓN................................................................................. 52
TABLA 3. 4. SEGUNDA ITERACIÓN................................................................................ 53
TABLA 3. 5. TERCERA ITERACIÓN ................................................................................ 54
TABLA 3. 6. CUARTA ITERACIÓN.................................................................................. 55
TABLA 3. 7. DESCRIPCIÓN DE ACTORES........................................................................ 56
TABLA 3. 8. DESCRIPCIÓN DE CASO DE USO "REGISTRO DE PERSONA" ........................ 57
TABLA 3. 9. DESCRIPCIÓN DE CASO DE USO "ASIGNAR ROL AL USUARIO"................... 58
TABLA 3. 10. DESCRIPCIÓN DE CASO DE USO "GENERAR REPORTES" .......................... 58
TABLA 3. 11. DESCRIPCIÓN DE CASO DE USO "REGISTRO DE PROPIETARIO" ................ 58
TABLA 3. 12. DESCRIPCIÓN DE CASO DE USO "REGISTRO DE MASCOTAS" ................... 59
TABLA 3. 13. DESCRIPCIÓN DE CASO DE USO "REGISTRO DE DENUNCIAS" .................. 59
TABLA 3. 14. DESCRIPCIÓN DE CASO DE USO "REGISTRO LIBRETA DE SALUD" ............ 60
TABLA 3. 15. CASO DE USO "REGISTRO DE DESAPARECIDOS Y ENCONTRADOS" ......... 60
TABLA 3. 16. DESCRIPCIÓN DE ROLES DEL SISTEMA .................................................... 69
TABLA 4. 1. MÉTRICAS DE CALIDAD DE SOFTWARE...................................................... 78
TABLA 4. 2. CRITERIOS Y DETALLES RESPECTO AL SISTEMA ........................................ 79
TABLA 5. 1. REQUERIMIENTOS MÍNIMOS DE HARDWARE 86
TABLA 5. 2. REQUERIMIENTOS RECOMENDADOS DE HARDWARE 87
TABLA 5. 3. COSTOS DE SOFTWARE 87
TABLA 5. 4. COSTO OPERATIVO 88
TABLA 5. 5. TARIFA LABORAL DEL PROGRAMADOR DE SISTEMAS 89
TABLA 5. 6. COSTO TOTAL EN EL CICLO DE EJECUCIÓN 89
TABLA 5. 7. TARIFA LABORAL DEL ANALISTA DE SISTEMAS 90
TABLA 5. 8. TIPOS DE OBJETO, COMPLEJIDAD/PESO 92
TABLA 5. 9. ESQUEMA DE CLASIFICACIÓN DE PUNTOS DE OBJETO 92
TABLA 5. 10. COMPLEJIDAD - PESO 93
TABLA 5. 11. RATIO DE PRODUCTIVIDAD PROD 94
TABLA 5. 12. FACTORES COCOMO II 95
TABLA 5. 13. COSTO DE DESARROLLO 96
RESUMEN
En nuestra actualidad las organizaciones ya sean públicas o privadas tienden a

depender de herramientas cada vez más rápidas para el procesamiento de datos que
afectan a la toma de decisiones inmediatas. Para ese procesamiento tenemos en
cuenta a los computadores y sistemas de información con el fin de centralizar y
sistematizar toda la información necesaria para el logro de sus objetivos.
Las enfermedades sin lugar a duda son el mayor problema que tiene el ser
humano más aún si estas las trasmiten los animales por esta razón la misión de la
Unidad de Protección Animal y Zoonosis es la de evitar la transmisión de las
enfermedades Zoonóticas al hombre, el presente Proyecto de Grado “Sistema Web de
Registro y Control de Mascotas”, Caso: Unidad de Protección Animal y Zoonosis,
surge de la necesidad de contar con un mecanismo sistemático y automatizado para
las actividades tan importantes que realizan para la población en general, además
necesitan que su atención sea rápida y efectiva.
Para el desarrollo del proyecto se utilizó la metodología de desarrollo

SCRUM adaptada con UWE (Ingeniería Web basada en UML) que incorpora los ya
conocidos estándares orientados a objetos, de acuerdo a la semántica y notación
provista por el Lenguaje UML, que se ajustan con los requerimientos y necesidades
del problema.
Con el sistema se debe poder registrar a los propietarios y sus mascotas, tanto
como las denuncias de la población en general sobre algún incidente con algún
animal, además de la colaboración a la población en general con los servicios de listas
de mascotas desaparecidas y encontradas y que los propietarios puedan tener a la
mano la información de su mascota.
ABSTRACT
In our present the organizations whether public or private tend to rely of tools
increasingly faster for data processings, because affecting the decision making
immediate. By this process we consider to computers and information systems to
centralize and organize all the information necessary for the achievement of its
objectives.
The diseases undoubtedly are the biggest problem of humans, worse if the
transmit is of animals for this reason the mission of the Unit Animal Protection and
Zoonoses is to prevent the transmission of Zoonotic diseases to man, this Draft
Grade: "Web System for Registration and Control of Pet", Case: Unit of Animal
Protection and Zoonoses, arises from the need for a systematic and automated
mechanism for important activities for the general population, as well also need offer
a attention fast and effective.
For the development of project was used the SCRUM methodology adapted
to UWE (UML-based Web Engineering) incorporating the object-oriented known
standards, according to the semantics and notation provided by the UML language,
which was used in accordance with requirements and needs of the problem.
With the system should be able to register to the owners and their pets, as well
as complaints from the general public about an incident with some animal, and the
collaboration so the general population with the services of lists of missing pets and
found and owners can have on hand information of your pet.
CAPÍTULO I
MARCO INTRODUCTORIO
1.1. INTRODUCCIÓN
En nuestra actualidad las organizaciones ya sean públicas o privadas tienden a

depender de herramientas cada vez más rápidas para el procesamiento de datos que
afectan a la toma de decisiones inmediatas. Para ese procesamiento tenemos en
cuenta a los computadores y sistemas de información con el fin de centralizar y
sistematizar toda la información necesaria para el logro de sus objetivos y aún mejor
tenemos la WWW (World Wide Web) red de redes que está compuesta por
incontables sitios web conectados entre sí, en esta propuesta será muy necesaria o
mejor dicho indispensable en algunos años más.
Las enfermedades sin lugar a duda son el mayor problema que tiene el ser
humano más aún si estas las trasmiten los animales por esta razón la misión de la
Unidad de Protección Animal y Zoonosis es la de evitar la transmisión de las
enfermedades Zoonóticas al hombre, actualizando y difundiendo las normas de
atención de rabia y de las diferentes zoonosis para lograr una óptima vigilancia
epidemiológica del Programa y pueda ser manejado en todos los niveles de atención
de los servicios de salud y así cortar con la circulación del virus rábico y otros
parásitos en el departamento de La Paz.
La mayoría de estas instituciones encargadas del cuidado de los animales

tienen como problema notable el controlar la tenencia de animales del hombre en un
caso generalizado los canes y los felinos, ya que según datos generados por la OMS
(Organización Mundial de la Salud) esas especies son las preferidas como mascotas
por el hombre, aunque en los últimos años se han ido reemplazando animales
domésticos por animales salvajes como lagartijas, tortugas, loros, monos,...,etc., y en
muchos casos los propietarios y/o tenedores tienden a romper con las leyes
establecidas por los gobiernos de los distintos países.
Lo más importante en un Sistema web está más allá de la información, es
llamar la atención del visitante o usuario porque su permanencia en dicha aplicación
dependerá de lo fácil y confortable que sea su viaje en el sistema, este Sistema web
será realizado porque el internet es un medio de difusión lo suficientemente grande
que nos permitirá concientizar a la población sobre la información que nos brinda la
Unidad de Protección Animal y Zoonosis, además de facilitar procedimientos tanto
para la población como para los funcionarios de dicha unidad para que lleguen a
alcanzar sus objetivos.
1.2. ANTECEDENTES
1.2.1. Antecedentes Institucionales

En Bolivia, el 24 de Abril de 2013 en la ciudad de Cochabamba se llevó a
cabo el primer registro único de mascotas aprobado por su Honorable Concejo
Municipal. Fue la primera ciudad del país en registrar a las mascotas y otorgarles un
carnet de identidad, la ciudad de Cochabamba es la sexta capital en Latinoamérica
que cuenta con este sistema. Las placas tienen un costo de Bs. 18, incluido el carnet
de identidad, también tienen opción del chip para sus mascotas. La placa de color
“celeste” quiere decir que esa raza de perro no es considerada potencialmente
peligrosa, mientras que la placa de color “rojo” es considerada potencialmente
peligrosa. Y la placa de color “amarilla” está consignada para los gatos. El carnet de
identidad lleva la fotografía, el nombre y apellido de la mascota, la fecha de
nacimiento y al reverso el nombre del propietario y/o tenedores que lo registren.
Actualmente la Unidad de Protección Animal y Zoonosis no cuenta con

ningún sistema informático y mucho menos un sistema web, por lo tanto, todavía
trabajan con métodos tradicionales y manuales.
2
1.2.2. Proyectos Similares
Examinaremos algunos proyectos similares anteriormente propuestos en la
Carrera de Informática, con la finalidad de tener mejores referencias para optimizar el
progreso del sistema propuesto, se tomara como origen de información la Biblioteca
de Informática. A continuación mencionamos algunos ejemplos:
a) Título: “Sistema de Información para la dirección de Zoonosis”

Autor: René Cayo Acuña
Año: 2007
Institución: Universidad Mayor de San Andrés
Este sistema registra y controla el seguimiento de los casos presentados en el
anteriormente Centro Municipal de Zoonosis (CEMZOO).
b) Título: “Sistema de Información geográfica para Zoonosis”

Autor: Johann Stanislao Casias Márquez
Año: 2009
En este sistema se utiliza información geográfica para mostrar zonas de riesgo
epidemiológico, esta idea nos permitirá aumentar la información para el
objetivo de la institución.
c) Título: “Sistema Web de Control y Seguimiento de Personal”

Autor: María Juana Aguilar Torrez
Año: 2011
En este sistema para su modelado se usó UWE es una herramienta para
modelar aplicaciones web, que en el sistema ahora propuesto nos servirá de
para el diseño del presente sistema.
3
1.3. PLANTEAMIENTO DEL PROBLEMA
1.3.1. Problema General

¿Cómo se puede brindar información oportuna en el control de los incidentes
con perros de razas peligrosas, la sobrepoblación de mascotas, control de
enfermedades en la Unidad de Protección Animal y Zoonosis?
1.3.2. Problemas Específicos
 Por la falta de información rápida y actualizada sobre los canes, no se tiene un

control adecuado sobre su cuidado o su estado de salud, ni tampoco datos
esenciales del can como saber si tiene o no propietario.
 La información no es consistente sobre las mascotas ni tampoco de alguna

enfermedad contagiosa que pueda tener un animal, esto puede llegar a ser una
epidemia de una de las enfermedades mortales como es la rabia.
 No se cuenta con un registro de las mascotas que van a parar en el centro

(canes abandonados, capturados o extraviados), por lo mismo no pueden
producir informes actualizados sobre estadísticas de los animales que llegan,
también se puede tomar en cuenta enfermedades, clasificación de razas,
verificación de incidentes por mordeduras.
 Los funcionarios de la Unidad no pueden realizar un seguimiento adecuado de

las mascotas, debido a que los procesos que realizan son manuales.
1.4. OBJETIVOS
1.4.1. Objetivo General

Desarrollar un Sistema Web para el Registro y Control de Mascotas que
contemple las enfermedades, vacunas, cirugías hasta la muerte natural o eutanasia del
4
animal, para así tener información precisa y útil con el fin de cumplir con el objetivo
de la Unidad de Protección Animal y Zoonosis.
1.4.2. Objetivos Específicos
 Desarrollar una Base de datos única que permita almacenar todos los
antecedentes del animal, además si éste tiene dueño debe incorporarse
necesariamente los antecedentes del propietario.
 Desarrollar niveles de seguridad para el acceso de los tipos de usuario

detectados.
 Diseñar una página web que permita obtener información básica, importante y
oportuna referente a los canes para su cuidado, protección y estilo de vida,
además de los diferentes casos presentados en la Unidad de Protección
Animal y Zoonosis.
 Elaborar un procedimiento para el registro de las mascotas de manera que se

pueda individualizar y reconocer a cada una, esto quiere decir que debe contar
con los antecedentes propios del animal vale decir su raza, color, edad, sexo,
especie, etc. Incluir el seguimiento de vacunas al día que deberán ser
acreditadas por certificados emitidos por un médico veterinario,
documentación que debería mantenerse a disposición del propietario y/o
tenedor.
 Diseñar e implementar una navegación de uso sencillo con el objeto de

facilitar la localización de toda la información existente para así poder realizar
la emisión de reportes en tiempo real con el objeto de minimizar los tiempos
de respuesta para la toma de decisiones.
5
1.5. JUSTIFICACION
1.5.1. Justificación Social

El proyecto mejorara el funcionamiento de la Unidad de Protección Animal y
Zoonosis ya que pasara de ser manual a automatizada, además reducirá las horas de
trabajo de los funcionarios de la Unidad al mismo tiempo permitirá realizar
actividades retrasadas o adelantar proyectos en vigencia, y cabe mencionar que para
la población de la ciudad de La Paz facilitara todos los procesos de información y
registro de cualquier tipo en la Unidad.
1.5.2. Justificación Económica

La información en el mundo actual es muy valiosa, por lo que se considerara
este sistema como una herramienta bastante útil en muchos aspectos de la labor de los
funcionarios al igual que de los ciudadanos porque con información prudente y
oportuna se evitaría a la larga pagar costos mayores para solucionar una epidemia o
contagio mayor, tanto para la Unidad como para la población.
1.5.3. Justificación Técnica

La implementación de este proyecto se justifica porque el Unidad de
Protección Animal y Zoonosis cuenta con equipos de computación actualizados que
cumplen los requisitos mínimos de hardware y software para la implementación del
sistema, además se cuenta con información ya obtenida pero no completa digital (en
Excel) para la verificación del funcionamiento del sistema una vez que se
implemente.
1.6. ALCANCES, LIMITES Y APORTES
1.6.1. Alcances
El sistema a desarrollarse se lo propone de alcance departamental solo en la
ciudad de La Paz ya que la Unidad de Protección Animal y Zoonosis depende del
6
Gobierno Autónomo Departamental de La Paz, tomando en cuenta la ampliación de
la información rápida, confiable y flexible que permita cubrir con las necesidades
urgentes y necesarias de la Unidad, considerando en el proyecto lo siguiente que
serían los módulos que se construirán para el sistema:
 El sistema tendrá un módulo de gestión de usuarios en el cual se

proporcionara y restringirán los permisos de acuerdo al papel que desempeñen
en la Unidad de Protección Animal y Zoonosis.
 Módulo de registro y almacenamiento de las mascotas que contendrá toda la

información necesaria y oportuna tanto de la mascota, como la del propietario.
 Módulo de registro de almacenamiento denuncias externas como también

internas de casos como maltrato, abandono, agresión de algún animal.
 Módulo de emisión de reportes según diversos aspectos como: casos de razas

peligrosas, casos de enfermedades, servicio de eutanasia y/o vacunas, etc.
 Módulo de información y referencias sobre la Unidad, ¿para qué sirve?,

¿porque se creó?, ¿qué funciones cumple?, e información sobre su cuidado los
deberes de los propietarios así como los derechos de los animales, talleres y/o
seminarios educativos de las unidades encargadas sobre los temas
relacionados a la Unidad.
 En cuanto a su manejo, se adaptara fácilmente para que los usuarios finales

puedan manipular el sistema como corresponde, con el cuidado y la
responsabilidad que la información necesita.
1.6.2. Límites
El sistema no realizara las siguientes tareas debido a que se enfocara solo en
los objetivos planteados:
7
 El sistema se limitara al registro, clasificación de lo mencionado antes en
objetivos, pero no así a cobros extras sobre collares de identificación, ni
libretas de salud animal, ya que se deberán designar a otras entidades
financieras u otras unidades.
 No se podrán obtener datos muy comprometedores como número de cuentas

bancarias, número de seguros médicos o de salud, etc., solo los necesarios
para el funcionamiento del sistema.
 El sistema está enfocado en el Área de Tenencia, Control y Protección con

información necesaria y suficiente de las demás áreas para el mejor
funcionamiento de los datos para el Sistema.
 El sistema no reemplaza en ningún sentido a los empleados a cargo de la

Unidad de Protección Animal y Zoonosis, mas por el contrario es una
herramienta para el mejor desarrollo de sus actividades.
1.6.3. Aportes
 Como aporte para la Unidad de Protección Animal y Zoonosis es poderles

brindar un Portal Web para que puedan desarrollar mejor sus actividades y
tener su información a la mano para la toma de decisiones.
 Como aporte más bien personal y propio, espero que con la información
proporcionada con mensajes claros y fuertes puestos en la página principal,
poder llegar a la conciencia de todas aquellas personas que poseen una
mascota la cuiden y críen como realmente debería ser.
 Como aporte a los propietarios que puedan tener la información de su

mascota, rápida y a la mano en un instante, al mismo tiempo se incluyó un
módulo de las mascotas desaparecidas y/o encontradas para que la población
en general pueda entrar al Portal para buscar o encontrar a su mascota.
8
1.7. METODOLOGÍA APLICADA
La recopilación de información para la determinación de requisitos de los

usuarios, es la base del sistema en los procesos que se necesitan automatizar, entonces
se usaran los siguientes métodos:
 Análisis del proceso de la unidad.
 Entrevistas con los encargados.
 Estudio de los requerimientos que muestra el personal responsable.
 Análisis de los recursos que se usan actualmente, además de la

investigación de libros y sitios Web.
Para el desarrollo del sistema se utilizara la metodología SCRUM por ser

utilizada en entornos basados en el desarrollo ágil de software, nos permitirá en cada
iteración el poder modificar los requisitos y entregar un producto funcional al final de
cada iteración en nexo con la metodología UWE (Ingeniería basada en UML) que se
compone de cuatro fases (análisis de requerimientos, diseño conceptual, diseño de
navegación y diseño de presentación).
En lo que respecta a las herramientas para el desarrollo del software se usara

el servidor Apache, como editor de interfaces Web HTML, además del lenguaje de
Alto Nivel PHP para operar las consultas del sistema, para la construcción de la base
de datos y poder centralizar la información se usara el gestor de base de datos
MySQL que nos permitirá:
 Crear y administrar la base de datos, los usuarios y los permisos.
 Diseñar y ejecutar las instrucciones SQL.
 Realizar las consultas requeridas por el usuario.
9
CAPÍTULO II
MARCO TEÓRICO
2.1. INGENIERIA DE SOFTWARE
Según la definición del IEEE, “software es la suma total de los programas de

computadora, procedimientos, reglas, la documentación asociada y los datos que
pertenecen a un sistema de cómputo”. De la misma definición, “un producto de
software es un producto diseñado para un usuario”. En este contexto, la Ingeniería de
Software SE (ingles Software Engineering) es “un enfoque sistemático del desarrollo,
operación, mantenimiento y retiro del software”, lo que en palabras más llanas
significa que “la Ingeniería de Software es la rama de la ingeniería que aplica los
principios de la ciencia de la computación y las matemáticas para lograr soluciones
costo-efectivas a los problemas de desarrollo de software”. [Cota, 1994]
El proceso de Ingeniería de Software se define como “un conjunto de etapas

parcialmente ordenadas con la intención de lograr un objetivo, en este caso, la
obtención de un producto de software de calidad”. El proceso de desarrollo de
software “es aquel en que las necesidades del usuario son traducidas en
requerimientos de software, estos requerimientos transformados en diseño y el diseño
implementado en código, el código es probado, documentado y certificado para su
uso operativo”. Concretamente “define quien está haciendo qué, cuándo hacerlo y
cómo alcanzar un cierto objetivo”.
El proceso de desarrollo de software requiere un conjunto de conceptos, una

metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida
del software que comprende cuatro grandes fases: concepción, elaboración,
construcción y transición. La concepción define el alcance del proyecto y desarrolla
un caso de negocio. La elaboración define un plan del proyecto, especifica las
características y fundamenta la arquitectura. La construcción crea el producto y la
transición transfiere el producto a los usuarios.
10
Para el ingeniero de software del futuro se necesita una nueva definición, una
que incluya el arte y habilidad de resolver amplios problemas socio-tecnológicos y,
como una necesidad que estará con nosotros para siempre, el arte y habilidad de
cambiar de administración. En este contexto, ninguna otra carrera, con la posible
excepción de medicina, ofrece tanto potencial para recompensas personales,
autoestima y añadir valor duradero a la humanidad.
2.2. CICLO DE VIDA DE LA INGENIERÍA DE SOFTWARE
El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está
desarrollando desde que nace la idea inicial hasta que el software es retirado o
remplazado (muere). También se denomina a veces paradigma. [Pressman, 2002]
La ingeniería de software requiere llevar a cabo numerosas tareas entre ellas:
 Análisis de los requisitos de software: Este proceso de reunión de requisitos

se intensifica y se centra especialmente en el software. Para comprender la
naturaleza de los programas a construirse, el ingeniero (analista) del software
debe comprender el dominio de la información del software, así como la
función requerida, comportamiento, rendimiento e interconexión.
 Diseño: El diseño del software es realmente un proceso de muchos pasos que

se centra en cuatro atributos distintos de programa: estructura de datos,
arquitectura de software, representaciones de interfaz y detalle procedimental
(algoritmo). El proceso del diseño traduce requisitos en una representación del
software donde se pueda evaluar su calidad antes de que comience la
codificación.
 La Generación de códigos o codificación: El diseño se debe traducir en una

forma legible por la máquina. El paso de generación de código lleva a cabo
esta tarea. Tomando en cuenta que si se lleva a cabo el diseño de una forma
detallada, la generación de código se realiza mecánicamente.
11
 Las Pruebas: Una vez que se ha generado el código, comienza las pruebas
del programa, en la cual se centra en los procesos lógicos internos del
software, asegurando de todas las sentencias se han comprobado, y en los
procesos externos funcionales; es decir, realizar las pruebas para la detección
de errores y asegurar que la entrada para la detección de errores y asegurar
que la entrada definida produce resultados reales de acuerdo con los
resultados requeridos.
 El Mantenimiento: El software indudablemente sufrirá cambios después de

ser entregado al cliente (una excepción posible es el software empotrado). Se
producirán cambios porque el software debe adaptarse para acoplarse a los
cambios de su entorno externo (ejemplo: se requiere un cambio debido a un
sistema operativo o dispositivo periférico nuevo), o porque el cliente requiere
mejoras funcionales o de rendimiento. El soporte y mantenimiento del
software vuelve a aplicar cada una de las fases precedentes a un programa ya
existente y no a uno nuevo.
2.3. METODOLOGÍAS DE DESARROLLO DE SOFTWARE
Las Metodologías de Desarrollo de Software surgen ante la necesidad de

utilizar una serie de procedimientos, técnicas, herramientas y soporte documental a la
hora de desarrollar un producto software. Dichas metodología pretenden guiar a los
desarrolladores al crear un nuevo software, pero los requisitos de un software a otro,
son tan variados y cambiantes, que ha dado lugar a que exista una gran variedad de
metodologías para la creación de un software. Se podrían clasificar en dos grandes
grupos:
 Las metodologías orientadas al control de los procesos, estableciendo

rigurosamente las actividades a desarrollar, herramientas a utilizar y
notaciones que se usaran. Estas metodologías son llamadas metodologías
pesadas.
12
 Las metodologías orientadas a la interactuación con el cliente y el
desarrollo incremental del software, mostrando versiones parcialmente
funcionales del software al cliente en intervalos cortos de tiempo, para que
pueda evaluar y sugerir cambios en el producto según se vaya desarrollando.
Estas son llamadas metodologías ligeras/agiles.
Existen varios modelos para simplificar el proceso de desarrollo, cada uno con
sus ventajas y desventajas, y le toca al equipo de desarrollo adoptar el más adecuado
para el proyecto. A veces, una combinación de los modelos puede ser lo más
indicado.
2.3.1. Modelo en Cascada

La primera descripción formal del modelo en cascada se cree que fue en un
artículo publicado en 1970 por Winston W. Royce, aunque Royce no usó el término
cascada en este artículo. Irónicamente, Royce estaba presentando este modelo como
un ejemplo de modelo que no funcionaba, defectuoso. El modelo en cascada "es un
proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo
(como una cascada) sobre las fases que componen el ciclo de vida". [Pressman,
2002].
Este modelo se caracteriza por ser apropiado, en general, para proyectos

estables (especialmente los proyectos con requisitos no cambiantes) y donde es
posible y probable que los diseñadores predigan totalmente áreas de problema del
sistema y produzcan un diseño correcto antes de que empiece la implementación.
Funciona bien para proyectos pequeños donde los requisitos están bien entendidos. Es
un modelo en el que todo está bien organizado y no se mezclan las fases. Es simple y
fácil de usar.
13
Análisis
Diseño
Codificación
Prueba
Mantenimiento
Figura 2. 1. Modelo en Cascada

Fuente: Elaboración propia, según [Pressman, 2002]
Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene
entregables específicos y un proceso de revisión. Las fases son procesadas y
completadas de una vez. Muchas veces se considera un modelo pobre para proyectos
complejos, largos, orientados a objetos y por supuesto en aquellos en los que los
requisitos tengan un riesgo de moderado a alto de cambiar. Genera altas cantidades de
riesgos e incertidumbres.
Los resultados y/o mejoras no son visibles progresivamente, el producto se ve

cuando ya está finalizado, lo cual provoca una gran inseguridad por parte del cliente
que quiere ir viendo los avances en el producto.
2.3.2. Modelos Iterativos e Incrementales

Es un modelo derivado del ciclo de vida en cascada, este modelo busca
reducir el riesgo que surge entre las necesidades del usuario y el producto final por
malos entendidos durante la etapa de recogida de requisitos. Consiste en la iteración
de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente
una versión mejorada o con mayores funcionalidades del producto. El cliente es quien
después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas
14
iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del
cliente. [Pressman, 2002]
Figura 2. 2. Modelo iterativo e incremental

Fuente: Metodología de Roger Pressman
Este modelo se suele utilizar en proyectos en los que los requisitos no están
claros por parte del usuario, por lo que se hace necesaria la creación de distintos
prototipos para presentarlos y conseguir la conformidad del cliente.
2.3.3. Modelos Evolutivos

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez
más completas y complejas, hasta llegar al objetivo final deseado; incluso
evolucionar más allá, durante la fase de operación. Los modelos “Iterativo
Incremental” y “Espiral” (entre otros) son dos de los más conocidos y utilizados del
tipo evolutivo. La idea detrás de este modelo es el desarrollo de una implantación del
sistema inicial, exponerla a los comentarios del usuario, refinarla en n versiones hasta
que se desarrolle el sistema adecuado. Una ventaja de este modelo es que se obtiene
una rápida realimentación del usuario, ya que las actividades de especificación,
15
desarrollo y pruebas se ejecutan en cada iteración. [Pressman, 2002]. Existen dos
tipos de desarrollo evolutivo que se mencionaran a continuación:
Figura 2. 3. Desarrollo Evolutivo

Fuente: Modelo evolutivo
 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el

usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza
con las partes que se tiene más claras. El sistema evoluciona conforme se
añaden nuevas características propuestas por el usuario.
 Enfoque utilizando prototipos: El objetivo es entender los requisitos del

usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del
desarrollo exploratorio, se comienza por definir los requisitos que no están
claros para el usuario y se utiliza un prototipo para experimentar con ellos. El
prototipo ayuda a terminar de definir estos requisitos.
2.3.4. Modelo en Espiral

El modelo espiral fue propuesto originalmente por Barry Boehm en 1985, es
un modelo de proceso de software evolutivo que conjuga la naturaleza evolutiva de la
construcción de prototipos con los aspectos controlados y sistemáticos del modelo
16
lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones
incrementales de software.
En el modelo espiral, el software se desarrolla en una serie de iteraciones

incrementales, durante las primeras iteraciones, la versión incremental podría ser un
modelo en papel o un prototipo. Durante las últimas iteraciones, se producen
versiones cada vez más complejas del sistema diseñado.
Figura 2. 4. Ciclo de vida en Espiral

Fuente: [Boehm, 1998]
Se caracteriza por generar mucho trabajo adicional. Al ser el análisis de

riesgos una de las tareas principales exige un alto nivel de experiencia y cierta
habilidad en los analistas de riesgos (es bastante difícil). Esto puede llevar a que sea
un modelo costoso. Además, no es un modelo que funcione bien para proyectos
pequeños. Este modelo se divide en un número de actividades de marco de trabajo
llamados región de tareas. Generalmente existen entre tres y seis regiones de tareas:
17
 Comunicación con el cliente: las tareas requeridas para establecer
comunicación entre el desarrollador y el cliente.
 Planificación: las tareas requeridas para definir recursos, el tiempo y otra

información relacionada con el proyecto.
 Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y de

gestión.
 Ingeniería: las tareas requeridas para construir una o más representaciones de

aplicación.
 Construcción y acción: las tareas requeridas para construir, probar, instalar y

proporcionar soporte al usuario (por ejemplo: documentación y practica).
 Evaluación del cliente: las tareas requeridas para obtener la reacción del
cliente según la evaluación de las representaciones de software creadas
durante la etapa de ingeniería e implementada durante la etapa de instalación.
2.4. Modelos Agiles

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el
término “ágil” aplicado al desarrollo de software. En esta reunión participan un grupo
de 17 expertos de la industria del software, incluyendo algunos de los creadores o
impulsores de metodologías de software. Su objetivo fue esbozar los valores y
principios que deberían permitir a los equipos desarrollar software rápidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretendía ofrecer una alternativa a los procesos de desarrollo de software

tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se
genera en cada una de las actividades desarrolladas.
18
Tras esta reunión se creó The Agile Alliance (La Alianza Ágil), una
organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados
con el desarrollo ágil de software y ayudar a las organizaciones para que adopten
dichos conceptos. El punto de partida es fue el Manifiesto Ágil, un documento que
resume la filosofía “ágil”. Introducción a la Agilidad y Scrum [Web 7]
2.4.1. Manifiesto Ágil

El Manifiesto Ágil comienza enumerando los principales valores del
desarrollo ágil. Según el Manifiesto se valora:
 Al individuo y las interacciones del equipo de desarrollo sobre el proceso

y las herramientas. La gente es el principal factor de éxito de un proyecto
software. Es más importante construir un buen equipo que construir el
entorno. Muchas veces se comete el error de construir primero el entorno y
esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y
que éste configure su propio entorno de desarrollo en base a sus necesidades.
 Desarrollar software que funciona más que conseguir una buena

documentación. La regla a seguir es “no producir documentos a menos que
sean necesarios de forma inmediata para tomar una decisión importante”.
Estos documentos deben ser cortos y centrarse en lo fundamental.
 La colaboración con el cliente más que la negociación de un contrato. Se

propone que exista una interacción constante entre el cliente y el equipo de
desarrollo. Esta colaboración entre ambos será la que marque la marcha del
proyecto y asegure su éxito.
 Responder a los cambios más que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.)
determina también el éxito o fracaso del mismo. Por lo tanto, la planificación
no debe ser estricta sino flexible y abierta.
19
2.4.2. Principios del Manifiesto Ágil
Los valores anteriores inspiran los doce principios del manifiesto, son
características que diferencian un proceso ágil de uno tradicional. Los dos primeros
principios son generales y resumen gran parte del espíritu ágil. El resto tienen que ver
con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y
organización del mismo. Los principios son:
1.- La prioridad es satisfacer al cliente mediante tempranas y continuas entregas

de software que le aporte un valor.
2.- Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva.
3.- Entregar frecuentemente software que funcione desde un par de semanas a un

par de meses, con el menor intervalo de tiempo posible entre entregas.
4.- La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del
proyecto.
5.- Construir el proyecto en torno a individuos motivados. Darles el entorno y el

apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
6.- El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
7.- El software que funciona es la medida principal de progreso.
8.- Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener una paz
constante.
9.- La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
10.- La simplicidad es esencial.
20
11.- Las mejores arquitecturas, requisitos y diseños surgen de los equipos
organizados por sí mismos.
12.- En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más
efectivo y según esto ajusta su comportamiento.
2.5. METODOLOGIA DE DESARROLLO SCRUM
Scrum se fundamenta en la teoría empírica de control de procesos, o

empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de
tomar decisiones basándose en lo que se conoce. Scrum emplea una aproximación
iterativa e incremental para optimizar la predictibilidad y controlar el riesgo. Tres
pilares soportan toda implementación del control empírico de procesos: transparencia,
inspección y adaptación.
 Transparencia: Los aspectos significativos del proceso deben ser visibles

para aquellos que son responsables del resultado. La transparencia requiere
que dichos aspectos sean definidos por un estándar común, de modo que los
observadores compartan un entendimiento común de lo que se está viendo.
 Inspección: Los usuarios de Scrum deben inspeccionar frecuentemente los

artefactos de Scrum y el progreso hacia un objetivo, para detectar variaciones
no deseables. Su inspección no debe ser tan frecuente como para que interfiera
en el trabajo. Las inspecciones son más beneficiosas cuando son realizadas de
forma diligente por inspectores expertos, en el mismo lugar de trabajo.
 Adaptación: Si un inspector determina que uno o más aspectos de un proceso

se desvían de límites aceptables, y que el producto resultante no será
aceptable, el proceso o el material que está siendo procesado deben ser
ajustados. Dicho ajuste debe ser realizado cuanto antes para minimizar
desviaciones mayores.
21
Scrum controla la evolución de un proyecto de forma empírica y adaptable
empleando las prácticas de la gestión ágil.
2.5.1. Revisión de las iteraciones

Al finalizar cada iteración (normalmente 30 días) se lleva a cabo una revisión
con todas las personas implicadas en el proyecto. Este es el periodo máximo que se
tarda en reconducir una desviación en el proyecto o en las circunstancias del
producto.
2.5.2. Desarrollo incremental

Durante el proyecto, las personas implicadas no trabajan con diseños o
abstracciones. El desarrollo incremental implica que al final de cada iteración se
dispone de una parte del producto operativa que se puede inspeccionar y evaluar.
2.5.3. Desarrollo Evolutivo

Los modelos de gestión ágil se emplean para trabajar en entornos de
incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales
cómo será el producto final y sobre dicha predicción desarrollar el diseño y la
arquitectura del producto no es realista, porque las circunstancias obligarán a
remodelarlo muchas veces.
Para qué predecir los estados finales de la arquitectura o del diseño si van a
estar cambiando. En Scrum se toma a la inestabilidad como una premisa, y se adoptan
técnicas de trabajo para permitir esa evolución sin degradar la calidad de la
arquitectura que se irá generando durante el desarrollo.
2.5.4. Auto-organización
Durante el desarrollo de un proyecto son muchos los factores impredecibles
que surgen en todas las áreas y niveles. La gestión predictiva confía la
responsabilidad de su resolución al gestor de proyectos. En Scrum los equipos son
22
auto-organizados (no auto-dirigidos), con margen de decisión suficiente para tomar
las decisiones que consideren oportunas.
2.5.5. Colaboración
Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del
equipo. Ésta es necesaria, porque para que funcione la auto-organización como un
control eficaz cada miembro del equipo debe colaborar de forma abierta con los
demás, según sus capacidades y no según su rol o su puesto.
2.5.6. Roles de SCRUM

Scrum clasifica a todas las personas que intervienen o tienen interés en el
desarrollo del proyecto en: propietario del producto, equipo, gestor de Scrum
(también Scrum Manager o Scrum Master) y “otros interesados”.
2.5.6.1. Roles Principales
a) Product Owner: El Product Owner representa la voz del cliente. Se asegura

de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del
negocio. El Product Owner escribe historias de usuario, las prioriza, y las
coloca en el Product Backlog.
b) Scrum Master (o Facilitador): El Scrum es facilitado por un Scrum Master,

cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo
alcance el objetivo del sprint. No es el líder del equipo (porque ellos se auto
organizan), sino que actúa como una protección entre el equipo y cualquier
influencia que le distraiga.
 Asegura de que el proceso Scrum se utiliza como es debido.
 El Scrum Master es el que hace que las reglas se cumplan.
c) Equipo de desarrollo: El equipo tiene la responsabilidad de entregar el
producto. Un pequeño equipo de 3 a 9 personas con las habilidades
23
transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo,
pruebas, documentación, etc.)
2.5.6.2. Roles Auxiliares

Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un
rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo
deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la
práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros
interesados (stakeholders). Es importante que esa gente participe y entregue
retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada
sprint.
a) Stakeholders (Clientes, Proveedores, Vendedores, etc.): Se refiere a la

gente que hace posible el proyecto y para quienes el proyecto producirá el
beneficio acordado que justifica su producción. Sólo participan directamente
durante las revisiones del sprint.
b) Administradores (Managers): Es la gente que establece el ambiente para el

desarrollo del producto.
2.5.7. Sprints
El corazón de Scrum es el Sprint, un bloque de tiempo (time-box) de un mes o
menos durante el cual se crea un incremento de producto “Hecho”, utilizable y
potencialmente entregable. La duración de los Sprints es consistente a lo largo del
esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la
finalización del Sprint previo.
Los Sprints contienen y consisten en la Reunión de Planificación del Sprint

(Sprint Planning Meeting), los Scrums Diarios (DailyScrums), el trabajo de
desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint
(Sprint Retrospective). Durante el Sprint:
24
 No se realizan cambios que afectarían al Objetivo del Sprint (Sprint Goal).
 La composición del Equipo de Desarrollo se mantiene constante.
 Los objetivos de calidad no disminuyen.
 El alcance puede ser clarificado y renegociado entre el Dueño de Producto y

el Equipo de Desarrollo a medida que se va aprendiendo más.
Cada Sprint puede ser considerado un proyecto con un horizonte no mayor de

un mes. Al igual que los proyectos, los Sprints se usan para obtener un logro. Cada
Sprint tiene una definición de qué va a ser construido, un diseño, y un plan flexible
que guiará la construcción, el trabajo y el producto resultante.
Los Sprints están limitados a un mes de calendario, cuando el horizonte de un

Sprint es demasiado amplio la definición de lo que se está construyendo podría
cambiar, la complejidad podría elevarse, y el riesgo podría aumentar. Los Sprints
habilitan la predictibilidad al asegurar la inspección y adaptación del progreso hacia
un objetivo, al menos en cada mes de calendario. Los Sprints también limitan el
riesgo al incurrido en el coste de un mes de calendario.
2.5.8. Elementos de SCRUM
2.5.8.1. Product backlog

Es un documento de alto nivel para todo el proyecto. Contiene
descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc.
priorizadas según su retorno sobre la inversión (ROI). Es el qué va a ser construido.
Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto
del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación
ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad
de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de
25
negocio la que requiera menor tiempo de desarrollo tendrá probablemente más
prioridad, debido a que su ROI será más alto.
2.5.8.2. Sprint backlog

Es un documento detallado donde se describe el cómo el equipo va a
implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas
con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas,
deberá ser divida en otras menores. Las tareas en el sprint backlog nunca son
asignadas, son tomadas por los miembros del equipo del modo que les parezca
oportuno.
Figura 2. 5. Funcionalidades y elementos de SCRUM

Fuente: [Palacio, 2007]
2.5.9. Fases de SCRUM

Se comienza con la visión general del producto, especificando y dando detalle
a las funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden
llevarse a cabo en un periodo de tiempo breve. Para esto necesitamos etapas las
cuales mencionaremos a continuación:
26
a) Planificación
 Objetivo: Es la etapa más importante de todas, ya que se define el

proyecto.
 Tareas: Relevamiento preliminar de los procesos del negocio, definición

y la secuencia de actividades, definición del alcance, estimación de
tiempos, definición de recursos, análisis de riesgos, estimación de costos.
 Entregable: Documento de definición del proyecto o del Sprint.
Los pasos de la planificación son los siguientes:
1. Desarrollo de un backlog completo.
2. Determinación de la fecha de entrega y la funcionalidad de una o más

versiones.
3. Selección de la versión más adecuada para desarrollo inmediato.
4. Trazado de los “paquetes del producto” (objetos) sobre los elementos del
backlog de la versión elegida.
5. Selección del equipo o equipos para desarrollar la nueva versión.
6. Evaluación y control adecuado de los riesgos.
7. Estimación del coste de la versión, incluyendo desarrollo, material,

marketing, formación y despliegue.
8. Conformidad de la dirección y financiación del proyecto.
b) Análisis
 Objetivo: Obtener definiciones y especificaciones funcionales para poder

llevar adelante las fases de Diseño y Construcción. Es una etapa clave ya
27
que el alcance y las características de la solución quedan acordadas, lo cual
permite mitigar los principales riesgos de un proyecto.
 Tareas: Afianzamiento de las definiciones funcionales, definición de los

requisitos a través de casos de uso, planificación de las etapas posteriores y
ajuste de los tiempos preestablecidos.
 Entregable: Documento de alcance, casos de uso y sus respectivas

descripciones.
Los pasos de diseño y arquitectura son los siguientes:
1. Revisión de los elementos del backlog incluidos en la versión.
2. Identificación de los cambios necesarios para implementar el backlog.
3. Análisis del dominio para incluir los requisitos que incluye el desarrollo
mejora o actualización.
4. Acotar la arquitectura del sistema para apoyar el nuevo contexto y

necesidades.
5. Identificar problemas del desarrollo o modificaciones.
6. Reunión de revisión de diseño. Cada equipo presenta los cambios para

implementar los elementos del backlog, e identificar posibles
reasignaciones.
c) Los pasos del desarrollo (Sprint)
La fase de desarrollo es un ciclo de trabajo repetitivo. La gestión determina el

cumplimiento de los tiempos, funcionalidad y calidad. Este enfoque es conocido
también como ingeniería concurrente. El desarrollo consiste en los siguientes
macro-procesos:
 Reunión con los equipos para revisar los planes de lanzamiento de versión.
28
 Distribución, revisión y ajuste de los estándares de conformidad para el
producto.
 Sprints iterativos hasta que el producto se considera listo para su

distribución.
Un sprint es un conjunto de actividades de desarrollo llevado a cabo durante un

periodo predefinido, por lo general entre una y cuatro semanas. Duración basada
en la complejidad del producto, evaluación de riesgos y grado de supervisión
deseado. El riesgo se evalúa de forma continua a través de las respuestas a los
controles adecuados establecidos.
2.6. SCRUM APLICADO AL DESARROLLO DE SOFTWARE
Aunque surgió como modelo para el desarrollo de productos tecnológicos,

también se emplea en entornos que trabajan con requisitos inestables y que requieren
rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados
sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en

Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se
integraría en VMARK, luego en Informix y finalmente en Ascential Software
Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal,
también para gestión del desarrollo de software en OOPSLA 96. En el desarrollo de
software Scrum está considerado como modelo ágil por la Agile Alliance.
La intención de Scrum es la de maximizar la realimentación sobre el

desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso
se está extendiendo cada vez más dentro de la comunidad de Metodologías Ágiles,
siendo combinado con otras como “XP” para completar sus carencias. Cabe
mencionar que Scrum no propone el uso de ninguna práctica de desarrollo en
29
particular; sin embargo, es habitual emplearlo como un framework ágil de
administración de proyectos que puede ser combinado con cualquiera de las
metodologías mencionadas.
2.6.1. Ciclo de Vida de Scrum
2.6.1.1. Pre-Juego: Planeamiento y Montaje (Staging)

El propósito es establecer la visión, definir expectativas y asegurarse la
financiación. Las actividades son la escritura de la visión, el presupuesto, el registro
de acumulación o retraso (backlog) del producto inicial y los ítems estimados, así
como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro
de acumulación es de alto nivel de abstracción.
El propósito es identificar más requerimientos y priorizar las tareas para la

primera iteración. Las actividades son planificación, diseño exploratorio y prototipos.
2.6.1.2. Juego o Desarrollo

El propósito es implementar un sistema listo para entrega en una serie de
iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son un
encuentro de planeamiento de corridas en cada iteración, la definición del registro de
acumulación de corridas y los estimados, y encuentros diarios de Scrum.
2.6.1.3. Post-Juego: Liberación

El propósito es el despliegue operacional. Las actividades, documentación,
entrenamiento, mercadeo y venta. Usualmente los registros de acumulación se llevan
en planillas de cálculo comunes, antes que en una herramienta sofisticada de gestión
de proyectos. Los elementos del registro pueden ser prestaciones del software,
funciones, corrección de bugs, mejoras requeridas y actualizaciones de tecnología.
Hay un registro total del producto y otro específico para cada corrida de 30 días. En la
30
jerga de Scrum se llaman “paquetes” a los objetos o componentes que necesitan
cambiarse en la siguiente iteración.
Figura 2. 6. Ciclo de vida de SCRUM

Fuente: [Palacio, 2007]
2.7. INGENIERIA WEB
“La ingeniería Web está relacionada con el establecimiento y utilización de

principios científicos, de ingeniería, gestión, y con enfoques sistemáticos y
disciplinados del éxito y desarrollo, empleo y mantenimiento de sistemas y
aplicaciones basados en la Web de alta calidad”. [Pressman, 2002]
Los sistemas y aplicaciones Web hacen posible que las personas puedan
acceder a recursos ofrecidos en Internet, estos deben ofrecer gran funcionalidad y
contenido.
31
2.8. METODOLOGÍA DE DESARROLLO DE APLICACIONES WEB
Dentro de la variabilidad que ofrecen los sistemas de información global,
existen muchas tendencias de metodologías que ofrecen diferentes marcos que los
desarrolladores pueden asumir a la hora de realizar su trabajo. Estos trabajos están
orientados a diferentes entornos de trabajo: aplicaciones multimedia, aplicaciones
web bibliotecas digitales entre otras.
UWE es un enfoque de ingeniería de software para el dominio Web con el

objetivo de cubrir todo el ciclo de vida de desarrollo de aplicaciones Web, Es aspecto
clave que distinguen a UWE es la confianza en las normas. UWE (UML-Based Web
Engineering) es una propuesta basada en UML y en el proceso unificado para
modelar aplicaciones Web. Los sistemas adaptativos y la sistematización son dos
aspectos sobre los que se enfoca UWE. Además de estar considerado como una
extensión del estándar UML, también se basa en otros estándares como ser XMI
como modelo de intercambio de formato, MOF para el metamodelado, los principios
de modelado de MDA y el modelo de transformación del lenguaje QVT y XML.
El modelo que propone UWE está compuesto por 6 etapas o sub-modelos:
1.- Modelos de Casos de Uso: modelo para capturar los requisitos del sistema.
2.- Modelo de Contenido: es un modelo conceptual para el desarrollo de

contenidos.
3.- Modelo de Navegación: en el cual se encuentra la presentación del sistema y

el modelo de flujo.
4.- Modelo de proceso: incluye el modelo de la interfaz de usuario y el modelo de

ciclo de vida del objeto.
32
5.- Modelo de Presentación: En cuanto a los requisitos, UWE los clasifica
dependiendo del carácter de cada uno. Además distingue entre las fases de
captura, definición y validación de requisitos.
2.9. INGENIERIA WEB BASADA EN UML (UWE)
Es un proceso de desarrollo para aplicaciones Web enfocado sobre el diseño

sistemático, la personalización y la generación semiautomática de escenarios que
guíen el proceso de desarrollo de una aplicación Web. UWE describe una
metodología de diseño sistemática, basada en las técnicas de UML, la notación de
UML y los mecanismos de extensión de UML.
2.9.1. Fases UWE

UWE cubre todo el ciclo de vida de este tipo de aplicaciones centrando
además su atención en aplicaciones personalizadas o adaptativas.
a) Fase de requisitos: Trata de diferente forma las necesidades de información,

las necesidades de navegación, las necesidades de adaptación y las de interfaz
de usuario, así como algunos requisitos adicionales. Centra el trabajo en el
estudio de los casos de uso, la generación de los glosarios y el prototipado de
la interfaz de usuario.
b) Fase de análisis y diseño: UWE distingue entre diseño conceptual, de modelo

de usuario, de navegación, de presentación, de adaptación, de la arquitectura,
en el diseño detallado de las clases y en la definición de los subsistemas e
interfaces.
c) Fase de implementación: UWE incluye implementación de la arquitectura,

de la estructura del hiperespacio, del modelo de usuario, de la interfaz de
usuario, de los mecanismos adaptativos y las tareas referentes a la integración
de todas estas implementaciones.
33
Figura 2. 7. Fases de UWE
Fuente: Introducción a la Ingeniería Web
2.9.2. Modelo de Caso de Uso

Un caso de uso especifica el comportamiento de un sistema o una parte del
mismo y es una descripción de un conjunto de secuencias de acciones, donde cada
secuencia representa la interacción de los elementos externos del sistema (sus actores)
con el propio sistema. Un caso de uso representa un requerimiento funcional de
sistema.
 Identificar actores: Los actores son mejor dicho, los roles que un usuario o
usuarios del sistema llevan a cabo en algún momento del tiempo. También
pueden ser otros sistemas con los que el 'sistema' en proceso de modelado
tiene interacción.
 Identificar Metas (Metas, objetivos generales o responsabilidades): Todos

los actores en el entorno a modelar tienen metas u objetivos, o en su defecto
responsabilidades, o en su defecto, acciones que desean realizar u obtener del
sistema.
34
 Obtener o identificar los Casos de Uso a partir de las Metas: Las metas
son importantes porque a partir de su identificación pasamos a realizarlas y
estas se convierten en los Casos de Uso, de esta forma tan sencilla obtenemos
la información de funcionalidad que requiere nuestro sistema.
 Especificar cada Caso de Uso: Una vez identificados seguimos a

especificarlos uno a uno, es probable que en el inter, de esos sencillos pasos
algunos casos de uso desaparezcan o se fusionen con otros, por ambigüedades
detectadas o por detalles que se hayan escapado durante el proceso.
Figura 2. 8. Modelo simple de caso de uso

Fuente: Elaboración Propia
2.9.3. Modelo de Contenido

Este modelo especifica cómo se encuentran relacionados los contenidos del
sistema, es decir, define la estructura de los datos que se encuentran alojados en el
sitio web. A continuación se muestra un ejemplo de este modelo contenido en la
página web de UWE.
Figura 2. 9. Modelo de contenido

Fuente: Elaboración propia
35
2.9.4. Modelo de Navegación
Este modelo indica como el sistema de páginas web del sitio está relacionado
internamente, esto quiere decir que es como se enlazan los elementos de navegación.
Para ello se utilizan unidades de navegación llamados “nodos” conectadas por

enlaces de navegación. Estos nodos pueden ser representados en la misma página
web, no tienen por qué estar en páginas diferentes. Los elementos para representar la
estructura de este modelo son los siguientes:
Figura 2. 10. Representación para el modelo de navegación

Fuente: Estudio de UWE
2.9.5. Modelo de Presentación

El Modelo de Navegación no indica cuáles son las clases de navegación y de
proceso que pertenecen a una página web, si deseamos tener esta información se usa
el Diagrama de Presentación.
Agrega una «presentationPage» class y agrega las propiedades con los

estereotipos de UWE en ellos para expresar, que el elemento está ubicado en una
36
página web. Las propiedades pueden anidarse, por ejemplo cada contacto
(«presentationGroup»-property) cubre diferentes textos y botones. Ello significa, que
para cada contacto la correspondiente dirección de correo y los correspondientes
campos de teléfonos y direcciones serán visualizados en la página. En los siguientes
diagramas, los estereotipos son solamente representados por sus iconos.
Figura 2. 11. Representación para el modelo de presentación

37
2.9.6. Modelo de Proceso
2.9.6.1. Modelo de Estructura del Proceso

Con el fin de describir las relaciones entre las diferentes clases de proceso,
creamos un diagrama de clases, usando la transformación de navegación a estructura
de proceso.
Figura 2. 12. Representación de la Estructura de Procesos

Como puede observarse en la figura 2.12 tiene agregada otras clases para
expresar, que las tres operaciones requieren una confirmación con una pregunta. Esto
significa que si un usuario quiere borrar un contacto, un mensaje será mostrado, el
cual deberá ser confirmado con un ok para que el contacto sea borrado.
38
2.9.6.2. Modelo de Flujo de Proceso
Un flujo del proceso (flujo de trabajo) es representado como un diagrama
de actividades, describiendo el comportamiento de una clase de proceso, por ejemplo
que sucede en detalle, cuando el usuario navega a una clase de proceso.
Podemos seleccionar nuestro diagrama de navegación y ejecutar la transformación de
navegación a flujo del proceso.
Figura 2. 13. Representación de Flujo de Proceso

2.10. UNIDAD DE PROTECCION ANIMAL Y ZOONOSIS
La Unidad de Protección Animal y Zoonosis es una institución pública que

depende de la Dirección de Salud y está a la vez del Gobierno Autónomo Municipal
de La Paz, según la nueva ordenanza municipal 511/2005 tiene como marco general
39
el normar, regular y brindar los instrumentos de control necesarios para la tenencia y
protección de animales en el Municipio de La Paz, los objetivos que debe cumplir
esta unidad son los siguientes:
a) Promover la protección, vigilar y regular la crianza, el crecimiento y la vida

de los animales domésticos, de ayuda laboral y con fines deportivos evitando
el deterioro del medio ambiente.
b) Promover la protección regular y vigilar la crianza, el crecimiento, la vida y el

sacrificio (faenado) de los animales de consumo útiles al ser humano, así
como regular la posesión de animales silvestres fuera de su hábitat natural, en
peligro de extinción, y los que por su especie y peligrosas pueden poner en
riesgo al ser humano, manteniéndose así el respeto, equilibrio, convivencia y
orden en la comunidad con respecto a la vida.
c) Impulsar el trato racional y humanitario hacia los animales domésticos, de

consumo, de ayuda laboral, con fines deportivos, silvestres y salvajes,
contribuyendo a la educación y formación del propietario, a su superación
personal, familiar y social, inculcándoles responsabilidades humanitarias
hacia los animales.
d) Propiciar el respeto y consideración a las diferentes especies animales,

domésticos y no domésticos, erradicando y sancionando el maltrato así como
los actos de crueldad innecesarios para con los mismos.
e) Compatibilizar la seguridad, tranquilidad y salud de la ciudadanía, con la

tenencia de animales.
f) Determinar a través del registro de identificación de animales, su tenencia,

comercialización, tránsito y transporte.
g) Establecer las prohibiciones y sanciones de la tenencia de animales en el

Municipio de La Paz.
40
2.10.1. Misión
Evitar la transmisión de las enfermedades Zoonóticas al hombre, actualizando
y difundiendo las normas de atención de rabia y de las diferentes zoonosis para
lograr una óptima vigilancia epidemiológica del Programa y pueda ser manejado en
todos los niveles de atención de los servicios de salud y así cortar con la circulación
del virus rábico y otros parásitos en el departamento de La Paz.
2.10.2. Visión
Controlar la circulación del virus rábico y de los parásitos para reducir la
incidencia de estas zoonosis, así como prevenir la transmisión del virus rábico y otros
parásitos de los animales al ser humano, sensibilizando a la población y brindando a
todos los habitantes del departamento el tratamiento oportuno, para evitar el
desarrollo de estas enfermedades mejorando así la calidad de vida de la población.
2.10.3. Organigrama de la Unidad de Protección Animal y Zoonosis
 Jefe de la Unidad: Es la persona encargada de dirigir, coordinar, controlar, y

evaluar la ejecución de los programas y el cumplimiento de la funciones
generales de la Unidad de Protección Animal y Zoonosis.
 Funcionario: Son todas aquellas personas que se encargan de recibir

denuncias, extender certificados de matriculación, recaudaciones además de
proveer los servicios de alimentación de animales, mantenimiento de
vehículos y los equipos necesarios en veterinaria.
 Veterinario General: Es la persona encargada de recibir los casos de

atención médico – veterinaria presentadas en la Unidad.
 Capturadores/Choferes: Son las personas encargadas de realizar diariamente

recorridos programados con los vehículos de captura recogiendo canes en vías
y áreas públicas y también por denuncias u otros casos.
41
Cabe mencionar que la Unidad de Protección Animal y Zoonosis consta de cuatro
áreas para poder cumplir con todos sus objetivos, estas áreas son las siguientes:
1) Área de Tenencia, Control y Protección de animales
Control de Rabia (en coordinación con SEDES).

 Atención de denuncias de agresiones de animales sospechosos de rabia.
 Observación de animales sospechosos de rabia.
 Vacunaciones gratuitas contra la rabia (en campañas y en sus instalaciones).
 Captura y eliminación de canes callejeros.
 Registro de animales domésticos.
 Atención clínica gratuita de animales (en coordinación S.O.S).
 Esterilizaciones gratuitas (por zonas y en la institución).
Control de enfermedades zoonóticas por contacto con perros y gatos
 Hongos
 Parásitos internos y externos
Educación sobre tenencia y protección de animales (en coordinación con el
Ministerio de Educación, Organización Mundial de la Salud y Juntas Vecinales)
 Educación en escuelas sobre Tenencia y Protección de animales.
 Educación a comercializadores de productos de origen animal (cárnicos).
 Educación a juntas vecinales sobre tenencia y protección de animales.
 Educación en instituciones que lo soliciten (Ej.: Intendencia, Policía, Ejército,
Enfermeras, etc.)
Control de Moscas, Cucarachas, Ratones, Palomas y otros
 Fumigaciones y desratización (mercados, locales de comercialización de
alimentos, expendio de comidas y bebidas, centros hospitalarios).
2) Área de Control de Vectores

 Reubicación de criaderos de vacas, cerdos, conejos y otros.
 Control de venta de comercialización de animales domésticos (en
coordinación con SENASAG).
42
 Control de la venta de animales silvestres (en coordinación con la Dirección
General de Biodiversidad).
3) Área de Control de Establecimientos Veterinarios
4) Área de Inspección de Venta de Productos Cárnicos
 Control en la venta de carne de cerdo (Programa Teniasis/ Cisticercosis en

coordinación con SENSAG, SEDES y prefectura).
 Control de la venta de carnes en mal estado (Pollo, pescado, cerdo, bovino,
ovino).
 Control de subproductos de origen animal (Chorizos, salchichas, embutidos).
 Control de zoonosis parasitarias (hidatidosis, fasciolasis, sarcocistiosis).
 Control de zoonosis bacterianas (Tuberculosis, brucelosis, etc.)
UNIDAD DE PROTECCION ANIMAL Y ZOONOSIS
JEFE DE UNIDAD
SEGURIDAD COCINA
CAPTURADORES/
PORTERIA
CHOFERES
AREA DE TENENCIA AREA DE AREA DE AREA DE INSPECCION DE

CONTROL Y CONTROL DE CONTROL DE VENTA DE PRODUCTOS
PROTECCCION VECTORES VETERINARIAS CARNICOS
Figura 2. 14. Organigrama de la Unidad

43
2.10.4. Precedentes de la Unidad de Protección Animal y Zoonosis
La Unidad de Protección Animal y Zoonosis realiza sus actividades con un
sistema de control manual, en la iniciación de la unidad debido a la poca fluidez de
información que había en los diferentes procesos era relativamente fácil realizar sus
actividades pero con el pasar del tiempo la cantidad de información fue creciendo y el
trabajo se fue haciendo moroso y con generación de redundancia de datos.
Actualmente todos sus registros se los lleva a cabo en cuadernos, libros de

anotaciones de animales domésticos maltratados, abandonados, registrados, perdidos,
etc. Se debe permitir su introducción en un sistema para que la información sea útil,
oportuna y confiable, en base a un procesamiento inmediato y concreto lo cual
permitirá un control adecuado.
La Dirección de Zoonosis opera de la siguiente forma, diariamente se realizan

recorridos programados con los vehículos de captura, recogiendo canes en vías y
áreas públicas.
 Los canes atrapados con placa de identificación son trasladados

individualmente (sin contacto con ningún otro can), depositado en un canil
exclusivo hasta que su dueño lo reclame con documentación (certificado de
vacunas y registro) una vez que el propietario cumple con todo se devuelve al
can previo pago de gastos y multas.
 Los canes que no tienen propietario se trasladan aun canil colectivo para su
eliminación y los cuerpos inertes son dispuestos apropiadamente en un relleno
sanitario.
 De los perros capturados el 70% son eliminados por la Unidad, pero solo con
este método cruel se podrá llegar a controlar la sobrepoblación canina.
44
 El 40% delos canes capturados vuelven a reincidir en sus capturas después de
haber sido registrados, vacunados y de instruir a sus propietarios sobre la
tenencia y protección de animales.
 El 90% de los canes capturados presentan heridas, tumores, parásitos externos

(sarna, pulgas, etc.,) e internos (áscaris y teniasis), fracturas, gestación, celo,
etc.
 De las canes hembras callejeras y vagabundas a veces en celo, gestación y/o

lactancia, en un año aumentarían la población canina de la mayoría llegan a
ser vagabundos y así continua el ciclo sin ningún tipo de control.
Las personas que llegan a ser agredidas por un can presentan su denuncia del
caso para que la unidad tome acciones de traslado o recojo del can mordedor a un
canil para su observación por 10 días, al cabo de ese periodo si no se presenta
síntomas de rabia canina es devuelto a su propietario, previa vacunación, registro,
pago de gastos de operación y compensación de daños y perjuicios al damnificado.
Actualmente con la nueva Ordenanza Municipal la Unidad de Protección

Animal y Zoonosis dentro del Área de Tenencia Control y Protección de Animales se
tiene un módulo de educación que en coordinación con la Dirección de Salud,
Ministerio de Educación y Juntas vecinales se realizan seminarios sobre Tenencia y
Protección de animales además se cuenta con el asesoramiento de la Organización
Panamericana de la Salud (OPS).
2.11. HERRAMIENTAS
2.11.1. Apache
Un servidor de páginas es la parte primordial de cualquier sitio de internet, ya
que es el encargado de generar y enviar la información a los usuarios finales. Apache
es uno de los Servidores de Páginas Web más utilizados, posiblemente porque ofrece
45
instalaciones sencillas para establecimientos pequeños y si se requiere es posible
expandir hasta el nivel de mejores productos comerciales. Este servidor es capaz de
utilizar otros interpretadores y lenguajes como TCL, PHP, y PYTHON, además
puede conectarse directamente a una base de datos. Cabe notar que si no se tienen los
suficientes recursos en cuanto a memoria y procesadores se refiere, seguramente
caerá el servidor de páginas o bien se queme el “Host” (hardware) por la demanda
excesiva. Gracias a que Apache tiene bastante tiempo de desarrollo se han ido
desarrollando diferentes soluciones para evitar ineficiencias.
2.11.2. PHP (Hyper Text Preprocessor)

Este lenguaje sofisticado fue creado por Rasmus Lerdorf para uso personal en
1994, Es un módulo que se añade al servidor web y fue concebido inicialmente para
Apache Para la creación de páginas HTML dinámicas a lo largo de la historia
inicialmente se usó programas C que devolvían información en hipertexto por su
salida estándar. Los scripts PHP están incrustados en los documentos HTML y el
servidor los interpreta y ejecuta antes de servir las páginas al cliente. La aparición de
soluciones más adecuadas y sencillas hace que PHP se convierta en la mejor opción
actual para multitud de necesidades. Algunas de sus características son:
 Potente, fácil de aprender y de libre distribución.

 Permite el acceso a bases de datos y otras funcionalidades orientadas a la red.
 Dispone de abundante soporte en la Web.
 PHP es un lenguaje de script del lado del servidor.
 El cliente no ve el código PHP sino los resultados que produce
 Actualmente es uno de los paquetes para programación más utilizados.
2.11.3. MySQL
MySQL es un sistema de administración de bases de datos en la que se puede
agregar, accesar y procesar la colección estructurada de información almacenada. La
información que se puede almacenar en una base de datos puede ser tan simple como
46
la de una agenda, un contador, o un libro de visitas o tan vasta como la de una tienda
en línea, un sistema de noticias, un portal o la información generada en una red
corporativa.
Es el servidor de bases de datos relacionales más popular, desarrollado y

proporcionado por MySQL AB, empresa cuyo negocio consiste en proporcionar
servicios en torno al servidor de bases de datos MySQL. Usa la licencia GPL
(Licencia Pública General de GNU), para definir qué es lo que se puede y que no se
puede hacer con el software para diferentes situaciones.
El servidor MySQL fue desarrollado originalmente para manejar grandes

bases de datos mucho más rápido que las soluciones existentes y ha estado siendo
usado exitosamente en ambientes de producción sumamente exigentes por varios
años. Aunque se encuentra en desarrollo constante, el servidor MySQL ofrece hoy un
conjunto rico y útil de funciones. Algunas de sus características son las siguientes:
 El principal objetivo de MySQL es velocidad y robustez.
 Soporta gran cantidad de tipos de datos para las columnas.
 Gran portabilidad entre sistemas, puede trabajar en distintas plataformas y

sistemas operativos.
 Aprovecha la potencia de sistemas multiproceso, gracias a su implementación

multihilo.
 Su conectividad, velocidad, y seguridad hacen de MySQL un servidor

bastante apropiado para accesar a bases de datos en Internet.
 Flexible sistema de contraseñas (passwords) y gestión de usuarios, con un

muy buen nivel de seguridad en los datos.
 El servidor soporta mensajes de error en distintas lenguas.
47
CAPÍTULO III
MARCO APLICATIVO
3.1. INTRODUCCION
En este capítulo se aplicaran los fundamentos teóricos mencionados

anteriormente que se enfocan en el análisis y diseño correspondiente al sistema,
dando curso a que Scrum es una metodología de desarrollo ágil, que requiere de
trabajo duro porque la gestión no se basa en el seguimiento de un plan sino más bien
a la adaptación continua de las circunstancias de la evolución del proyecto.
Para trabajar exitosamente con SCRUM y UWE se necesita entender el

proceso de desarrollo con SCRUM, en la figura 3.1 que nos muestra cómo se acopla
UWE en SCRUM. Se optó por UWE por ser una versión liviana de UML que no
genera una gran cantidad de documentación, lo que respeta uno de los puntos que
valora más el desarrollo ágil de software que es “software que funciona sobre
documentación comprensiva”.
Figura 3. 1. Adaptación de SCRUM y UWE

48
3.2. PRE-GAME
3.2.1. Recopilación de requerimientos

Durante la fase de creación de la Backlog del producto (Pila de Producto) se
capturaran los requerimientos de los usuarios, los cuales serán ítems de la pila del
producto. Si bien se obtendrá el mayor número de requerimientos posible, la
priorización de los mismos será realizada por el Propietario del Producto, que en este
caso será la el Dr. Héctor Mencias Gutiérrez responsable de la Unidad de Protección
Animal y Zoonosis.
N° Descripción Estado
1 Modelar la Base de Datos. Terminado
2 Desarrollar el Modelo Web con UWE (General). Terminado
3 Configurar PHP y MySQL para desarrollo del sistema. Terminado
4 Generar entidades en MySQL de acuerdo al modelado de la Terminado
Base de Datos.
5 Realizar pruebas automatizadas en las entidades generadas. Terminado
6 Mejorar los modelos de UWE para el Registro de Persona Terminado
7 Desarrollar el Modulo de Gestión de Usuarios. Terminado
8 Realizar pruebas del Módulo de Gestión de Usuarios. Terminado
9 Mejorar los modelos de UWE añadiendo autentificación. Terminado
10 Desarrollar el Modulo de Autenticación del Sistema. Terminado
11 Realizar pruebas del Módulo de Autenticación del Sistema. Terminado
12 Integración del Sistema. Terminado
13 Mejorar los modelos UWE añadiendo el Registro de Mascotas Terminado
con sus respectivos propietarios.
14 Desarrollar el módulo de Registro de Mascotas. Terminado
15 Realizar pruebas al módulo de Registro de Mascotas. Terminado
49
17 Mejorar el modelo UWE añadiendo el Registro de Denuncias. Terminado
18 Desarrollar el módulo de Registro de Denuncias. Terminado
19 Realizar pruebas al módulo de Registro de Denuncias. Terminado
21 Mejorar los modelos UWE para el módulo de Administración de Terminado
Sistema.
22 Desarrollar el módulo de Administración de Sistema. Terminado
23 Realizar pruebas al módulo de Administración de Sistema. Terminado
25 Desarrollo del Módulo de reportes. Terminado
26 Corrección de Bugs. Terminado
27 Puesta en Marcha Final del Sistema. Terminado
Tabla 3. 1. Requerimientos
3.2.2. Definición de “Hecho”

En nuestro caso “Hecho” significara a lo largo del desarrollo del proyecto
“Codificado según estándares, revisado, documentado, implementado, probado e
integrado”.
3.2.3. Análisis de riesgo

Un riesgo es la probabilidad de que ocurra algo adverso en la planificación o
realización de cualquier actividad relacionada con el proyecto. Existen 3 tipos de
riesgo:
1. Riesgo del proyecto: que afecta a la calendarización o recursos del proyecto.
2. Riesgo del producto: que afectan a la calidad o rendimiento del software que
se está desarrollando.
50
3. Riesgo del negocio: afecta a la organización que desarrolla o suministra el
software.
Riesgo Tipo Probabilidad Efecto Estrategia
Realizar otro
No cumplir con
Proyecto Alta Tolerable cronograma más
fechas establecidas
flexible
Proyecto Realizar revisión
constante a los
Cambio repentino en requerimientos
Moderada Tolerable
los requerimientos Producto Programar
reuniones con los
funcionarios
Agilizar los
No cumplir con
procesos de
plazos de entrega del Producto Moderada Serio
desarrollo del
producto
producto
No existe recursos Solicitar recursos
necesarios para Proyecto Baja Tolerable necesarios con
implementación anticipación
Tabla 3. 2. Análisis de riesgos

3.3. GAME
Durante esta etapa del proyecto se desarrollaron 4 iteraciones, cada una de

ellas corresponde a un elemento del Sistema: Registro, Denuncias e Información. A
continuación se desglosan las actividades realizadas en cada una de las etapas.
La estrategia para el desarrollo de cada iteración es construir en un principio

los modelos de la metodología UWE y posteriormente implementarlos utilizando
como elemento central la Base de Datos “MySQL”. Las clases y sus métodos fueron
implementados en lenguaje PHP. Finalmente se desarrollaron las páginas Web en
base a los modelos de presentación y navegación.
51
3.3.1. Primera iteración
Durante la primera iteración se desarrollaron los elementos pertenecientes a la
Plataforma de registro y control de la Unidad de Protección Animal y Zoonosis. Las
actividades realizadas durante esta iteración se observa en la siguiente tabla,
constituye el Backlog del Sprint.
Sprint Inicio Duración

1 06-06-2014 30 días
Nro. Tarea del Sprint Tipo Tiempo Estado

(Días)
1.1 Realizar la planificación de la Planificación
4 Terminado
iteración
1.2 Analizar el Backlog del producto Planificación 4 Terminado
1.3 Analizar los Casos de uso Desarrollo 2 Terminado
1.4 Construir el modelo de contenidos Desarrollo 2 Terminado
1.5 Construir el modelo de usuario Desarrollo 2 Terminado
1.6 Construir el modelo de navegación Desarrollo 2 Terminado
1.7 Construir el modelo de procesos Desarrollo 2 Terminado
1.8 Construir el modelo de presentación Desarrollo 2 Terminado
1.9 Desarrollar la página de ingreso Desarrollo 3 Terminado
1.10 Desarrollar módulo de registro nuevo Desarrollo
7 Terminado
propietario
Tabla 3. 3. Primera Iteración

Las funcionalidades correspondientes al incremento de la iteración son:
 Base de datos independiente del sistema
 Página de ingreso con control de acceso a los usuarios
52
3.3.2. Segunda iteración
En esta iteración se desarrollaron los sistemas para el proceso y seguimiento
de los procesos del registro de mascotas.

2 20-07-2014 30 días

(Días)
2.1 Realizar la planificación de la Planificación 3 Terminado
iteración
2.4 Completar el modelo de contenidos Desarrollo 1 Terminado
2.5 Completar el modelo de usuario Desarrollo 1 Terminado
2.6 Completar el modelo de navegación Desarrollo 1 Terminado
2.7 Completar el modelo de procesos Desarrollo 1 Terminado
2.8 Completar el modelo de presentación Desarrollo 1 Terminado
2.9 Desarrollar el modulo para registro Desarrollo 8 Terminado
de usuarios
2.10 Desarrollar módulo de denuncias Desarrollo 8 Terminado
Tabla 3. 4. Segunda Iteración

En la segunda iteración se desarrollaron las siguientes funcionalidades para el

Sistema:
 Módulo de registro de mascotas
 Módulo de emisión de reportes
53
3.3.3. Tercera iteración
En esta iteración se desarrollaron los sistemas para el almacenamiento de
información en el Sistema.

3 01-08-2014 30 días
(Días)
iteración
3.9 Desarrollar el módulo de Desarrollo 8 Terminado
información del Sistema
3.10 Desarrollar módulo de búsqueda Desarrollo 8 Terminado
Tabla 3. 5. Tercera Iteración

En la tercera iteración se desarrollaron las siguientes funcionalidades para el

sistema:
 Desarrollo del reporte de denuncias externas por distrito
 Desarrollo del reporte de la cantidad de razas registradas
 Desarrollo del reporte de las ganancias generadas según servicios
54
 Desarrollo del reporte de la lista de canes con antecedentes o de razas
consideradas peligrosas.
3.3.4. Cuarta iteración

Finalmente durante la cuarta iteración se desarrollaron los sistemas para los
procesos y seguimiento de los procesos de Registro y Control de mascotas. Las
actividades realizadas durante esta iteración se las puede observar en la siguiente
tabla:

4 12-09-2014 30 días

(Días)
iteración
4.9 Desarrollar el módulo de mis Desarrollo 8 Terminado
propietarios
4.10 Desarrollar el módulo de control de Desarrollo 8 Terminado
enfermedades y vacunas
Tabla 3. 6. Cuarta Iteración

55
3.3.5. Modelo de Casos de Uso
El modelo de casos de uso es un diagrama del sistema que contiene actores,
casos de uso y sus perspectivas relacionales. A continuación se describen las
características de los actores identificados en el manejo e implementación del
sistema.
Actores Descripción
Administrador - Jefe de Toma conocimiento de los reportes que se le entrega

la Unidad cada mes o cuando se necesita.
Funcionario de la Realiza registro de propietarios y su(s) mascota(s) y

Unidad denuncias realizadas en la unidad.
Veterinaria autorizada Realiza registro de propietario(s) y su(s) mascota(s).
Propietario de mascota Interesado en la información de su(s) mascota(s).
Tabla 3. 7. Descripción de actores

3.3.5.1. Diagrama de Casos de Uso General

Los casos de uso describirán la secuencia de eventos de un actor, es decir
es un documento narrativo de los actores del sistema para completar.
56
Figura 3. 2. Diagrama de Casos de Uso General
3.3.5.2. Descripción de Casos de Uso
CASO DE USO Registro de Persona

Actor Administrador
Descripción El sistema debe poder almacenar los datos personales del
funcionario y/o veterinario (C.I., Apellidos, Nombres, dirección,
teléfono). Para administrar de forma adecuada se debe llevar un
archivo total del personal.
Tipo Primario
Tabla 3. 8. Descripción de Caso de Uso "Registro de persona"

57
CASO DE USO Asignar rol al usuario
Actor Administrador
Descripción El sistema debe poder almacenar los datos de los Usuario (Login,
password), para administrar de forma segura los usuarios del
sistema.
Tipo Primario
Tabla 3. 9. Descripción de Caso de Uso "Asignar rol al usuario"

CASO DE USO Generar reportes
Actor Jefe de la Unidad de Protección Animal y Zoonosis

Descripción El sistema debe poder generar reportes (formato pdf) de
importancia definidos por el administrador.
Tipo Primario
Tabla 3. 10. Descripción de Caso de Uso "Generar reportes"

CASO DE USO Registro de propietarios
Actor Funcionario público y veterinaria

Descripción El sistema debe poder almacenar los datos personales Propietario
de Mascota (C.I., Apellidos, Nombres, dirección, teléfono). Para
administrar de forma adecuada se debe llevar un archivo total de
los propietarios de mascotas.
Tipo Primario
Tabla 3. 11. Descripción de Caso de Uso "Registro de propietario"

58
CASO DE USO Registro de mascotas

Descripción El sistema debe poder almacenar los datos de las mascotas de un
propietario (nombre, raza, color, pelaje, tamaño, sexo, fecha de
nacimiento, procedencia, función, signos particulares,
antecedentes), también de mascotas que no tengan propietario.
Para administrar de forma adecuada se debe llevar un archivo total
de mascotas con propietario o sin propietario.
Tipo Primario
Tabla 3. 12. Descripción de Caso de Uso "Registro de mascotas"

CASO DE USO Registro de denuncias
Actor Funcionario publico

Descripción El sistema debe poder almacenar los datos de las Denuncias
Internas (fecha de la denuncia, fecha del suceso, tipo, lugar del
suceso, distrito, nro. jaula, raza, color, pelaje, sexo, observación,
Usuario que registra) y Externas (fecha de la denuncia, fecha del
suceso, tipo, lugar del suceso, nombre completo, tipo de animal,
nombre del propietario, ci, dirección, teléfono) también de
mascotas que no tengan propietario. Para administrar de forma
adecuada se debe llevar un archivo total de mascotas con
propietario o sin propietario.
Tipo Primario
Tabla 3. 13. Descripción de Caso de Uso "Registro de denuncias"

59
CASO DE USO Registro de la libreta de salud
Descripción El sistema debe poder almacenar los datos de la libreta de salud de

la Mascota como ser desparasitaciones (fecha, producto, fecha de
la próxima desparasitación), control de celo en caso de ser
hembra (fecha, fecha del próximo control), vacunas (info. de la
vacuna, contra, laboratorio, serie, procedencia, expiración),
enfermedades (fecha, enfermedad, observaciones, duración,
tratamiento). Se debe llevar un archivo total de la libreta de salud
de las mascotas.
Tipo Primario
Tabla 3. 14. Descripción de Caso de Uso "Registro libreta de salud"

CASO DE USO Registro de Mascotas desaparecidas y/o encontradas

Descripción El sistema debe poder almacenar los datos de las mascotas de un
(Fecha, nombre, raza, color, tamaño, sexo, signos particulares,
foto, estado). Para administrar de forma adecuada se debe llevar
un archivo total de las Mascotas desaparecidas y/o encontradas.
Tipo Primario
Tabla 3. 15. Caso de Uso "Registro de Desaparecidos y Encontrados"

3.3.6. Modelado de la Base de Datos

Una vez revisado los requerimientos para el sistema (Casos de Uso), las
entidades encontradas para la Base de Datos del “Sistema Web de Registro y Control
60
de Mascotas”. Entonces la estructura relacional de la Base de Datos generada para el
Sistema Web de Registro y Control de Mascotas se puede observar en la figura 3.3 y
la figura 3.4.
Figura 3. 3. Modelo Lógico de la Base de Datos

61
A continuación se representa el modelo Físico de la Base de Datos en cual se
muestra los atributos de las entidades.
Figura 3. 4. Modelo Físico de la Base de Datos

62
3.3.7. Modelo de Contenidos
Este modelo especifica cómo se encuentra relacionados los contenidos del
sistema, es decir, define la estructura de los datos que se encuentran alojados en el
sitio web el modelo de contenidos valga la redundancia contiene la información
relevante almacenada en el sistema, como se estructura y como se relaciona.
Figura 3. 5. Modelo de Contenidos

63
3.3.8. Modelo de Navegación
En este modelo se especifica la relación interna del sitio web, es decir cómo se
relaciona cada página web con las demás, con la cual, en definitiva es como se
navega por el sitio web. El modelo que se representa a continuación es un modelo
simplificado ya que presentar el modelo de navegación completo es una tarea
bastante extensa.
Figura 3. 6. Modelo de Navegación

64
3.3.9. Modelo de Presentación
Se contemplan las clases de navegación y de procesos que pertenecen a cada
página web. Las propiedades que contiene por composición se representan como un
rectángulo en el que un elemento queda contenido en otro.
Figura 3. 7. Modelo de Presentación

65
3.3.10. Modelo de Procesos
En este modelo se definen las acciones que realizan las clases de procesos
(operacionales) especificadas en el modelo de navegación. El modelo de Procesos se
divide en dos partes, la primera es el Modelo de Estructura de Procesos, en el cual se
incluyen las relaciones entre las clase de procesos y la segunda parte es el Modelo de
Flujo de Procesos, en el cual se incluyen las actividades relacionadas con cada
proceso, describiendo el comportamiento interno de cada clase de proceso.
Figura 3. 8. Modelo de Estructura de Procesos

66
A continuación se presentaran algunos de los modelos de flujo de procesos
serán los más relevantes ya que algunos se parecen mucho en cuestión a su proceso:
Figura 3. 9. Proceso de Agregar Propietario y su mascota

Figura 3. 10. Proceso de Agregar Denuncia

67
En los anteriores modelos pudimos ver la agregación de propietarios y sus
mascotas, además de las denuncias y como se puede observar son procesos bastante
similares, se pueden ver que se muestran la aparición de errores en la aparición de las
consultas.
Figura 3. 11. Proceso de modificación o borrado

En la figura 3.11 se puede ver como se realiza la modificación o borrado en

cualquiera de las entidades la secuencia de tareas es la misma en los otros procesos
que son similares, es decir, en los que se haya que modificar o borrar los registros ya
guardados.
68
3.4. POST-GAME
Durante esta última etapa se realizaron las actividades de prueba de la
aplicación Web, se propusieron las políticas de seguridad para el sistema, se
obtuvieron las métricas y se realizó el diseño el manual de usuario para la Unidad de
Protección Animal y Zoonosis.
3.4.1. Identificación de Roles

Conocer tanto a los usuarios como sus objetivos es para dar el rumbo que debe
seguir el proyecto, con esta información se lograra conocer a quien está destinado el
sistema y la forma de conocer el grado de satisfacción del usuario lo que es el
objetivo primario a la hora de desarrollar el software con metodologías agiles.
Se identifica y clasifica los tipos de actores de la aplicación, esto implica

identificar a las clases u sub-clases de actores como se puede observar en la figura
3.16.
Roles Descripción
Administrador - Jefe de la Es la persona que realiza tareas administrativas

como generación de reportes, también realiza la
Unidad de Protección
inscripción de los funcionarios y veterinarias
Animal y Zoonosis autorizadas.
Funcionario autorizado Es la persona que se encarga del registro de
mascotas y sus propietarios como también del
registro de denuncias (internas y externas) realizadas
en la unidad.
Veterinaria autorizada Realiza registro de propietario(s) y su(s) mascota(s).
Propietarios de mascotas Interesado en la información de su(s) mascota(s).
Tabla 3. 16. Descripción de roles del Sistema

69
Rol: Usuario que visita la
pagina Web
Descripción: Representa cualquier

usuario que interactúa con el portal Web.
Rol: Funcionario Rol: Veterinaria Rol: Propietario
Descripción: Es la persona que se encarga Descripción: Es la persona que puede

Descripción: Es la persona que se
del registro tanto de mascotas y sus ingresar al Portal y ver solo a sus mascotas
encarga solo de registrar mascotas y sus
propietarios como de denuncias internas y registradas, si es que estan en el registro.
propietarios.
externas.
Rol: Administrador
Descripción: Es la persona que realiza

tareas admnistrativas y la suscribcion
de funcionarios y veterinarias.
Figura 3. 12. Clasificación e identificación de roles

Fuente: Elaboración propia (Según Soto & Palma, 2004)
3.5. PANTALLAS DEL SISTEMA
En el diseño de la interfaz usuario-maquina se debe tomar en cuenta una

interfaz amigable que permita seleccionar acciones fácilmente, además de ver por las
necesidades y características que tienen los usuarios como también las que requiera el
sistema. A continuación se mostraran las pantallas relevantes del sistema con sus
respectivos nombres de lo que representa:
70
Figura 3. 13. Menú principal de Sistema
Figura 3. 14. Pantalla de inicio de sesión al sistema

71
Figura 3. 15. Lista de los reportes del administrador
Figura 3. 16. Noticias publicadas por el administrador

72
Figura 3. 17. Reporte generado en PDF
Figura 3. 18. Listado y registro de propietarios

73
Figura 3. 19. Formulario de registro de mascota
Figura 3. 20. Ficha de un perro registrado

74
Figura 3. 21. Formulario de registro de denuncia
Figura 3. 22. Mascotas desaparecidas o encontradas

75
CAPÍTULO IV
METRICAS DE CALIDAD Y SEGURIDAD
4.1. METRICAS DE CALIDAD
El objetivo de un producto de software es que posea la calidad necesaria y

suficiente para que satisfaga las necesidades del usuario tanto explicitas e implícitas.
El propósito de la ingeniería de software es construir un software de calidad. Por
consiguiente en este capítulo se detalla cuantitativamente la calidad del Sistema.
La determinación de calidad del producto de Software se toma en cuenta las

métricas de McCall. Dentro de la tabla tenemos: factor, criterio, usuario, puntuación,
factibilidad de uso, integridad, corrección, fiabilidad, eficiencia, factibilidad de
almacenamiento, factibilidad de prueba, flexibilidad, reusabilidad, interoperabilidad,
portabilidad.
También comprende criterio y detalle respecto al sistema, como ser exactitud,

tolerancia de error, eficiencia de ejecución, capacidad de expansión, independencia
del Hardware, instrumentación, modularidad, operatividad, seguridad, auto
documentación, trazabilidad, formación. (Ver anexo “D”).
Usuario
Funcionario de
Puntuación
Administrador
Veterinaria
zoonosis
Unidad)
(Jefe de
Nº Factor Criterio
1 Factibilidad de Factibilidad de operación 100 100 100 100

uso Factibilidad de
100 100 100 100
comunicación
Factibilidad de
100 100 100 100
aprendizaje
Factibilidad de
50 50 50 50
reutilización
Factibilidad en uso
100 60 100 86,667
temporal
76
Factibilidad de respaldo 100 30 30 53,333
Factibilidad de costo 100 100 100 100
TOTAL 92,85 77,14 82,85 84,28
2 Integridad Control de acceso 100 100 100 100
Facilidad de auditoría 80 100 90 90
TOTAL 90 100 95 95
3 Corrección Completitud 100 100 100 100
Consistencia 100 100 100 100
Trazabilidad 100 100 100 100
TOTAL 100 100 100 100
4 Fiabilidad Precisión 100 90 100 96,667
Consistencia 100 100 50 83,333
Tolerancia a fallos 85 90 95 90
Modularidad 70 100 100 90
Simplicidad 100 100 100 100
TOTAL 91 96 89 92
5 Eficiencia Eficiencia de ejecución 100 100 100 100
Eficiencia de
100 100 100 100
almacenamiento
TOTAL 100 100 100 100
6 Facilidad de Modularidad 100 100 100 100
almacenamiento
Simplicidad 100 100 100 100
Auto descripción 80 80 90 83,333
Consistencia 100 100 100 100
Concisión 60 50 60 56,667
TOTAL 88 86 90 88
7 Facilidad de Modularidad 100 100 100 100
prueba Simplicidad 100 100 100 100
Auto descripción 85 85 85 85
Instrumentación 100 100 100 100
TOTAL 96,25 96,25 96,25 96,25
8 Flexibilidad Auto descripción 100 100 100 100
Generalidad 75 100 100 91,667
Modularidad 100 100 75 91,667
Independencia entre
100 100 100 100
sistema y software
Independencia de 100 100 100 100
77
Hardware
TOTAL 95 100 95 96,667
9 Reusabilidad Auto descripción 50 80 50 60
Generalidad 60 60 60 60
Independencia entre
100 100 100 100
sistema y software
Independencia de
100 100 100 100
Hardware
TOTAL 82 88 82 84
10 Interoperabilidad Modularidad 100 100 100 100
Compatibilidad de
100 100 100 100
comunicación
Compatibilidad de datos 60 50 50 53,33
TOTAL 86,66 83,33 83,33 84,444
11 Portabilidad Auto descripción 80 90 90 86,667
Independencia entre
100 100 100 100
sistema y software
Independencia de
70 100 100 90
Hardware
TOTAL 87,5 97,5 97,5 94,167
Tabla 4. 1. Métricas de calidad de software

CRITERIOS DETALLE AL REPECTO DEL SISTEMA

Exactitud Los resultados obtenidos, al introducir datos reales de
prueba, son equivalentes a los datos obtenidos de forma
manual.
Tolerancia de error El daño causado implícitamente por algún error, puede
causar la terminación del programa del cliente que está
en ejecución, sin causar ningún daño en la base de datos
y al usuario activo.
Eficiencia de ejecución Al ejecutarse el sistema ocupa lo suficiente de memoria
extendida y cumple todos los requerimientos de los
usuarios finales exigido en su trabajo
Capacidad de Con facilidad se puede ampliar el diseño de arquitectura
expansión de datos y procedimientos para anexar otros módulos
como el control de activos fijos de la institución.
78
Independencia del El sistema puede ser ejecutado en una estación de trabajo
Hardware Core 2 Duo hasta en Pc de última generación.
Instrumentación Los procesos del sistema, se ejecutan de manera
ordenada la ejecución termina en la obtención de
resultados o el usuario las puede cancelar.
La introducción de los datos está validada, detectando
errores causados por el usuario o implícitamente.
Modularidad El lenguaje de programación utilizado, facilita la
independencia funcional en los procesos.
Operatividad Los usuarios sólo deben hacer clic sobre los botones y la
barra de menús para obtener un determinado resultado de
datos.
Seguridad La aplicación del sistema está instalada en un servidor,
de arquitectura cliente/servidor. El cliente no tiene acceso
al código fuente del programa.
Auto documentación Las funciones procedimentales variable de programas
representan una documentación respecto al proceso que
realiza y a los valores que manipula durante la ejecución
del sistema salvo algunas librerías propias del sistema
operativo.
Trazabilidad El requerimiento de un determinado proceso puede ser
realizado desde su diseño hasta el programa que realiza
el requerimiento.
Formación Los usuarios solo deben elegir en el menú la opción o
proceso a ejecutar, el sistema lo guiará hasta obtener el
resultado final.
Tabla 4. 2. Criterios y detalles respecto al Sistema

Usuario 1: Es el puntaje que ha sido asignado por el administrador del sistema, Dr.
Héctor Mencias Gutiérrez que actualmente es Jefe de la Unidad de Protección Animal
y Zoonosis, a cargo de los funcionarios de la misma unidad.
Usuario 2: Es la calificación otorgada por uno de los funcionarios Lic. Roger Iraola
que se encarga del registro y control de los animales.
Usuario 3: Es la puntuación otorgada por la Veterinaria “Adonai”, de la cual el Sr.
Alberto es dueño.
79
Finalmente el puntaje promedio obtenido de los tres usuarios es de 369,00
sobre las métricas de McCall de (400). Entonces se concluye que la calidad del
Sistema Web de Registro y Control de Mascotas, se encuentra entre los niveles
aceptados de las métricas de calidad de Software.
4.1.1. Operación del producto - Facilidad de Uso
 Facilidad de operación: Según la encuesta realizada, del presente proyecto

de Software cumple con este criterio y además se puede apreciar con facilidad
en la interfaz gráfica del sistema (Ver anexo “D”).
 Facilidad de comunicación: El cuestionario realizado con respecto a este

criterio refleja que el producto de software cumple con este criterio en su
totalidad (Ver anexo “D”).
 Facilidad de aprendizaje: Este criterio es dependiente de la facilidad de

operación, por lo tanto se cumple con este criterio ya que el producto de
software gracias a su facilidad de operación brinda gran facilidad al proceso
de transición o cambio de sistemas (Ver anexo “D”).
 Capacitación y evaluación: Por la sencillez en la operación del sistema el

tiempo de capacitación ha sido de las dos horas durante una semana está
orientada a operadores habilitados del sistema el mismo que deberá ser
evaluado para garantizar un correcto aprendizaje.
La capacitación consistirá en el manejo adecuado de las pantallas y formas de

emisión de reportes a impresora o medios magnéticos.
Los operadores deben recibir instrucciones sobre errores comunes que pueden
ocurrir como detectarlos, tomar las medidas necesarias cuando se presentan.
80
Recibirán instructivos para la codificación del ingreso de datos al sistema. A
los directores se los instruirá para que puedan obtener información de la base
de datos central mediante la utilización de herramientas propias del sistema.
 Mantenimiento: La fase de mantenimiento es una actividad permanente

orientada básicamente a conservar la vigilancia del sistema así como satisfacer
los requerimientos emanados según el funcionamiento del mismo.
 Documentación: Para lograr una transferencia efectiva del sistema se sustenta

la posibilidad de entrega del manual de usuario, así como los programas
fuente bajo la recomendación de que toda modificación realizada al sistema
debe ir antecedida por la actualización de los documentos correspondientes.
 Resultado de las Pruebas
Con la aplicación de la prueba de la caja negra, se ha logrado verificar la

operatividad de los módulos del sistema.
Con la prueba de la caja blanca, se verificó el conocimiento interno (código

fuente), con la probabilidad de ejecución.
Según la métrica de calidad de McCall, nos proporciona un promedio de 92%,

que se ha realizado a tres usuarios del sistema.
4.2. SEGURIDAD
Podemos entender como seguridad en términos generales e informáticos a un

estado que nos indica que el sistema está libre de peligro, daño o riesgo. Se entiende
como daño o riesgo todo aquello que pueda afectar su funcionamiento directo o los
resultados que se obtienen del mismo. Para una gran mayoría de los expertos el
concepto de seguridad en la informática es ilusorio porque no existe un sistema 100%
seguro.
81
Para que un sistema se pueda definir como seguro debe cumplir con 4 características:
a) Integridad: La información solo puede ser modificada por quien está

autorizado y de manera controlada.
b) Confidencialidad: La información solo debe ser visible y legible para los
autorizados.
c) Disponibilidad: Debe estar disponible cuando se necesita en todo momento.
d) Irrefutabilidad (no repudio): El uso y/o modificación de la información por
parte de un usuario debe ser irrefutable, es decir, que el usuario no puede
negar dicha acción.
4.2.1. Integridad
La creación de usuarios con sus respectivos roles identificados y sus permisos
agregados ayudaran a clasificar a los mismos y designar tareas a realizar. La buena
administración de los roles de usuario debe estar reflejada de acuerdo a la estructura
organizativa de la Institución de forma natural y de acuerdo a las funciones que
realizan los funcionarios que serán usuarios del Sistema.
4.2.2. Confidencialidad
Según lo mencionado anteriormente sobre la definición de roles de usuarios,
los cuales se encuentran asociados a un código de servidor público, toda acción
realizada por dicho usuario será registrado con el código de funcionario de la Unidad
de Protección Animal y Zoonosis que es único y a la vez tendrá acceso a la
información que el mismo usuario registro y no así la información que otros usuarios
introdujeron al sistema; con esta acción se evitara la pérdida o cambio fraudulenta de
la información.
También cabe mencionar que el campo de contraseña de los funcionarios se

encuentra encriptado, esto para brindar más seguridad en el sistema y en la tabla de
autorizados para administradores.
82
4.2.3. Disponibilidad
La disponibilidad del sistema como también el acceso a los datos deben
realizarse en el momento preciso en que el usuario lo solicite, la tecnología con la que
cuenta el sistema permitirá la accesibilidad en cualquier momento y desde cualquier
momento desde cualquier terminal perteneciente a la Red de la Unidad de Protección
Animal y Zoonosis sin necesidad que el sistema sea instalado en el equipo ya que el
Sistema está desarrollado bajo tecnología Web. Conjuntamente se contara con una
réplica de la Base de Datos y del Servidor para que en caso de que el servidor tenga
conflictos se direccione y se levante el otro servidor.
4.2.4. Irrefutabilidad
Para realizar esta tarea se tiene una tabla llamada bitácora la cual tiene la
función de registrar todos los movimientos (Altas, Bajas, Modificación y Consulta)
realizados en el Sistema que a su vez almacena la fecha en la que se realizó la
operación, quien la realizo, que funcionario fue afectado con el cambio, la tabla que
fue afectada y el IP del equipo donde se realizó dicha operación.
83
CAPÍTULO V
ANALISIS DE COSTO/BENEFICIO
5.1. INTRODUCCION
El desarrollo del presente proyecto, cuenta con una inversión para el

desarrollo e implementación del sistema propuesto para la Unidad de Protección
Animal y Zoonosis, por lo tanto en relación al costo/beneficio que se obtenga del
sistema no se debe exceder en corto, mediano o largo plazo.
Esto implica evaluar cuál es la arquitectura que mejor se adapta para el

procesamiento de las aplicaciones que se piensa desarrollar para el futuro servidor.
Según la filosofía para su construcción, el procesamiento puede ser: Centralizado,
descentralizado, distribuido o una mezcla de todos ellos y de acuerdo a la
envergadura de la institución.
Cada filosofía establece un diseño o arquitectura de construcción de cada

dispositivo del nuevo sistema, y en función de esas pautas que determinan el tamaño,
capacidad, velocidad, etc. Para cada componente del sistema. Por lo expuesto, resulta
imprescindible el conocimiento del “problema” de la institución, antes de iniciar
todos los aspectos de costos, para que permita definir la nueva filosofía, arquitectura
y tipo de procesamiento a emplear para el nuevo sistema.
5.1.1. Estudio de Factibilidad

Es necesario conocer la problemática del presente proyecto a realizar, las
particularidades de su implementación y los motivos que la impulsan a estudiar la
factibilidad de un proyecto de inversión como sistema de información cliente -
servidor con la particularidad de una base de datos con la tecnología MySql.
Todos estos aspectos y las estimaciones sobre la evolución del nuevo sistema
se contemplan en la estrategia global de la información que ha de brindar en el nuevo
84
sistema y es esta la que define las políticas que condicionan dicho proyecto a
realizarse.
5.1.2. Factibilidad Técnica.

Con el mismo criterio con que se desarrolla una estrategia de factibilidad y se
confecciona un plan de implementación, será necesario establecer una estrategia de
sistemas factibles que contemple tanto las necesidades actuales respecto al nuevo
sistema como servicio, como de mediano y largo plazo en materia de implementación
prueba y resultados.
A continuación, se detalla algunos de los aspectos a considerar, si bien se ha

mencionado, carecen de universalidad y sólo sirven como referencia para
implementar, hacer pruebas u obtener resultados del nuevo sistema.
Estrategia de Hardware
 Establecer requerimientos globales
 Establecer la filosofía de procesamiento
 Definir arquitectura
 Pautar crecimiento para el mediano y largo plazo.
 Definir grado de sofisticación técnica
Estrategia de Software
 Establecer criterios para fijar prioridades en el desarrollo de instalación de

sistemas.
 Pautar desarrollo interno de sistemas.
 Establecer pautas para el desarrollo de metodologías.
85
 Pautar desarrollo de Software de base.
 Establecer requerimientos básicos de documentación de sistema.
 Sistemas de comunicación de datos.
 Establecer alcance del sistema. Especificar los sistemas de información

afectados.
 Fijar pautas para el diseño de la red de comunicaciones entre el nuevo servicio

y servicio actual.
 Establecer requerimientos globales del nuevo sistema:
 Procesamiento de información
 Envió de información del sistema.
 Sistemas de modelización.
 Priorización de la información a brindar.
5.1.3. Requerimientos de Hardware

Los equipos informáticos necesarios para la implementación del presente
proyecto, es una decisión crítica ya que sin esto, el Software no es factible y no se
podremos realizar el desarrollo del proyecto.
DESCRIPCIÓN CANTIDAD
Procesador Pentium Core2 Duo Intel de 2.4
Ghz. Original.
Disco duro de 120 Gb. SATA
Memoria RAM: de 2 Gb. DDR2 expandible 1
Lector de DVD-RW 52x
Monitor – Teclado – Mouse – Parlantes
Sistema operativo: Windows Siete o superior
Tabla 5. 1. Requerimientos mínimos de Hardware

86
Procesador Intel Core I5 de 4ta. Generación de 3.5 Ghz
Memoria Cache de 2 MB
Disco duro de 512 Gb. SATA de 7200 rpm
Memoria RAM: de 4 Gb. DDR3 expandible 1
Red de 10/1000 Mbps
Lector de DVD-RW 52x
Monitor – Teclado – Mouse – Parlantes
Sistema operativo: Windows Siete o superior
Tabla 5. 2. Requerimientos recomendados de Hardware

Según datos referenciales de la institución y de experiencia propia en la

compra de Hardware podemos determinar el promedio del costo del equipo:
Costo promedio del equipo: CPE = 1141,6 $us.
5.1.4. Requerimientos de Software.

Para determinar el costo del Software, se tomó como referencia el costo de las
licencias de Software que están relacionadas con el desarrollo del proyecto.
COSTO COSTO
UNITARIO $us.
Microsoft Windows 7 Ultimate 3 150 450.-
Base de datos: MySql5.0 1 5 5.-
TOTAL $us. 455.-
Tabla 5. 3. Costos de Software

Fuente: Elaboración propia.
87
5.1.5. Factibilidad Operativa.
Para el análisis de factibilidad operativa, debemos determinar dos aspectos
muy importantes que son:
a) Operación garantizada
Se debe analizar la garantía en base al cálculo estimado en pruebas.
b) Uso garantizado
Debemos de realizar el cálculo a través de los métodos y el tiempo empleado,
para brindar a los usuarios toda la información acerca del manejo.
Se toma el costo de operación en el tiempo de desarrollo del proyecto, como

muestra a continuación en la siguiente tabla:
Tasa de cambio del Dólar: 1 dólar = 6,90 Bs.
DETALLE UNIDAD CANTIDAD PRECIO COSTO

DE BS. $US.
MEDIDA
Papel bond tam. carta Paquete 4 120 17,24
Cartucho de tinta Pieza 3 375 53,87
Dominio de la página Gob.bo 1 por año 280 40,22
web
Servicio de Internet 1024 Mbps 1 por mes 260 37,35
Servicio eléctrico Kw/h 45 por mes 50 7,18
TOTAL en $us. 155,86
Tabla 5. 4. Costo Operativo

5.1.6. Costos
5.1.6.1. Costo Laboral en el Ciclo de Ejecución

El costo laboral está determinado por la cantidad de programadores
necesarios y el salario que estos perciben, como se detalla en la siguiente tabla.
88
Institución/Empresa Salario mensual
($us.)
Dimensoft 250,00
Quality Net 300,00
Dragnus 400,00
Tabla 5. 5. Tarifa Laboral del Programador de Sistemas

El costo laboral está determinado por una estimación de los datos

recolectados, con los mismos realizamos una media aritmética o promedio para
obtener el sueldo promedio que es 316,6 $us por mes, el cual utilizaremos para el
pago total hasta culminar el proyecto, que ilustramos a continuación.
DETALLE SUELDO CANTIDAD DURACION

5 MESES
Programadores 316,6 3 949,8 * 5
TOTAL: $us 4750
Tabla 5. 6. Costo total en el ciclo de ejecución

Costo Fijo = Sueldo programadores + Hardware requerido * Depreciación 1

durante 7 meses + Software requerido.
Costo Fijo = 4750,00 + 1141,60 * 0,25 * 5/12 + 870,00 = 1483,71 $us.
Costo Total = Co + Cf
Costo Total = 155,86 + 1483,71 = 1639,57 $us.
1
La Depreciación, calculada para activos fijos es de 25% anual (Art. 26,
DS. 24051).
89
Personal Requerido.
Para el personal que se requiere se calculara en base a la siguiente fórmula:
Pr = Pm / D
Por lo tanto tenemos:
Pr = 13 Personas mes / 4,94 meses = 2,63 personas = 3 Personas.
A continuación de detalla el costo laboral y pago del analista de sistemas, que
averiguó en las siguientes empresas.
Empresa Salario mensual
$us.
Quality Net 280,00
Dimensoft 250,00
Gragnus 300,00
Tabla 5. 7. Tarifa Laboral del Analista de Sistemas

De las cuales se determinó una media en el costo de un analista, obteniendo

como pago promedio de 276,66 $us./mes.
El costo para el análisis y diseño del proyecto para el pago de sueldos será
calculado por la siguiente fórmula.
Cs = Pr * D * Sp
Dónde:
Cs: Costo del desarrollo del Software
Pr: Personas requeridas
D: Tiempo requerido
Sp: Sueldo del personal
CS = 3 * 4,94 * 276,66 = 4100,10 $us.
90
El presente resultado es utilizado para calcular cómo parámetro económico,
que luego calculamos el valor neto.
Para el presente proyecto debemos tomar en cuenta las siguientes

estimaciones del costo, tiempo y esfuerzo requerido.
Esfuerzo requerido = 13 personas / mes

Tiempo requerido = 4,59 meses
Costo requerido = 4100,10 $us.
5.2. APLICACIÓN DE COCOMO.
Con el estudio de costo – beneficio del presente proyecto se determinará el

valor de la inversión para el desarrollo e implementación del Software, combinando
los métodos de estimación de esfuerzo, tiempo y costo que son las más utilizadas en
el desarrollo de proyectos informáticos.
5.2.1. Modelo de Composición de Aplicaciones

Para la estimación, usaremos los Puntos de Objeto (PO), la definición de los
términos utilizados en los Puntos de Objeto son las siguientes:
 NOP: Nuevos Puntos Objeto; (cantidad de puntos objeto ajustados por la

reutilización).
 SRVR: Número de tablas de datos del servidor (Mainframe o equivalente)

usadas junto con la pantalla o informe.
 CLNT: Número de tablas de datos del cliente (estimación de trabajo personal)

usados junto con la pantalla o informe.
 %REUSE: Porcentaje de pantallas, informes y módulos 3GL reutilizados a

partir de aplicaciones anteriores prorrateadas por grado de reutilización. Para
la aplicación del modelo anticipando debemos seguir un orden de aplicación.
91
1.- Recuento de objetos: Estimar el número de pantallas, informes y
componentes.
TIPO DE OBJETO COMPLEJIDAD / PESO

Simple Medio Difícil
Pantallas 0 8 3
Reportes 0 5 3
Tabla 5. 8. Tipos de objeto, complejidad/peso

Donde obtenemos:
Cantidad de pantallas = 16
Cantidad de reportes = 8
2.- Clasificaremos cada instancia de objeto dentro de niveles de complejidad

(simple, media y difícil).
PANTALLAS
Cantidad CANTIDAD Y FUENTES DE LAS TABLAS DE DATOS
de vistas Total < 4 Total < 8 Total 8 +
contenidas (<2 servidor<3 cliente) (<2 – 3 servidor <3 – 5 (>9servidor>5cliente)
cliente)
<3 Simple Simple Media
3–7 Simple Media Difícil
>8 Media Difícil Difícil
Tabla 5. 9. Esquema de Clasificación de puntos de objeto

Fuente: [Boehm 1995]
Obtenemos los siguientes datos:
Complejidad de pantallas: 8 medios, 3 difíciles

Complejidad de reportes: 5 medios, 3 difíciles
92
5.2.2. Complejidad Asociada a las Instancias de Objetos
Pensar el número de cada celda usando las tablas 8 y 9, el peso refleja el
esfuerzo relativo que se requiere para implementar una instancia de ese nivel de
complejidad haciendo uso de la siguiente tabla:
TIPOS DE OBJETO COMPLEJIDAD - PESO

Simple Media Difícil
Pantalla 2 3 9
Reporte 2 5 10
Tabla 5. 10. Complejidad - peso

Fuente: [Boehm 1195/2]
5.2.3. Pesos Asociados a los Niveles de Complejidad

Considerando la tabla 9 determinamos la complejidad en las pantallas y los
reportes, obtenidos con el siguiente cálculo:
Pesos de Pantallas : 3 * 2, 2 * 3
Pesos de componentes: 6 * 5, 4 * 8
1.- Determinar Puntos Objeto: Suma todas las instancias de objeto pasadas para
conseguir un número. El recuento de puntos objeto se refleja a continuación
con la suma de los datos obtenidos de las tablas 8, 9,10 respectivamente como
se detalla a continuación.
Suma de Puntos Objetos: 3*2 + 2*3 + 6*5 + 4*8 = 74
2.- Estimar el porcentaje de reutilización que se espera lograr en este

proyecto. Calcular los nuevos Puntos Objeto a desarrollar el porcentaje de
reutilización del proyecto puede estimarse en un 25% debido a las
características que poseen los objetos e informes requeridos.
NOP=(Object Points) X (100 - %Reuse) / 100
93
NOP = (74) X (100 – 25) / 100 = 55,5
3.- Determinar un ratio de productividad PROD = NOP / meses/personas a partir

de la siguiente tabla.
Experiencias y capacidad de Muy bajo Bajo Nominal Alto Muy alto
los programadores
ICASE madurez y capacidad Muy bajo Bajo Nominal Alto Muy alto
PROD 4 7 13 25 50
Tabla 5. 11. Ratio de Productividad PROD

PROD = NOP / meses – persona = 13 NOP / PM
Con esto calculamos el número de personas – mes para la realización del

proyecto estimado en base a la siguiente ecuación:
PM = NOP / PROD
PM = 74 NOP / 13 NOP = PM = 7 personas mes (Esfuerzo)
5.2.4. Duración y Personal del Proyecto

Además de la estimación de esfuerzo, se debe estimar el tiempo requerido
para determinar el proyecto, así como el personal necesario para el desarrollo del
mismo. El tiempo de desarrollo del proyecto puede estimarse mediante la fórmula de
COCOMO II.
D = c * PMd
Dónde:
D = duración en meses
Cy d: son los factores de Cocomo II en base a la tabla.
94
COCOMO aa bb cb db
Orgánico 2.4 1.05 2.5 0.38
Semiacoplado 3.0 1.15 2.5 0.35
Empotrado 3.6 1.2 2.5 0.32
Tabla 5. 12. Factores Cocomo II
Existe una jerarquía de modelos COCOMO, la cual se aplica tres tipos de

Software:
1.- Proyectos orgánicos: Son relativamente pequeños, con proyectos de Software

sencillos y pocos requisitos escritos.
2.- Proyectos semiacoplados: Son proyectos intermedios (en complejidad y

tamaño). La experiencia y un entorno de gran innovación técnica. Se trabaja
con uno o más requisitos muy restrictivos.
Las características del sistema propuesto son certificados como

semiacoplados, por lo consiguiente los factores c, d serán 2.5 y 0.35 respectivamente.
De tal forma que la cantidad de meses requerida para el desarrollo del
proyecto será:
D = 2.5 * 7 0.35 = 4.94 meses
5.3. COSTOS
5.3.1. Costos del Anterior Sistema

Actualmente la Unidad de Protección Animal y Zoonosis, no cuenta con un
sistema web para el registro y control de los propietarios, ni de las mascotas, tampoco
cuenta con un registro de las actividades que realizan los funcionarios de la Unidad.
95
5.3.2. Costos del Nuevo Sistema
Obteniendo la suma de los costos totales de Hardware, Software, el costo del
desarrollo del sistema, obtenemos la inversión requerida para el desarrollo e
implementación del sistema propuesto, como se detalla en el siguiente resumen de
costos.
Resumen de Costos.
DESCRIPCIÓN COSTO
$us.
Costo operativo 1639,57
Costo de desarrollo 4100,10
TOTAL $us. 5739,67
Tabla 5. 13. Costo de desarrollo

5.4. CONCLUSIÓN DE ESTIMACIÓN DE COSTO Y BENEFICIO

Se ha alcanzado a concluir en el presente capítulo de la propuesta del proyecto
“SISTEMA WEB DE REGISTRO Y CONTROL DE MASCOTAS” Caso: Unidad
de Protecciòn Animal y Zoonosis, es posible en el aspecto de factibilidad tanto
económicamente como tecnológicamente para contar con un sistema propuesto al
alcance de las instituciones educativas tanto públicas y privadas, como podemos
observar que la parte económica es de bajo coste, en el proceso de desarrollo e
implementación de la misma.
96
CAPÍTULO VI
CONCLUSIONES Y RECOMENDACIONES
6.1. CONCLUSIONES
Una vez finalizado el desarrollo del Sistema Web para el Registro y Control de
Mascotas, mediante la aplicación de la metodología propuesta, es posible expresar las
siguientes conclusiones:
 Se logró desarrollar la base de datos única que permite almacenar la

información de los animales con propietario que de igual forma se almacenan
en la base de datos del Sistema.
 Se logró desarrollar un sistema seguro al momento de ingresar datos

(validaciones, inyecciones SQL, diccionario de palabras), autenticación
(usuario y password codificados, manejo de sesiones automáticamente).
 Se logró diseñar una página web que permite obtener información básica,
importante y oportuna referente a los canes para su cuidado, protección y
estilo de vida como también de la diversidad de casos presentados en la
Unidad de Protección Animal y Zoonosis.
 Se logró elaborar un proceso estandarizado tanto para el registro de las

mascotas como para el registro de denuncias para la Unidad de Protección
Animal y Zoonosis, para que de esta manera se lo pueda individualizar y
reconocer.
 Con el diseño e implementación del Sistema se logro que sea de uso sencillo
con el objeto de facilitar la localización de toda la información existente para
así poder realizar la emisión de reportes en tiempo real con el objeto de
minimizar los tiempos de respuesta para la toma de decisiones.
 Entonces con el cumplimiento de lo señalado en los objetivos se puede

concluir que se logró mejorar la atención a las personas que necesitan algún
servicio de la Unidad además de coadyuvar con el personal que trabaja en la
Unidad con la extensa información que debe manipular y también coadyuvara
con las veterinarias registradas.
97
6.2. RECOMENDACIONES
 Se sugiere realizar una investigación sobre microchips, como los animales no

poseen huella dactilar única, este dispositivo permitiría el reconocimiento de
la mascota leyendo el código del microchip ya implantado, de manera rápida
sobre todo en el caso de extravió del animal; pero existe una variedad de
opciones en relación a esta sugerencia.
 Se recomienda un módulo de inventarios para el control de los medicamentos

existentes, insumos de laboratorio, instrumentos, etc. Para la planificación de
reportes en la adquisición de presupuestos.
 Implementar un modelo de simulación que permita estimar el comportamiento

de la población canina situada en la ciudad de La Paz, sus tasas de fecundidad,
natalidad y mortalidad, como también una relación estadística entre canes y
humanos.
 Se recomienda a la organización contactarse con todas las entidades públicas

o privadas dedicadas al cuidado de mascotas, para proporcionarles el Sistema
para así tener el mayor registro posible para mejores resultados en el Sistema.
 Es de vital importancia para el proyecto que los ciudadanos que posean una
mascota, la registren en el Sistema; se recomienda proponer ordenanzas que
obliguen a todo propietario y/o tenedor de una mascota a inscribir a su
mascota en el Sistema.
98
BIBLIOGRAFIA
TEXTOS
[Cota, 1994] Cota A. (1994): “Ingeniería de Software. Soluciones

Avanzadas”, 1ª Edición. Adison Wesley. Estados Unidos
[Pressman, 2002] Pressman, R. (2002): “Ingeniería del Software, un enfoque

práctico”, 5ª Edición. Mc Graw Hill.
[Kendall & Kendall] Kendall K. y Kendall J. (1995): “Análisis y diseño de sistemas

de información”, Prentice Hall. Mexico.
[Minguez&Garcia, 2000] Minguez, D. &Garcia, E. Metodología para el Desarrollo de

Aplicaciones Web: UWE. (s.e.), 2000.
[Palacio, 2007] Palacio J. (2007): “Flexibilidad con Scrum”. (s.e.)
[Prentice, 1999] Prentice, L. (1999): “UML y Patrones Introducción al Análisis

y Diseño Orientado a Objetos”. (s.e.).
[Yourdon, 1993] Yourdon, E. (1993): “Análisis Estructurado Moderno”. México

DF: 5ta ed. Prentice Hall.
REFERENCIAS WEB
[Web 1] Noticia de Registro Único de Mascotas (RUM)

http://www.cochabamba.gob.bo/Noticias/detallenoticia/id/3402#
[Consulta 24 de octubre de 2013]
[Web 2] Ley pretende cobrar impuesto por tenencia de los animales

http://www.fmbolivia.com.bo/radioenvivo.php
[Consulta: 24 de octubre de 2013]
[Web 3] Programa de Control y Vigilancia de Zoonosis

http://www.sedeslapaz.gob.bo/index.php?option=com_content&
99
view=article&id=238&Itemid=164
[Consulta: 20 de octubre 2013]
[Web 4] Lista de todas las razas de perros

http://marcos-marcosnavarro-marcos.blogspot.com/2012/01/lista
-de-todas-las-razas-de-perros.html [Consulta: 10 de marzo 2014]
[Web 5] Metodología de Roger Pressman

http://sisteminformacii.wikispaces.com/METODOLOG%C3%8
DA+DE+ROGER+PRESSMAN [Consulta: 2 de agosto 2014]
[Web 6] Modelo Evolutivo

http://jorgetrejos.blogspot.com/2010/08/modelo-evolutivo.html
[Web 7] Introducción a la Agilidad y Scrum

http://www.martinalaimo.com/es/blog/
[Web 8] El modelo Scrum

http://www.navegapolis.net [Consulta: 2 de noviembre 2014]
100
ANEXOS
ANEXO A. Organigrama y dependencias de la Unidad de Protección Animal y
Zoonosis - GAMLP
101
ANEXO B: Encuesta realizada al Administrador (Jefe de la unidad), Funcionario de
la unidad y una veterinaria x.
Nombre Completo: ……………………………………………………………….

Fecha: ………………………………….. Usuario: ……………………………..
Calificar la funcionalidad del sistema, en un puntaje de (1) como más bajo y (100)
como calificación más alta.
NRO. PREGUNTAS PUNTAJE

1 Considera factible la automatización y control del sistema
web de registro y control de mascotas de la Unidad de
Protección Animal y Zoonosis.
2 Los módulos del sistema son óptimos para el registro de datos
de los participantes.
3 La capacitación y el manejo del sistema fue fácil de aprender,
en el manejo de menús y botones.
4 Considera que los módulos del sistema se pueden reutilizar,
herramientas del mismo estilo de los formularios y reportes.
5 El registro de vacunas y enfermedades de las macotas son de
mucha utilidad.
6 Las copias de respaldo de la base de datos, son suficientes y
fueron utilizadas.
7 El costo del sistema es mínimo o suficiente, en la satisfacción
de las necesidades de la institución.
8 El cargado de imágenes es lo suficientemente eficiente.
9 El control y acceso de los usuarios es seguro y fiable.
10 El llenado de formularios es fácil y amigable para el usuario.
102
ANEXO C. El modelo de McCall
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde
los cuales el usuario puede contemplar la calidad de un producto, basándose en once
factores de calidad organizados en torno a los tres ejes y a su vez cada factor se
desglosa en otros criterios:
FACTOR CRITERIOS
OPERACIÓN DEL PRODUCTO

 Facilidad de operación: Atributos del software que
Facilidad de uso determinan la facilidad de operación del software.
 Facilidad de comunicación: Atributos del software que
proporcionan entradas y salidas fácilmente asimilables.
 Facilidad de aprendizaje: Atributos del software que facilitan
la familiarización inicial del usuario con el software y la
transición del modo actual de operación.
 Formación: El grado en que el software ayuda para permitir
que nuevos usuarios apliquen el sistema.
 Control de accesos: Atributos del software que proporcionan
Integridad control de acceso al software y los datos que maneja.
 Facilidad de auditoría: Atributos del software que facilitan la
auditoría de los accesos al software.
 Seguridad: La disponibilidad de mecanismos que controlen o
protejan los programas o los datos.
 Completitud: Atributos del software que proporcionan la
Corrección implementación completa de todas las funciones requeridas.
 Consistencia: Atributos del software que proporcionan
uniformidad en las técnicas y notaciones de diseño e
implementación.
103
 Trazabilidad o rastreabilidad: Atributos del software que
proporcionan una traza desde los requisitos a la
implementación con respecto a un entorno operativo concreto.
OPERACIÓN DEL PRODUCTO

 Precisión: Atributos del software que proporcionan el grado de
Fiabilidad precisión requerido en los cálculos y los resultados.
 Consistencia.
 Tolerancia a fallos: Atributos del software que posibilitan la
continuidad del funcionamiento bajo condiciones no usuales.
 Modularidad: Atributos del software que proporcionan una
estructura de módulos altamente independientes.
 Simplicidad: Atributos del software que posibilitan la
implementación de funciones de la forma más comprensible
posible.
 Exactitud: La precisión de los cálculos y del control.
 Eficiencia en ejecución: Atributos del software que minimizan
Eficiencia el tiempo de procesamiento.
 Eficiencia en almacenamiento: Atributos del software que
minimizan el espacio de almacenamiento necesario.
REVISIÓN DEL PRODUCTO

Facilidad de  Modularidad.
mantenimiento  Simplicidad.
 Consistencia.
 Concisión: Atributos del software que posibilitan la
implementación de una función con la menor cantidad de
códigos posible.
 Auto descripción: Atributos del software que proporcionan
explicaciones sobre la implementación de las funciones.
104
 Modularidad.
Facilidad de  Simplicidad.
prueba  Auto descripción.
 Instrumentación: Atributos del software que posibilitan la
observación del comportamiento del software durante su
ejecución para facilitar las mediciones del uso o la
identificación de errores.
 Auto descripción.
Flexibilidad  Capacidad de expansión: Atributos del software que
posibilitan la expansión del software en cuanto a capacidades
funcionales y datos.
 Generalidad: Atributos del software que proporcionan
amplitud a las funciones implementadas.
 Modularidad.
Reusabilidad  Generalidad.
 Modularidad.
 Independencia entre sistema y software: Atributos del
software que determinan su dependencia del entorno
operativo.
 Independencia del hardware: Atributos del software que
determinan su dependencia del hardware.
 Modularidad.
Interoperabilidad  Compatibilidad de comunicaciones: Atributos del software
que posibilitan el uso de protocolos de comunicación e
interfaces estándar.
 Compatibilidad de datos: Atributos del software que
posibilitan el uso representaciones de datos estándar.
 Estandarización en los datos: El uso de estructuras de datos
105
y de tipos estándar a lo largo de todo el programa.
Portabilidad  Modularidad.
 Independencia entre sistema y software.
 Independencia del hardware.
Cómo emplear el modelo de McCall: Antes de comenzar a utilizar el modelo de

McCall hay que seguir las siguientes pautas:
 Se aceptan los factores, criterios y métricas que propone el modelo.
 Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas.
 Se selecciona un subconjunto de factores de calidad sobre los que aplicar los
requisitos de calidad establecidos para el proyecto.
Al comienzo del proyecto habrá que especificar los requisitos de calidad del
producto software, para lo cual se seleccionarán los aspectos inherentes a la calidad
deseada del producto. Las características particulares del propio producto que se está
diseñando: por ejemplo, su ciclo de vida que si se espera que sea largo implicará un
mayor énfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema
en desarrollo está destinado a un entorno donde el hardware evoluciona rápidamente
implicará como requisito su portabilidad.
La relación calidad-precio, que puede evaluarse a través del coste de cada

factor de calidad frente al beneficio que proporciona. La siguiente tabla muestra la
relación calidad-precio para cada factor considerado:
Factor Beneficio / coste

Corrección Alto
Fiabilidad Alto
Eficiencia Bajo
Integridad Bajo
106
Facilidad de uso medio
Facilidad de mantenimiento Alto
Facilidad de prueba Alto
Flexibilidad medio
Portabilidad medio
Reusabilidad medio
Interoperabilidad Bajo
 La determinación de las etapas del ciclo de vida donde es necesario evaluar

cada factor de calidad para conocer en cuales se dejan sentir más los efectos
de una calidad pobre con respecto a cada uno de los factores.
 Las propias interrelaciones entre los factores debido a que algunos factores
pueden entrar en conflicto entre sí: por ejemplo, la eficiencia plantea
conflictos prácticamente con todos los demás factores de calidad. La
interacción entre los diversos factores a evaluar queda reflejada en la tabla I
que indica la dependencia entre los factores de McCall.
También habrá que establecer valores deseables para los criterios, para lo cual
se emplearán datos históricos, el promedio en la industria, y con ellos se concretarán
los valores finales y otros intermedios o predictivos en cada período de medición
durante el desarrollo, así como unos valores mínimos aceptables. La explicación para
cualquier selección o decisión deberá ser adecuadamente documentada.
En la fase de desarrollo será necesario implementar las métricas elegidas,

analizar sus resultados y tomar medidas correctivas cuando los valores obtenidos
estén por debajo de los mínimos aceptables. Una vez finalizado el proyecto será
necesario contrastar las medidas predictivas utilizadas y comprobar si, en efecto, se
pueden tomar como indicadores de los valores finales.
107
108
DOCUMENTACIÓN

Universidad Mayor de San Andres: Facultad de Ciencias Puras Y Naturales Carrera de Informática

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Universidad Mayor de San Andres: Facultad de Ciencias Puras Y Naturales Carrera de Informática

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDAD MAYOR DE SAN ANDRES

FACULTAD DE CIENCIAS PURAS Y NATURALES

“SISTEMA WEB PARA EL REGISTRO Y CONTROL DE MASCOTAS”

CASO: UNIDAD DE PROTECCION ANIMAL Y ZOONOSIS

PARA OPTAR AL TITULO DE LICENCIATURA EN INFORMATICA

POSTULANTE: LORENA ALVAREZ VACAFLORES

TUTOR METODOLOGICO: M. Sc. ALDO RAMIRO VALDEZ ALVARADO

ASESOR: M. Sc. CARLOS MULLISACA CHOQUE

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

“Sistema Web para el Registro y Control de Mascotas”

Lorena Alvarez Vacaflores

Para obtener el grado académico de Licenciatura en Informática mención Ingeniería de

Nota Numeral: ……………………………………..………………………………

Nota Literal: …………………..………………………………………................

Director de Carrera: M. Sc. Edgar Clavijo Cárdenas …………………........

Tutor: M. Sc. Aldo Ramiro Valdez Alvarado ……………………….

Asesor: M. Sc. Carlos Mullisaca Choque ……………………….

A mis padres Carla Vacaflores e Ismael

Alvarez por guiarme en el transcurso de

mi vida con amor y comprensión.

A mi hermosa True por su compañía y

amor incondicional, asimismo a todas

aquellas personas que Dios puso en mi

camino y que algún día me aconsejaron y

En primer lugar a Dios porque siempre me dio las ganas y la

fuerza que necesitaba para seguir adelante.

A mis padres por no dejarme sola aunque vivimos separados

siempre los llevo en mi corazón y sigo adelante por mí y por

ustedes, también a mi hermanita Romina por todo su cariño.

A mi tutor M. Sc. Aldo Ramiro Valdez Alvarado, por su apoyo,

comprensión y paciencia en el seguimiento otorgado al presente

A mi asesor M. Sc. Carlos Mullisaca Choque por la entrega de

conocimiento y colaboración otorgada para la culminación del

A mi familia a la que está cerca y a la que no, porque por lo

menos con una llamada sé que me estiman, también a mis

amigos que siempre con un sencillo consejo me levantaron, en

especial a Rodrigo López por su apoyo incondicional.

Finalmente agradecer a la Universidad Mayor de San Andrés

por su recibimiento durante el transcurso de estos años y a la

estimada Carrera de Informática.

MARCO INTRODUCTORIO ......................................................................................................1

1.1. INTRODUCCIÓN ..............................................................................................................1

1.2. ANTECEDENTES .............................................................................................................2

1.2.1. Antecedentes Institucionales ...............................................................................................2

1.2.2. Proyectos Similares .............................................................................................................3

1.3. PLANTEAMIENTO DEL PROBLEMA ............................................................................4

1.3.1. Problema General ...............................................................................................................4

1.3.2. Problemas Específicos ........................................................................................................4

1.4. OBJETIVOS .......................................................................................................................4

1.4.1. Objetivo General .................................................................................................................4

1.4.2. Objetivos Específicos..........................................................................................................5

1.5. JUSTIFICACION ...............................................................................................................6

1.5.1. Justificación Social .............................................................................................................6

1.5.2. Justificación Económica .....................................................................................................6

1.5.3. Justificación Técnica ...........................................................................................................6

1.6. ALCANCES, LIMITES Y APORTES ...............................................................................6

1.6.1. Alcances .............................................................................................................................6

1.6.2. Límites ................................................................................................................................7

1.6.3. Aportes ...............................................................................................................................8