Modelo de informe de practicas pre profesionales UNJBG

UNIVERSIDAD NACIONAL JORGE BASADRE GROHMANN – TACNA Facultad de Ingeniería Escuela Profesional de Ingeniería en Informática y Sistemas

Informe de Prácticas Pre Profesionales “Análisis y Diseño del Prototipo de Sistema Web de Requerimientos Informáticos para la Unidad de Soporte Informático”

Institución: Municipalidad Distrital de Pocollay Presentado por: Carlos Cesar Zelada Melchor Periodo de prácticas: 01 de Marzo del 2016 al 31 de Julio del 2016

TACNA - PERÚ 2017

ÍNDICE GENERAL Pag. CAPÍTULO I GENERALIDADES ...................................................................... 16 1.1. Generalidades de la Institución .................................................................. 16 1.1.1. Razón Social ........................................................................................ 16 1.1.2. Naturaleza Jurídica .............................................................................. 16 1.1.3. Descripción .......................................................................................... 16 1.1.4. Misión .................................................................................................. 17 1.1.5. Visión ................................................................................................... 17 1.1.6. Objetivos de la Institución ................................................................... 18 1.1.7. Reseña Histórica .................................................................................. 18 1.1.8. Ubicación ............................................................................................. 21 1.2. Generalidades de la Organización de la Institución ................................... 22 1.2.1. Órganos de Alta Dirección .................................................................. 22 1.2.2. Órganos Consultivos y de Coordinación ............................................. 22 1.2.3. Órgano de Control Institucional .......................................................... 23 1.2.4. Órgano de Defensa Judicial ................................................................. 23 1.2.5. Órganos de Asesoramiento .................................................................. 23 1.2.6. Órganos de Apoyo ............................................................................... 23 1.2.7. Órganos de Línea ................................................................................. 24 1.2.8. Órganos de Desconcentrados ............................................................... 24 1.2.8. Organigrama ........................................................................................ 25 1.3. Generalidades de las Prácticas.................................................................... 26 1.3.1. Objetivo General .................................................................................. 26 1.3.2. Objetivos Específicos .......................................................................... 26 1.4. Generalidades del Área de Desempeño ...................................................... 26

ii

1.4.1. Área de Desempeño ............................................................................. 26 1.4.2. Funciones del Área de Desempeño ...................................................... 26 1.4.3. Descripción del Área de Trabajo ......................................................... 27 1.4.4. Actividades Realizadas ........................................................................ 28 1.4.5. Recursos Humanos .............................................................................. 30 1.4.6. Recursos Informáticos y Tecnológicos ................................................ 30 CAPÍTULO II FUNDAMENTO TEÓRICO ....................................................... 32 2.1. Marco Referencial ...................................................................................... 32 2.1.1. Definición de Sistema .......................................................................... 32 2.1.2. Definición de Sistema de Información ................................................ 33 2.1.3. Definición de Programación Orientada a Objetos ............................... 34 2.1.4. Definición de Análisis Orientado a Objetos ........................................ 34 2.1.5. Definición de Base de Datos ................................................................ 35 2.2. Terminologías Web .................................................................................... 35 2.2.1. Definición de Internet .......................................................................... 35 2.2.2. Definición de World Wide Web (WWW) ........................................... 36 2.2.3. Definición de Aplicaciones Web ......................................................... 36 2.2.4. Definición de Portal Web .................................................................... 37 2.2.5. Definición de Requerimientos Informáticos ........................................ 37 2.3. Metodología de Desarrollo ......................................................................... 38 2.3.1. Metodología de Diseño de Hipermedia Orientado a Objetos – OOHDM ....................................................................................................................... 38 2.3.2. Descripción del Esquema de la Metodología OOHDM ...................... 39 2.3.3. Descripción de levantamiento de requisitos ........................................ 41 2.3.4. Definición de Diseño Conceptual ........................................................ 41 2.3.5. Definición de Diseño Navegacional .................................................... 42 2.3.6. Diseño de Interfaz Abstracta................................................................ 43 2.3.7. Descripción de la Implementación Metodológica ............................... 46 iii

2.4. Lenguaje Unificado de Modelado (UML) .................................................. 47 2.4.1. Definición de Diagrama de Casos de Uso ........................................... 47 2.4.2. Descripción de Diagrama de Secuencia............................................... 48 2.4.3. Descripción de Diagrama de Actividades ............................................ 49 2.5. Definición de PHP (PHP Hypertext Pre-processor) ................................... 50 2.6. Definición de MySQL ................................................................................ 52 CAPÍTULO III MATERIAL Y MÉTODO UTILIZADO EN LAS PRÁCTICAS PRE PROFESIONALES ....................................................................................... 53 3.1. Materiales Utilizados .................................................................................. 53 3.1.1. Hardware .............................................................................................. 53 3.1.2. Software ............................................................................................... 54 3.2. Administración del Proyecto ...................................................................... 54 3.2.1. Objetivo General .................................................................................. 54 3.2.2. Objetivos Específicos .......................................................................... 55 3.2.3. Pruebas de Factibilidad del Proyecto ................................................... 55 3.2.4. Factibilidad Operacional ...................................................................... 55 3.2.5. Factibilidad Técnica ............................................................................. 58 3.2.6. Factibilidad Financiera ........................................................................ 60 3.2.7. Alcance del Proyecto ........................................................................... 61 3.2.8. Aportes ................................................................................................. 62 3.3. Desarrollo del Sistema................................................................................ 62 3.3.1. Identificación de Usuarios y Tareas..................................................... 62 3.3.2. Descripción de Cada Autor .................................................................. 63 3.3.3. Diagrama Principal de Caso de Uso .................................................... 64 3.3.4. Diagrama de Caso de Uso del Autor Administrador ........................... 65 3.3.5. Diagrama de Caso de Uso del Autor Soporte ...................................... 65 3.3.6. Diagrama de Caso de Uso del Autor Usuario ...................................... 66

iv

3.3.7. Especificaciones de Caso de Uso......................................................... 67 3.3.8. Diagrama de Secuencias ...................................................................... 75 3.3.9. Diagrama de Clases ............................................................................. 76 3.4. Análisis del Sistema ................................................................................... 77 3.4.1. Diseño Conceptual ............................................................................... 77 3.4.2. Diseño de Base de Datos ..................................................................... 77 3.4.3. Modelo Lógico de la BD ..................................................................... 78 3.4.4. Modelo Físico de la BD ....................................................................... 79 3.4.5. Diccionario de Datos ........................................................................... 79 3.4.6. Diseño Navegacional ........................................................................... 86 3.4.7. Diseño de Interfaz Abstracta................................................................ 88 3.4.8. ADV de la Aplicación Web del Usuario ............................................. 90 3.4.9. ADV de la Aplicación Web del Soporte .............................................. 92 3.4.10. ADV de la Aplicación Web del Administrador ................................. 94 3.4.11. ADV de Inicio de Sesión Web........................................................... 96 CAPÍTULO IV RESULTADOS DE LA PRÁCTICA REALIZADA ................. 96 4.1. Administración del Sistema Informático .................................................... 96 4.1.1. Inicio de Sesión al Sistema .................................................................. 96 4.1.2. Sección de Escritorio del Administrador ............................................. 97 4.1.3. Módulo de Creación de Usuarios......................................................... 97 4.1.4. Sección de Escritorio del Soporte ........................................................ 98 4.1.5. Módulo de Creación de Soluciones ..................................................... 98 4.1.6. Sección de Escritorio del Usuario ........................................................ 99 4.1.7. Módulo de Creación de Requerimientos ............................................. 99 CAPÍTULO V CONCLUSIONES Y SUGERENCIAS ..................................... 100 5.1. Conclusiones ............................................................................................ 100 5.1.1. Conclusiones de las prácticas pre-profesionales ................................ 100

v

5.1.2. Conclusiones del proyecto ................................................................. 101 5.2. Sugerencias ............................................................................................... 102 CAPÍTULO VI BIBLIOGRAFÍA...................................................................... 100

vi

ÍNDICE DE FIGURAS Pág. Figura 1: Dirección de la Entidad Municipal ........................................................ 22 Figura 2: Organigrama Municipal ......................................................................... 25 Figura 3: Dependencia de la Unidad de Soporte Informático ............................... 28 Figura 4: Esquema Grafico General de un Sistema .............................................. 32 Figura 5: Esquema de Sistema de Información..................................................... 34 Figura 6: Etapas de la Metodología OOHDM ...................................................... 39 Figura 7: Ejemplo de Diagrama Conceptual ......................................................... 42 Figura 8: Ejemplo de Esquema de Contexto Navegacional .................................. 43 Figura 9: Ejemplo de Vista de Datos Abstracta .................................................... 45 Figura 10: Ejemplo de Diagrama de Caso de Uso ................................................ 48 Figura 11: Ejemplo de Diagrama de Secuencia .................................................... 49 Figura 12: Ejemplo de Diagrama de Actividades ................................................. 50 Figura 13: Esquematización de Actores ................................................................ 63 Figura 14: Diagrama de Caso de Uso General del Proyecto ................................. 64 Figura 15: Diagrama de Caso de Uso del Administrador ..................................... 65 Figura 16: Diagrama de Caso de Uso del Autor Soporte ...................................... 66 Figura 17: Diagrama de Caso de Uso del Usuario ................................................ 66

vii

Figura 18: Diagrama de Secuencia – Administrador ............................................ 75 Figura 19: Diagrama de Secuencia – Soporte ....................................................... 75 Figura 20: Diagrama de Secuencia – Usuario ....................................................... 76 Figura 21: Diagrama de Clase Sistema de Requerimientos Informáticos............. 76 Figura 22: Diseño Conceptual de la Base de Datos .............................................. 77 Figura 23: Modelo Lógico de la Base de Datos .................................................... 78 Figura 24: Modelo Físico de la Base de Datos ..................................................... 79 Figura 25: Diseño Navegacional Administrador................................................... 86 Figura 26: Diseño Navegacional Soporte ............................................................. 87 Figura 27: Diseño Navegacional Usuario ............................................................. 88 Figura 29: Diseño de Interfaz Abstracta Administrador ....................................... 88 Figura 30: Diseño de Interfaz Abstracta Soporte .................................................. 89 Figura 31: Diseño de Interfaz Abstracta Usuario .................................................. 89 Figura 32: ADV's de la Aplicación Web de Usuario ............................................ 90 Figura 33: ADV Descripción del Requerimiento ................................................. 90 Figura 34: ADV Agregar Nuevo Requerimiento .................................................. 91 Figura 35: ADV de la Aplicación Web de Soporte............................................... 92 Figura 36: ADV Agregar Solución a Requerimiento ............................................ 93 Figura 37: ADV de la Aplicación Web de Administrador .................................... 94 Figura 38: ADV Agregar Nuevo Usuario ............................................................. 95 Figura 39: ADV de Inicio de Sesion Web ............................................................ 96

viii

Figura 40: Login de Acceso al Sistema................................................................. 96 Figura 41: Escritorio de Acceso a Administrador ................................................. 97 Figura 42: Módulo de Creación de Nuevos Usuarios ........................................... 97 Figura 43: Escritorio de Acceso Soporte .............................................................. 98 Figura 44: Módulo de Creación de Soluciones ..................................................... 98 Figura 45: Escritorio de Acceso Usuario .............................................................. 99 Figura 46: Módulo de Creación de Requerimiento ............................................... 99

ix

ÍNDICE DE TABLAS Pág. Tabla 1: Ubicación Geográfica ............................................................................. 21 Tabla 2: Recursos Humanos de la USI ................................................................. 30 Tabla 3: Recursos Tecnológicos de la USI ........................................................... 30 Tabla 4: Metodología OOHDM ............................................................................ 40 Tabla 5: Características del Terminal de Desarrollo ............................................. 53 Tabla 6: Caso de Uso Registro de Requerimiento ................................................ 67 Tabla 7: Caso de Uso Modificación de Requerimiento ........................................ 68 Tabla 8: Caso de Uso Listado y Clasificacion de Requerimiento ......................... 69 Tabla 9: Caso de Uso Visualizar Requerimiento .................................................. 70 Tabla 10: Caso de Uso Registrar Soluciones y Requerimientos ........................... 71 Tabla 11: Caso de Uso Reporte de Requerimiento ............................................... 72 Tabla 12: Caso de Uso Creación de Usuarios, entre otros formularios ................ 73 Tabla 13: Caso de Uso Administrar el Sistema .................................................... 74 Tabla 14: Diccionario de Datos - Tabla Requerimiento ....................................... 80 Tabla 15: Diccionario de Datos - Tabla Personal ................................................. 81 Tabla 16: Diccionario de Datos - Tabla Solución de Requerimiento ................... 81 Tabla 17: Diccionario de Datos - Tabla Usuario .................................................. 82

ix

Tabla 18: Diccionario de Datos - Tabla Año ........................................................ 83 Tabla 19: Diccionario de Datos - Tabla Estado .................................................... 83 Tabla 20: Diccionario de Datos - Tabla Área ....................................................... 84 Tabla 21: Diccionario de Datos - Tabla Tipo de Personal .................................... 84 Tabla 22: Diccionario de Datos - Tabla Tipo Requerimiento ............................... 85 Tabla 23: Diccionario de Datos - Tabla Tipo Usuario .......................................... 85 Tabla 24: Tarjeta ADV Agregar Nuevo Requerimiento ....................................... 91 Tabla 25: Tarjeta ADV Agregar Solución a Requerimiento ................................. 93 Tabla 26: Tarjeta ADV Agregar Usuario .............................................................. 96 Tabla 27: Tarjeta ADV de Inicio de Sesion .......................................................... 97

x

AGRADECIMIENTO

Agradezco a Dios por haber sido mi guía y mi fortaleza en todo momento, por haber puesto en mi camino a personas realmente grandiosas que apoyaron en la realización de mis prácticas pre-profesionales y la elaboración del informe de prácticas correspondiente. A mi familia, mis padres, quienes han estado siempre conmigo, brindándome su amor y paciencia, mis hermanos de los cuales recibí un apoyo incondicional. También el agradecimiento a todos mis docentes quienes me brindaron sus conocimientos en mi etapa de formación profesional durante 5 años para poder culminar mi carrera de Ingeniería en Informática y Sistemas. Gracias

a

todos

ellos

en

la

ix

realización

de

este

proyecto

INTRODUCCIÓN

Las prácticas Pre-Profesionales dan el inicio a nuestra experiencia como futuros profesionales para desenvolvernos en un ámbito competitivo y exigente, esto hace que nos esforcemos en captar más conocimientos para poder desenvolvernos en el área donde desempeñamos.

Es contribuir a la formación profesional donde la empresa nos ofrece la oportunidad de conocer y enfrentar la realidad empresarial en la actividad de distribución y administración pública, como un valor agregado muy importante que complementa a la formación Universitaria.

Al realizar una práctica profesional te permite aplicar los conocimientos teóricos adquiridos en la universidad y así dar soluciones a problemas reales, conocer las relaciones laborales y personales que se crean dentro de la organización y adquirir experiencia profesional.

en el desempeño de una actividad

CAPÍTULO I GENERALIDADES 1.1. Generalidades de la Institución 1.1.1. Razón Social Municipalidad Distrital de Pocollay 1.1.2. Naturaleza Jurídica

Médiate ley Nº 23828, el 09 de mayo del 1984, se crea en el departamento de Tacna, el distrito de Pocollay fue creado mediante Ley N° 13069 del 15 de enero de 1959. La Municipalidad Distrital de Pocollay (M.D.P.) es el órgano de Gobierno Local Distrital, con personería jurídica de derecho público, con autonomía política, económica y administrativa de los asuntos municipales de su competencia dentro de su jurisdicción, aplicando las leyes y disposiciones y de qué manera general y de conformidad con la constitución política del Perú rigen para los gobiernos locales de nivel distrital, su representatividad emana de la voluntad ciudadana.

1.1.3. Descripción

La Municipalidad Distrital de Pocollay (M.D.P.) es el órgano de Gobierno Local Distrital, donde desarrolla e incorpora instrumentos de gestión municipal

eficientes, para generar desarrollo en el distrito, con sustento en la participación ciudadana. Con programas en materia de población, salud y saneamiento a nivel de la municipalidad distrital, tomando en cuenta los problemas y necesidades de la población vecinal.

1.1.4. Misión La Municipalidad Distrital de Pocollay es una institución al servicio de su población, con liderazgo y capacidad de liderazgo para gobernar, generar desarrollo y calidad de vida.

1.1.5. Visión Al 2021 Pocollay es un distrito próspero con un crecimiento sostenible basado en una agricultura tradicional pero competitiva la que se vincula con las actividades turísticas, industriales y comerciales; las que conviven respetando el medio y articulados a los procesos locales y globales existentes; y con una población comprometida y organizada que potencia sus capacidades y habilidades inmersos en una cultura de valores y respeto, desarrollando estilos de vida saludables y provista adecuadamente de los servicios básicos.

17

1.1.6. Objetivos de la Institución a)

Promover el desarrollo social, cultural, turístico, económico, sostenible y armónico de su jurisdicción en concordancia con la misión y visión contenida en el Plan de Desarrollo Institucional.

b)

Promover y elevar el desarrollo humano del distrito velando por que los más pobres y desvalidos tengan acceso a los servicios que la municipalidad ofrece.

c)

Promover y ejecutar una adecuada presentación de los servicios públicos.

d)

Promover, concertar y coordinar acciones con la sociedad civil, entidades públicas y privadas, nacionales e internacionales.

1.1.7. Reseña Histórica En la heroica Ciudad de Tacna, Capital del Departamento de Moquegua a los 26 días del mes de noviembre de mil ochocientos cincuenta y ocho, reunidos los tres regidores que suscriben en sesión ordinaria, y bajo la presidencia del ilustrísimo alcalde interino, se leyó y aprobó el acta anterior. Inmediatamente, la comisión nombrada para hacer un reconocimiento del nuevo pueblo que se está formándose en Pocollay, dio cuenta de haber cumplido su comisión y presentó su informe por escrito, concebido en los términos siguientes:

18

Los que suscriben, individuos de la comisión nombrada por la ilustrísima municipalidad para que pasaran al acta de Pocollay y en vista de esas localidades trazaran las calles y plazas convenientes de un pueblo que debe formarse allí y además informar sobre varias cuestiones que se han suscitado en dichos solares constituidos en dicho acto el día de ayer, dicen: que si hasta la fecha se halla delineada una vereda de la calle en el costado de la capilla y escuelas, perfectamente bien arregladas por la rectitud que se ha observado en su demarcación, así es que en esa parte nada hay que se pudiera aumentar. La plaza que le tenía designada hay creído la Comisión que era demasiado pequeña y por lo mismo, opina que debe darle doble extensión de superficie: de este modo sin el menor esfuerzo resulta otra calle al sur y paralela a la primera lo que dará con el tiempo mucha regularidad e importancia al pueblo. Expuesto como lo han opinado la ilustrísima municipalidad que las adjudicaciones de solares que se hagan sean gratis a las personas que las solicitan dentro del término de un año para que de esta manera se situé la concurrencia apresurando la fundación del pueblo, pasando este término ya que tendrán valor los terrenos vacantes y entonces se le impondrá un canon municipal a los nuevos pueblos peticionarios, pues si desde el principio requiriera a el impuesto debía alejar la concurrencia

y quedar esto desierto como se ha encontrado y se

encuentra ahora aun en su mayor parte, siendo evidente que de lo bajo de ese

19

dispuesto han empezado a construir habitaciones. Asimismo, parece conveniente para dar impulso a la población que los títulos de adjudicaciones se contenga la indispensable condición de que, si pasados dos años no han inscrito su casa o por lo menos cerrado el terreno asignado, se considere sin efecto y de libre disposición de la ilustre municipalidad para que pueda darlo a cualquier otro solicitante y bajo la misma condición. Por lo que respecta a los solares en cuestión, dicen: que los que solicitan: Flores solo al que está situado al costado de arriba de la capilla y escuelas que lo disputa Godines, pero la comisión opina finalmente que ninguno de los dos tiene un título perfecto para detenerlo de derecho demandando tan solo la preferencia, Por lo que en este sentido la ilustrísima corporación resolverá lo que hayan empezado a edificar Zeballos y que digne inmediatamente es inevitable que debe a otro Zeballos, pues este ha vivido allí más de 20 años y al parecer no ha hecho más que prolongar su propio terreno para ponerse a la línea de la calle, teniendo expandido algunos trabajos, lo que da un derecho para no ser despojados luego digne otro terreno desierto y que ocupa al frente de la finca de Godines lo mismo que de todos los que hemos hablado en donde puede este tomar las varas que se necesita, sin contradicción, pues hasta la fecha se hallan vacantes.

20

Si la ilustrísima municipalidad aprueba la disposición de la plaza y calles que se manifiestan en el plano pasará una copia de él al dependiente municipal de este pago, para que cuide de que los agraviados al verificar no alteren lo menos la demarcación y haga perfecta conformidad con lo dispuesto, a fin de conservar la regularidad del pueblo. (Acta de Fundación del pueblo de Pocollay, 1858) 1.1.8. Ubicación La Municipalidad Distrital de Pocollay (M.D.P.) tiene domicilio legal en la calle Hermanos Reynoso N°15, Plaza Principal de Pocollay. Tabla 1: Ubicación Geográfica Región

Tacna

Provincia

Tacna

Distrito Pocollay Extensión territorial Área de influencia

Pocollay 265 km2 Regional

Fuente: http://munidepocollay.gob.pe/distrito/ubicacion

21

Figura 1: Dirección de la Entidad Municipal Fuente: Google Maps

1.2. Generalidades de la Organización de la Institución 1.2.1. Órganos de Alta Dirección a)

Consejo Municipal.

b)

Alcaldía.

c)

Gerencia Municipal.

1.2.2. Órganos Consultivos y de Coordinación a)

Comisiones de regidores.

b)

Comité de Coordinación Local.

c)

Comité de Defensa Civil.

d)

Comité de Seguridad Ciudadana.

e)

Comité de Juntas Vecinales. 22

f)

Comité de Administración del Vaso de Leche y de Seguridad Alimentaria.

g)

Comité del Club de Madres.

h)

Comité Multisectorial de Desarrollo.

i)

Comité Distrital de la Juventud.

1.2.3. Órgano de Control Institucional a)

Oficina de Control Institucional.

1.2.4. Órgano de Defensa Judicial a)

Oficina de la Procuraduría Pública Municipal.

1.2.5. Órganos de Asesoramiento a)

Oficina de Asesoría Jurídica.

b)

Oficina de Planificación y Presupuesto.

c)

Unidad de Programación de Inversiones y Gestión de Proyectos.

1.2.6. Órganos de Apoyo a)

Unidad de Secretaría General e Imagen Institucional.

b)

Unidad de Supervisión y Liquidación de Proyectos.

c)

Unidad de Administración Tributaria.

d)

Unidad de Ejecutoría Coactiva.

e)

Oficina de Administración y Finanzas.

23

f)

Unidad de Personal.

g)

Unidad de Contabilidad.

h)

Unidad de Tesorería.

i)

Unidad de Logística.

j)

Unidad de Soporte Informático.

1.2.7. Órganos de Línea a)

Gerencia de Ingeniería y Desarrollo Urbano. a.

Subgerencia de Planeamiento Urbano, Catastro y Margesí.

b.

Subgerencia de Estudios.

c.

Subgerencia de Obras Públicas.

b)

División de Desarrollo Económico, Agrario y Turismo.

c)

Gerencia de Servicios Sociales y Locales. a.

Subgerencia de Desarrollo Social y Humano.

b.

Subgerencia de Gestión Ambiental y Mantenimiento.

1.2.8. Órganos de Desconcentrados a) Grifo Municipal. b) Cementerio Municipal. c) Equipo Mecánico.

24

1.2.8. Organigrama

Figura 2: Organigrama Municipal Fuente: ROF 2013 de la Municipalidad Distrital de Pocollay

25

1.3. Generalidades de las Prácticas 1.3.1. Objetivo General Aplicar todos los conocimientos adquiridos dentro de la formación académica dados en la universidad, en la solución de problemas reales en la institución donde se realizó las prácticas pre profesionales, en la Municipalidad Distrital Pocollay 1.3.2. Objetivos Específicos  Adquirir experiencia profesional en el campo laboral, afrontando situaciones de presión reales.  Aplicar una metodología aprendida durante los años de formación académica en la casa superior de estudios, para poder desarrollar el diseño y modelado del Sistema Web de Requerimientos Informáticos. 1.4. Generalidades del Área de Desempeño

1.4.1. Área de Desempeño Unidad de Soporte Informático (USI) 1.4.2. Funciones del Área de Desempeño a)

Elaborar, dirigir y ejecutar el Plan Informático de la Municipalidad conforme a la normatividad vigente.

26

b)

Conducir la sistematización y procesamiento de la información para la toma de decisiones.

c)

Elaborar estudios sobre tecnologías de la información en función a las necesidades de interconexión de la Municipalidad.

d)

Diseñar, elaborar y desarrollar software de aplicación acorde con las necesidades, los requerimientos y las exigencias de las diferentes áreas y dependencias de la Municipalidad.

e)

Administrar el Portal Electrónico de la Municipalidad.

f)

Las demás funciones de su competencia que conforme a la ley debe ejecutar y las que le delegue o asigne la Oficina de Administración y Finanzas.

1.4.3. Descripción del Área de Trabajo La Unidad de Soporte Informático, es responsable de planear, organizar, dirigir, controlar, evaluar, y apoyar técnicamente a todo el sistema de informática de la municipalidad, optimizando el uso de los equipos de cómputo hacia el logro de los objetivos y metas de las diferentes órganos y unidades orgánicas de la Municipalidad. Está a cargo de un especialista y depende de la Oficina de Administración y Finanzas.

27

CONCEJO MUNICIPAL ALCALDÍA GERENCIA MUNICIPAL OFICINA DE ADMINISTRACIÓN Y FINANZAS UNIDAD DE SOPORTE INFORMÁTICO Figura 3: Dependencia de la Unidad de Soporte Informático Fuente: Elaboración Propia

1.4.4. Actividades Realizadas a)

Desarrollo del “Sistema de Requerimientos Informáticos” de la Municipalidad Distrital de Pocollay para el Área de Soporte Informática.

b)

Instalación de los Sistemas Municipales para las gerencias y oficinas para el año 2016 (SIAF, ABASOFT, CUADRO DE NECESIDAD).

c)

Apoyar a usuarios en operaciones de implementación o adecuación de servicios informáticos.

d)

Detección y eliminación de virus y programas espías.

e)

Instalación y mantenimiento de software propio o programas comerciales. 28

f)

Instalación y configuración de componentes internos o externos.

g)

Recuperación de datos eliminados o destruidos.

h)

Exportación de la información a formatos manejables por aplicaciones ofimáticas

i)

Brindar apoyo a los usuarios cuando se presenta problemas de software y hardware.

j)

Resolver los problemas técnicos menores que se presenten con los computadores.

k)

Realizar servicios técnicos a los equipos, de acuerdo a la solicitud del usuario, o en caso de presentar falla.

l)

Configurar impresoras y dispositivos de hardware y otros periféricos.

m)

Crear las direcciones IP, cuentas de usuarios de dominio, correo electrónico, entre otros.

n)

Actualización del portal de transparencia. (Resolución de Alcaldía, Ordenanzas Municipales, Acuerdos de Concejo, Resolución de Gerencia Municipal, Decretos de Alcaldía).

o)

Actualización del Texto Único de Procedimientos Administrativos (TUPA) en el portal de transparencia.

29

1.4.5. Recursos Humanos El recurso Humano de la Unidad de Soporte Informático está compuesto por un grupo de Profesionales: Tabla 2: Recursos Humanos de la USI Recursos humanos

Cantidad

Jefe de área

1

Asistente de área

1

Practicante

3

Total

5

Fuente: Elaboración Propia

1.4.6. Recursos Informáticos y Tecnológicos El recurso informático y tecnológico de la Unidad de Soporte Informático está compuesto por lo siguiente: Tabla 3: Recursos Tecnológicos de la USI Recurso

Cantidad

Estaciones de trabajo

4

Impresoras laser

2

Servidores

5

Teléfono/anexo

1

Escáner

1

Total

13

Fuente: Elaboración Propia

30

CAPÍTULO II FUNDAMENTO TEÓRICO 2.1. Marco Referencial 2.1.1. Definición de Sistema Según Pressman (2002); “Un sistema es un conjunto o disposición de elementos que están organizados para realizar un objetivo predefinido procesando información”. Un sistema es un conjunto de partes o elementos organizados y relacionados que interactúan entre sí para lograr un objetivo. Los sistemas reciben entrada de datos, energía o materia del ambiente y proveen salida de información, energía o materia. (James, 2002)

Figura 4: Esquema Grafico General de un Sistema Fuente: http://www.alegsa.com.ar/Dic/sistema.php

2.1.2. Definición de Sistema de Información Según Kendall y Kendall (1993); “Sistemas de Información son sistemas computarizados, que trabajan debido a la interacción resuelta entre gentes y computadora. Requieren que las gentes, el software y el hardware trabajen al unísono. Los Sistemas de Información dan Soporte a un espectro amplio de tareas organizacionales, incluyendo el análisis de decisiones y la toma de decisiones”. Según I.T. Hawryszkiewycz. (1994); “Un sistema es un conjunto de elementos organizados que interactúan entre sí y con su ambiente, para lograr objetivos comunes, operando sobre información, sobre energía o materia u organismos para producir como salida información o energía o materia u organismos. Un sistema aislado no intercambia ni materia ni energía con el medio ambiente”. Según Ralph M. Stair, George W. Reynolds (2000); “Un Sistema es un conjunto de elementos o componentes interrelacionados para recolectar (entrada), manipular (procesamiento) y diseminar (salida) datos e información, que cuenta además con un mecanismo de retroalimentación para el cumplimiento de un objetivo”.

33

Figura 5: Esquema de Sistema de Información Fuente: http://es.wikipedia.org “Sistema de Información”.

2.1.3. Definición de Programación Orientada a Objetos Programación Orientada a Objetos (OOP, Object Oriented Programming, en inglés); es una técnica de programación cuyo soporte fundamental es el objeto. Un objeto es una extensión de un Tipo Abstracto de Datos (TAD), concepto ampliamente utilizado desde la década de los setenta. Un TAD es un tipo definido por el usuario, que encapsula un conjunto de datos y las operaciones sobre estos datos. 2.1.4. Definición de Análisis Orientado a Objetos Es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. (Addison-Wesley, 2012)

34

2.1.5. Definición de Base de Datos Es una colección o depósito de datos integrados con redundancia controlada y con una estructura que refleje las interrelaciones y restricciones existentes en el mundo real; los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de éstas, y su definición y descripción, únicas para cada tipo de datos, han de estar almacenadas junto con los mismos. Los procedimientos de actualización y recuperación, comunes y bien determinados, habrán de ser capaces de conservar la integridad, seguridad y confidencialidad del conjunto de los datos. (Castaño, 1995) 2.2. Terminologías Web 2.2.1. Definición de Internet Internet es un conjunto descentralizado de redes de comunicación interconectadas que utilizan la familia de protocolos TCP/IP, garantizando que las redes físicas heterogéneas que la componen funcionen como una red lógica única, de alcance mundial. Sus orígenes se remontan a 1969, cuando se estableció la primera conexión de computadoras, conocida como ARPANET, entre tres universidades en California y una en Utah, Estados Unidos. Uno de los servicios que más éxito ha tenido en Internet ha sido la World Wide Web (WWW, o "la Web"), hasta tal punto que es habitual la confusión entre ambos términos. (Pressman, 1999) 35

2.2.2. Definición de World Wide Web (WWW) World Wide Web (también conocida como Web o WWW) es una colección de ficheros, que incluyen información en forma de texto, gráficos, sonidos y videos, además de vínculos con otros ficheros. Los ficheros son identificados por un localizador universal de recursos (Universal Resourse Lacation - URL) que especifica el protocolo de transferencia, la dirección de Internet de la máquina y el nombre del fichero. Los programas informáticos denominados exploradores como Navigator, de Netscape, o Internet Explorer, de Microsoft utilizan el protocolo HTTP (lenguaje de marcado hipertexto). (Pressman, 1999) 2.2.3. Definición de Aplicaciones Web Una aplicación Web en un sitio web donde la navegación a través del mismo y la entrada de datos son por parte del usuario. En esencia se utiliza un sitio Web como entrada en una aplicación única “Un sistema de información donde una gran cantidad de datos volátiles, altamente estructurados, son consultados, procesados y actualizados mediante navegadores”. (Pressman, 1999) Pressman y las características de la aplicación Web: a)

Intensivas de red, por que reside en una red y debe satisfacer a diferentes usuario.

36

b)

Evolución continua, porque cada día es creada una nueva herramienta, es decir, la tecnología está en constante evolución.

c)

Inmediatez, a diferencia de los sistemas tradicionales, el requerimiento de estos sistemas es de menor tiempo.

d)

La estática, la interfaz presentada debe ser bastante amigable para el usuario.

e)

Seguridad, como esta aplicación está ejecutándose en una red de acceso público, es difícil controlar el acceso no autorizado.

2.2.4. Definición de Portal Web Portal Web, es una página que sirve de entrada a la Web y representa un punto de interacción con la información existente. Los portales son sistemas de información basados en la Web, que ofrecen un punto de acceso único a la información proveniente de fuentes diversas. 2.2.5. Definición de Requerimientos Informáticos Predomina el concepto de requerimientos como necesidad y como problema, por lo que es un concepto que refleja el dinamismo del internet. Lo informático, tiene que ver con el propósito del sistema referido a articularse flexiblemente y responder a diversas demandas. Informáticos en este contexto se relaciona con el hecho que los requerimientos es relativo en espacio y tiempo; porque sus fronteras, las marcas, la disponibilidad temporal y la instancia de la 37

demanda de quien la solicita. Los requerimientos permiten a la Unidad de Soporte Informático tener una idea clara del problema que posee un usuario para ello responde dinámicamente a partir de su red de fuentes de información. 2.3. Metodología de Desarrollo 2.3.1. Metodología de Diseño de Hipermedia Orientado a Objetos – OOHDM La

Metodología

OOHDM

(Object

Oriented

Hipermedia

Design

Methodology – Metodología de Diseño Hipermedia Orientado a Objetos), para

diseño

de aplicaciones hipermedia y para la Web, fue diseñado por D.

Schwabe, G. Rossi (2002) y es una extensión de Modelo de Diseño de Hipermedia - HDM con orientación a objetos. Es

un

enfoque

basado

en

modelos

para

construir

grandes

aplicaciones de hipermedia, este enfoque ha sido utilizado para el diseño de diferentes tipos de aplicaciones tales como; sitios web, sistemas de información y presentaciones de multimedia, etc. Tratan los patrones de diseño, específicamente de navegación, personalización y los diagramas de interacción con los usuarios (UID – User Interaction Diagramas). La metodología OOHDM propone el desarrollo de aplicaciones Web a través de un proceso compuesto por cinco diferentes actividades denominadas:

38

a)

Levantamiento de requisitos

b)

Diseño conceptual (Conceptual Design)

c)

Diseño Navegacional (Navegational Design)

d)

Diseño de Interfaz Abstracta (Abstract Interface Design)

e)

Implementación (Implementación)

2.3.2. Descripción del Esquema de la Metodología OOHDM En la figura siguiente se presenta un sumario de metodología OOHDM describiendo los productos, mecanismos e interés de diseño que se utilizan en cada fase.

Figura 6: Etapas de la Metodología OOHDM Fuente: http://www.inf.ucv.cl/

39

Tabla 4: Metodología OOHDM Actividades Especificación requisitos

de

Productos

Formalismos

Casos uso

Casos de uso

de

Mecanismos

Temas de diseño

Casos de uso

Modelo gráfico que representa el intercambio de información entre el usuario y el sistema.

Clasificación, agregación, generalización y especificación.

Se modela semántica dominio de aplicación.

Se tiene en cuenta el perfil del usuario y las tareas. Se enfatiza los aspectos cognitivos y arquitecturas.

Clases, sub sistemas, relaciones, atributos.

Modelos orientados objetos.

Nodos enlaces, estructura de acceso, contexto navegacion ales, transformac iones de navegación.

Vistas orientadas a objetos, cartas de navegación orientadas a objetos, clases de contexto.

Trazando entre los objetos conceptuales y de navegación.

Diseño abstracto

Objeto de la interfaz abstracta, respuestas a eventos externos, transformac iones de la interfaz.

Vistas abstractas de datos ADV, diagramas de configuración, cartas de navegación de los ADV

Trazando entre Modelado de objetos objetos de permisibles. navegación y Implementa objetos de metáforas escogidas. interfaces. Descripción de interfaces para objetos.

Implementación

Los que provea Se realizan Aplicación Los completan. en soportados por el entorno funcionamie el entorno. nto.

Diseño conceptual

Diseño navegacional

a

Modelos de la navegación para la descripción de la estructura general de la aplicación.

Fuente: Proyecto de Grado, Pág. 28, Autor: Lic. Eufren Llanque Quispe

40

la del la

y

2.3.3. Descripción de levantamiento de requisitos En esta etapa se tiene los siguientes pasos: a)

Clasificación e identificación de usuarios y tareas: Se identifican a los actores que intervienen en el sistema, las tareas y relaciones que existen entre ambos.

b)

Especificaciones de escenarios: Los escenarios son descripciones narrativas de las acciones de los actores, de cómo pueden usar la aplicación.

c)

Especificación de casos de uso: Se elaboran los diagramas de casos de uso, especificando la interacción de los usuarios con el sistema, buscando interrelaciones y propiedades comunes que permitan reutilizar especificaciones navegacionales.

d)

Especificación de los Diagramas de Interacción de Usuarios – UID; son modelos gráficos que representan la interacción entre el usuario y el sistema, sin considerar aspectos específicos interfaz ni de navegación.

2.3.4. Definición de Diseño Conceptual El modelo OOHDM luego de especificar los requisitos, realiza el desarrollo del esquema conceptual representado por los objetos del dominio, las relaciones y colaboraciones establecidas entre ellas. Se construye un esquema 41

conceptual representado por los objetos de dominio o clases y las relaciones entre dichos objetos, viene a ser equivalente al modelo Entidad-Relación

Figura 7: Ejemplo de Diagrama Conceptual Fuente: http://www-di.inf.puc-rio.br

2.3.5. Definición de Diseño Navegacional El modelo se compone de objetos construidos a partir de los objetos del modelo conceptual, es decir, como una vista sobre un diseño conceptual, admitiéndola construcción de modelos diferentes de acuerdo con los diferentes

perfiles

de

usuario

constituyéndose

en

elementos

de

las

aplicaciones hipermedia tradicionales: modos, enlaces, anclas y estructuras de accesos. Los enlaces derivan de las relaciones y los nodos representan ventanas lógicas sobre las clases conceptuales. En el momento de la especificación de las clases navegacionales es cuando el diseñador define las correspondencias, no

42

impone metáforas preestablecidas. Los nodos inducidos de las clases del modelo del dominio y los enlaces inducidos de las relaciones del modelo del dominio se pueden precisar. Como el segundo nivel está consagrado a la especificación de la navegación, expresada exclusivamente sobre los objetos navegacionales (no sobre los elementos del modelo del dominio), constituye un mecanismo que permite enriquecer el modelo hipermedia. El diseño de navegación es expresado en dos esquemas: el de clase navegacional y el de contextos navegacionales.

Figura 8: Ejemplo de Esquema de Contexto Navegacional Fuente: http://commons.wikimedia.org

2.3.6. Diseño de Interfaz Abstracta En OOHDM se utiliza el diseño de interfaz. Por otro parte en el OOHDM se usa un acercamiento de Diseño de Vista de Datos Abstractos (ADV) para

43

especificar el modelo de interfaz abstracta de una aplicación hipermedia. Los ADV son abstractos en el sentido de que ellos solo representan la interfaz y el estado y no así la aplicación. Una vez que las estructuras navegacionales son definidas, se deben especificar los aspectos de interfaz. Esto significa la forma en la cual los objetos navegacionales pueden aparecer, cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad de la aplicación, qué transformaciones son pertinentes y cuándo necesarios realizarlas. Un ADV usado en el diseño de aplicaciones Web puede verse como un objeto de interfaz. Comprende un conjunto de atributos (y objeto de interfaz anidado) que define sus propiedades de percepción, y el conjunto de eventos que pueda manejar, como eventos generados por el usuario. Los ejemplos de eventos son generados por el usuario que son MouseClick, MouseOn, etc. Los ADV pueden ser fácilmente implementados en ambientes orientados a objetos para la Web. Pueden definirse valores del atributo como constantes y pueden definirse estilos particulares de apariencia como color, posición o sonido. El modo de interfaz ADV especifica la organización y comportamiento de la interfaz, pero la apariencia física real de los atributos y la disposición de los ADV. En la pantalla real son hechas en la fase de implementación.

44

Figura 9: Ejemplo de Vista de Datos Abstracta Fuente: http://commons.wikimedia.org/wiki/ Diseño de interfaz

Utilización de ADV para especificar la interface hipermedia: La definición del modelo de interface de una aplicación hipermedia con OOHDM, implica: a)

Definir la estructura general de la interface de la aplicación

b)

Definir ADV para modos, índices, etc.

c)

Definir en cada Nodo, objetivos de interface apropiados para atributos, anclas, etc.

d)

Definir ADV para clases de contexto.

e)

Mostrar los relacionamientos estáticos entre componentes de ADV.

45

A pesar de ser independiente de la implementación, las especificaciones de la interface abstractas deben considerar ciertos aspectos de la implementación, para que la especificación sea realista. 2.3.7. Descripción de la Implementación Metodológica Durante la actividad de la implementación, reflejamos los objetos conceptuales, de navegación y de interfaz, sobre el entorno de ejecución destinatario. Cuando el entorno de implementación no es totalmente orientado a objetos, se tiene que reflejar los objetos conceptuales, de navegación y de interfaz abstracta sobre objetos concretos, es decir, aquellos disponibles en el entorno de implementación seleccionado. Esto pude requerir definir páginas HTML, código en cierto lenguaje, preguntas a base de datos relacionales, etc. Observar que aun en entornos orientados a objetos, pueden no existir deferencias significativas entre objetos conceptuales y de navegación, los cuales actuarán como modelos de interface. Mientras tanto, en un entorno más hibrido los objetos conceptuales se reflejando en un almacenamiento persistente (archivos y bases de datos relacionales) y los objetos de navegación y de interfaz se implementaran como páginas Web convencionales.

46

2.4. Lenguaje Unificado de Modelado (UML) El Lenguaje de Modelado Unificado (UML) sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o como diseñar el sistema, sino que simplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros. UML está controlado por el Grupo de Administración de Objetos (OMG) y es el estándar de descripción de esquemas de software. (Jacobson, 1999) Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico, nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Los modelos de UML que se tratan en esta parte son los siguientes: a)

Diagrama de Casos de Uso

b)

Diagrama de Secuencia

c)

Diagrama de actividades

2.4.1. Definición de Diagrama de Casos de Uso Un caso de uso es una descripción de las acciones de su sistema desde el punto de vista del usuario. Para los desarrolladores del sistema, esta es una

47

herramienta valiosa, ya que es una técnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad es crear un sistema que puede ser utilizado por la gente en general (no solo por expertos en computación). (Schmuller)

Figura 10: Ejemplo de Diagrama de Caso de Uso Fuente: Elaboración Propia

2.4.2. Descripción de Diagrama de Secuencia Los diagramas de secuencia describen como los objetos del sistema colaboran. Se trata de un diagrama de interacción que detalla como las operaciones se llevan a cabo, qué mensajes son enviados y cuando, organizado todo en torno al tiempo. El tiempo avanza “hacia abajo” en el diagrama. Los objetos involucrados en la operación se listan de izquierda a derecha de acuerdo a su orden de participación dentro de la secuencia de mensajes.

48

Figura 11: Ejemplo de Diagrama de Secuencia Fuente: Grady Booch, James Rumbaugh, Ivar Jacobson, 1996

2.4.3. Descripción de Diagrama de Actividades Un diagrama de actividad es uno de los diagramas UML utilizados para modelar aspectos dinámicos de un sistema. Un diagrama de actividad modela la secuencia y en ocasiones la coocurrencia, de pasos de un proceso computacional. También podemos modelar el flujo de un objeto cuando pasa de un estado a otro en diferentes flujos de control de actividades. (Maeda, 2009)

49

Figura 12: Ejemplo de Diagrama de Actividades Fuente: http://docs.kde.org/ “Manual de Umbrello UML Modeller”

2.5. Definición de PHP (PHP Hypertext Pre-processor) Hypertext Pre-processor, es un procesador de hipertexto y, por ende, se ejecuta en un servidor Web remoto para procesar páginas web antes de que sean cargadas en el navegador. Además de sus potentes características, PHP es un lenguaje simple que ha sido diseñado específicamente para el desarrollo y

50

producción de páginas web. Su sintaxis es similar a la de “c” y “Perl”. (Villar, 2011) Lo que puede hacer con PHP (community, 2013): a)

PHP puede ser utilizado en cualquiera de los principales sistemas operativos del mercado, incluyendo Linux, muchas variantes Unix (incluyendo HP-UX, Solaris y OpenBSD), Microsoft Windows, Mac OS X, RISC OS y probablemente alguno más. PHP soporta la mayoría de servidores web de hoy en día, incluyendo Apache, IIS, y muchos otros. Esto incluye cualquier servidor web que pueda utilizar el binario PHP de FastCGI, como lighttpd y nginx. PHP funciona ya sea como un módulo, o como un procesador de CGI.

b)

Con PHP no se encuentra limitado a resultados en HTML. Entre las habilidades de PHP se incluyen: creación de imágenes, archivos PDF e incluso películas Flash (usando libswf y Ming) sobre la marcha. También puede presentar otros resultados, como XHTML y cualquier otro tipo de ficheros XML. PHP puede autogenerar estos archivos y almacenarlos en el sistema, creando un caché en el lado-servidor para contenido dinámico.

51

2.6. Definición de MySQL MySQL es la base de datos de código abierto más popular del mundo. Con su probado rendimiento, fiabilidad y facilidad de uso, MySQL se ha convertido en la opción principal base de datos para las aplicaciones basadas en la Web, que se utiliza por sus propiedades web de alto perfil, incluyendo Facebook, Twitter, YouTube, Yahoo y muchos más. (mysql.com, 2016) Oracle impulsa la innovación de MySQL, la entrega de nuevas capacidades a la web de próxima generación de potencia, nube, aplicaciones móviles e integradas.

52

CAPÍTULO III MATERIAL Y MÉTODO UTILIZADO EN LAS PRÁCTICAS PRE PROFESIONALES 3.1. Materiales Utilizados Se dará a conocer los diferentes dispositivos (materiales) que se utilizaron durante el tiempo de prácticas pre-profesionales, comprenden generalmente dispositivos informáticos como terminales en los cuales se desarrolló el software. La lista de materiales que se muestra a continuación se indican las características técnicas de los equipos informáticos que se utilizaron en la Municipalidad Distrital de Pocollay. 3.1.1. Hardware En la lista de materiales que se muestra a continuación se indican las características técnicas de los equipos informáticos que se utilizó en la Municipalidad Distrital de Pocollay. Tabla 5: Características del Terminal de Desarrollo Procesador

Intel(R) Core(Tm)2 Duo Cpu @ 3.00ghz

Disco Duro

250 GB

Monitor

Marca lg

Fuente: Elaboración Propia

3.1.2. Software 3.1.2.1. Sistema Operativo Microsoft

Windows

7

Ultimate

Copyright

2009

Microsoft

Corporation.Reservados todos los derechos. 3.1.2.2. Herramientas de Soporte MicrosoftOfficeWord2007 3.1.2.3. Herramienta de Planificación Libre Project 3.1.2.4. Herramienta de Análisis 

Start UML



WorkBench

3.1.2.5. Herramientas de Desarrollo 

MySQL

3.2. Administración del Proyecto 3.2.1. Objetivo General Desarrollar un modelo para un Sistema Web de Requerimientos Informáticos, y así llevar un control de los requerimientos solicitados por los trabajadores de la Municipalidad Distrital de Pocollay. 54

3.2.2. Objetivos Específicos 

Realizar requerimientos de información de la Unidad de Soporte Informático.



Analizar el Sistema web de requerimientos con uso de la metodología OOHDM.



Diseñar los modelos de requerimientos del Sistema con UML.



Implementar el Sistema con programación orientada GLP.

3.2.3. Pruebas de Factibilidad del Proyecto Las investigaciones preliminares investigan la factibilidad del proyecto, la posibilidad que es sistema sea de utilidad para la organización. (James, 2002) 3.2.4. Factibilidad Operacional a)

¿Existe apoyo suficiente para el proyecto por parte de la Administración?, ¿y por parte de los Usuarios? Existe un total apoyo del personal Administrativo y usuarios (personal de cada área/oficina o dependencia), debido a que el nuevo sistema vendrá a facilitar gran parte de su trabajo específicamente al momento de presentar un requerimiento a la Unidad de Soporte Informático el cual debe de tener un informe para los usuarios.

55

b)

¿Los métodos que actualmente se emplean en la empresa, son aceptados por los usuarios? Existen algunas deficiencias en la atención de los requerimientos informáticos de la USI, tanto en el tiempo de atención, el conocimiento de la existencia de algún problema o registro anterior en esa oficina, por lo cual usuarios y administradores de la unidad necesita el uso del sistema para mejorar la calidad del servicio que brindan en la entidad.

c)

¿Los Usuarios han participado en la planeación y desarrollo del Proyecto? Se recibió el apoyo necesario por parte del usuario (personal de cada área/oficina o dependencia) y administrador de la USI (Jefe de Área y/o Asistente), para realizar el análisis para el sistema así lograr al final que todos los usuarios que intervienen en el sistema queden conformes.

d)

¿El Sistema propuesto causara prejuicios? No causará perjuicios, sino optimizará tiempos de búsqueda, reportes y la solución más rápida y oportuna a los requerimientos informáticos de la USI.

56

e)

¿Producirá resultados en algún aspecto o área? El sistema estará diseñado para que produzca únicamente resultados efectivos en el área, de obtener la información actual y adecuada a los requerimientos, lo cual tomaría tiempo educar al usuario a usar dicha tecnología por ser algo nuevo, abría una resistencia al cambio pero es solo momentáneo.

f)

¿Se perderá la facilidad de acceso a la información? No. El sistema facilitará el acceso a la misma información debido al tratamiento digital en la administración y la disponibilidad de la misma para los usuarios que intervienen.

g)

¿La productividad de los empleados será menor después que antes de la implantación? Podemos

asegurar

que

el

sistema

aumentará

la

productividad, reducirá tiempos, facilitará en trato de los objetos de los involucrados, optimizando el rendimiento de la administración de los requerimientos informáticos conforme a la llegada de los mismos. h)

¿Los Usuarios se verán afectados en forma poco favorable? No, el sistema será usado tanto por el administrador como por

el

usuario,

ya

que

57

cuenta

con

tres

interfaces

(administrador/soporte/usuario), así que ninguno afectará la tarea del otro, más bien los usuarios tendrán la factibilidad de ver sus requerimientos y también la solución del mismo e imprimir el mismo, lo cual será de gran ayuda para el usuario.

El

sistema

de requerimientos informáticos apoyara al usuario y al

administrador; proporcionara

al

sector administrativo una herramienta que

colabore y facilite las actividades diarias especialmente del personal que labora en las demás oficinas en la entidad municipal, mejorando el control y actualización, ofreciendo información inmediata de los requerimientos. Por cuanto la factibilidad operacional es positiva. 3.2.5. Factibilidad Técnica a)

¿Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide? Sí, la municipalidad en una institución dispuesta al cambio, por lo cual ha adquirido servidores de última generación para reemplazar los antiguos servidores, así que la institución cuenta con la tecnología necesaria para el uso del sistema.

58

b)

¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos requeridos para usar el nuevo sistema? Sí, la municipalidad de Distrital de Pocollay cuenta con Servidor web, intranet con Microsoft Windows Server 2012 R2 Enterprise Edition, sí cuenta capacidad de soportar el Sistema.

c)

¿El Sistema propuesto ofrecerá respuestas adecuadas a las peticiones, sin importar el número y ubicación de los usuarios? Sí, es un sistema web, basado en PHP y MySQL, va ser subido a la intranet, posteriormente a internet con acceso a usuarios de las diferentes sedes del palacio municipal.

d)

Si se desarrolla el Sistema, ¿puede crecer con facilidad? El sistema es desarrollado con PHP (PHP Script Language Version 5.2.3), es muy flexible y aceptado por la gran mayoría de programadores, así que el proyecto puede crecer sin mayores problemas.

e)

¿Existen

garantías

técnicas

de

exactitud,

confiabilidad,

facilidad de acceso y seguridad de los datos? Sí, se tienen actividades de seguridad. El uso de backup ya sean periódicos o backup realizados por el administrador de red. El uso de filtros ante ataques Web (Anti SQL inyección), y autentificación de usuario para el portal de administración.

59

El Sistema de Requerimientos Informáticos tiene justificación técnica, por cuanto su desarrollo e implementación permitirá el aprovechamiento óptimo de los recursos computacionales y de redes con las que cuenta la institución. El sistema será de gran apoyo para la Unidad de Soporte Informático y para los funcionarios de toda la entidad municipal ya que contará con un manual de usuario, capacitación de manejo, Seguridad de los Requerimientos, el mismo sistema que será fácil de manejar y permitirá un óptimo conocimiento de los requerimientos informáticos que lleguen a la USI. 3.2.6. Factibilidad Financiera a)

El costo de llevar a cabo la investigación completa de sistemas. El recurso humano para la implementación está dado por una persona y es un servicio de la Unidad de Soporte Informático, será económicamente solvente para solventar el desarrollo del sistema.

b)

El costo del hardware y software para la aplicación. Ese gasto se ha hecho debido a que la entidad dispone de hardware necesario y disponible, respecto al software se utilizará plataformas de uso software libre (php, MySQL, editores de texto 60

libre, etc) para el desarrollo del sistema. c)

Beneficios en la forma de reducción de costos o de menos errores costosos. Los beneficios son los que más se verán con la implantación del nuevo sistema, y sobre todo los que evitaran los errores que al final generan pérdidas de tiempo y dinero.

Cada institución pública tiene la necesidad de reducir los costos y de tener un máximo rendimiento. De manera que el sistema a desarrollar no tiene un costo monetario ya que se cuenta con el hardware necesario (la empresa lo tiene) y el software de carácter gratuito y libre. Por lo cual la factibilidad financiara es positiva. 3.2.7. Alcance del Proyecto Luego de analizar los problemas identificados, el presente proyecto desarrolla un sistema de información conformada por los siguientes módulos: ADMINISTRADOR: Módulo de Adición, Modificación y Eliminación de unos usuarios, tipos de requerimientos, entre otros registros de la base de datos donde se almacenarán los datos necesarios de cada requerimiento informático.

61

SOPORTE: Nivel de acceso para la adición de soluciones de requerimientos insertados por cada usuario. USUARIO: Diseño de sitio Web permitiendo a los usuarios una inserción de requerimientos informáticos que posteriormente será atendido por los encargados de soporte, el cual al finalizar se remitirá un informe. 3.2.8. Aportes Dentro del aporte tenemos al mismo sistema que incluye CD del sistema, los que se van a beneficiar son los usuarios y administradores de la de la Unidad de Soporte Informático (USI). 3.3. Desarrollo del Sistema 3.3.1. Identificación de Usuarios y Tareas Los actores que interactúan con el sistema son definidos el siguiente Figura, estos cumplen roles específicos para los métodos de Inserción de requerimientos, solución de los mismos, o la administración del sistema, para un mejor entendimiento del rol que desempeña, a continuación se realiza una breve descripción de cada actor. Quienes son actores:

62

Figura 13: Esquematización de Actores Fuente: Elaboración Propia

3.3.2. Descripción de Cada Autor Administrador: Es el responsable del sistema de administración, esta persona tiene libertad de eliminar usuarios, añadir, modificar y eliminar los datos e información contenida en la base de datos del sistema. Pueden ser administrador de red o el jefe de área de la USI. Soporte: El actor Soporte será encargado de poder responder y realizar las soluciones, al requerimiento que genere el usuario. Usuario: Acuden diariamente a la USI personal de las diferentes oficinas del palacio municipal asi como de las diferentes sedes; por ello los usuarios serán los trabajadores de la municipalidad ya que ellos efectúan los requerimientos informáticos.

63

3.3.3. Diagrama Principal de Caso de Uso Los actores y sus Relaciones en el sistema de Requerimientos Informáticos

Figura 14: Diagrama de Caso de Uso General del Proyecto Fuente: Elaboración Propia

64

3.3.4. Diagrama de Caso de Uso del Autor Administrador En el siguiente diagrama de caso de uso se puede observar al usuario con el rol de administrador, la interacción al ingresar al sistema de administración de contenidos que funciona al interior del portal Web dinámico, representando de esa manera la finalidad y los procesos que realiza para administrar reporte de requerimientos, creación de nuevos usuario, adición, modificación, eliminación, clasificación entre otros procesos que realiza el administrador.

Figura 15: Diagrama de Caso de Uso del Administrador Fuente: Elaboración Propia

3.3.5. Diagrama de Caso de Uso del Autor Soporte El siguiente diagrama de casos de uso representa la funcionalidad parcial del portal Web dinámico para el sistema de requerimientos informáticos con el rol de soporte. 65

Figura 16: Diagrama de Caso de Uso del Autor Soporte Fuente: Elaboración Propia

3.3.6. Diagrama de Caso de Uso del Autor Usuario El siguiente diagrama de casos de uso representa la funcionalidad parcial del portal Web dinámico para el sistema de requerimientos informáticos con el rol de usuario (Personal municipal).

Figura 17: Diagrama de Caso de Uso del Usuario Fuente: Elaboración Propia

66

3.3.7. Especificaciones de Caso de Uso En las siguientes tablas se muestran las especificaciones de “Casos de Uso” del sistema de requerimientos informáticos de la Municipalidad Distrital de Pocollay. Tabla 6: Caso de Uso Registro de Requerimiento CU-001

Registro de Requerimiento

Actores

Usuario(Personal de la Entidad Municipal)

Descripción

El caso de estudio se inicia cuando un usuario de la entidad requiere el servicio de la USI, el cual se procede al registro del mismo.

Flujo

Flujo Básico

1.- El usuario necesita del servicio de la USI 2.- Abre el sistema y realiza inicio de sesión. 3.- Aparece el escritorio principal luego “Agregar Nuevo Requerimiento” o Agregar. 4.- El sistema mostrará un formulario en el cual se deberá ingresar la información del Requerimiento. 5.- Si al ingresar el requerimiento se procederá a asignarle una categoría. 6.- Se procederá a Actualizar el sistema.

Flujo

No se realiza un flujo Alternativo.

de Eventos

Alternativo Pre condiciones

El Usuario debe de estar Autentificado.

Post condiciones

Ninguna.

Requerimientos Especiales

El usuario deberá de tener Usuario y Clave que será suministrada por el encargado del sistema.

Fuente: Elaboración Propia

67

Tabla 7: Caso de Uso Modificación de Requerimiento CU-002 Actores Descripción

Flujo de Eventos

Modificación de Requerimiento Usuario(Personal de la Entidad Municipal) El caso de estudio se inicia cuando un usuario de la entidad necesita editar o modificar un requerimiento antes ya registrado en el sistema de la USI, el cual se procede a la modificación del mismo. Flujo Básico

1.- El usuario necesita editar un requerimiento antes registrado en el sistema de la USI 2.- Abre el sistema y realiza inicio de sesión. 3.- Aparece el escritorio principal luego “Mis Requerimientos”. 4.- Selecciona el Requerimiento que desea editar y luego “Editar” 5.- El sistema mostrará un formulario en el cual se deberá modificar la información del Requerimiento ya registrado. 6.- Concluido esto se guarda y cambia para poder concluir con la modificación del mismo. 7.- Se procederá a Actualizar el sistema.

Flujo Alternativo Pre condiciones

No se realiza un flujo alternativo.

Post condiciones Requerimientos Especiales

Ninguna. El usuario deberá de tener usuario y clave que será suministrada por el encargado del sistema.

El usuario debe de estar autentificado.

Fuente: Elaboración Propia

68

Tabla 8: Caso de Uso Listado y Clasificación de Requerimiento CU-003 Actores Descripción

Flujo de Eventos

Flujo Básico

Flujo Alternativo Pre condiciones Post condiciones Requerimientos Especiales

Listado y Clasificación de Requerimiento Usuario(Personal de la Entidad Municipal) El caso de estudio se inicia cuando un usuario desea listar y clasificar sus requerimientos realizados a la USI. 1.- El usuario listar y clasificar los requerimientos antes registrados en el sistema de la USI 2.- Abre el sistema y realiza inicio de sesión. 3.- Aparece el escritorio principal luego “Mis Requerimientos”. 4.- Los requerimientos consignados se pueden listar y clasificar por categoría de requerimiento, fecha e incluso por nombre. 5.- El sistema mostrará un formulario en el cual se deberá consignar la forma de listado y clasificación de los requerimientos. 6.- Se procederá a actualizar el sistema. No se realiza un flujo alternativo. El usuario debe de estar autentificado. Ninguna. El usuario deberá de tener usuario y clave que será suministrada por el encargado del sistema.

Fuente: Elaboración Propia

69

Tabla 9: Caso de Uso Visualizar Requerimiento CU-004

Visualizar Requerimientos

Actores

Usuario(Personal de la Entidad Municipal)

Descripción

El caso de estudio se inicia cuando un usuario desea ver los requerimientos que a solicitado a la USI.

Flujo

Flujo

de

Básico

Eventos

1.- El usuario desea visualizar los requerimientos hechos a la USI. 2.- Abre el sistema y realiza inicio de sesión. 3.- Aparece el escritorio principal luego “Mis Requerimientos”. 4.- El sistema mostrará todos los requerimientos ordenados por fecha de solicitud.

Flujo

No se realiza un flujo alternativo.

Alternativo Pre condiciones

El usuario debe de estar autentificado.

Post condiciones

Ninguna.

Requerimientos

El usuario deberá de tener usuario y clave que será

Especiales

suministrada por el encargado del sistema.

Fuente: Elaboración Propia

70

Tabla 10: Caso de Uso Registrar Soluciones y Requerimientos CU-005 Actores Descripción

Flujo de Evento s

Flujo Básico

Flujo Alternativo Pre condiciones

Registrar Soluciones a Requerimientos Soporte(Asistente Técnico y Practicantes de la USI) El caso de estudio se inicia cuando un actor soporte soluciona un requerimiento insertado por el actor usuario; este debe de tener un detalle el cual será el diagnóstico y la solución y/o recomendaciones al requerimiento realizado a la USI. 1.- El actor soporte deber de haber solucionado el requerimiento antes registrado por el actor usuario en el sistema de la USI. 2.- Abre el sistema y realiza inicio de sesión. 3.- Aparece el escritorio principal luego “Mis Soluciones”. 4.- Seleccionara el requerimiento a solucionar. 5.- El sistema mostrará un formulario en el cual se deberá consignar la solución y detalles al requerimiento solucionado. 6.- Se procederá a actualizar el sistema. No se realiza un flujo alternativo. El usuario debe de estar autentificado.

Post condiciones Requerimientos Especiales

Ninguna. El usuario deberá de tener usuario y clave que será suministrada por el encargado del sistema. Fuente: Elaboración Propia

71

Tabla 11: Caso de Uso Reporte de Requerimiento CU-006 Actores Descripción

Flujo de Evento s

Flujo Básico

Flujo Alternati vo Pre condiciones

Reportes de los requerimientos Soporte(Asistente Técnico y Practicantes de la USI) El caso de estudio se inicia cuando un actor soporte debe de extraer un reporte en físico del sistema para realizar algún trámite correspondiente; este debe de tener un detalle el cual será el diagnóstico y la solución y recomendaciones al requerimiento realizado a la USI. 1.- El actor Soporte debe solucionar el requerimiento en el sistema de la USI. 2.- Abre el sistema y realiza inicio de sesión. 3.- Aparece el escritorio principal luego “Mis Soluciones”. 4.- Seleccionará el requerimiento solucionado. 5.- El sistema deberá tener la opción de descargar un archivo en formato .pdf en el cual se encuentre el informe final del requerimiento solucionado. 6.- Se procederá a la impresión del mismo. No se realiza un flujo alternativo.

El usuario debe de estar autentificado.

Post condiciones Requerimientos Especiales

Ninguna. El usuario deberá de tener usuario y clave que será suministrada por el encargado del sistema. Fuente: Elaboración Propia

72

Tabla 12: Caso de Uso Creación de Usuarios, entre otros formularios CU-007 Actores Descripción Flujo de Eventos

Flujo Básico

Flujo Alternativo

Creación de Usuario, Tipos de Requerimientos, etc. Administrador (Jefe del Unidad de Soporte Informático) El caso de estudio se inicia cuando se deben crear nuevos usuario o tipos de requerimientos, etc. 1.- El actor administrador deber de tener las solicitudes de creación de nuevos usuario o tipos de requerimientos, entre otros; en el sistema de la USI. 2.- Abre el sistema y realiza inicio de sesión. 3.- Aparece el escritorio principal luego dependiendo de lo que desee registrar podrá desplegar menús diferentes tanto para la creación de usuario o tipos de requerimientos y demás. 4.- Seleccionara la opción a realizar en base a la situación planteada. 5.- El sistema mostrará un formulario en el cual se deberá consignar la información requerida para poder guardar los datos. 6.- Se procederá a actualizar el sistema. No se realiza un flujo alternativo.

Pre condiciones

El Usuario debe de estar autentificado.

Post condiciones Requerimientos Especiales

Ninguna. El usuario deberá de tener usuario y clave que será suministrada por el encargado del sistema.

Fuente: Elaboración Propia

73

Tabla 13: Caso de Uso Administrar el Sistema CU-008

Administrar el Sistema

Actores

Administrador(Jefe del Unidad de Soporte Informático)

Descripción

El caso de estudio se inicia cuando se deben administrar el sistema de forma completa.

Flujo

Flujo

de

Básico

1.- El actor administrador deber de tener la necesidad de querer administrar todos los

Eventos

niveles del sistema ya que esto permitirá que él pueda eliminar, modificar y cambiar cualquier aspecto del sistema. 2.- Abre el sistema y realiza inicio de sesión. 3.- Aparece

el

escritorio

principal

luego

dependiendo de lo que desee administrar se desplegaran menús diferentes. 4.- Seleccionara la opción a realizar en base a la situación planteada. 5.- El sistema mostrara un formulario en el cual se deberá consignar la información requerida para poder guardar los datos. 6.- Se procederá a actualizar el sistema. Flujo

No se realiza un flujo alternativo.

Alternativo Pre condiciones

El usuario debe de estar autentificado.

Post condiciones

Ninguna.

Requerimientos

El usuario deberá de tener usuario y clave que será

Especiales

suministrada por el encargado del sistema.

Fuente: Elaboración Propia

74

3.3.8. Diagrama de Secuencias Mensaje que debe atender el sistema en el desarrollo en función a actividad de casos de uso.

Figura 18: Diagrama de Secuencia – Administrador Fuente: Elaboración Propia

Figura 19: Diagrama de Secuencia – Soporte Fuente: Elaboración Propia

75

Figura 20: Diagrama de Secuencia – Usuario Fuente: Elaboración Propia

3.3.9. Diagrama de Clases Mostramos una vista de la aplicación de requerimientos informáticos usando el diagrama de clases, con las principales clases que usaran en el sistema con sus atributos, operaciones y las relaciones entre ella.

Figura 21: Diagrama de Clase Sistema de Requerimientos Informáticos Fuente: Elaboración Propia

76

3.4. Análisis del Sistema 3.4.1. Diseño Conceptual Con el análisis de la aplicación se tiene como resultado una estructura conceptual perfectamente definida, como es el diagrama Entidad – Relación para la base de datos, la que viene a ser un equivalente al diseño conceptual. El modelo conceptual es el diagrama que detalla el dominio del problema, es el artefacto más importante dentro del análisis de un sistema orientado a objetos.

Figura 22: Diseño Conceptual de la Base de Datos Fuente: Elaboración Propia

3.4.2. Diseño de Base de Datos En esta parte se considera las entidades y relaciones del modelo Entidad Relación (E-R) empleado en el diseño conceptual por lo cual obtenemos los diagramas Lógico y Físico del Sistema.

77

3.4.3. Modelo Lógico de la BD Presentamos Informáticos.

el

modelo

lógico

Figura 23: Modelo Lógico de la Base de Datos Fuente: Elaboración Propia

78

del

Sistema

de

Requerimientos

3.4.4. Modelo Físico de la BD Presentamos el modelo lógico del Sistema de Requerimientos Informáticos

Figura 24: Modelo Físico de la Base de Datos Fuente: Elaboración Propia

3.4.5. Diccionario de Datos Se realizará el diccionario de datos de la base de datos de Requerimientos Informáticos, las tablas intervenidas son las que a continuación se detallan:

79

a)

Tabla Requerimiento: Es donde se almacenan los requerimientos de los diferentes usuarios de la entidad municipal, es una de las tablas de gran importancia.

Tabla 14: Diccionario de Datos - Tabla Requerimiento Nombre de columna

Tipo de dato

Clave primaria

No null

Auto incremento

X

X

X

Valor por defecto

Id_requerimiento

Int(11)

Nombre_problema

Varchar(45)

X

Description

Longtext

X

Fecha

Date

Null

Hora

Time

Null

Estadoreq

Varchar(io)

'Pendiente'

Host_pc

Varchar(45)

Null

Id_anio

Int(11)

X

Idtiporequerimiento Idusuario

Int(11) Int(11)

X X

Fuente: Elaboración Propia

b)

Tabla Personal: Es donde se almacena el personal que labora en el área de TI, este a su vez solucionará los requerimientos insertados por los usuarios de la entidad municipal.

80

Tabla 15: Diccionario de Datos - Tabla Personal Nombre de columna

Tipo de dato

Clave primaria

No null

Auto incremento

X

X

X

Id_personal_ti

Int(11)

Nombres_personal_ti

Varchar(50)

X

Ape11idos_personal_ti

Varchar(50)

X

Estado_personal_ti

Varchar(11)

X

Imagen

Varchar(200)

X

Id_tipo_personal

Int(11)

X

Valor por defecto

'Activo'

Fuente: Elaboración Propia

c)

Tabla Solución Requerimiento: en donde se registran las diferentes soluciones insertadas por el personal que labora en la USI de la entidad municipal esta tabla se usada para poder emitir los reportes solicitados por los usuarios. Tabla 16: Diccionario de Datos - Tabla Solución de Requerimiento Nombre de columna

Tipo de dato

Clave primaria

No null

Auto incremento

X

X

Valor por defecto

Id_requerimiento

Int(11)

Id_personal_ti

Int(11)

Idestado

Int(11)

Diagnostico

Longtext

Null

Solucion_primaria

Mediumtext

Null

X

X X

Fuente: Elaboración Propia

81

d)

Tabla Usuario: en donde se encontrarán todos los usuarios que podrán ingresar al sistema; y en base a esta tabla se podrán realizar las

diferentes

inserciones,

ediciones

o

eliminaciones

de

requerimientos. Tabla 17: Diccionario de Datos - Tabla Usuario Nombre de columna

Tipo de dato

Clave primaria

No null

Auto incremento

X

X

X

Id_usuario

Int(11)

Nickname

Varchar(50)

X

Password

Varchar(50)

X

Nombres_usuario Ape11idosusuario

Varchar(ioo) Varchar(ioo)

X X

Dni

Varchar(8)

X

Estadousuario

Varchar(50)

Imagen

Varchar(200)

X

Idarea Id_tipo_usuario

Int(11) Int(11)

X X

Valor por defecto

‘activo'

X

Fuente: Elaboración Propia

e)

Tabla Año: en esta tabla se registraran los años, los cuales se iniciaran conforme vayan iniciando dichos años, y con el cual se podrán hacer las filtraciones de cantidad de requerimientos realizados por cada año.

82

Tabla 18: Diccionario de Datos - Tabla Año Nombre de columna

Tipo de dato

Id_anio

Int(11)

Anio

Varchar(4)

Clave primaria

No null

Auto incremento

X

X

X

Valor por defecto

X

Fuente: Elaboración Propia

f)

Tabla Estado: esta tabla está relacionada con la de soluciónrequerimiento el cual poseerá un estado el cual varía de acuerdo al personal que labora en la Unidad de Soporte Informático de la entidad municipal. Tabla 19: Diccionario de Datos - Tabla Estado Nombre de columna

Tipo de dato

Id_estado

Int(11)

Nombreestado

Varchar(20)

Clave primaria

No null

Auto incremento

X

X

X

Valor por defecto

X

Fuente: Elaboración Propia

g)

Tabla Área: esta tabla se encuentra relacionada con los usuarios ya que cada usuario creado es asignado a un área, desde el cual se identifica cada requerimiento insertado.

83

Tabla 20: Diccionario de Datos - Tabla Área Nombre de columna

Tipo de dato

Clave primaria

No null

Auto incremento

Idarea

Int(11)

X

X

X

Nombre_area

Xarchar( 150)

Valor por defecto

X

Fuente: Elaboración Propia

h)

Tabla Tipo Personal: esta tabla se encuentra asociada a la tabla de personal por la cual se le asigna un tipo de personal, este servirá para poder identificar un requerimiento y asignarle un personal con la

experiencia

necesaria

para

solucionar

un

determinado

requerimiento. Tabla 21: Diccionario de Datos - Tabla Tipo de Personal Nombre de columna

Tipo de dato

Id_tipo_per sonal

Int(11)

Nombre_tip o_personal

Varchar(5 0)

Clave primar ia

No null

Auto incremen to

X

X

X

X

Fuente: Elaboración Propia

84

Valor por defec to

i)

Tabla Tipo Requerimiento: esta tabla se encuentra vinculada con la de requerimientos, la cual genera un tipado de requerimientos el cual en lo posterior nos ayudará a visualizar los requerimientos por tipos pre establecido. Tabla 22: Diccionario de Datos - Tabla Tipo Requerimiento Nombre de columna

Tipo de dato

Clave primar ia

Idtiporequeri miento Nombre_tipo_ requerimiento

Int(11)

X

Varcha r( 100)

N o nu ll X

Auto incremen to

Valor por defec to

X

X

Fuente: Elaboración Propia

j)

Tabla Tipo Usuario: esta tabla se encuentra vinculada con la tabla de usuario ya que ayudará a poder determinar los niveles de acceso al sistema de requerimientos. Tabla 23: Diccionario de Datos - Tabla Tipo Usuario Nombre de columna

Idtipousuari o Nombre_tipo _usuario

Tipo de dato

Int(11)

Clave primari a

No nul l

Auto increment o

X

X

X

Varchar( 45)

Valor por defect o

Nu1 1

Fuente: Elaboración Propia

85

3.4.6. Diseño Navegacional El diseño navegacional es la principal parte de un sistema de información orientado a una interfaz Web. a)

Diseño Navegacional Administrador: Se presenta el esquema de clases de navegación para el administrador el cual tiene permiso para entrar a todos los módulos de administración mediante previa autentificación.

Figura 25: Diseño Navegacional Administrador Fuente: Elaboración Propia

b)

Diseño Navegacional Soporte: Se presenta el esquema de clases de navegación para el Soporte el cual tiene permiso para entrar a

86

algunos

módulos

de

administración

mediante

previa

autentificación.

Figura 26: Diseño Navegacional Soporte Fuente: Elaboración Propia

c)

Diseño Navegacional Usuario: Se presenta el esquema de clases de navegación para el Soporte el cual tiene permiso para entrar al módulo de requerimiento mediante previa autentificación.

87

Figura 27: Diseño Navegacional Usuario Fuente: Elaboración Propia

3.4.7. Diseño de Interfaz Abstracta En la fase de diseño de interfaz abstracta se define la interfaz de portal web y el sistema de administración de contenidos reconociendo los diferentes objetivos de la interfaz los cuales activaran vistas de datos u otros objetos de la interfaz además se verifican donde y cuando se realizaran las vistas o llamadas a otros objetos de la interfaz.

Figura 28: Diseño de Interfaz Abstracta Administrador Fuente: Elaboración Propia

88

Figura 29: Diseño de Interfaz Abstracta Soporte Fuente: Elaboración Propia

Figura 30: Diseño de Interfaz Abstracta Usuario Fuente: Elaboración Propia

89

3.4.8. ADV de la Aplicación Web del Usuario APLICACIÓN WEB DE REQUERIMIENTOS INFORMATICOS (USUARIO)

Ventana de Sesión Escritorio de Administración de Requerimientos Información del Requerimiento

Figura 31: ADV de la Aplicación Web de Usuario Fuente: Elaboración Propia

a)

ADV de descripción del Requerimiento ADV DESCRIPCION DEL REQUERIMIENTO

AÑO

USUARIO

ID_AÑO

NOMBRE_USUARIO

id_requerimiento nombre_problema description fecha hora estado_req host_pc

TIPO REQUERIMIENTO NOMBRE_TIPO_REQUERIMIENTO

Figura 32: ADV Descripción del Requerimiento Fuente: Elaboración Propia

90

b)

ADV’s de agregar Nuevo Requerimiento ADV AGREGAR NUEVO REQUERIMIENTO

Datos del Requerimiento: ========================== id_requerimiento nombre_problema description fecha hora

estado_req host_pc Nombre_usuario Nombre_tipo_requerimiento año

Figura 33: ADV's Agregar Nuevo Requerimiento Fuente: Elaboración Propia

Tabla 24: Tarjeta ADV Agregar Nuevo Requerimiento ADV Agregar Nuevo Requerimiento PARA Requerimiento

Hereda de: Ninguno

Atributos: id_requerimiento, nombre_problema, description, fecha, hora, estado_req, host_pc, nombre_usuario, nombre_tipo_requerimiento, año Partes: ADV’s, Tipo Requerimiento, Año, Usuario. Parte-de: No Servicios Ofrecidos: registro Servicios Requeridos: registro de usuarios, registro de año y registro de tipo de requerimiento. Comentarios: Es una parte importante del sistema. Rastro a Atrás: Ventana de bienvenida.

Rastro Para Adelante: ADV detalle del requerimiento

Fuente: Elaboración Propia

91

3.4.9. ADV de la Aplicación Web del Soporte

APLICACIÓN WEB DE REQUERIMIENTOS INFORMÁTICOS (SOPORTE)

Ventana de Sesión Escritorio de Administración Requerimiento Soluciones Usuarios Personal Estado Área Tipo de Requerimiento

Figura 34: ADV de la Aplicación Web de Soporte Fuente: Elaboración Propia

92

a)

ADV’s Agregar Solución

ADV AGREGAR NUEVO SOLUCION A REQUERIMIENTO

Datos de la Solución: ======================== id_requerimiento id_personal_ti Idestado Diagnostico solucion_primaria

Figura 35: ADV's Agregar Solución a Requerimiento Fuente: Elaboración Propia Tabla 25: Tarjeta ADV's Agregar Solución a Requerimiento

ADV Agregar Solucion a Requerimiento PARA Hereda de: Soluciones Ninguno Atributos: id_requerimiento, id_personal_ti, Idestado, Diagnostico, solucion_primaria. Partes: ADV’s, Requerimiento, Personal, Estado. Parte-de: No Servicios Ofrecidos: registro Servicios Requeridos: registro de requerimientos, registro de personal y registro de estado. Comentarios: Es una parte importante del sistema. Rastro a Atrás: Rastro Para Adelante: Ventana de ADV detalle del solución bienvenida. Fuente: Elaboración Propia

93

3.4.10. ADV de la Aplicación Web del Administrador APLICACIÓN WEB DE REQUERIMIENTOS INFORMÁTICOS (ADMINISTRADOR)

Ventana de Sesión Escritorio de Administración Requerimiento Soluciones Usuarios Personal Estado

Área Tipo de Requerimiento Tipo de Personal Tipo de Usuario Año

Figura 36: ADV de la Aplicación Web de Administrador Fuente: Elaboración Propia

94

a)

ADV’s Agregar un Nuevo Usuario ADV AGREGAR UN NUEVO USUARIO

Datos de la Usuario: ======================== id_usuario Nickname Password nombres_usuario Apellidosusuario DNI Estadousuario Imagen Idarea id_tipo_usuario Figura 37: ADV's Agregar Nuevo Usuario Fuente: Elaboración Propia

95

Tabla 26: Tarjeta ADV's Agregar Usuario Hereda de: ADV Agregar Usuario PARA Usuario Ninguno Atributos: id_usuario, Nickname, Password, nombres_usuario, Apellidosusuario, DNI, Estadousuario, Imagen, Idarea id_tipo_usuario. Partes: ADV’s, Area, Tipo Usuario. Parte-de: No Servicios Ofrecidos: registro Servicios Requeridos: registro de area, registro de tipo de usuario. Comentarios: Es una parte importante del sistema. Rastro a Atrás:

Rastro Para Adelante:

Ventana de bienvenida. ADV detalle del usuario

Fuente: Elaboración Propia

3.4.11. ADV de Inicio de Sesión Web

Figura 38: ADV de Inicio de Sesion Web Fuente: Elaboración Propia

96

Tabla 27: Tarjeta ADV's de Inicio de Sesion

Hereda de: ADV sesión PARA Ingresar al Sistema Ninguno Atributos: Nombre de usuario, Clave de acceso. Partes: Ninguno. Parte-de: ADV’s Sistema Web. Servicios Ofrecidos: Autentificación. Servicios Requeridos: No Comentarios: Es una parte fundamental del sistema. Rastro a Atrás:

Rastro Para Adelante:

Ninguno

ADV Escritorio Sistema de Requerimientos.

Fuente: Elaboración Propia

97

CAPÍTULO IV RESULTADOS DE LA PRÁCTICA REALIZADA 4.1. Administración del Sistema Informático 4.1.1. Inicio de Sesión al Sistema

Figura 39: Login de Acceso al Sistema Fuente: Elaboración Propia

4.1.2. Sección de Escritorio del Administrador

Figura 40: Escritorio de Acceso a Administrador Fuente: Elaboración Propia

4.1.3. Módulo de Creación de Usuarios

Figura 41: Módulo de Creación de Nuevos Usuarios Fuente: Elaboración Propia

97

4.1.4. Sección de Escritorio del Soporte

Figura 42: Escritorio de Acceso Soporte Fuente: Elaboración Propia

4.1.5. Módulo de Creación de Soluciones

Figura 43: Módulo de Creación de Soluciones Fuente: Elaboración Propia

98

4.1.6. Sección de Escritorio del Usuario

Figura 44: Escritorio de Acceso Usuario Fuente: Elaboración Propia

4.1.7. Módulo de Creación de Requerimientos

Figura 45: Módulo de Creación de Requerimiento Fuente: Elaboración Propia

99

CAPÍTULO V CONCLUSIONES Y SUGERENCIAS 5.1. Conclusiones 5.1.1. Conclusiones de las prácticas pre-profesionales  Se aplicaron los conocimientos adquiridos durante los cinco años en la casa superior de estudios (Universidad Nacional Jorge Basadre Grohmann), los cuales permitieron el desarrollo laboral exitoso en la Municipalidad Distrital de Pocollay.  El uso de tecnologías para el modelado de Datos, desarrollo, análisis, diseño, implementación es la parte crucial para culminación con éxito del sistema, en nuestro caso se optó por UML, OOHDM y la POO. Lo cual son excelentes para cubrir todas nuestras necesidades en el desarrollo del sistema.  Se adquirió experiencia laboral durante el periodo de prácticas preprofesionales, que será útil durante el desarrollo laboral profesional.  El uso de Aplicaciones Web, desarrollo e implementación es la forma innovadora de desarrollo de aplicaciones, es más flexible, económica, factible de forma operacional como técnica, y tener una aplicación web puede ser vista, administrada, trabajada de cualquier parte del globo que

tenga uso de Internet, esto lo hace una herramienta infalible para cualquier desarrollador que programe en Web.  Las tecnologías web es una ayuda excelente para responder a los requerimientos de los usuarios, instituciones, organizaciones, etc. El uso de PHP, en nuestro caso el gestor de BD es MySQL por todas sus virtudes es la que usamos. 5.1.2. Conclusiones del proyecto  Se logró optimizar el uso de recursos y llevar un registro de las diferentes actividades por la unidad al implantar la Aplicación Web “Sistema de Requerimientos Informáticos”.  Se automatizó el proceso de emisión de informes técnicos de los requerimientos por la Intranet,

usando

la

Aplicación

Web

como

herramienta efectiva.  Se realizó un análisis de cómo es que está funcionando actualmente el control de requerimientos informáticos, se empezó recabando los requerimientos para el sistema, con los cuales se empezó a realizar el modelado respectivo  El sistema de requerimientos informáticos fue desarrollado básicamente en PHP y MySQL, contiene una sesión de usuario, soporte y administrador, totalmente separados, es flexible el sistema y practico, lo cual facilita la modificación de código en cualquier momento.

101

5.2. Sugerencias  Para el desarrollo de cualquier Aplicación Web,

es muy importante

conocer el giro de negocio de lo que se desea automatizar, así como interactuar con los usuarios finales ante cualquier duda que aparezca, para así capturar la mayor cantidad de requisitos y poder desarrollar una Aplicación Web que satisfaga las necesidades de los usuarios finales.  Se sugiere el uso para el desarrollador, de solo software libre para evitar inconvenientes en el uso de licencias, para ahorrar dinero a la empresa y ser más competitivos en el ámbito laboral y poder desenvolvernos sin resistencia por motivos de software licenciado.  Se sugiere siempre estar al día, en cuanto a la aparición de nuevas tecnologías, para poner aprovecharlas, así innovar cada día en cuanto a desarrollo, como ahora en el mundo toda aplicación está siendo llevado a Web y a este paso en el futuro todo se trabajara en la Red (internet).

102

CAPÍTULO VI

BIBLIOGRAFÍA

Addison-Wesley. (2012). Analisis y dieño POO con aplicaciones. Castaño. (1995). community, P. (2013). PHP.net. Obtenido de “http://www.php.net/manual/es/intro-whatcando.php” Hawryszkiewycz. (1994). Analisis y Diseño de Base de Datos 1er Edicion. Jacobson, B. (1999). Rumbaugh. James, S. (2002). Analisis y Diseño de Sistemas de Información. McGraw-Hill. Kendall, K. y. (1991). Analisis y Diseño de Sistemas 1er Edicion. Maeda, S. M. (2009). Analisis y diseño Orientado a Objetos con UML y Rational Rose. mysql.com. (30 de Junio de 2016). Obtenido de http://www.mysql.com/about Pressman. (1999). Concepto de aplicacion web. Schmuller, J. (s.f.). Aprendiendo UML en 24 horas. Stair, R. (2000). Principios de Sistemas de Informacion: Enfoque Administrativo. Villar, J. d. (2011). PHP y MySQL.