• Author / Uploaded
• Alex Calle Fernandez

Citation preview

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

Lic. Antonio A. Valdez Daza

DIRECTOR DE CARRERA DE CIENCIAS DE LA COMUNICACIÓN

Lic. Edgar Huarachi Mamani

DIRECTOR DE LA 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 TAREAS

METODO

Metodología de la investigación proceso unificado de Rational (RUP)

Proceso unificado de Rational (RUP)

Pruebas

Implementación

Diseño

Análisis de Requisitos

Recopilar información, aplicar técnicas de recopilación.

Análisis

ETAPA

Proceso unificado de Rational (RUP)

Establecer los requisitos de construcción. Detallar casos de uso del negocio, descripción detallada de los casos de uso. Detallar casos de uso del sistema, construcción de casos de uso del sistema, descripción detallada de los casos de uso. Definir la interacción de casos de uso del sistema, describir las interacciones entre objetos de diseño. Definir las clases, describir operaciones métodos y relaciones entre clases

PRODUCTOS Especificación de requerimientos Listado de requisitos Diagrama de casos de uso del negocio. Descripción de casos de uso del negocio con objetos incorporados

Modelo de casos de uso del sistema.

Diagrama de clases de diseño Diagrama de secuencia y colaboración Descripción de la arquitectura del diseño

Proceso unificado de Rational (RUP)

Implementar la arquitectura

Diagrama de componentes y despliegue, descripción de la arquitectura

Proceso unificado de Rational (RUP)

Diseñar la prueba, diseñar los casos de prueba, procedimiento de prueba

Casos 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 plugins 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 () o de Herencia ().

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 de clase

Ilustración 12 ejemplo de clase con 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 3.1.2

personal solicitante

solicitar mantenimiento de equipos

solicitar mantenimiento de parte de equipos

encargadp de laboratorio

solicitar kardex por equipo

solicitar informe de estados por equipo

solicitar informe solicitudes de mantenimientos

39

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.

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.

Mejoras

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. Acción del actor

Respuesta del proceso de negocio

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.

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.

Mejoras

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 Asistente de laboratorio, encargado de Actores laboratorio Solicitar el informe de los estados de los Propósito equipos. Resumen: el encargado de laboratorio solicita un informe de los equipos de y en los estados en los que se encuentra cada equipo. Acción del actor Respuesta del proceso de negocio 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. 6.- el encargado de 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 Asistente de laboratorio, encargado del

Actores

laboratorio Solicitar informe de las solicitudes de

Propósito

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. Acción del actor

Respuesta del proceso de negocio

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 Solicitar kardex por equipo.

Propósito

Resumen: El encargado el laboratorio realiza una solicitud de kardex por equipo para saber las partes y subpartes que componen los equipos. Acción del actor

Respuesta del proceso de negocio

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. 6.-

el

encargado

recepciona

la

de

laboratorio

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 de realizar los mantenimientos de equipos, de la misma forma los informes y reportes.

Asistente de ntics

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

Ilustración 19 casos de uso del sistema

53

Seguimiento a la solicitud de mtto. a las partes de equipo

Seguimiento a la solicitud de mtto. de equipo

Solicitar mantenimiento de las parte del equipo

Solicitar mantenimiento de equipo

solicitar mantenimiento de equipos y partes

Gestionar equipos

Recepcionar las solicitudes de mantenimiento Solicitar mantenimiento de las partes de equipo

Asistente de NTICS

Solicitar mantenimiento de equipo

Gestionar Equipo

Personal solicitante

Encargado de NTICS

Gestionar usuarios

3.4.3 DIAGRAMA DE CASOS DE USO DEL SISTEMA

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 Realizar solicitudes de mantenimiento de Propósito 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 mantenimiento de equipo llenando el formulario vía Principal 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 Realizar solicitudes de mantenimiento de Propósito 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 mantenimiento de parte equipo llenando el Principal 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 mantenimiento de equipo Sistema sistema y personal solicitantes Actores del Sistema

solicitud

de

Ver en qué estado se encuentra la solicitud de mantenimiento de equipo.

Propósito

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 Principal

1

2

El personal solicitante realiza la verificación del estado en que se encuentra la solicitud de mantenimiento de equipo todo esto a través del sistema. 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 mantenimiento de parte equipo Sistema sistema y personal solicitantes Actores del Sistema

solicitud

de

Ver en qué estado se encuentra la solicitud de mantenimiento de parte equipo.

Propósito

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 Principal

1

2

El personal solicitante realiza la verificación del estado en que se encuentra la solicitud de mantenimiento de parte de equipo todo esto a través del sistema. 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 asistente de NTICS Actores del Sistema Nos da la posibilidad de realizar, inserción, edición y eliminación de los equipos y sus partes.

Propósito

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 Principal

1

El asistente de ntics, ingresa al formulario de la gestión 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 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.

4

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 asistente de NTICS, sistema Actores del Sistema El asistente tiene la posibilidad de solicitar el mantenimiento de equipo cuando lo realice del de NTICS.

Propósito

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 Principal

1

El asistente de ntics, ingresa al formulario de solicitud 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

5

Posteriormente, y una vez realizado el mantenimiento de equipo, lo cambia de estado ha terminado. 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 asistente de NTICS Actores del Sistema 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 Principal

1

El asistente de ntics, ingresa al formulario de la gestión 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 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.

4

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 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ú.

Pr_logueo

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 actividades. En este formulario nos da la posibilidad de ingresar los datos del equipo que posteriormente será sometido a un mantenimiento.

Pr_principal

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 los equipos. En esta clase, nos permite guardar los datos de las partes de equipo.

Pr_registrarequipo

Frmregistrarparteequipo

4.1.2. DIAGRAMA DE CLASES DE DISEÑO

62

Ilustración 21 diagrama de clases iniciar sesión

RegSolicitud mantenimiento (f rom clases client page)

personal solicitante

frmRegSolicitudMante nimiento

(f rom Actors)

(f rom clases Form)

pr_regsolicitudma ntenimiento

solicitudmantenimento

(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”

: personal solicitante

: frmRegSolicitudMantenimiento

: RegSolicitud mantenimiento

: 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

Asistente de NTICS

Ilustración 25 diagrama de organización de interfaces "encargado 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 Tipo componente Descripción

Frmsolicitarmantenimientoequipo Formulario 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