Tesis de Sistemas Informaticos

INDICE GENERAL
1. CAPÍTULO I ASPECTOS GENERALES ............................................................................... 1

1.1. ANTECEDENTES ................................................................................................................. 1
1.1.1. ANTECEDENTES DE LA INSTITUCION ....................................................................... 1
1.1.2. ANTECEDENTES DE CONTEXTO ................................................................................. 2
1.1.3. ANTECEDENTES DEL TEMA ......................................................................................... 3
1.2. PLANTEAMIENTO DEL PROBLEMA ............................................................................... 4
1.2.1. FUNDAMENTACION DEL PROBLEMA ........................................................................ 4
1.2.2. FORMULACION DEL PROBLEMA ................................................................................ 5
1.3. OBJETIVOS .......................................................................................................................... 5
1.3.1. OBJETIVO GENERAL ...................................................................................................... 5
1.3.2. OBJETIVOS ESPECIFICOS .............................................................................................. 5
1.4. JUSTIFICACION .................................................................................................................. 6
1.4.1. JUSTIFICACION TECNICA ............................................................................................. 6
1.4.2. JUSTIFICACION OPERATIVA ........................................................................................ 7
1.4.3. JUSTIFICACION ECONOMICA ...................................................................................... 7
1.5. METODOLOGIA .................................................................................................................. 8
1.6. ALCANCE Y APORTE......................................................................................................... 9
1.6.1. ALCANCE .......................................................................................................................... 9
1.6.2. APORTE ........................................................................................................................... 10
2. CAPITULO II MARCO TEORICO ....................................................................................... 11
2.1. MARCO CONCEPTUAL .................................................................................................... 11
2.1.1. DEFINICIÓN DE SISTEMA............................................................................................ 11
2.1.10. ENTRADA DE INFORNACION ................................................................................... 18
2.1.11. PROCESAMIENTO DE INFORMACION .................................................................... 18
2.1.12. SALIDA DE INFORMACION ....................................................................................... 19
2.1.13. CARACTERISITICAS DE LA BASE DE DATOS ....................................................... 19
2.1.14. MODELO RELACIONAL ............................................................................................. 20
2.1.15. NORMALIZACION ....................................................................................................... 20
2.1.2. COMPONENTES DEL SISTEMA DE INFORMACIÓN ............................................... 12
2.1.3. PROGRAMACIÓN .......................................................................................................... 13
2.1.4. HTML ............................................................................................................................... 14
2.1.5. CSS.................................................................................................................................... 14
2.1.6. PHP ................................................................................................................................... 15
2.1.7. JQUERY ........................................................................................................................... 16
2.1.8. MYSQL ............................................................................................................................. 17
2.1.9. BASE DE DATOS ............................................................................................................ 17
2.2. MARCO METODOLOGICO .............................................................................................. 21
2.2.1. PROCESO UNIFICADO DE RATIONAL (RUP) ........................................................... 21
2.2.1.1. REQUISITOS ................................................................................................................ 21
2.2.1.2. ANALISIS Y DISEÑO .................................................................................................. 22
2.2.1.3. INPLEMENTACION..................................................................................................... 23
2.2.1.4. PRUEBA ........................................................................................................................ 24
2.2.2. FASES DE PROCESO UNFICADO DE RATIONAL (RUP) ......................................... 25
2.2.2.1. FASE DE INICIO .......................................................................................................... 25
2.2.2.2. FASE DE ELABORACION .......................................................................................... 25
2.2.2.3. FASE DE CIERRE......................................................................................................... 25
1
2.2.2.4. LENGUAJE MODELADO UNFICADO (UML) ......................................................... 26
2.2.3. DIAGRAMAS................................................................................................................... 27
2.2.3.1. DIAGRAMA DE ACTIVIDADES ................................................................................ 27
2.2.3.2. DIAGRAMA DE CASO DE USO ................................................................................. 27
2.2.3.3. DIAGRAMA DE SECUENCIAS .................................................................................. 29
2.2.3.4. DIAGRAMA DE OBJETOS ......................................................................................... 31
2.2.3.5. DIAGRAMA DE CLASES ............................................................................................ 32
2.2.3.6. DIAGRAMA DE COMPONENTES ............................................................................. 33
2.2.3.7. DIAGRAMA DE COLABORACION ........................................................................... 35
2.2.3.8. DIAGRAMA DE ESTADOS......................................................................................... 36
2.2.3.9. DIAGRAMA DE ACTIVIDADES ................................................................................ 37
3. CAPÍTULO III ANALISIS DEL SISTEMA .......................................................................... 38
3.1. MODELO DEL NEGOCIO ................................................................................................. 38
3.1.1. DESCRIPCIÓN DEL NEGOCIO ..................................................................................... 38
3.1.2. DIAGRAMA DE CASOS DE USO DEL NEGOCIO ..................................................... 39
3.1.3. DESCRIPCIÓN DE CASOS DE USO DEL NEGOCIO.................................................. 40
3.1.4. DIAGRAMAS DE ACTIVIDADES DE CASOS DE USO DEL NEGOCIO ................. 45
3.2. ESPECIFICACION DE REQUERIMIENTOS ................................................................... 50
3.3. FUNCIONES DEL SISTEMA............................................................................................. 50
3.4. MODELO DE CASOS DE USO DEL SISTEMA .............................................................. 50
3.4.1. IDENTIFICACIÓN DE ACTORES ................................................................................. 51
3.4.2. IDENTIFICACIÓN DE CASOS DE USO DEL SISTEMA ............................................ 51
3.4.3. DIAGRAMA DE CASOS DE USO DEL SISTEMA....................................................... 53
3.4.4. DESCRIPCION DE CASOS DE USO DEL SISTEMA .................................................. 61
3.5. DIAGRAMA DE ACTIVIDADES DEL SISTEMA ........................................................... 61
4. CAPITULO IV DISEÑO DEL SISTEMA ............................................................................. 62
4.1. MODELO DE DISEÑO ....................................................................................................... 62
4.1. SUBSISTEMAS DE DISEÑO ............................................................................................. 62
4.1.1. IDENTIFICACIÓN DE LAS CLASES DEL SISTEMA ................................................. 63
4.1.2. DIAGRAMA DE CLASES DE DISEÑO ......................................................................... 64
4.2. DIAGRAMA DE INTERACCIÓN ..................................................................................... 64
4.2.3. DIAGRAMA DE ESTADOS............................................................................................ 65
4.3. DIAGRAMA DE CLASES PERSISTENTES PARA LA BASE DE DATOS ................... 65
4.4. DISEÑO DE INTERFACES ................................................................................................ 66
4.4.1. DIAGRAMA DE ORGANIZACIÓN DE INTERFACES................................................ 67
4.4.2. ESPECIFICACION DE INTERFACES DE USUARIO .................................................. 70
5. CAPITULO V IMPLEMENTACION Y PRUEBAS DEL SISTEMA .................................. 70
5.1. DIAGRAMA DE COMPONENTES ................................................................................... 70
5.2. DIAGRAMA DE DESPLIEGE ........................................................................................... 70
5.3. MODELO DE PRUEBA ...................................................................................................... 70
6. CAPITULO VI CONCLUSIONES Y RECOMENDACIONES ............................................ 70
6.1. CONCLUSIONES ............................................................................................................... 70
6.2. RECOMENDACIONES ...................................................................................................... 70
2
INDICE DE ILUSTRACIONES
Ilustración 1 crokis de la institución .............................................................................................. 2

Ilustración 2 metodologías ............................................................................................................ 8
Ilustración 3 actor ....................................................................................................................... 28
Ilustración 4 caso de uso ............................................................................................................. 28
Ilustración 5 relación de asociación ............................................................................................ 28
Ilustración 6 relación de dependencia ......................................................................................... 28
Ilustración 7 relación de generalización ...................................................................................... 29
Ilustración 8 línea de vida del mensaje ....................................................................................... 30
Ilustración 9 mensajes ................................................................................................................. 30
Ilustración 10 mensaje llamado a si mismo ................................................................................ 31
Ilustración 11 ejemplo de clase ................................................................................................... 33
Ilustración 12 ejemplo de clase con atributos ............................................................................ 33
Ilustración 13 diagrama de actividades del caso de uso solicitar mantenimiento de equipos ..... 45
Ilustración 14 Diagrama de actividades del caso de uso “solicitar mantenimiento de parte de
equipo” ........................................................................................................................................ 46
Ilustración 15 diagrama de actividades del caso de uso "solicitar kardex por equipo" ............... 47
Ilustración 16 diagrama de actividades del caso de uso "solicitar informe de solicitudes de
mantenimiento" ........................................................................................................................... 48
Ilustración 17 diagrama de actividades del caso de uso "solicitar los estados por equipo" ........ 49
Ilustración 18 identificación de actores ....................................................................................... 51
Ilustración 19 casos de uso del sistema ....................................................................................... 53
Ilustración 20 diagrama de actividades del caso de uso del sistema "solicitar mantenimiento de
equipos" ...................................................................................................................................... 61
Ilustración 21 diagrama de clases iniciar sesión ......................................................................... 63
Ilustración 22 diagrama de clases solicitar mantenimiento de equipo ...................................... 63
Ilustración 23 diagrama de secuencia "solicitar mantenimiento de equipo" ............................. 64
Ilustración Diagrama de organización de interfaces "personal solicitante" ............................ 66
Ilustración 24 diagrama de organización de interfaces "encargado NTICS" ............................... 67
Ilustración 25 diagrama de organización de interfaces "asistente de NITCS" ............................ 67
Ilustración 26 especificación de interface de usuario "solicitar mantenimiento de equipo ...... 68
3
INDICE DE TABLAS
Tabla 1 autoridades de la facultad de Derecho.............................................................................. 1
Tabla 2 Descripción de casos de uso del negocio: solicitar mantenimiento de equipo ............... 40
Tabla 3 Descripción de casos de uso del negocio: solicitar mantenimiento de parte de equipo . 41
Tabla 4 Descripción de casos de uso del negocio: solicitar informe de los estados de los equipos
..................................................................................................................................................... 42
Tabla 5Descripción de casos de uso del negocio: solicitar informe de solicitudes de
mantenimiento ............................................................................................................................. 43
Tabla 6 Descripción de casos de uso del negocio: solicitar kardex por equipo .......................... 44
Tabla 7 descripción de caso de uso del sistema solicitud de mantenimiento de equipo ........... 54
Tabla 8 Descripción de caso de uso del sistema solicitud de mantenimiento de parte de equipo
..................................................................................................................................................... 55
Tabla 9 Descripción de caso de uso del sistema seguimiento de estado de solicitud de
mantenimiento de equipo .......................................................................................................... 56
Tabla 10 Descripción de caso de uso del sistema estado de solicitud de mantenimiento de
parte de equipo ........................................................................................................................... 57
Tabla 11 Descripción de caso de uso del sistema solicitar kardex por equipo ... Error! Bookmark
not defined.
Tabla 12 Descripción de caso de uso del sistema informe de estados de equipo ................Error!
Bookmark not defined.
Tabla 13 Descripción de caso de uso del sistema solicitar informe de solicitudes de
mantenimiento realizados ..............................................................Error! Bookmark not defined.
4
1. CAPITULO I
ASPECTOS GENERALES
1.1. ANTECEDENTES
1.1.1. ANTECEDENTES DE LA INSTITUCION
La facultad de Derecho, Ciencias Políticas y Sociales, fue creada en base a la carrera

de derecho, por ley 15 de octubre de 1892, año en que se funda la Universidad Técnica
de Oruro, con el nombre de distrito de Oruro, al presente ofrece las siguientes carreras,
Derecho, Ciencias de la Comunicación y Antropología.
El Origen de la universidad técnica de Oruro se remonta a 1876, año en el que empezó

a funcionar la Facultad de Derecho, con carácter de empresa particular, su creación
fue impulsado, por la dinámica de conocimiento, como expresión del aumento
económico laboral pujante a fines del siglo XIX.
Tabla 1 autoridades de la facultad de Derecho
DECANO M. Sc. Edgar Chire Andrade
VICE-DECANO M. Sc. Raúl Guzmán Candía
DIRECTOR CARRERA DE Dr. Jorge Rene Miranda Ocampo

DERECHO
DIRECTOR DE CARRERA Lic. Antonio A. Valdez Daza

DE CIENCIAS DE LA
COMUNICACIÓN
DIRECTOR DE LA Lic. Edgar Huarachi Mamani
CARRERA DE
ANTROPOLOGIA
1
Posteriormente, el 12 de noviembre de 1937, durante el gobierno de la junta militar
presidida, por el Tcnl. Germán Bush se dictó el Decreto Supremo reconociendo la
autonomía del Distrito universitario de Oruro, con el nombre de san Agustín.
La actual denominación, de Universidad Técnica de Oruro, fue adoptada, el 31 de

marzo de 1941, en la gestión rectoral, del Josermo Murillo Vacarreza, en virtud del
gran interés, de los estamentos universitarios de orientar y dirigir, la enseñanza
superior de Oruro.
Ilustración 1 crokis de la institución
Facultad de Derecho
Oruro
1.1.2. ANTECEDENTES DE CONTEXTO

La facultad de Derecho Ciencias Políticas y Sociales, tiene relación con la
Universidad Técnica de Oruro, que se encarga de formar a los estudiantes de
la carrera de Derecho en personas, integras para la sociedad, que apoyen al
crecimiento de nuestra amada ciudad para que un futuro apoyan al desarrollo
de la ciudad.
La misma ya mencionada se encarga enseñar a los estudiante de la facultad

de Derecho, en sus distintas ramas que tiene dicho de otro manera tiene
varias materias que apoyan al desarrollo del estudiante en el transcurso de
cada año que pasa en la facultad con el único fin de ser un buen profesional
y ayude a la evolución de nuestra amada ciudad de Oruro.
2
Es importante mencionar que la facultad tiene varias áreas donde se
desarrollan varias y diversas actividades en la misma, mencionamos algunas,
como el área de Kardex que hace referencia a toda la gestión de los datos de
notas, materias, la pertenencia de los paralelos área muy importante de la
carrera, también tenemos a el área de seguro estudiantil que tiene la gran
función de respaldar a los estudiantes que tiene problemas médicos, para
poder asistirles y darles el debido tratamiento y colaborar a su estado físico,
también tenemos el área de nuevas tecnologías de la comunicación que está
encargada de brindar varios servicios y aportes a la facultad, una de ellas es
el de apoyo a la realización de actividades académicas, al desarrollo de
exámenes en distintas materias, dando la evolución en las maquinas o
equipos del laboratorio de nuevas tecnologías de la información y
comunicación, de igual forma brindando apoyo al examen con simulacros
para el mejor desarrollo de la distintas actividades realizados en dicha área,
también cabe destacar que esta área es encargada de registrar a los
estudiantes de las carreras de Derecho, Ciencias de la Comunicación y
antropología.
1.1.3. ANTECEDENTES DEL TEMA
El sistema de información de solicitud de mantenimientos e inventario de

equipos, del laboratorio de nuevas tecnologías de información y
comunicación de tener la capacidad de ser utilizado por el encargado de
NTIC.
El propósito para la realización del proyecto es para elaborar un sistema de
información que ahorre tiempo, mayor rapidez y seguridad para luego
obtener buenos resultados.
El sistema de información va controlar la solicitud de mantenimientos que
se realice en la facultad de derecho ciencias políticas y sociales, la misma se
realizara mediante un formulario por la cual deben llenar y ser enviado al
encargado de laboratorio y este procederá con el mantenimiento respectivo
3
solicitado, también tiene que imprimir un reporte en la que se indique los,
mantenimientos que se realizó, todo esto para quede como constancia que se
ha trabajado y que se realiza los mantenimientos respectivos y que se da el
soporte necesario a las demás oficinas que estén en el marco de la facultad
de Derecho.
Por otra parte se realizara el inventario de los equipos del laboratorio y de
las demás oficinas que pertenezcan a la institución para que se tenga un
seguimiento de los estados que se encuentran cada equipo de cómputo al
igual que de sus partes que la componen ya que es muy importante saber, si
los mismos se encuentran activos o inactivos, de la misma manera se debe
sacar un reporte por cada equipo en la que muestre si ficha de datos de todas
las partes que la componen y su actividad o estado en la que se encuentra.
1.2. PLANTEAMIENTO DEL PROBLEMA

1.2.1. FUNDAMENTACION DEL PROBLEMA
El proceso de solicitud de mantenimiento e inventario de equipos de la

facultad de Derecho San Agustín, no cuenta con un sistema ya que todo se
realiza de manera manual, y de esta forma se tarda mucho en la solicitud de
mantenimiento y de la misma forma en el cumplimiento de la misma, por
otro lado no queda constancia de los mantenimientos realizados ya que las
mismas son realizadas de manera verbal.
Por otra parte se realizara el inventario de los equipos ya que los mismos
están difusos ya que solo se cuenta en cuaderno la información de los equipos
y de las partes que la componen, y que se tarda en buscar la información y
que dificulta saber que equipos están activos o inactivos de la misma manera
sus partes por lo que se pretende mejorar es el tiempo de ejecución de
mencionadas cuestiones y de la misma forma que se deje constancia del
trabajo realizado.
4
1.2.2. FORMULACION DEL PROBLEMA
1.3. OBJETIVOS
1.3.1. OBJETIVO GENERAL
Desarrollar un sistema de información en entorno web para la solicitud de

mantenimiento e inventario de equipos de la facultad de Derecho San
Agustín de manera que la información generada sea precisa, exacta,
almacenada de forma uniforme y detallada facilitando la toma de decisiones.
1.3.2. OBJETIVOS ESPECIFICOS
- Analizar la información necesaria para realizar las distintas solicitudes

de mantenimiento de equipos de la misma manera la información para
el inventario de los equipos.
- Diseñar las interfaces necesarias para que el sistema pueda correr con
toda tranquilidad y que no se produzca inconvenientes.
- Implementar el sistema de información para que se tenga en uso y se
ayude al trabajo de la institución y que mejore en tiempo sus
actividades.
- Probar el sistema de información para que se tenga una constancia de
que el trabajo sea el deseado y de la misma forma que este en los
parámetros establecido.
5
1.4. JUSTIFICACION
1.4.1. JUSTIFICACION TECNICA
La institución cuenta con los equipos técnicos necesarios los mismos que
reúnen las características para la implementación del sistema, a estos equipos
se le dará un constante mantenimiento, también cuenta con impresoras para
la eficiente emisión de reportes e informes.
El sistema de información estará controlado por usuarios y contraseñas

puesto que la información contenida no será de utilidad para el uso externo.
El laboratorio de nuevas tecnologías de la información y comunicación

cuenta con acceso a internet las 24 horas para que el sistema sea utilizado
bajo un entorno web.
El sistema de información para su gestionamiento con lleva el desarrollo de

una aplicación para la gestión de la información, la aplicación es
desarrollado en una arquitectura cliente servidor, sobre una plataforma web,
y se maneja las tecnologías de php, para la maquetación y la presentación de
la aplicación se utiliza html5 con etiquetas estandarizadas, para la
presentación se utiliza etiquetas de estilo css3 hojas de estilo en cascada, la
base de datos esta modelado en mysql , administrada con phpadmin.
Las distintas características que proveen estas aplicaciones apoyaran a

desarrollar un sistema de información web fácil y confiable pero ante todo
práctica, con interfaz amigable para el usuario final.
Así mismo se utilizara los conocimientos necesarios para modelar el sistema

de información utilizando la metodología de RUP con su herramienta del
UML.
6
La centralización de la información tendrá un impacto significante en cuanto
a la gestión de uso del laboratorio y huella dactilar, reduciendo el papeleo, y
el tiempo la cual beneficiara a las intenciones del laboratorio.
1.4.2. JUSTIFICACION OPERATIVA
La implementación del presente sistema de información agilizara los

procesos de gestión de laboratorio, huella dactilar y mantenimientos de
equipos, y que la información de la institución se almacene de manera segura
y confiable.
El sistema cuenta con los equipos necesarios para la implementación del

mismo.
El área de NTIC y la Facultad de Derecho san Agustín tiene el personal
capacitado para el manejo del sistema de información, lo cual permitirá tener
información más rápida y precisa de los procesos que se realizan.
1.4.3. JUSTIFICACION ECONOMICA
El área de NITC dispone de los recursos necesarios para la implementación

del sistema de información.
El sistema de información guardara los datos en una base de datos, la
información será digitalizada que ayudara en la reducción de gastos en el
material de escritorio e impresión.
7
1.5. METODOLOGIA
ACTIVIDADES Y
ETAPA METODO PRODUCTOS
TAREAS
Especificación de
Recopilar
requerimientos
información, aplicar
técnicas de
Análisis de Requisitos recopilación.
Listado de
requisitos
Metodología de la
investigación Establecer los
Diagrama de casos
proceso unificado requisitos de
de uso del negocio.
de Rational (RUP) construcción.
Detallar casos de
Descripción de
uso del negocio,
casos de uso del
descripción
negocio con objetos
detallada de los
incorporados
casos de uso.
Detallar casos de
uso del sistema,
Análisis
construcción de
Proceso unificado Modelo de casos de
casos de uso del
de Rational (RUP) uso del sistema.
sistema, descripción
detallada de los
casos de uso.
Definir la Diagrama de clases
interacción de casos de diseño
de uso del sistema,
describir las Diagrama de
interacciones entre secuencia y
colaboración
Diseño
Proceso unificado objetos de diseño.

de Rational (RUP) Definir las clases,
describir
Descripción de la
operaciones
arquitectura del
métodos y
diseño
relaciones entre
clases
Implementación
Diagrama de
componentes y
Proceso unificado Implementar la
despliegue,
de Rational (RUP) arquitectura
descripción de la
arquitectura
Diseñar la prueba,
Pruebas
diseñar los casos de

Proceso unificado
prueba, Casos de prueba
de Rational (RUP)
procedimiento de
prueba
Ilustración 2 metodologías
8
1.6. ALCANCE Y APORTE
1.6.1. ALCANCE
- El sistema de información tiene los siguientes alcances, registrar todos

los equipos de las diferentes oficinas que se tiene en la facultad de
Derecho san Agustín, para obtener el inventario de todos los equipos y
de la misma forma sus partes que a componen.
- En cuanto a las partes que la componen se tiene que registrar sus datos
como por ejemplo tenemos su número de serie, modelo, marca y otros
que ayuden a identificar y tener un almacén de datos más extenso e
informado.
- De la misma manera el sistema de información va recibir las diferentes
solicitudes de mantenimiento que se lo realizara en el laboratorio de las
distintas partes de la facultad, también se tiene que llenar un formulario
en la cual se tiene que especificar las cosas que se deben realizar como
pueden ser los mantenimientos correctivos preventivos o de
complementación, de la misma manera se pondrá los datos del solicitante
y la hora la fecha, y el lugar de donde se solicita.
- Imprimir un reporte en la que se puede observar las solicitudes que se
han realizado en determinado tiempo y otros.
- Imprimir un informe de cada equipo en la cual se debe mostrar, su estado,
las partes en que las componen, en qué lugar se encuentra.
9
1.6.2. APORTE
- Aporte a la institución
Este sistema de información es un aporte a la institución ya que es un
fruto de la misma atravez de las enseñanzas que se imparte por parte de
los docentes que ayudan a que los estudiantes sean cada día mejor.
- Aporte científico
Es un aporte científico ya que el proyecto será un punto de referencia
para los demás estudiantes de los cursos siguientes, para que los mismos
realicen sus proyectos.
- Aporte bibliográfico
Un aporte bibliográfico ya que el mismo se quedara en la biblioteca del
instituto para que los demás estudiante pueden ver el trabajo que se a
realizado y los temas que se han tratado.
10
2. CAPITULO II MARCO TEORICO
2.1. MARCO CONCEPTUAL

2.1.1. DEFINICIÓN DE SISTEMA
Según el diccionario de María Moliner (Moliner, 1990), sistema es el
“Conjunto ordenado de normas y procedimientos con que funciona o se hace
funcionar una cosa. Conjunto de cosas que se mueven, actúan u obran
coordenadamente”.
Esta definición tan amplia combina los elementos estáticos con los
dinámicos, al mismo tiempo que por un lado las normas y por otro los
elementos.
Esencialmente, con respecto a la definición de sistema debemos destacar
que:
• Los sistemas están limitados, natural o artificialmente.
• Todo lo que está situado fuera de los límites del sistema se denomina
entorno
• El sistema toma elementos del entorno, entradas, como materias primas
para elaborar los productos que se devuelven al entorno, salidas.
• Los sistemas pueden ser naturales o artificiales, si son debidos al hombre.
Un sistema de información es un sistema artificial.
Contiene información de sus procesos y su entorno. En palabras de (Laudon

& Laudon, 2001) “Un conjunto de componentes interrelacionados que
permiten capturar, procesar, almacenar y distribuir la información para
apoyar la toma de decisiones y el control en una institución”.
11
SISTEMAS INFORMATICOS
- Definición basada en tecnología de la información (Whitten, Bentley y

Ritman, 2004) ◦ Conjunto de personas, datos, procesos y tecnología de
la información que interactúan para recoger, procesar, almacenar y
proveer la información necesaria para el correcto funcionamiento de la
organización. Personas: Directivos, usuarios, analistas, diseñadores,
Datos: materia prima para crear información útil Procesos: actividades
de empresa que generan información Tecnologías de información:
hardware y software que sostienen a los anteriores tres componentes.
- Definición basada desde una perspectiva estratégica (Andreu, Ricarte y
valor, 1996) ◦ Conjunto formal de procesos que, operando con un
conjunto de datos estructurados de acuerdo a las necesidades de una
empresa, recopila, elabora y distribuye (parte de) la información
necesaria para la operación de dicha empresa y para las actividades de
dirección de control correspondientes, apoyando al menos en parte, la
toma de decisiones necesaria para desempeñar las funciones y procesos
de negocio de la empresa de acuerdo con su estrategia.
2.1.2. COMPONENTES DEL SISTEMA DE INFORMACIÓN
Individuos participantes: Son todas aquellas personas cuyo trabajo tiene que
ver con la creación, la recolección, la distribución y el uso de la información.
- Propietarios de sistemas
- Usuarios de sistemas
- Diseñadores de sistemas
- Constructores de sistemas
- Analistas de sistemas
- Project Manager
Datos e información: Diferencia entre datos e información:
12
- Datos: Hechos y cifras con existencia propia e independiente con poco
significado para el usuario, Ejemplo: Horas que produce un trabajador,
tiempo que tarda, Se necesita saber en qué contexto se utilizan Gracias
a las tecnologías de la información, se almacenan y se transforman en
información
- Información: Conjunto de datos procesados con significado, y dotados
de relevancia y propósito. Ejemplo: Precio hora por horas trabajadas nos
dan información de lo que ganará un empleado.
Procesos de negocio: Los sistemas de información tienen que alcanzar el

objetivo de mejorar la eficiencia de los procesos de negocio, deben
implicarse los propietarios y los usuarios del sistema. Propietarios deben
definir y acotar las funciones de negocio (grupo de procesos que interactúan
entre ellos: ventas, producción, logística, contabilidad).
Usuarios deben definir los procesos de negocio (conjunto de tareas que

responden a acontecimientos de negocio: pedido, factura, alta cliente,
albarán), Automatizar estos procesos.
2.1.3. PROGRAMACIÓN
Es el proceso de diseñar, codificar y mantener el código fuente de programas

computacionales. El código fuente es escrito en un lenguaje de
programación, el propósito del mismo es de crear programas que muestren
un comportamiento deseado por alguna entidad, el proceso de escribir el
código requiere frecuentemente de varios conocimientos, aparte del dominio
del lenguaje, algoritmos y lógica formal, programar no involucra
necesariamente al análisis y diseño de la aplicación, aunque suelen ser
usados en pequeños programas.
13
2.1.4. HTML
HTML provee básicamente tres características: estructura, estilo y
funcionalidad. Nunca fue declarado oficialmente pero, incluso cuando
algunas APIs (Interface de Programación de Aplicaciones) y la
especificación de CSS3 por completo no son parte del mismo, HTML5 es
considerado el producto de la combinación de HTML, CSS y Javascript.
Estas tecnologías son altamente dependientes y actúan como una sola unidad
organizada bajo la especificación de HTML5.
HTML está a cargo de la estructura, CSS presenta esa estructura y su
contenido en la pantalla y Javascript hace el resto que (como veremos más
adelante) es extremadamente significativo.
Más allá de esta integración, la estructura sigue siendo parte esencial de un
documento. La misma provee los elementos necesarios para ubicar
contenido estático o dinámico, y es también una plataforma básica para
aplicaciones. Con la variedad de dispositivos para acceder a Internet y la
diversidad de interfaces disponibles para interactuar con la web, un aspecto
básico como la estructura se vuelve parte vital del documento. Ahora la
estructura debe proveer forma, organización y flexibilidad, y debe ser tan
fuerte como los fundamentos de un edificio.
2.1.5. CSS
La sigla CSS corresponde a la expresión inglesa Cascading Style Sheets, que

puede traducirse como “Hojas de estilo en cascada”. El concepto se utiliza
en el ámbito de la informática para referirse a un lenguaje empleado en el
diseño gráfico.
El lenguaje CSS permite presentar, de manera estructurada, un documento
que fue escrito en un lenguaje de marcado. Se usa especialmente en el diseño
visual de un sitio web cuando las páginas se hallan escritas en XML o
HTML.
14
El CSS se desarrolló en distintos niveles. El CCS1 ya no se emplea, mientras
que el CSS2 funciona como recomendación. El CSS3, que se divide en
varios módulos, es el lenguaje que se está tomando como estándar.
Lo que hace el CSS es encargarse de la descripción de las formas y de la
sintaxis del lenguaje de marcado. De esta manera describe cómo se tienen
que renderizar (generar las imágenes) los elementos que aparecen en
pantalla.
El diseño del CSS posibilita establecer una separación entre el contenido y
la forma de presentación del documento (dada por las fuentes, los colores y
las capas empleadas). Así se puede lograr que muchos documentos HTML
compartan la apariencia, utilizando una única hoja de estilo para todos (que
se especifica en un archivo .css).
Gracias a esta particularidad, se evita tener que repetir el código en la
estructura.
2.1.6. PHP
El acrónimo recursivo, sin embargo, en la actualidad está vinculado a PHP

Hipertexto Pre-Processor. El lenguaje es desarrollado hoy en día por The
PHP Group aunque carece de una normativa formal. La Free Software
Foundation, por lo tanto, considera la licencia PHP como parte del software
libre.
El lenguaje PHP suele procesarse directamente en el servidor aunque
también puede usarse a través de software capaz de ejecutar comandos y para
el desarrollo de otra clase de programas.
Lerdorf diseñó la primera versión de PHP en lenguaje Perl basado en la
escritura de un conjunto de CGI del lenguaje C. Su intención era presentar
su currículum vitae y almacenar datos como la cantidad de visitantes que
accedían a su página web.
15
Los programadores de origen israelí Zeev Suraski y Andi Gutmans, por su
parte, se encargaron de reescribir el analizador sintáctico en 1997 y lanzaron
el PHP3, reemplazando el nombre del lenguaje con el más reciente. Con el
tiempo, estos programadores reescribirían la totalidad del código de PHP.
Actualmente el PHP suele incrustarse dentro del código HTML de las

páginas web y ejecutarse desde un servidor. Se estima que PHP está presente
en más de veinte millones de webs y en cerca de un millón de servidores.
Una de las ventajas de PHP es su parecido con lenguajes de programación

del tipo estructurado (como Perl y C), lo que ayuda a que los programadores
puedan desarrollar aplicaciones complejas en poco tiempo. De hecho, para
un programador con poca experiencia en este lenguaje, es muy sencillo
aprenderlo y trasladar a sus páginas funciones y estructuras que suela utilizar
en la creación de otras clases de software.
2.1.7. JQUERY
JQuery es una biblioteca gratuita de Javascript, cuyo objetivo principal es

simplificar las tareas de creación de páginas web responsivas, acordes a lo
estipulado en la Web 2.0, la cual funciona en todos los navegadores
modernos. Por otro lado, se dice que jQuery ayuda a que nos concentremos
de gran manera en el diseño del sitio, al abstraer por completo todas las
características específicas de cada uno de los navegadores.
Otra de las grandes ventajas de jQuery es que se enfoca en simplificar los

scripts y en acceder/modificar el contenido de una página web. Finalmente,
jQuery agrega una cantidad impresionante de efectos nuevos a Javascript,
los cuales podrán ser utilizados en tus sitios Web.
Escenarios que se facilitan con el uso de jQuery:
 Carga de la página -> Configuraciones de la página

 Eventos -> Agarrar contenido de la página, manipula o anima el
contenido, regresa el contenido
16
Beneficios del uso de jQuery:
 jQuery utiliza sintaxis muy parecida a CSS.

 Funciona con series de elementos.
 Permite manipular series de elementos y modificarlas con una simple
línea de código. (Encadenamiento de enunciados).
 Te ayuda a concentrarte en el resultado final.
 jQuery es muy fácil de expandir, ya que cuenta con gran cantidad de plug-
ins que se pueden utilizar o hasta crear uno propio.
 Compatible con todos los navegadores modernos.
2.1.8. MYSQL
MySQL es un sistema de gestión de base de datos relacional (RDBMS) de

código abierto, basado en lenguaje de consulta estructurado (SQL).
MySQL se ejecuta en prácticamente todas las plataformas, incluyendo
Linux, UNIX y Windows. A pesar de que se puede utilizar en una amplia
gama de aplicaciones, MySQL se asocia más con las aplicaciones basadas
en la web y la publicación en línea y es un componente importante de una
pila empresarial de código abierto llamado LAMP.
LAMP es una plataforma de desarrollo web que utiliza Linux como sistema
operativo, Apache como servidor web, MySQL como sistema de gestión de
base de datos relacional y PHP como lenguaje de programación orientado a
objetos (a veces, Perl o Python se utiliza en lugar de PHP).
2.1.9. BASE DE DATOS
Una base de datos se define como un fichero en el cual se almacena

información en campos o delimitadores, teniendo acceso a ella
posteriormente tanto de forma separada como de forma conjunta. Se utiliza
normalmente para recoger grandes cantidades de información. (Por ejemplo
el listado de nombres y apellidos de los alumnos de varios cursos)
17
Normalmente el número de campos (columnas) que se pueden tener en una
base varía según las necesidades en cuanto a gestión de datos, de forma que
después se pueda explotar la información de forma ordenada y separada,
aunque el resto de la información sigue almacenada y guardada en la base de
datos.
En realidad aparte de los datos que son almacenados en el archivo, también
hay una serie de datos, en los que se informa del tipo de campo, los campos
y la longitud de cada campo, es lo que se llama gestor de datos, que permite
saber cada registro o fila, (un registro es una suma de campos).
El programa que sirve para manejar toda esa información se denomina

sistema gestor de base de datos. Las principales en estos momentos son
Microsoft Access, Lotus Aproach, parados, u Oracle.
2.1.10. ENTRADA DE INFORNACION
Una entrada es, en el campo de la informática, una serie de datos que es

recibida por un determinado sistema para su posterior procesamiento. Este
concepto siempre aparece vinculado con la salida, que supone la
presentación de la información para que el usuario haga uso de ésta según lo
necesite.
2.1.11. PROCESAMIENTO DE INFORMACION
Es la Técnica que consiste en la recolección de los datos primarios de

entrada, que son evaluados y ordenados, para obtener información útil, que
luego serán analizados por el usuario final, para que pueda tomar las
decisiones o realizar las acciones que estime conveniente.
18
2.1.12. SALIDA DE INFORMACION
La salida en informática es el proceso de transmitir la información por un

objeto (el uso de verbo). Esencialmente, es cualquier dato que sale de un
sistema de ordenador.
2.1.13. CARACTERISITICAS DE LA BASE DE DATOS
- Independencia de los Datos. Es decir, que los datos no dependen del

programa y por tanto cualquier aplicación puede hacer uso de los datos.
- Reducción de la Redundancia. Llamamos redundancia a la existencia de

duplicación de los datos, al reducir ésta al máximo conseguimos un mayor
aprovechamiento del espacio y además evitamos que existan inconsistencias
entre los datos. Las inconsistencias se dan cuando nos encontramos con datos
contradictorios.
- Seguridad. Un SBD debe permitir que tengamos un control sobre la

seguridad de los datos.
- Se visualiza normalmente como una tabla de una hoja de cálculo, en la que

los registros son las filas y las columnas son los campos, o como un
formulario.
- Permite realizar un listado de la base de datos.
- Permiten la programación a usuarios avanzados.
19
2.1.14. MODELO RELACIONAL
El modelo relacional, para el modelado y la gestión de bases de datos, es un

modelo de datos basado en la lógica de predicados y en la teoría de
conjuntos.
En este modelo todos los datos son almacenados en relaciones, y como cada
relación es un conjunto de datos, el orden en el que estos se almacenen no
tiene relevancia (a diferencia de otros modelos como el jerárquico y el de
red).
Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar
por un usuario no experto. La información puede ser recuperada o
almacenada por medio de consultas que ofrecen una amplia flexibilidad y
poder para administrar la información.
Este modelo considera la base de datos como una colección de relaciones.
De manera simple, una relación representa una tabla que no es más que un
conjunto de filas, cada fila es un conjunto de campos y cada campo
representa un valor que interpretado describe el mundo real.
Cada fila también se puede denominar tupla o registro y a cada columna
también se le puede llamar campo o atributo.
Para manipular la información utilizamos un lenguaje relacional,
actualmente se cuenta con dos lenguajes formales el Álgebra relacional y el
Cálculo relacional.
2.1.15. NORMALIZACION
La normalización de bases de datos es un proceso que consiste en designar

y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo
entidad-relación al modelo relacional. Las bases de datos relacionales se
normalizan para: Evitar la redundancia de los datos. Las bases de datos
relacionales se normalizan para:
Evitar la redundancia de los datos.
20
Disminuir problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para
que una tabla sea considerada como una relación tiene que cumplir con
algunas restricciones:
Cada tabla debe tener su nombre único.
No puede haber dos filas iguales. No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.
2.2. MARCO METODOLOGICO

2.2.1. PROCESO UNIFICADO DE RATIONAL (RUP)
El Proceso Racional Unificado o RUP (por sus siglas en inglés de Rational

Unified Process) es un proceso de desarrollo de software desarrollado por la
empresa Rational Software, actualmente propiedad de IBM. Junto con el
Lenguaje Unificado de Modelado (UML), constituye la metodología
estándar más utilizada para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos.
2.2.1.1. REQUISITOS
Este es uno de los flujos de trabajo más importantes, porque en él se

establece qué tiene que hacer exactamente el sistema que
construyamos. En esta línea los requisitos son el contrato que se debe
cumplir, de modo que los usuarios finales tienen que comprender y
aceptar los requisitos que especifiquemos.
Los objetivos del flujo de datos Requisitos es [RSC02]:
Establecer y mantener un acuerdo entre clientes y otros stakeholders
sobre lo que el sistema podría hacer.
Proveer a los desarrolladores un mejor entendimiento de los requisitos
del sistema.
21
o Definir el ámbito del sistema.
o Proveer una base para la planeación de los contenidos técnicos
de las iteraciones.
o Proveer una base para estimar costos y tiempo de desarrollo del
sistema.
o Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.
Los requisitos se dividen en dos grupos. Los requisitos funcionales
representan la funcionalidad del sistema. Se modelan mediante
diagramas de Casos de Uso. Los requisitos no funcionales representan
aquellos atributos que debe exhibir el sistema, pero que no son una
funcionalidad específica. Por ejemplo requisitos de facilidad de uso,
fiabilidad, eficiencia, portabilidad, etc.
Para capturar los requisitos es preciso entrevistar a todos los interesados
en el proyecto, no sólo a los usuarios finales, y anotar todas sus
peticiones. A partir de ellas hay que descubrir lo que necesitan y
expresarlo en forma de requisitos.
En este flujo de trabajo, y como parte de los requisitos de facilidad de
uso, se diseña la interfaz gráfica de usuario. Para ello habitualmente se
construyen prototipos de la interfaz gráfica de usuario que se contrastan
con el usuario final.
2.2.1.2. ANALISIS Y DISEÑO
El objetivo de este flujo de trabajo es traducir los requisitos a una

especificación que describe cómo implementar el sistema.
Los objetivos del análisis y diseño son [RSC02]:
• Transformar los requisitos al diseño del futuro sistema.
• Desarrollar una arquitectura para el sistema.
• Adaptar el diseño para que sea consistente con el entorno de
implementación, diseñando para el rendimiento.
22
El análisis consiste en obtener una visión del sistema que se preocupa
de ver qué hace, de modo que sólo se interesa por los requisitos
funcionales. Por otro lado el diseño es un refinamiento del análisis que
tiene en cuenta los requisitos no funcionales, en definitiva cómo cumple
el sistema sus objetivos.
Al principio de la fase de elaboración hay que definir una arquitectura
candidata: crear un esquema inicial de la arquitectura del sistema,
identificar clases de análisis y actualizar las realizaciones de los Casos
de Uso con las interacciones de las clases de análisis.
Durante la fase de elaboración se va refinando esta arquitectura hasta
llegar a su forma definitiva. En cada iteración hay que analizar el
comportamiento para diseñar componentes. Además si el sistema usará
una base de datos, habrá que diseñarla también, obteniendo un modelo
de datos.
El resultado final más importante de este flujo de trabajo será el modelo
de diseño. Consiste en colaboraciones de clases, que pueden ser
agregadas en paquetes y subsistemas.
Otro producto importante de este flujo es la documentación de la
arquitectura de software, que captura varias vistas arquitectónicas del
sistema.
2.2.1.3. INPLEMENTACION
En este flujo de trabajo se implementan las clases y objetos en ficheros

fuente, binarios, ejecutables y demás. Además se deben hacer las
pruebas de unidad: cada implementador es responsable de probar las
unidades que produzca. El resultado final de este flujo de trabajo es un
sistema ejecutable.
En cada iteración habrá que hacer lo siguiente:
• Planificar qué subsistemas deben ser implementados y en qué orden
deben ser integrados, formando el Plan de Integración.
23
• Cada implementador decide en qué orden implementa los elementos
del subsistema.
• Si encuentra errores de diseño, los notifica.
• Se prueban los subsistemas individualmente.
• Se integra el sistema siguiendo el plan.
La estructura de todos los elementos implementados forma el modelo
de implementación. La integración debe ser incremental, es decir, en
cada momento sólo se añade un elemento. De este modo es más fácil
localizar fallos y los componentes se prueban más a fondo. En fases
tempranas del proceso se pueden implementar prototipos para reducir
el riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el
principio, probar tecnologías o diseñar la interfaz de usuario. Los
prototipos pueden ser exploratorios (desechables) o evolutivos. Estos
últimos llegan a transformarse en el sistema final.
2.2.1.4. PRUEBA
Este flujo de trabajo es el encargado de evaluar la calidad del producto

que estamos desarrollando, pero no para aceptar o rechazar el producto
al final del proceso de desarrollo, sino que debe ir integrado en todo el
ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son
• Encontrar y documentar defectos en la calidad del software.
• Generalmente asesora sobre la calidad del software percibida.
• Provee la validación de los supuestos realizados en el diseño y
especificación de requisitos por medio de demostraciones concretas.
• Verificar las funciones del producto de software según lo diseñado.
• Verificar que los requisitos tengan su apropiada implementación.
Las actividades de este flujo comienzan pronto en el proyecto con el
plan de prueba (el cual contiene información sobre los objetivos
generales y específicos de las prueba en el proyecto, así como las
24
estrategias y recursos con que se dotará a esta tarea), o incluso antes
con alguna evaluación durante la fase de inicio, y continuará durante
todo el proyecto.
El desarrollo del flujo de trabajo consistirá en planificar que es lo que
hay que probar, diseñar cómo se va a hacer, implementar lo necesario
para llevarlos a cabo, ejecutarlos en los niveles necesarios y obtener los
resultados, de forma que la información obtenida nos sirva para ir
refinando el producto a desarrollar.
2.2.2. FASES DE PROCESO UNFICADO DE RATIONAL (RUP)

2.2.2.1. FASE DE INICIO
Esta fase tiene como propósito definir y acordar el alcance del proyecto
con los patrocinadores, identificar los riesgos asociados al proyecto,
proponer una visión muy general de la arquitectura de software y
producir el plan de las fases y el de iteraciones posteriores.
2.2.2.2. FASE DE ELABORACION
En la fase de elaboración se seleccionan los casos de uso que permiten

definir la arquitectura base del sistema y se desarrollaran en esta fase,
se realiza la especificación de los casos de uso seleccionados y el
primer análisis del dominio del problema, se diseña la solución
preliminar.
2.2.2.3. FASE DE CIERRE
El propósito de esta fase es completar la funcionalidad del sistema, para

ello se deben clarificar los requisitos pendientes, administrar los
cambios de acuerdo a las evaluaciones realizados por los usuarios y se
realiza. El propósito de esta fase es asegurar que el software esté
25
disponible para los usuarios finales, ajustar los errores y defectos
encontrados en las pruebas de aceptación, capacitar a los usuarios y
proveer el soporte técnico necesario. Se debe verificar que el producto
cumpla con las especificaciones entregadas por las personas
involucradas en el proyecto.
2.2.2.4. LENGUAJE MODELADO UNFICADO (UML)
UML significa "Unified Modeling Language": Lenguaje de Modelado

o Modelamiento Unificado. El Lenguaje de Modelado Unificado es un
lenguaje usado para especificar, visualizar y documentar los diferentes
aspectos relativos a un sistema de software bajo desarrollo, así como
para modelado de negocios y otros sistemas no software.
Puede ser utilizado con cualquier metodología, a lo largo del proceso
de desarrollo de software, en cualquier plataforma tecnológica de
implementación (Unix, Windows etc.).
Es un sistema notacional (que, entre otras cosas, incluye el significado
de sus notaciones) destinado a los sistemas de modelado que utilizan
conceptos orientados a objetos.
Los principales factores que motivaron la definición de UML fueron:
la necesidad de modelar sistemas, las tendencias en la industria del
software, unificar los distintos lenguajes y métodos existentes e innovar
los modelos para adaptarse a la arquitectura distribuida.
Es importante resaltar que un modelo UML describe lo que
supuestamente hará un sistema, pero no dice cómo implementar dicho
sistema.
26
2.2.3. DIAGRAMAS
2.2.3.1. DIAGRAMA DE ACTIVIDADES
Son similares a los diagramas de flujos de otras metodologías OO. En

realidad se corresponden con un caso especial de los diagramas de
estado donde los estados son estados de acción (estados con una acción
interna y una o más transiciones que suceden al finalizar esta acción, o
lo que es lo mismo, un paso en la ejecución de lo que será un
procedimiento) y las transiciones vienen provocadas por la finalización
de las acciones que tienen lugar en los estados de origen. Siempre van
unidos a una clase o a la implementación de un caso de uso o de un
método (que tiene el mismo significado que en cualquier otra
metodología OO).
Los diagramas de actividad se utilizan para mostrar el flujo de
operaciones que se desencadenan en un procedimiento interno del
sistema.
2.2.3.2. DIAGRAMA DE CASO DE USO
Se emplea para visualizar el comportamiento del sistema, una parte de

él o de una sola clase; y como se relaciona con su entorno. De ésta
forma se puede conocer cómo responde ésa parte del sistema ante un
estímulo del ambiente. El diagrama de uso es muy útil para definir
como debería ser el comportamiento de una parte del sistema, ya que
solo especifica cómo deben comportarse y no como están
implementadas las partes que define.
Un caso de uso especifica un requerimiento funcional.
Un diagrama de casos de uso consta de los siguientes elementos:
27
Actor
Un actor es un rol que tiene un usuario con respecto al sistema. Es decir,
sería un usuario del sistema. Es importante destacar el uso de la palabra
“rol”, ya que esto especifica que un actor no necesariamente representa
a una persona en particular, si no la labor que realiza frente al sistema.
Ilustración 3 actor
Caso de Uso
Es una operación o tarea específica que se realiza tras una orden o
estímulo de un agente externo, puede ser un actor o desde la invocación
desde otro caso de uso.
Se representa mediante el siguiente gráfico:
Ilustración 4 caso
de uso
Relaciones de asociación
Es el tipo de relación más básica, indica la invocación desde un actor
o caso de uso a otra operación (caso de uso). Dicha relación se denota
con una flecha simple:
Ilustración 5 relación de asociación
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una
clase depende de otra, es decir, se instancia (se crea). Dicha
relación se denota con una flecha punteada:
Ilustración 6 relación de dependencia
28
Generalización
Este tipo de relación es una de las más utilizadas, cumple una doble
función dependiendo de su estereotipo, que puede ser de Uso
(<<uses>>) o de Herencia (<<extends>>).
Ilustración 7 relación de generalización
2.2.3.3. DIAGRAMA DE SECUENCIAS

Este diagrama (también llamado diagrama de interacción) muestra las
interacciones entre un conjunto de objetos (clases, actores), ordenadas
según el tiempo en que tienen lugar.
Es decir, muestra el orden de las llamadas en el sistema. Se utiliza un
diagrama para cada llamada a representar. Es imposible representar en
un solo diagrama la secuencia de todas las llamadas posibles del
sistema, es por ello que se escoge un punto de partida. El diagrama se
compone con los objetos que forman parte de la secuencia, estos se
sitúan en la parte superior de la pantalla, normalmente a la izquierda se
sitúa el que inicia la acción.
De estos objetos sale una línea que indica su vida en el sistema. Esta
línea simple se convierte en una línea gruesa cuando representa que el
objeto tiene el foco del sistema, es decir cuando él está activo.
El objeto puede existir sólo durante la ejecución de la interacción, se
puede crear o puede ser destruido durante la ejecución de la interacción.
En este tipo de diagramas también intervienen los mensajes, que son la
forma en que se comunican los objetos: el objeto origen solicita (llama
a) una operación del objeto destino.
El diagrama de secuencia puede ser obtenido de dos partes, desde el
Diagrama Estático de Clases o desde el de Casos de Usos.
Elementos
29
Los componentes de un diagrama de interacción son:
Línea de vida
Ilustración 8 línea de vida del mensaje
Un objeto (o actor) se representa como una línea vertical punteada con

un rectángulo de encabezado y con rectángulos a través de la línea
principal que denotan la ejecución de métodos (activación). El
rectángulo de encabezado contiene el nombre del objeto y el de su
clase.
Activación
Muestra el periodo de tiempo en el cual el objeto se encuentra
desarrollando alguna operación, bien sea por sí mismo o por medio de
delegación a alguno de sus atributos. Se denota como un rectángulo
delgado sobre la línea de vida del objeto.
Mensajes
Ilustración 9 mensajes
El envío de mensajes entre objetos se denota mediante una línea sólida

dirigida, desde el objeto que emite el mensaje hacia el objeto que lo
ejecuta. Representa la llamada de un método (operación) de un objeto
en particular.
30
Ilustración 10 mensaje llamado a si mismo
También es posible visualizar llamadas a métodos desde el mismo

objeto en estudio.
El presente diagrama es útil para observar la vida de los objetos en el

sistema, identificar llamadas a realizar o posibles errores del modelo
estático, que imposibiliten el flujo de información o de llamadas entre
los componentes del sistema.
2.2.3.4. DIAGRAMA DE OBJETOS
Pertenece a la clasificación de los diagramas que dan una vista estática

del sistema.
Contiene un conjunto de instancias de los elementos encontrados en un
Diagrama de Clases. Por lo tanto, expresa la parte estática de una
interacción, consistiendo en los objetos que colaboran, pero son
ninguno de los mensajes enviados entre ellos.
Para realizarlo primero se debe decidir que situación queremos
representar del sistema, en un momento concreto del mismo,
permitiendo así mostrar los objetos y sus relaciones
En los diagramas de objetos también se pueden incorporar clases, para
mostrar la clase de la que es un objeto representado.
Con los Diagrama de Objetos no se puede especificar completamente
la estructura de objetos del sistema. Puede existir una multitud de
posibles instancias de una clase particular, y para un conjunto de clases
31
con relaciones entre ellas, pueden existir muchas más configuraciones
posibles de esos objetos.
2.2.3.5. DIAGRAMA DE CLASES
En el diagrama de clases como ya hemos comentado será donde

definiremos las características de cada una de las clases y relaciones de
dependencia y generalización. Es decir, es donde daremos rienda suelta
a nuestros conocimientos de diseño orientado a objetos, definiendo las
clases e implementando las ya típicas relaciones de herencia y
agregación.
Este diagrama sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de
uso y de contenido.
Se utiliza cuando necesitamos realizar un Análisis de Dominio: El
analista se entrevista con el cliente con el objetivo de conocer las
entidades principales en el dominio del cliente. Durante la conversación
entre el cliente y el analista se deben tomar apuntes. Desde estos
apuntes, se buscarán las clases para los objetos del modelo buscando
los sustantivos (ej: proveedor, pedido, factura, etc.) y convirtiéndolos
en clases. Después se verá que algunos de estos sustantivos pueden ser
atributos de otros en vez de entidades por si mismas. También se
buscarán los métodos para estas clases buscando los verbos (ej:
Calcular, imprimir, Agregar,..)
Elementos
Un diagrama de clases esta compuesto por los siguientes elementos:
• Clase: atributos, métodos y visibilidad.

• Relaciones: Herencia, Asociación, Ensamblado y Uso.
32
Clase
Es la unidad básica que encapsula toda la información de un Objeto (un
objeto es una instancia de una clase). A través de ella podemos modelar
el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
Ilustración 11 ejemplo Ilustración 12 ejemplo de clase con

de clase atributos
Relaciones entre Clases

Existen tres relaciones diferentes entre clases, Dependencias,
Generalización y Asociación. En las relaciones se habla de una clase
destino y de una clase origen. La origen es desde la que se realiza la
acción de relacionar. Es decir desde la que parte la flecha, la destino es
la que recibe la flecha.
2.2.3.6. DIAGRAMA DE COMPONENTES
Un diagrama de componentes muestra las organizaciones y

dependencias lógicas entre componentes software, sean éstos
componentes de código fuente, binarios o ejecutables. Los elementos
de modelado dentro de un diagrama de componentes serán
componentes y paquetes. En cuanto a los componentes, sólo aparecen
tipos de componentes, ya que las instancias específicas de cada tipo se
encuentran en el diagrama de despliegue.
33
Cada componente en el diagrama debe ser documentado con un
diagrama de componentes más detallado, un diagrama de clases, o un
diagrama de casos de uso.
Un paquete en un diagrama de componentes representa una división
física del sistema. Los paquetes se organizan en una jerarquía de capas
donde cada capa tiene una interfaz bien definida. Un diagrama de
componentes se representa como un grafo de componentes software
unidos por medio de relaciones de dependencia (generalmente de
compilación).
Normalmente los diagramas de componentes se utilizan para modelar

código fuente, versiones ejecutables, bases de datos físicas, entre otros.
Código fuente: En el modelado de código fuentes se suelen utilizar para

representar las dependencias entre los ficheros de código fuente, o para
modelar las diferentes versiones de este fichero. Para ello se deben
identificar el conjunto de archivos de código fuente de interés y
estereotiparlos como archivos file, agruparlos en paquetes, utilizar
valores etiquetados para la información de versiones y modelar las
dependencias de compilación.
Código ejecutable: Se utiliza para modelar la distribución de una nueva
versión a los usuarios. Para tal propósito se identifican el conjunto de
componentes ejecutables que intervienen, se utilizan estereotipos para
los diferentes tipos de componentes (ejecutables, bibliotecas, tablas,
archivos, documentos, etc.), se consideran las relaciones entre dichos
componentes que la mayoría de las veces incluirán interfaces que son
exportadas (realizadas) por ciertos componentes e importadas
(utilizadas) por otros.
Bases de datos física: UML permite el modelado de bases de datos
físicas así como de los esquemas lógicos de bases de datos.
34
Así si tenemos en cuenta las dependencias asociadas al proceso de
compilación un componente podría ser:
Código fuente: que depende de otros componentes (no necesariamente
código fuente) que deben estar disponibles durante la compilación del
componente.
Código objeto binario: como por ejemplo una librería, que puede
depender de algún código objeto con el que se linkea.
Código ejecutable: que puede depender de otros programas ejecutables
con los que interaccionan en tiempo de ejecución.
2.2.3.7. DIAGRAMA DE COLABORACION

Este diagrama muestra la interacción entre varios objetos y los enlaces
que existen entre ellos. Representa las interacciones entre objetos
organizadas alrededor de los objetos y sus vinculaciones. A diferencia
de un diagrama de secuencias, un diagrama de colaboraciones muestra
las relaciones entre los objetos, no la secuencia en el tiempo en que se
producen los mensajes. Los diagramas de secuencias y los diagramas
de colaboraciones expresan información similar, pero en una forma
diferente.
Elementos
Los elementos que intervienen en éstos diagramas son: objetos, enlaces

y flujos de mensajes.
Objeto
Un objeto se representa con un rectángulo, que contiene el nombre y la
clase del objeto. Un objeto es una instancia de una clase que participa
como una interacción, existen objetos simples y complejos. Un objeto
es activo si posee un thread o hilo de control y es capaz de iniciar la
actividad de control, mientras que un objeto es pasivo si mantiene datos
pero no inicia la actividad.
35
Enlace
Un enlace es una instancia de una asociación en un diagrama de clases.
Se representa como una línea continua que une a dos objetos en este
diagrama. Esta acompañada por un número que indica el orden dentro
de la interacción y por un estereotipo que indica que tipo de objeto
recibe el mensaje. El enlace puede ser reflexivo si conecta a un
elemento consigo mismo. La existencia de un enlace entre dos objetos
indica que puede existir un intercambio de mensajes entre los objetos
conectados.
Flujo de mensajes
Expresa el envío de un mensaje. Se representa mediante una flecha
dirigida cercana a un enlace. Los mensajes que se envían entre objetos
pueden ser de distintos tipos, también según como se producen en el
tiempo; existen mensajes simples, sincrónicos, balking, timeout y
asíncronos.
Durante la ejecución de un diagrama de colaboración se crean y
destruyen objetos y enlaces.
2.2.3.8. DIAGRAMA DE ESTADOS

Representan la secuencia de estados por los que un objeto o una
interacción entre objetos pasan durante su tiempo de vida en respuesta
a estímulos recibidos. Representa lo que podemos denominar en
conjunto una máquina de estados. Un estado en UML es cuando un
objeto o una interacción satisfacen una condición, desarrolla alguna
acción o se encuentra esperando un evento.
Cuando un objeto o una interacción pasa de un estado a otro por la
ocurrencia de un estímulo o evento se dice que ha sufrido una
transición, existen varios tipos de transiciones entre objetos: simples
(normales y reflexivas) y complejas. Además una transición puede ser
36
interna si el estado del que parte el objeto o interacción es el mismo que
al que llega, no se provoca un cambio de estado y se representan dentro
del estado, no de la transición.
2.2.3.9. DIAGRAMA DE ACTIVIDADES

Son similares a los diagramas de flujos de otras metodologías OO. En
realidad se corresponden con un caso especial de los diagramas de
estado donde los estados son estados de acción (estados con una acción
interna y una o más transiciones que suceden al finalizar esta acción, o
lo que es lo mismo, un paso en la ejecución de lo que será un
procedimiento) y las transiciones vienen provocadas por la finalización
de las acciones que tienen lugar en los estados de origen. Siempre van
unidos a una clase o a la implementación de un caso de uso o de un
método (que tiene el mismo significado que en cualquier otra
metodología OO). Los diagramas de actividad se utilizan para mostrar
el flujo de operaciones que se desencadenan en un procedimiento
interno del sistema.
37
3. CAPÍTULO III ANALISIS DEL SISTEMA
3.1 MODELO DEL NEGOCIO

3.1.1 DESCRIPCIÓN DEL NEGOCIO
El laboratorio de nuevas tecnologías de la comunicación e información se

dedica mantenimiento de equipos, y otras ocupaciones que ayuden a la
facultad de Derecho san Agustín.
El laboratorista se encarga de recepciona la solicitud de mantenimiento de

equipos, esto funciona de la siguiente manera el personal administrativos
u otros vienen y hacen su solicitud de mantenimiento, en la cual tienen que
dejar su constancia la cual es llenar un formulario, con los siguientes datos,
nombre completo del solicitante, el lugar en donde se encuentra el equipo,
el tipo de mantenimiento, una descripción del problema.
Luego el encargado del laboratorio recepciona, remite posteriormente al

asistente de laboratorio y en un tiempo devuelve el equipo con las
correcciones necesarias y solicitadas.
Por otra parte el inventario de equipos del laboratorio y otras áreas tiene
los siguientes tintes lo que se quiere es que se registre a todos los equipos,
con las siguientes características, el lugar en donde se encuentra el equipo,
en código de equipo, las partes de los equipos, sus números de serie de
cada parte de los equipos, de la misma forma a sus subpartes con todo lo
ya mencionado.
Los informes que se deben generar son los siguientes, un informe

mensual de las solicitudes que sean realizados con todos los datos
registrados.
Un informe en el cual tiene que mostrar todos los datos, de sus partes y
subpartes por cada equipo, esto tiene que mostrar también su estado en el
que se encuentra, ya que esto muy necesario para la toma de decisiones.
38
DIAGRAMA DE CASOS DE USO DEL NEGOCIO
solicitar kardex por equipo

solicitar mantenimiento de equipos
solicitar informe de estados por equipo
personal solicitante
39
encargadp de laboratorio
solicitar mantenimiento de parte de equipos
solicitar informe solicitudes de mantenimientos
3.1.2
3.1.3 DESCRIPCIÓN DE CASOS DE USO DEL NEGOCIO
Tabla 2 Descripción de casos de uso del negocio: solicitar mantenimiento de equipo
Caso de uso del negocio Solicitar mantenimiento de equipos
Actores Personal, encargado del laboratorio
Propósito Solicitar el mantenimiento de equipo
Resumen: el personal realiza una solicitud para que se realice el mantenimiento de un

determinado equipo al encargado de laboratorio.
Acción del actor Respuesta del proceso de negocio
1.- El personal se dirige al laboratorio para
solicitar el mantenimiento de un equipo.
2.- el personal llena el formulario de
solicitud de mantenimiento de equipo.
3.- el encargado de laboratorio revisa la

solicitud de mantenimiento.
4.- el encargado de laboratorio
5.- el personal se retira a su lugar de trabajo recepciona la solicitud de
a espera de la conclusión de la solicitud de mantenimiento.
mantenimiento.
Mejoras Mediante el sistema el personal podrá

realizar la solicitud desde su área de
trabajo vía web y de esta forma reducir
el tiempo de solicitud.
40
SOLICITAR MANTENIMIENTO DE PARTE DE EQUIPO
Caso de uso del negocio Solicitar mantenimiento de parte equipos
Actores Personal, encargado del laboratorio
Propósito Solicitar el mantenimiento de parte de

equipo
Resumen: el personal realiza una solicitud para que se realice el mantenimiento de una
determinada parte equipo al encargado de laboratorio.

1.- El personal se dirige al laboratorio para
solicitar el mantenimiento de una parte
equipo.
2.- el personal llena el formulario de solicitud
de mantenimiento de parte de equipo.
3.- el encargado de laboratorio revisa la

solicitud de mantenimiento de parte de
equipo.
4.- el encargado de laboratorio recepciona
la solicitud de mantenimiento de parte de
5.- el personal se retira a su lugar de trabajo a equipo.
espera de la conclusión de la solicitud de
mantenimiento solicitado.
Mejoras Mediante el sistema web el personal podrá

realizar la solicitud de parte de equipo desde
su área de trabajo vía web y de esta forma
reducir el tiempo de solicitud.
Tabla 3 Descripción de casos de uso del negocio: solicitar mantenimiento de parte de equipo
41
SOLICITAR INFORME DE LOS ESTADOS DE LOS EQUIPOS.
Caso de uso del negocio Solicitar el informe de los estados de los

equipos
Actores Asistente de laboratorio, encargado de
laboratorio
Propósito Solicitar el informe de los estados de los
equipos.
Resumen: el encargado de laboratorio solicita un informe de los equipos de y en los
estados en los que se encuentra cada equipo.
1.- el encargado de laboratorio solicita
el informe de los estados de equipos.
2.- el asistente de laboratorio recepciona la
solicitud de informe de los estados de los
equipos.
3.- el asistente revisa los documentos de
cada equipo para ver sus estados hoja por
hoja.
4.- el asistente de laboratorio procede a
imprimir el informe.
5.- el asistente de laboratorio se dirige a
entregar el informe al encargado del
laboratorio.
recepciona el informe solicitado.
Mejoras Mediante el sistema el asistente de

laboratorio podrá imprimir el informe con
mayor facilidad ya que se evitara de
buscar la información en el monto de
documentos que existe y de esta manera se
reducirá el tiempo de respuesta a la
solicitud de informe de los estados de los
equipos.
Tabla 4 Descripción de casos de uso del negocio: solicitar informe de los estados de los equipos
42
Solicitar informe de solicitudes de mantenimiento
Caso de uso del negocio Solicitar informe de solicitudes de

mantenimiento
Actores Asistente de laboratorio, encargado del
laboratorio
Propósito Solicitar informe de las solicitudes de
mantenimiento.
Resumen: El encargado el laboratorio realiza una solicitud de informe de las
solicitudes que se han realizado en un determinado tiempo por ejemplo puede ser
mensual, el asistente del laboratorio recepciona y realiza la solicitud correspondiente.
1.- el encargado del laboratorio realiza la
solicitud de informe de las solicitudes
realizadas. 2.- el asistente del laboratorio recepciona
la solicitud de informe sobre las
solicitudes recepcionadas.
3.- el asistente del laboratorio empieza a
buscar y a realizar un conteo de las
solicitudes.
4.- realiza el informe que se ha pedido.
5.- el asistente se dirige donde el
encargado para darle su informe
6.- el encargado recibe el informe de las
solicitudes de mantenimiento.
Mejoras Mediante el sistema se ayudara en el
tiempo y reducirá el mismo en tiempo de
respuesta.
Tabla 5Descripción de casos de uso del negocio: solicitar informe de solicitudes de mantenimiento
43
Solicitar kardex por equipo
Caso de uso del negocio Solicitar kardex por equipo

Actores Asistente de laboratorio, encargado del
laboratorio
Propósito Solicitar kardex por equipo.
Resumen: El encargado el laboratorio realiza una solicitud de kardex por equipo para
saber las partes y subpartes que componen los equipos.
1.- el encargado del laboratorio realiza la
solicitud de kardex por equipo.
2.- el asistente de laboratorio de
recepciona la solicitud de kardex por
equipo.
3.- el asistente busca los datos de los
equipo.
4.- el asistente reúne la información
necesaria para realizar los kardex.
5.- el asistente lleva los kardex por equipo
al encargado de laboratorio.
recepciona la solicitud de
mantenimiento.
Mejoras Mediante el sistema se ayudara en el
tiempo de ejecución de la solicitud de esta
forma reduciendo esfuerzo.
Tabla 6 Descripción de casos de uso del negocio: solicitar kardex por equipo
44
3.1.4 DIAGRAMAS DE ACTIVIDADES DE CASOS DE USO DEL
NEGOCIO
Diagrama de actividades de actividades del caso de uso “solicitud de

mantenimiento de equipo
Ilustración 13 diagrama de actividades del caso de uso solicitar mantenimiento de equipos
45
Diagrama de actividades del caso de uso “solicitar mantenimiento de parte de equipo”
Ilustración 14 Diagrama de actividades del caso de uso “solicitar mantenimiento de parte de equipo”
46
Diagrama de actividades del caso de uso “solicitar kardex por equipo”
Ilustración 15 diagrama de actividades del caso de uso "solicitar kardex por equipo"
47
Diagrama de actividades para el caso de uso “solicitar informe de solicitudes de
mantenimientos de equipos”
Ilustración 16 diagrama de actividades del caso de uso "solicitar informe de solicitudes de mantenimiento"
48
Diagrama de actividades para el caso de uso “solicitar informe de los estados por
equipo”
Ilustración 17 diagrama de actividades del caso de uso "solicitar los estados por equipo"
49
3.2 ESPECIFICACION DE REQUERIMIENTOS
Requerimientos funcionales
- Registrar usuarios.- registrar los datos de los personales de las personas
que van a actuar con el sistema.
- Registrar los equipos.- se registrara los equipos para que posteriormente
se realice los mantenimientos solicitados.
- Registrar las solicitudes de mantenimiento.- se registrar las solicitudes
de mantenimiento de los equipos así mismo de las parte de equipo con
los tipos de mantenimiento como el preventivo correctivo.
Emitir informes y reportes
- Elaborar los informes de las solicitudes de mantenimiento en un tiempo
determinado.
- Elaborar el kardex por equipo, todo esto para saber las partes que
componen al equipo.
- Elaborar el informe y reporte de los estados de los equipos, para saber en
qué estado se encuentra.
Requerimientos no funcionales
- Facilidad de uso
El uso del sistema debe ser de fácil uso para el usuario final, debe ser
desarrollado con características simples para una completa comprensión,
Para que se evite las malas interpretaciones.
- Seguridad
El sistema debe ser desarrollado para que mantenga la seguridad, ya será
controlado por usuarios y contraseñas, para el ingreso al mismo y de esta
forma convirtiendo al sistema con características confiables.
- Confiabilidad
El sistema debe ser confiable, que no se tenga la posibilidad de cometer
algún error, ya que esto perjudicaría al desempeño de las funciones de
los usuarios.
50
3.3 FUNCIONES DEL SISTEMA
3.4 MODELO DE CASOS DE USO DEL SISTEMA
3.4.1 IDENTIFICACIÓN DE ACTORES
ACTOR DESCRIPCION
El encargado de laboratorio es el
que atiende las solicitudes de
mantenimiento de equipos, por
parte del personal solicitante.
El personal es el que se encarga

de realizar la solicitud de
mantenimiento de los equipos,
tanto de sus partes como sub
partes.
El asistente es el que se encarga

Asistente de ntics de realizar los mantenimientos
de equipos, de la misma forma
los informes y reportes.
Ilustración 18 identificación de actores
51
3.4.2 IDENTIFICACIÓN DE CASOS DE USO DEL SISTEMA
- Solicitar mantenimiento de equipos:

Se registra la solicitud de mantenimiento de equipos por parte del personal
solicitante, los datos del equipo que se realizara la solicitud, y de la misma
forma de la persona que lo solicita, de la oficina a la que pertenece el equipo.
- Solicitar mantenimiento de parte de equipo:

Se registra la solicitud de la parte de equipo, para su mantenimiento, se registra
los siguientes datos: su procedencia, el encargado que solicita su
mantenimiento, y otros según corresponda.
- Solicitar Kardex por equipo:

Se muestra los datos de un equipo en específico, las partes que la componen,
las sub partes que la componen, de la misma forma los estados en la que se
encuentra si está activo o inactivo.
- Solicitar informe de los estados en los que se encuentra en los equipos:

Se muestra un informe, de los equipos en el estado en el que se encuentra,
cuantos mantenimientos se le realizo, porque motivos.
- Solicitar informe de las solicitudes de equipos:

Se muestra un informe, de las solicitudes realizadas, cual es la frecuencia de
solicitudes, cual es el más común de los tipos de solicitudes.
52
3.4.3
Solicitar mantenimiento de equipo
Gestionar usuarios
Solicitar mantenimiento de las

parte del equipo
Gestionar equipos
53
Encargado de NTICS
Personal solicitante
solicitar mantenimiento de equipos

y partes
Seguimiento a la solicitud de mtto.
de equipo
Asistente de NTICS
DIAGRAMA DE CASOS DE USO DEL SISTEMA
Ilustración 19 casos de uso del sistema

Recepcionar las solicitudes de
Seguimiento a la solicitud de mtto. Gestionar Equipo mantenimiento
a las partes de equipo
Solicitar mantenimiento de las

Solicitar mantenimiento de equipo partes de equipo
3.4.4 DESCRIPCION DE CASOS DE USO DEL SISTEMA
Descripción de caso de uso del sistema Solicitud de mantenimiento de equipo
Caso de Uso del Solicitud de mantenimientos de equipo

Sistema
Actores del Sistema Encargado de NTICS y personal solicitantes
Propósito Realizar solicitudes de mantenimiento de
equipo para el personal.
Breve Descripción
El personal solicitante, realiza la solicitud de mantenimiento de
equipo al encargado NITCS para que se realice el mismo, esto puede
ser preventivo o correctivo.
FLUJO DE EVENTOS
Flujo 1 El personal solicitante realiza la solicitud de
Principal mantenimiento de equipo llenando el formulario vía
web.
2 El sistema recepciona la solicitud de mantenimiento
de equipo.
3 Posteriormente se realiza el cambio de estado de la
solicitud, para que se proceda con el mantenimiento
respectivo.
Flujos A- Si el equipo por el que se realiza la solicitud de
Alternos 1 mantenimiento de equipo no está registrado, se
procede al registro correspondiente.
Tabla 7 descripción de caso de uso del sistema solicitud de mantenimiento de equipo
54
Descripción de caso de uso del sistema solicitud de mantenimiento de parte de
equipo
Caso de Uso del Solicitud de mantenimientos de parte equipo

Sistema
Actores del Sistema Encargado de NTICS y personal solicitantes
Propósito Realizar solicitudes de mantenimiento de
parte equipo para el personal.
Breve Descripción
El personal solicitante, realiza la solicitud de mantenimiento de parte
equipo al encargado NITCS para que se realice el mismo, esto puede
ser preventivo o correctivo.
FLUJO DE EVENTOS
Flujo 1 El personal solicitante realiza la solicitud de
Principal mantenimiento de parte equipo llenando el
formulario vía web.
2 El sistema recepciona la solicitud de mantenimiento
de equipo.
3 Posteriormente se realiza el cambio de estado de la
solicitud, para que se proceda con el mantenimiento
respectivo.
Flujos A- Si del equipo por el que se realiza la solicitud de
Alternos 1 mantenimiento de parte de equipo o equipo no está
registrado, se procede al registro correspondiente.
Tabla 8 Descripción de caso de uso del sistema solicitud de mantenimiento de parte de equipo
55
Descripción de casos del sistema seguimiento de estado de solicitud de mantenimiento de
equipo
Caso de Uso del Seguimiento de estado de solicitud de

Sistema mantenimiento de equipo
Actores del Sistema sistema y personal solicitantes
Propósito Ver en qué estado se encuentra la solicitud de
mantenimiento de equipo.
Breve Descripción
El personal solicitante, realiza el seguimiento de la solicitud de
mantenimiento de equipo, verificando en el estado en que se encuentra la
misma.
FLUJO DE EVENTOS
Flujo 1 El personal solicitante realiza la verificación del estado
Principal en que se encuentra la solicitud de mantenimiento de
equipo todo esto a través del sistema.
2 El sistema genera en la pantalla el estado en el que se
encuentra la solicitud.
3 El personal solicitante realizara la búsqueda del equipo

ingresando el dato, del código de equipo con el que se
registró la solicitud de mantenimiento de equipo.
4 El personal solicitante tendrá la opción de sacar una
copia de la consulta del estado de la solicitud de
mantenimiento.
Tabla 9 Descripción de caso de uso del sistema seguimiento de estado de solicitud de mantenimiento de equipo
56
Descripción de caso de uso del sistema de estado de solicitud de mantenimiento de parte
de equipo
Caso de Uso del Seguimiento de estado de solicitud de

Sistema mantenimiento de parte equipo
Actores del Sistema sistema y personal solicitantes
Propósito Ver en qué estado se encuentra la solicitud de
mantenimiento de parte equipo.
Breve Descripción
El personal solicitante, realiza el seguimiento de la solicitud de
mantenimiento de parte equipo, verificando en el estado en que se
encuentra la misma.
FLUJO DE EVENTOS
Flujo 1 El personal solicitante realiza la verificación del estado
Principal en que se encuentra la solicitud de mantenimiento de
parte de equipo todo esto a través del sistema.
2 El sistema genera en la pantalla el estado en el que se
encuentra la solicitud.
3 El personal solicitante realizara la búsqueda del equipo

ingresando el dato, del código de equipo, y el nombre
de la parte, con el que se registró la solicitud de
mantenimiento de equipo.
4 El personal solicitante tendrá la opción de sacar una

copia de la consulta del estado de la solicitud de
mantenimiento.
Tabla 10 Descripción de caso de uso del sistema estado de solicitud de mantenimiento de parte de equipo
57
Descripción de casos de uso del sistema gestionar equipo
Caso de Uso del Gestionar equipos

Sistema
Actores del Sistema asistente de NTICS
Propósito Nos da la posibilidad de realizar, inserción,
edición y eliminación de los equipos y sus
partes.
Breve Descripción
El asistente de NTICS., va a realizar en supuesto evento, donde la
posibilidad de registrar equipos, de la misma forma a las partes según a
los equipos a los que correspondan, también a los mismos se le puede
editar y eliminar.
FLUJO DE EVENTOS
Flujo 1 El asistente de ntics, ingresa al formulario de la gestión
Principal de los equipos.
2 Cuando corresponda registra al equipo y a sus partes

correspondientes.
3 Por otro lado tiene la posibilidad de editar los datos de

los equipos por algún equívoco cometido con
anterioridad
4 De la misma forma tiene la posibilidad de eliminar al
equipo, por varias razones, como puede pasar que se de
baja por los activos fijos de la institución.
5 También las opciones que nos dispone el formulario de
gestión de equipos.
58
Descripción de caso de uso del sistema Solicitar mantenimiento de equipo
Caso de Uso del Solicitar mantenimiento de equipo

Sistema
Actores del Sistema asistente de NTICS, sistema
Propósito El asistente tiene la posibilidad de solicitar el
mantenimiento de equipo cuando lo realice del
de NTICS.
Breve Descripción
El asistente de NTICS., realizara la solicitud de mantenimiento de equipo,
cuando se proceda a la solicitud de mantenimiento por el mismo, en el
laboratorio de nuevas tecnologías de información y comunicación.
FLUJO DE EVENTOS
Flujo 1 El asistente de ntics, ingresa al formulario de solicitud
Principal de mantenimiento de equipo.
2 Solicita el mantenimiento de equipo.

3 Recepciona la solicitud enviada con anterioridad y lo
cambia de estado para su revisión.
4 Posteriormente, y una vez realizado el mantenimiento

de equipo, lo cambia de estado ha terminado.
5 Una vez cambiado el estado ha terminado, se llena el

detalle de que es lo que se ha realizado en el
mantenimiento.
Descripción de caso de uso del sistema recepción de solicitud de mantenimiento de equipo
Caso de Uso del Gestionar equipos

Sistema
Actores del Sistema asistente de NTICS
Propósito Nos da la posibilidad de realizar, inserción,
edición y eliminación de los equipos y sus
partes.
Breve Descripción
El asistente de NTICS., va a realizar en supuesto evento, donde la
posibilidad de registrar equipos, de la misma forma a las partes según a
los equipos a los que correspondan, también a los mismos se le puede
editar y eliminar.
59
FLUJO DE EVENTOS
Flujo 1 El asistente de ntics, ingresa al formulario de la gestión
Principal de los equipos.
2 Cuando corresponda registra al equipo y a sus partes

correspondientes.
3 Por otro lado tiene la posibilidad de editar los datos de

los equipos por algún equívoco cometido con
anterioridad
4 De la misma forma tiene la posibilidad de eliminar al
equipo, por varias razones, como puede pasar que se de
baja por los activos fijos de la institución.
5 También las opciones que nos dispone el formulario de
gestión de equipos.
3.5 DIAGRAMA DE ACTIVIDADES DEL SISTEMA
Diagrama de actividades del caso de uso del sistema “solicitar mantenimiento de

equipo”
60
Ilustración 20 diagrama de actividades del caso de uso del sistema "solicitar mantenimiento de equipos"
4. CAPITULO IV DISEÑO DEL SISTEMA

4.1. MODELO DE DISEÑO
4.1.1. IDENTIFICACIÓN DE LAS CLASES DEL SISTEMA
CLASES ENTIDAD
Nombre de la clase Descripción
Es un formulario en el que se
muestra las opciones para ingresar
al sistema con el respectivo usuario
y contraseña
61
Frmlogueo
Es el proceso o control en cual hace

la verificación de los usuarios en la
base de datos, comparando los
datos ingresados con los de la base
Pr_logueo de datos y si son los mismos
permite el ingreso al sistema y por
lo contrario no le deja ingresar.
es la ventana principal del sistema
donde nos aparece lo que podemos
hacer según el nivel de usuario,
todo esto en descrito en el menú.
Frmprincipal
Este es la clase de control, con los
botones del menú nos da la opción
de ir a otros formularios o ventanas
para realizar determinadas
Pr_principal actividades.
En este formulario nos da la
posibilidad de ingresar los datos del
equipo que posteriormente será
sometido a un mantenimiento.
Frmregistrarequipo
Esta clase nos permite registrar los
datos ingresados en la base de
datos. También nos dara la
posibilidad de registrar las partes de
Pr_registrarequipo los equipos.
En esta clase, nos permite guardar
los datos de las partes de equipo.
Frmregistrarparteequipo
4.1.2. DIAGRAMA DE CLASES DE DISEÑO
62
Ilustración 21 diagrama de clases iniciar sesión
<<ClientPage>>
RegSolicitud
mantenimiento
(f rom clases client page)
frmRegSolicitudMante
personal solicitante nimiento
(f rom Actors) (f rom clases Form)
pr_regsolicitudma solicitudmantenimento
ntenimiento
(f rom clases serv er page)
...) (f rom claseentidad)
Ilustración 22 diagrama de clases solicitar mantenimiento de equipo
63
4.2. DIAGRAMA DE INTERACCIÓN
4.2.1. DIAGRAMA DE SECUENCIA
Un diagrama de secuencia nos muestra los objetos en una línea de vida a
lo largo de la página y con sus interacciones en el tiempo, representados
con mensajes dibujados con flechas.
Diagrama de secuencia de “solicitar mantenimiento de equipos”
: RegSolicitud
: personal : :
mantenimiento
solicitante frmRegSolicitudMantenimiento pr_regsolicitudmantenimiento : solicitudmantenimento
llena el formulario para la solicitud( )
guardar solcitud( )
Ilustración 23 diagrama de secuencia "solicitar mantenimiento de equipo"
4.3. DIAGRAMA DE CLASES PERSISTENTES PARA LA BASE DE DATOS
64
4.4. DISEÑO DE INTERFACES
4.4.1. DIAGRAMA DE ORGANIZACIÓN DE INTERFACES
65
personal solicitante
solicitar mantenimiento de
equipo
solicitar mantenimiento de
parte de equipo
seguimiento de estado de
solicitud de mantenimiento
de equipo
seguimiento de estado de
solicitud de mantenimiento
de parte de equipo
Ilustración 24 Diagrama de organización de interfaces "personal solicitante"
66
encargado de NTICS
solicitar kardex por
equipo
solicitar informe de
estados de equipo
solicitar informe de
solicitudes realizados
Ilustración 25 diagrama de organización de interfaces "encargado NTICS"

Asistente de NTICS
realizar informes
realizar las recepciones de

las solicitudes de
mantenimiento
Ilustración 26 diagrama de organización de interfaces "asistente de NITCS"
67
4.4.2. ESPECIFICACION DE INTERFACES DE USUARIO
Interfaz: SOLICITAR MANTENIMIENTO DE EQUIPO
Nombre de componente Frmsolicitarmantenimientoequipo

Tipo componente Formulario
Descripción En este formulario lo que podemos
realizar, lo que personal solicitante puede
hacer, es de hacer el pedido de la
solicitud de mantenimiento de equipo
Ilustración 27 especificación de interface de usuario "solicitar mantenimiento de equipo
68
5. CAPITULO V IMPLEMENTACION Y PRUEBAS DEL SISTEMA
5.1. DIAGRAMA DE COMPONENTES
5.2. DIAGRAMA DE DESPLIEGE
5.3. MODELO DE PRUEBA
6. CAPITULO VI CONCLUSIONES Y RECOMENDACIONES
6.1. CONCLUSIONES
6.2. RECOMENDACIONES
BIBLIOGRAFIA
ANEXOS
ANEXO A
ANEXO B
ANEXO C
69

Tesis de Sistemas Informaticos

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesis de Sistemas Informaticos

Caricato da

Copyright:

Formati disponibili

INDICE GENERAL

1. CAPÍTULO I ASPECTOS GENERALES ............................................................................... 1

Ilustración 1 crokis de la institución .............................................................................................. 2

La facultad de Derecho, Ciencias Políticas y Sociales, fue creada en base a la carrera

El Origen de la universidad técnica de Oruro se remonta a 1876, año en el que empezó

Tabla 1 autoridades de la facultad de Derecho

DECANO M. Sc. Edgar Chire Andrade

VICE-DECANO M. Sc. Raúl Guzmán Candía

DIRECTOR CARRERA DE Dr. Jorge Rene Miranda Ocampo

DIRECTOR DE CARRERA Lic. Antonio A. Valdez Daza

La actual denominación, de Universidad Técnica de Oruro, fue adoptada, el 31 de

Ilustración 1 crokis de la institución

1.1.2. ANTECEDENTES DE CONTEXTO

La misma ya mencionada se encarga enseñar a los estudiante de la facultad

1.1.3. ANTECEDENTES DEL TEMA

El sistema de información de solicitud de mantenimientos e inventario de

1.2. PLANTEAMIENTO DEL PROBLEMA

El proceso de solicitud de mantenimiento e inventario de equipos de la

Desarrollar un sistema de información en entorno web para la solicitud de

1.3.2. OBJETIVOS ESPECIFICOS

- Analizar la información necesaria para realizar las distintas solicitudes

El sistema de información estará controlado por usuarios y contraseñas

El laboratorio de nuevas tecnologías de la información y comunicación

El sistema de información para su gestionamiento con lleva el desarrollo de

Las distintas características que proveen estas aplicaciones apoyaran a

Así mismo se utilizara los conocimientos necesarios para modelar el sistema

1.4.2. JUSTIFICACION OPERATIVA

La implementación del presente sistema de información agilizara los

El sistema cuenta con los equipos necesarios para la implementación del

1.4.3. JUSTIFICACION ECONOMICA

El área de NITC dispone de los recursos necesarios para la implementación

Proceso unificado objetos de diseño.

diseñar los casos de

- El sistema de información tiene los siguientes alcances, registrar todos

2.1. MARCO CONCEPTUAL

Contiene información de sus procesos y su entorno. En palabras de (Laudon

- Definición basada en tecnología de la información (Whitten, Bentley y

2.1.2. COMPONENTES DEL SISTEMA DE INFORMACIÓN

Datos e información: Diferencia entre datos e información:

Procesos de negocio: Los sistemas de información tienen que alcanzar el

Usuarios deben definir los procesos de negocio (conjunto de tareas que

Es el proceso de diseñar, codificar y mantener el código fuente de programas

La sigla CSS corresponde a la expresión inglesa Cascading Style Sheets, que

El acrónimo recursivo, sin embargo, en la actualidad está vinculado a PHP

Actualmente el PHP suele incrustarse dentro del código HTML de las

Una de las ventajas de PHP es su parecido con lenguajes de programación

JQuery es una biblioteca gratuita de Javascript, cuyo objetivo principal es

Otra de las grandes ventajas de jQuery es que se enfoca en simplificar los

Escenarios que se facilitan con el uso de jQuery:

 Carga de la página -> Configuraciones de la página

 jQuery utiliza sintaxis muy parecida a CSS.

MySQL es un sistema de gestión de base de datos relacional (RDBMS) de

2.1.9. BASE DE DATOS

Una base de datos se define como un fichero en el cual se almacena

El programa que sirve para manejar toda esa información se denomina

2.1.10. ENTRADA DE INFORNACION

Una entrada es, en el campo de la informática, una serie de datos que es

2.1.11. PROCESAMIENTO DE INFORMACION

Es la Técnica que consiste en la recolección de los datos primarios de

La salida en informática es el proceso de transmitir la información por un

2.1.13. CARACTERISITICAS DE LA BASE DE DATOS

- Independencia de los Datos. Es decir, que los datos no dependen del

- Reducción de la Redundancia. Llamamos redundancia a la existencia de