UNVERSIDAD FRANCISCO DE PAULA SANTANDER BIBLIOTECA EDUARDO COTE LAMUS RESUMEN TESIS DE GRADO AUTOR (ES): NOMBRE (S):

EDINSON GIOVANNY NOMBRE (S): FACULTAD: INGENIERA PLAN DE ESTUDIOS: INGENIERA DE SISTEMAS DIRECTOR: NOMBRE (S): JUDITH DEL PILAR APELLIDOS: RODRIGUEZ TENJO

APELLIDOS: MORALES MANTILLA APELLIDOS:

TITULO DE LA TESIS: DESARROLLO DE UN PORTAL WEB COMO HERRAMIENTA DE BSQUEDA DE OFERTAS LABORALES PARA LA UNIVERSIDAD FRANCISCO DE PAULA SANTANDER RESUMEN: Se desarroll un portal de tipo Corporativo, permitiendo a las distintas personas vinculadas con la Universidad Francisco de Paula Santander contar con herramientas para buscar, ingresar y obtener informacin referente a perfiles educativos y puestos laborales disponibles que hayan a su vez sido previamente ingresados por el portal. As mismo, se desarroll el portal, para uso general de la comunidad universitaria (alumnos, egresados), permitiendo el ingreso de hojas de vida, manteniendo una base de datos para la consulta de estudiantes, docentes, directivos o cualquier empresa formal. Por ltimo, se implement la tecnologa Web, permitiendo el ingreso de las hojas de vida de la comunidad estudiantil desde cualquier parte y que estas a su vez sean consultadas por cualquier empresa del mundo.

CARACTERSTICAS: PAGINAS: 180 PLANOS: ILUSTRACIONES: CD-ROM: 1

DESARROLLO DE UN PORTAL WEB COMO HERRAMIENTA DE BSQUEDA DE OFERTAS LABORALES PARA LA UNIVERSIDAD FRANCISCO DE PAULA SANTANDER

EDINSON GIOVANNY MORALES MANTILLA

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER FACULTAD DE INGENIERIA PLAN DE ESTUDIOS DE INGENIERA DE SISTEMAS SAN JOS DE CCUTA 2010

DESARROLLO DE UN PORTAL WEB COMO HERRAMIENTA DE BSQUEDA DE OFERTAS LABORALES PARA LA UNIVERSIDAD FRANCISCO DE PAULA SANTANDER

EDINSON GIOVANNY MORALES MANTILLA

Trabajo de grado presentado como requisito para optar al ttulo de: Ingeniero de Sistemas

Director: JUDITH DEL PILAR RODRGUEZ TENJO Ingeniero de Sistemas

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER FACULTAD DE INGENIERIA PLAN DE ESTUDIOS DE INGENIERA DE SISTEMAS SAN JOS DE CCUTA 2010

CONTENIDO pg. INTRODUCCION 1. GENERALIDADES 1.1 LIMITACIONES 2. ANALISIS DE REQUISITOS APLICANDO LA TECNICA NDT EN LA METODOLOGIA OOHDM 2.1 MODELOS DE LA INGENIERA DE REQUISITOS CON NDT 11 13 14

18 18

2.2 IDENTIFICAR Y DEFINIR LOS REQUISITOS DE ALMACENAMIENTO DE INFORMACIN 29 3. DISEO DE LA APLICACIN UTILIZANDO LA METODOLOGA OOHDM 3.1 DISEO CONCEPTUAL 3.2 DISEO NAVEGACIONAL 3.3 DISEO DE INTERFAZ ABSTRACTA 4. CONCLUSIONES 5. RECOMENDACIONES BIBLIOGRAFA ANEXOS

54 56 66 69 72 73 74 75

LISTA DE CUADROS pg. Cuadro 1. Tratamiento de la navegacin en cada fase de cada metodologa Cuadro 2. Fases, actividades y tareas de NDT Cuadro 3. Patrn para la definicin de los objetivos Cuadro 4. Objetivo OBJ-01 Cuadro 5. Objetivo OBJ-02 Cuadro 6. Objetivo OBJ-03 Cuadro 7. Objetivo OBJ-04 Cuadro 8. Objetivo OBJ-05 Cuadro 9. Objetivo OBJ-06 Cuadro 10. Objetivo OBJ-06 Cuadro 11. Requisito RA-01 Cuadro 12. Requisito RA-02 Cuadro 13. Requisito RA-03 Cuadro 14. Requisito RA-04 Cuadro 15. Naturaleza NA-01 Cuadro 16. Naturaleza NA-02 Cuadro 17. Naturaleza NA-03 Cuadro 18. Requisito RA-05 Cuadro 19. Requisito RA-06 Cuadro 20. Patrn para la definicin de actores

18 19 25 25 26 26 27 27 28 28 29 30 31 31 33 34 34 35 36 36

Cuadro 21. Actor AC-01 Cuadro 22. Actor AC-02 Cuadro 23. Actor AC-03 Cuadro 24. Actor AC-04 Cuadro 25. Actor AC-05 Cuadro 26. Actor AC-06 Cuadro 27. Matriz de descripcin de la incompatibilidad de actores Cuadro 28. Ejemplo de requisito funcional Cuadro 29. Requisito RF-01 Cuadro 30. Requisito RF-02 Cuadro 31. Requisito RF-03 Cuadro 32. Requisito RF-04 Cuadro 33. Requisito RF-05 Cuadro 34. Requisito RF-06 Cuadro 35. Frase FR-01 Cuadro 36. Frase FR-02 Cuadro 37. Prototipo de visualizacin PV-01 Cuadro 38. Prototipo de visualizacin PV-02 Cuadro 39. Prototipo de visualizacin PV-03 Cuadro 40. Requisito no funcional RNF-01 Cuadro 41. Requisito no funcional RNF-02 Cuadro 42. Requisito no funcional RNF-03 Cuadro 43. Matriz de rastreabilidad Cuadro 44. Fases, actividades y tareas de NDT
7

37 37 38 39 39 40 40 41 42 42 43 43 44 44 45 46 47 48 49 50 50 51 51 52

Cuadro 45. Comparacin de las 3 fases de NDT y OOHDM LISTA DE FIGURAS

53

pg. Figura 1. Modelo de generalizacin de actores Figura 2. Patrn de un actor y su interaccin con el sistema Figura 3. Diagrama de clases navegante Figura 4. Diagrama de clases hojas de vida Figura 5. Diagrama de clases solicitud Figura 6. Diagrama de clases completo Figura 7. Diagrama de secuencias entrar a portal Figura 8. Diagrama de secuencia iniciar sesin Figura 9. Diagrama de secuencia navegar Figura 10. Diagrama de secuencia insertar datos Figura 11. Diagrama de secuencia editar datos Figura 12. Diagrama de secuencia eliminar datos Figura 13. Diagrama de secuencia buscar datos Figura 14. Diagrama de secuencia cerrar sesin Figura 15. Diagrama navegacional navegante interno Figura 16. Diagrama navegacional director plan de estudios Figura 17. Bsqueda estudiante o egresado por parte del navegante externo 38 41 57 58 59 60 61 62 62 63 64 64 65 66 67 68 68

Figura 18. Bsqueda de empresa por parte del navegante estudiante y navegante egresado 68 Figura 19. Diagrama de interfaz abstracta principal modelo grafico
8

69

Figura 20. Diagrama de interfaz abstracta ingresar-modificar-eliminar 70 Figura 21. Diagrama de interfaz abstracta bsqueda modelo grafico Figura 22. Diagrama de interfaz abstracta bsqueda detalle modelo grafico 70 71

Figura 23. Diagrama de interfaz abstracta bsqueda navegante director plan de estudios modelo grafico 71

LISTA DE ANEXOS pg. Anexo A. Implementacin Anexo B. Arquitectura Anexo C. Pruebas Anexo D. A1 Tcnica desarrollo navegacional NDT y sus patrones 76 89 99 109

10

INTRODUCCION El trabajo en trminos lingsticos se refiere a Esfuerzo humano aplicado a la produccin de riqueza, en contraposicin a capital; Lo que nos hace ver que el ser humano es motivado a trabajar por la necesidad de conseguir capital, pero cuando un ser humano ha dedicado tiempo de su vida a labrar una carrera sus motivaciones no son solo capitalistas, sino personales como el logro de sueos mayores, sociales porque quiere construir una mejor forma de vida a su alrededor e intelectuales porque sabe que su conocimiento lo llevara a ocupar espacios dignos dentro de una comunidad. Estas motivaciones son con frecuencia y en alto porcentaje limitadas para algunos seres, ya que una de las caractersticas de los pases en va de desarrollo es el alto ndice de desempleo y los bajos salarios, entonces surge una problemtica de la que la Universidad no se debe enajenar, Cmo garantizar la ubicacin de mis egresados en puestos de trabajo? La Internet en la actualidad se ha convertido en un medio de comunicacin indispensable para el acceso e intercambio de informacin, lo cual debe ser aprovechado para satisfacer las necesidades que van surgiendo en la sociedad, ella se ha convertido en un medio que facilita al ser humano el logro de objetivos con mayor rapidez, gracias al gran contenido de informacin y servicios que de ella se desprenden. La Universidad Francisco de Paula Santander UFPS no se ha alejado de esta realidad y en pro del continuo cambio ha venido integrando sus procesos a sistemas en red no solo en la parte administrativa sino tambin acadmica. La realizacin del siguiente proyecto permite integrar dentro de la UFPS un sistema que permita a la comunidad universitaria usar la Internet como un medio para incluir toda la informacin relevante que sea de inters a diversas empresas que deseen contar con el material intelectual que se forja en la Universidad. Se plantea as una solucin a los integrantes de la UFPS, para que sean fcilmente ubicados de acuerdo a su perfil acadmico por empresas de cualquier parte ya que la informacin se consultar mediante un ambiente Web. La importancia de esta implantacin tiene connotaciones de gran alcance ya que la UFPS ubicar sus profesionales no solo dentro de la regin Nortesantandereana, sino podr darse el caso de vnculos con empresas de cualquier parte del mundo.
11

Este proyecto surge de la necesidad de crear un canal ms eficiente entre la industria y la comunidad universitaria de la Universidad Francisco de Paula Santander que desea un posicionamiento laboral. A su vez se ha visto en la Industria el planteamiento ofrecerle una nueva forma de realizar la bsqueda de personal con una herramienta tecnolgica de acceso libre y gratuito que le permitir clasificar de manera ms exacta el perfil del personal que esta requiere. Los portales de enlace laboral o bolsas de empleo montados en plataformas Web y gestionados por sistemas manejadores de base de datos solucionan en gran medida el desempleo de este pas, ya que en diversas ocasiones se ve en medios impresos tradicionales de comunicacin anuncios de empresas solicitando gran cantidad de profesionales, pero por otro lado las cifras de desempleo no bajan, esto debido a que no existe una correlacin o un canal que permita a la empresa encontrar el perfil buscado ni a la persona con ese perfil encontrar la empresa que lo esta requiriendo, la tecnologa de la Internet permite que estas falencias sean superadas, es esa una razn suficiente para integrar en la Universidad Francisco de Paula Santander un sistema que permita generar dicho canal entre industria y academia.

12

1. GENERALIDADES Es comn encontrar en la sociedad o dentro de nuestra universidad alumnos talentosos o con altos conocimientos en diversas reas que luego en el futuro se convierten en egresados que no se ubican en un puesto profesional acorde a sus estudios o simplemente no encuentran un puesto. Tambin es claro que en ocasiones las empresas desean emprender diversos proyectos y desean contar con la colaboracin de alumnos de pre-grado que hayan avanzado sus estudios en niveles medio o avanzado, pero la falta de una herramienta que le permita a las facultades o planes de estudio tener conocimiento sobre las actuales habilidades de sus alumnos no permite que exista un verdadero enlace entre la industria y la academia. En el sector industrial esto tambin se ha convertido en un problema porque el no contar con las herramientas que le permitan ubicar el talento humano requerido a sus condiciones hace que la industria de nivel regional tenga la necesidad de usar otros mtodos de reclutamiento de personal o de buscar en otras partes, cuando este puede estar formado dentro de nuestro claustro. Existen casos en los que la industria no cuenta con la Universidad para su desarrollo por el desconocimiento del talento que se forma dentro de la Universidad Francisco de Paula Santander, y en un mundo tan competitivo como el actual es indispensable proporcionar a la industria las facilidades suficientes que permitan ubicar mas integrantes de esta comunidad universitaria frente a otras universidades, elevando el prestigio de la academia UFPS. La idea de desarrollar un portal como herramienta de busqueda de ofertas laborales para la universidad francisco de paula santander viene tomada del portal que tiene el SENA del servicio que este presta a nivel nacional y de el uso que varios colombianos le han dadoa dicho portal, Es cuando surge la inquietud, si el SENA cuenta con esta herramienta, deberia la UFPS tambien contar con dicha herramienta? El segundo paso consisti en formular la idea a un Docente de la UFPS para que con su experiencia y su conocimiento interno de la institucin viera como realizable dicho proyecto y aceptase la direccin del proyecto, se plantea en ese instante la interrogante de cmo validar la existencia de las empresas que se registren en el portal, por lo cual para darle solucin habra que acudir a realizar
13

una conexin con las bases de datos de la cmara de comercio, situacin que merece un convenio interinsitucional sobre el manejo, privacidad y exclusividad de la informacin que se consulte, lo cual esta fuera del alcance de este proyecto, por lo cual se decide pedir el mximo de informacin posible a la empresa en su registro a fin de que toda persona que se interese por una vacante pueda constatar por medio fsico en papel, telefnicamente y residencialmente de que empresa se trata. Como un apoyo adicional a este proyecto se cont con una participacin de la Oficina del egresado en cuanto al tipo de informacin que all manejan, el proceder y apoyo que tiene con el egresado, adicional a esto se buscara el apoyo de Bienestar universitario para mejoras en el proceso, interaccin del portal y otras tareas similares. 1.1 LIMITACIONES La informacin por defecto que tendr cada integrante de la comunidad universitaria es con la que cuenta la Divisin de Admisiones y Registro y Recurso Humano en sus bases de datos-SIA. Para proyectar eficazmente el sistema es necesario adelantar una campaa interna publicitaria en la universidad con una divisin como Bienestar Universitario, Consejo estudiantil, el diario universitario o alguna otra que tenga dentro de sus objetivos el apoyo en esas acciones al estudiante. Por parte del sector privado se hace necesario solicitar vinculacin de agremiaciones regionales como Acopi, FENALCO y Cmara de Comercio, para que proporcionen un espacio publicitario o de reconocimiento dentro de los medios que estas entidades usan para comunicarse con sus afiliados a fin de que conozcan una nueva opcin de contratacin laboral, para esto se hace indispensable presentar por intermedio de la UFPS la respectiva solicitud. La validacin de empresas en cuanto a su existencia tambin es una limitante, habra que manejar junto con la cmara de comercio o DIAN mediante el cdigo RUT, la existencia de las mismas, esto implica una conexin a sus bases de datos que permita la opcin de consulta, por lo que debera existir un permiso el cual debe ser gestionado por intermedio de la universidad, el cual podra no otorgarse para este proyecto.
14

La opcin de notificacin mediante mensaje de texto depende de una plataforma tecnolgica con la cual la universidad no cuenta, pero que se puede adquirir mediante alquiler del servicio a empresas privadas, adems debe la universidad como entidad responsable del servicio concertar las polticas del servicio SMS con las operadoras de telefona celular nacional disponibles. Debido a que es necesario que la aplicacin sea interactiva, es decir, que la informacin pueda ser modificada en tiempo de ejecucin, los lenguajes a trabajar sern: HTML, DHTML, XHTML, MYSQL y PHP. El diseo del Portal abarcar las siguientes especificaciones: Usuarios: Navegante. Es cualquier persona que ingresa al portal. Dependiendo del tipo de acciones que desee realizar, el navegante se clasificara en NAVEGANTE EXTERNO y NAVEGANTE INTERNO, de modo que se presenta una especializacin en dos actores. Navegante Interno. Es una persona vinculada a la Universidad como ESTUDIANTE, EGRESADO, DOCENTE o DIRECTIVO. Tambin puede ser una persona con cargo ADMINISTRATIVO que labore como administrador del sistema. Estudiantes. Alumnos de pre-grado o post-grado matriculados en la UFPS Egresados. Ex alumnos de pre-grado que hayan obtenido su respectivo titulo profesional en la UFPS. Docentes. Cualquier persona contratada para el semestre vigente en cualquiera de las categoras docentes. Directivo. Persona que sea Director de Plan de Estudios, Jefe de Departamento, Decano de Facultad. Administrador. Personal de la universidad al que se le delegue alguna funcin
15

administrativa sobre el sistema. Navegante Externo. Es una Empresa, entidad o persona jurdica, debidamente registrada en el sistema. Se desea integrar este sistema al sitio oficial de la UFPS, www.ufps.edu.co, en forma de vnculo. La popularidad y buen uso del sistema esta proyectado a tres aos, tiempo suficiente para que el sistema sea bien reconocido por la comunidad universitaria y el sector privado, adems de ser el tiempo en que muchos alumnos se convertirn en egresados popularizando aun mas el sistema fuera del claustro Informacin. La toma de datos bsicos, perfiles profesionales, ocupacionales y humanos, de las personas y los datos comerciales de las empresas, son diseados en base a los diversos sistemas que ya existen en Internet y tienen gran reconocimiento como: colombianostrabajando.com, elempleo.com y csgc.gov.co, los datos ms prescindibles que se deben tener en cuenta son: Datos personales, los cuales se tomaran en gran parte del SIA (Divisin de Admisiones y Registro UFPS). Datos sobre estudios de Secundaria, donde se ingresara el ao de graduacin, la institucin y tiempo de estudio. Datos sobre conocimientos en Idiomas, donde se incluir el Idioma, lugar donde lo aprendi, el dialecto y el nivel de habla, lectura y escritura. Datos sobre otras carreras realizadas, universidad o instituto donde la curso, ao, numero de semestres cursados. Datos legales de las empresas, telfonos, persona encargada, nit y rut, direccin comercial y lugar de establecimiento. Datos actuales a nivel universitario, semestre actual, materias destacadas,
16

materias actualmente matriculadas. Servicios. Envo y recepcin de formularios y mensajes, que contienen la informacin anteriormente enunciada, en formatos estndares para aplicaciones web. El portal proporcionara el intercambio de mensajes entre las empresas debidamente inscritas y las personas que cumplan con los perfiles solicitados por dichas empresas. El portal proporcionara una respuesta por e-mail o mensaje de texto a la persona y empresa cuando se encuentre correspondencia en una opcin laboral. El portal permitir hacer a los directores de planes de estudio consultas que les permitan obtener informacin sobre el nivel educacional de sus alumnos y los tipos de empresas que requieren personal.

17

2. ANALISIS DE REQUISITOS APLICANDO LA TECNICA NDT EN LA METODOLOGIA OOHDM 2.1 MODELOS DE LA INGENIERA DE REQUISITOS CON NDT La metodologa a usarse en el desarrollo de este proyecto es OOHDM-Mtodo de Diseo Hipermedia Orientado a Objetos pero haciendo una evaluacin de esta metodologa se ve una poca profundizacin en la etapa de Requisitos El siguiente cuadro, muestra las diferentes propuestas metodolgicas de desarrollo de aplicaciones Web y las distintas fases que se manejan. Se ve claramente que OOHDM presenta una debilidad en la Fase de Requisitos. Cuadro 1. Tratamiento de la navegacin en cada fase de cada metodologa

Por lo tanto para la obtencin de los requerimientos se usara el mtodo navegacional NDT (Navigational Development Techniques). Se hace necesario usar esta tcnica ya que solo contar con la metodologa OOHDM no es insuficiente para lograr un buen desarrollo de la aplicacin El siguiente cuadro, muestra el contenido de las diferentes fases, actividades y tareas que deben tenerse en cuanta al trabajar en NDT.

18

Cuadro 2. Fases, actividades y tareas de NDT

Fuente: STALLINGS William. Comunicacin y redes de computadores: Mxico: Prentice Hall, 1995. NDT es una propuesta metodolgica compuesta por un proceso en el que se plantean tcnicas para capturar, describir y validar los requisitos de un sistema web y, partiendo de esos requisitos, generar de manera sistemtica los modelos de anlisis del sistema. Para NDT el desarrollo es un proceso que se podra definir como bottom-up. Centrndose en una detallada fase de ingeniera de requisitos guiada por objetivos, que contempla tanto la captura, como la definicin y la verificacin de los requisitos.
19

El ciclo comienza definiendo los objetivos y en base a stos se describe un proceso por el que se pueden capturar y definir los diferentes requisitos del sistema. stos son clasificados y tratados dependiendo de la tipologa a la que pertenezca. NDT divide los requisitos en: Requisitos de almacenamiento de informacin, contiene la descripcin de la informacin que maneja el sistema y especifica su estructura y significado. Requisitos de actores, en los que se definen los roles que podrn interactuar con el sistema y las relaciones que se pueden producir entre ellos. Requisitos funcionales, que permitirn definir la funcionalidad del sistema. Requisitos de interaccin, que definen la estructura de navegacin a alto nivel del sistema, as como los criterios de recuperacin que se van a ofrecer a los diferentes actores. Requisitos no funcionales, que recogen otros requisitos del sistema. Una vez validados estos requisitos, el proceso de NDT propone generar tres modelos: Modelo conceptual, que representa mediante un diagrama de clases la estructura esttica del sistema; Modelo de navegacin, que representa mediante un conjunto de diagramas con una notacin muy similar a la del diagrama de clases la forma en que se podr navegar en el sistema; Validacin de Prototipos, que mediante un conjunto de prototipos evaluables, permite mostrar cmo se va a interactuar con el sistema. Estos tres (3) modelos son semejantes o iguales a las fases definidas por OOHDM. Ms adelante en la definicin de OOHDM Se vera con mayor amplitud.
20

Ya de manera especifica se puede encontrar que los requisitos se pueden dividir en actividades, estas actividades son las que me van registrando los verdaderos requisitos del sistema, para poder lograr una actividad es necesario ir cumpliendo de manera secuencial unas tareas, a continuacin el listado de actividades y tareas necesarias para cumplir con el desarrollo de cada requisito. Requisitos de almacenamiento de informacin. informacin sobre el entorno de trabajo y definir objetivos: Actividad 1-Obtener

Tarea 1.1- Obtener informacin sobre el dominio del problema. Tarea 1.2- Preparar y realizar las reuniones y entrevistas. Tarea 1.3- Identificar y definir los objetivos del sistema. Actividad 2- Identificar y definir los requisitos de almacenamiento de informacin. Tarea 2.1- Identificar y definir los requisitos de almacenamiento de informacin. Tarea 2.2-Identificar y definir las nuevas naturalezas. Modelo de requisitos de actores. Actividad 3- Identificar y definir los actores: Tarea 3.1- Identificar y definir a los actores bsicos del sistema. Tarea 3.2- Identificar y definir la generalizacin de actores. Tarea 3.3- Identificar y definir la incompatibilidad entre actores. Modelo de requisitos funcionales. Actividad 4- Identificar y definir los requisitos funcionales:

21

Tarea 4.1- Disear los diagramas de casos de uso. Modelo de requisitos de interaccin. Actividad 5- Identificar y definir los requisitos de interaccin: Tarea 5.1- Identificar y definir las frases. Tarea 5.2- Identificar y definir los prototipos de visualizacin. Modelo de requisitos no funcionales. Actividad 6- Identificar y definir los requisitos no funcionales: Tarea 6.1- Identificar y definir los requisitos no funcionales. Actividad 7- Validar los requisitos. Tarea 7.1- Realizar la matriz de rastreabilidad. Se vera el desarrollo de cada una de estos requisitos con los datos de nuestro sistema, la descripcin tcnica y las tablas empleadas se pueden consultar en el anexo A. Requisitos de almacenamiento de informacin. Definen qu informacin se va a manejar en el sistema y cmo se relacionan entre s. Actividad 1 Obtener informacin sobre el entorno de trabajo y definir objetivos. Tarea 1.1 Obtener informacin sobre el dominio del problema. Para obtener la informacin sobre el dominio del problema se hace necesario revisar el funcionamiento de portales similares al desarrollar en este proyecto, para lograr una idea de cmo seria la construccin de este portal para la UFPS. Inicialmente se tom los diferentes formularios para ingresar la informacin y su distribucin. Los formularios ms importantes encontrados fueron:
22

Datos Bsicos. Informacin Acadmica. Informacin Acadmica Adicional (Cursos, Talleres, Seminarios). Experiencia Laboral. Otros Datos. Tambin se identificaron los interesados: Estudiantes. Egresados. Oficina del Egresado. Jefes de plan de estudios. Empresas. Tarea 1.2 Preparar y realizar las reuniones y entrevistas. Aqu se detallan o se amplan los puntos de vista. Se desea que el sistema pueda en primera instancia el mxime de informacin til en cuanto a estudiantes o egresados, para lograr la efectividad en el reclutamiento. Caractersticas naturales como datos personales y datos de contacto, Datos sobre estudios de pre-grado inclusive de post-grado ya que se puede dar el caso que un actual estudiante ya tenga una carrera terminada o un post-grado, datos sobre actitudes como los cursos realizados, congresos entre otros, datos laborales como experiencias de trabajo y logros. Sobre las empresas interesa obtener los datos bsicos, los perfiles solicitados, y un histrico de las solicitudes ingresadas.
23

El primer paso de la investigacin se hizo a travs de charlas con compaeros de estudio, con preguntas simples como Le parece buena la idea de desarrollar un portal Web donde usted ingrese su hoja de vida y las empresas lo puedan contactar para un trabajo o una practica empresarial?, estas charlas ayudan a ver los gestos de la gente, y si el tema es o no es interesante. Se concluye que en la mayora de la gente hubo buena aceptacin y tambin se escucharon nuevas ideas que los otros portales no tenan. Estudiantes: Desean que el sistema les permita contactarse con trabajos formales que se acomoden a sus conocimientos, tiempo e interaccin estudiotrabajo. Egresados: Contactarse de manera ms amplia y ser escogidos en la menor brevedad por empresas regionales o exteriores. Oficina del egresado: Contar con una herramienta en la que se puedan consultar las hojas de vida, lograr una mayor efectividad contactando egresados con las empresas, las cuales ya frecuentan esta oficina para adquirir talento UFPS. Jefes de planes de estudio: Poder enviar a los estudiantes ms adecuados a las distintas pasantas, prcticas empresariales las cuales siempre toman un tiempo amplio en la recepcin de hojas de vida y su estudio. Empresas: Lograr encontrar Obtener respuesta de las personas que cumplen con el perfil solicitado de una manera inmediata y sin ningn costo para ellas. Tarea 1.3 Identificar y definir los objetivos del sistema. El estudio de estos objetivos es esencial para todo el desarrollo del flujo de trabajo. A medida que se va desarrollando la especificacin de requisitos, los objetivos se pueden ir refinando y concretando de manera que cada vez se vayan identificando mejor los requisitos del sistema. Un requisito no es ms que una necesidad que el sistema debe cubrir para poder alcanzar uno o varios objetivos impuestos por el usuario. Nota: El desarrollo de este y los patrones subsecuentes correspondientes al desarrollo del problema se encuentran en el anexo A. A continuacin se presenta el modelo usado para la recoleccin de los objetivos del sistema, los campos con (*) son opcionales.
24

Cuadro 3. Patrn para la definicin de los objetivos

Aqu, en base al patrn anteriormente mostrado se desarrolla el primer objetivo, que permitir la creacin de hojas de vida. Cuadro 4. Objetivo OBJ-01
OBJ-01 Autor Fuentes Descripcin OFRECER LA CREACIN DE HOJAS DE VIDA Nombre Autor: Edinson Giovanny Morales Cargo: Estudiante Organizacin: UFPS Nombre Fuente: Oficina del Egresado Organizacin: UFPS El sistema deber permitir a los integrantes de la UFPS describir los elementos de su perfil y generar una hoja de vida que se ajuste a sus perspectivas de trabajo. Esta hoja de vida podr luego ser consultada por las empresas interesadas en dicho perfil. Alta Normal Pendiente de Validacin

Subobjetivo Importancia Urgencia Estado

25

Este cuadro representa el objetivo OBJ-02 el cual le permite a empresas crear las solicitudes de trabajo que desean. Cuadro 5. Objetivo OBJ-02
OBJ-02 Autor Fuentes Descripcin Subobjetivo Importancia Urgencia Estado OFRECER LA CREACIN DE SOLICITUDES DE PUESTOS DE TRABAJO Nombre Autor: Edinson Giovanny Morales Cargo: Estudiante Organizacin: UFPS Nombre Fuente: Oficina del Egresado Organizacin: UFPS El sistema deber permitir a las entidades legalmente constituidas generar solicitudes de puesto de trabajo que estn necesitando, para ello describen las actitudes y formaciones requeridas para cubrir este puesto de trabajo. Alta Normal Pendiente de Validacin

Este cuadro muestra el objetivo OBJ-03 el cual tiene en cuenta el perfil del usuario para poderlo adaptar a sus necesidades. Cuadro 6. Objetivo OBJ-03
OBJ-03 Autor Fuentes Descripcin ADECUAR EL SISTEMA AL PERFIL DE USUARIO Nombre Autor: Edinson Giovanny Morales Cargo: Estudiante Organizacin: UFPS Nombre Fuente: Oficina del Egresado Organizacin: UFPS El sistema debe ser capaz de adaptarse al perfil del usuario con el cual se ingresa al portal. Cuando el usuario se identifica, se tratar como un navegante interno (estudiante, egresado, administrador, profesor) o externo (una entidad). Alta Normal Pendiente de Validacin

Subobjetivo Importancia Urgencia Estado

Este cuadro muestra el objetivo OBJ-04 el cual tiene en cuenta el perfil del usuario para poder realizar sus respectivas consultas.

26

Cuadro 7. Objetivo OBJ-04 OBJ-04 Autor Fuentes Descripcin CONSULTAR INFORMACIN DE ACUERDO AL PERFIL DEL USUARIO Nombre Autor: Edinson Giovanny Morales Cargo: Estudiante Organizacin: UFPS Nombre Fuente: Oficina del Egresado. Organizacin: UFPS El sistema debe ser capaz de adaptarse al perfil del usuario con el cual se ingresa al portal. Cuando el usuario se identifica, se tratar como un navegante interno (estudiante, egresado, administrador, profesor) o externo (una entidad) los cuales tienen necesidades de consulta diferentes. OBJ-05 < Consultar Hojas de Vida> OBJ-06 < Consultar solicitudes de puestos de trabajo> Alta Normal Pendiente de Validacin

Subobjetivo Importancia Urgencia Estado

Este cuadro muestra el objetivo OBJ-05 el cual tiene en cuenta el perfil del usuario para permitirle consultar las diferentes hojas de vida. Cuadro 8. Objetivo OBJ-05 OBJ-05 Autor Fuentes Descripcin Subobjetivo Importancia Urgencia Estado CONSULTAR HOJAS DE VIDA Nombre Autor: Edinson Giovanny Morales Cargo: Estudiante Organizacin: UFPS Nombre Fuente: Oficina del Egresado Organizacin: UFPS El sistema debe ser capaz de adaptarse al perfil del usuario con el cual se ingresa al portal. Cuando el usuario se identifica, este le podr permitir consultar las hojas de vida. Alta Normal Pendiente de Validacin

27

Este cuadro muestra el objetivo OBJ-06 el cual tiene en cuenta el perfil del usuario para permitirle consultar las diferentes solicitudes de puestos de trabajo. Cuadro 9. Objetivo OBJ-06 OBJ-06 Autor Fuentes Descripcin Subobjetivo Importancia Urgencia Estado CONSULTAR SOLICITUDES DE PUESTOS DE TRABAJO. Nombre Autor: Edinson Giovanny Morales Cargo: Estudiante Organizacin: UFPS Nombre Fuente: Oficina del Egresado Organizacin: UFPS El sistema debe ser capaz de adaptarse al perfil del usuario con el cual se ingresa al portal. Cuando el usuario se identifica, este le podr permitir consultar las solicitudes de puestos de trabajo. Alta Normal Pendiente de Validacin

Este cuadro muestra el objetivo OBJ-07 el cual tiene en cuenta el perfil del Administrador para que pueda actualizar el sistema y administrar determinadas peticiones. Cuadro 10. Objetivo OBJ-06 OBJ-07 Autor Fuentes Descripcin Subobjetivo Importancia Urgencia Estado ADMINISTRAR EL SISTEMA Nombre Autor: Edinson Giovanny Morales Cargo: Estudiante Organizacin: UFPS Nombre Fuente: Propia Organizacin: UFPS Cuando el usuario se identifica, este le podr permitir administrar informacin como carreras, pases, solicitudes no validas entre otras. Alta Normal Pendiente de Validacin

28

2.2 IDENTIFICAR Y DEFINIR LOS REQUISITOS DE ALMACENAMIENTO DE INFORMACIN Tarea 2.1- Identificar y definir los requisitos de almacenamiento de informacin. En esta tarea se determinan todas las necesidades de almacenamiento que se detecten durante la realizacin de las entrevistas. La idea esencial de los requisitos de almacenamiento de informacin es la de dar respuesta a preguntas como qu informacin debe almacenar el sistema? o con qu informacin va a trabajar el sistema. Cuadro 11. Requisito RA-01
RA-01 Objetivos Asociados Descripcin Datos Especficos DATOS PERSONALES BSICOS OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-04: Consultar informacin de acuerdo al perfil del usuario El sistema deber almacenar la informacin correspondiente a los datos personales de los estudiantes y/o egresados. Nombre y Descripcin Documento de Identidad: Almacena de manera univoca la informacin sobre el documento que lo identifica. Nombre: Almacena informacin sobre el nombre del usuario. Direccin: Almacena informacin sobre la direccin de residencia del usuario. Fecha Nacimiento: Almacena la informacin de la fecha de nacimiento del usuario. Sexo: Almacena el sexo (femenino masculino) del usuario. Pas: Almacena informacin sobre el pas de residencia del usuario. Departamento: Almacena informacin sobre el departamento de residencia del usuario. Municipio: Recoge el Municipio en el cual reside actualmente. Estado Civil: Recoge el estado civil del Usuario. Telfono: All se almacena el telfono donde puede contactarse al usuario. e-mail: All se almacena el e-mail donde puede contactarse al usuario. Naturaleza Entero Rango:12 Cadena Cadena Fecha Formato: dd/mm/aaaa Enumerado Valores: M-F RA-03 NA-04 Cadena Enumerado Valores: SolteroCasado Entero Rango: 12 Cadena

29

Cuadro 12. Requisito RA-02 RA-02 Objetivos Asociados Descripcin FORMACIONES ACADMICAS OBTENIDAS OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-04: Consultar informacin de acuerdo al perfil del usuario El sistema deber almacenar la informacin correspondiente a las formaciones acadmicas de los estudiantes y/o egresados. Nombre y Descripcin Naturaleza Cdigo Carrera: Almacena de manera NA-01 univoca la informacin sobre el cdigo que la identifica. Nombre: Almacena informacin sobre el Cadena nombre que identifica a la carrera. Semestre: Almacena la informacin del semestre actual que esta cursando, en caso de ser egresado esta opcin no se tendr en cuenta. Fecha Fin: Almacena la informacin de la fecha de graduacin del egresado, o de alguna otra formacin acadmica realizada anteriormente. Institucin: Almacena el nombre de la institucin donde realizo su formacin acadmica. Pas: Recoge el pas de donde es propia la institucin donde realizo la formacin acadmica. Departamento: Recoge el Departamento o estado del pas en la cual se realizo la formacin acadmica Municipio: Recoge el Municipio en el cual se realizo la formacin acadmica. Nivel: Recoge el nivel de la formacin realizada colocndolo en diferentes descripciones como especializaciones, maestras, doctorados, etc. Idioma: Recoge los idiomas y su respectivo nivel de dominio. Entero Rango: 1-10 Fecha Formato: dd/mm/aaaa Cadena RA-03 NA-04 Cadena NA-03

Datos Especficos

30

Cuadro 13. Requisito RA-03 RA-03 Objetivos Asociados Descripcin EXPERIENCIAS LABORALES OBTENIDAS OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-04: Consultar informacin de acuerdo al perfil del usuario. El sistema deber almacenar la informacin correspondiente a las experiencias laborales de los estudiantes y/o egresados. Nombre y Descripcin Nombre Empresa: Almacena informacin sobre el nombre donde se tiene la experiencia laboral. Cargo: Funcin que desempeo en esa empresa. Fecha Ingreso: Almacena la fecha en la que se ingreso a laborar. Fecha Fin: Almacena la fecha en la que se retiro de laborar. Pas: Recoge el pas de donde es propia la empresa donde laboro o labora. Departamento: Recoge el departamento de donde es propia la empresa donde laboro o labora. Municipio: Recoge el municipio de donde es propia la empresa donde laboro o labora. Cuadro 14. Requisito RA-04 RA-04 Objetivos Asociados Descripcin PERFIL REQUERIDO OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo. OBJ-04: Consultar informacin de acuerdo al perfil del usuario. OBJ-07: Administrar el sistema. El sistema deber almacenar la informacin correspondiente a los perfiles necesarios para ocupar un puesto de trabajo. Naturaleza Cadena Cadena Fecha Formato: dd/mm/aaaa Fecha Formato: dd/mm/aaaa NA-04 NA-05 Cadena

Datos Especficos

31

Cuadro 14. (Continuacin) Datos Especficos Nombre y Descripcin Cdigo Perfil: Almacena de manera univoca la informacin sobre el cdigo que la identifica. Nombre Profesin: Recoge informacin sobre el nombre de la carrera profesional que se requiere para el puesto de trabajo. Descripcin: Almacena la informacin que describe la actividad del puesto de trabajo. Habilidades: Almacena la informacin que permite especificar la habilidades con las que debe contar el aspirante al puesto de trabajo. Vacantes: Almacena el nmero de vacantes en ese puesto de trabajo. Fecha Finalizacin: Almacena la informacin correspondiente a la fecha hasta la cual estar vigente ese puesto de trabajo. Jornada: Almacena la informacin que corresponde a la jornada laboral en la cual se desarrollara este puesto de trabajo. Pas: Recoge el pas en la cual se desarrollara el trabajo. Departamento: Recoge el departamento en el cual se desarrollara el trabajo. Municipio: Recoge el municipio en el cual se desarrollara el trabajo. Nivel: Recoge el nivel de formacin requerida para cubrir el puesto de trabajo. Nombre Entidad: All se almacena el nombre de la entidad que realiza la solicitud del puesto de trabajo. Naturaleza Entero NA-01 Cadena Cadena Entero Fecha Enumerado: Diurno-Nocturno RA-03 NA-04 Cadena NA-03 Cadena

Tarea 2.2-Identificar y definir las nuevas naturalezas. La naturaleza define el dominio de dicho dato especfico. Permite delimitar el conjunto de valores y los detalles estructurales que tiene el dato especfico. El concepto de naturaleza, aunque muy cercano, no coincide con el concepto de tipo de dato. La naturaleza representa un dominio como un conjunto de valores que tienen un significado concreto dentro del sistema sin entrar en detalles de bajo nivel, es el punto de vista que el usuario tiene sobre el dominio y la estructura de la informacin.

32

Es posible definir tres tipos de naturalezas: Naturalezas predefinidas, Nuevas naturalezas, Requisito de almacenamiento, la ampliacin de estos tres tipos se encuentran en el anexo A. A continuacin los cuadros nos muestran su desarrollo. Cuadro 15. Naturaleza NA-01 NA-01 Objetivos asociados CDIGO CARRERA OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo. Esta naturaleza representa la estructura que describe el cdigo univoco identificativos de cada carrera otorgado por la Direccin de Admisiones y Registro. Nombre y Descripcin Precdigo: Cdigo de un solo digito que va antepuesto de la numeracin correspondiente a la carrera. Naturaleza NA-02 Tamao: 1 Rango: 1 o 0

Descripcin

Datos Especficos

Presentacin

Cdigo: Numero de 2 Entero dgitos que guarda el Tamao: 2 cdigo particular que tiene esa carrera Los datos se representan mediante un cdigo de 3 dgitos. El primero corresponde a un precdigo de carrera que sirve como referencia para identificar alumnos nuevos y antiguos, luego se acompaa de dos dgitos que identifican la carrera: XXX

33

Cuadro 16. Naturaleza NA-02

NA-02 Objetivos asociados Descripcin PRECDIGO CDIGO CARRERA OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo Esta naturaleza representa la estructura que describe un precdigo de carrera para aquellos alumnos matriculados antes del II semestre del 2006 con 0 y los que se matricularon luego de ese o en ese semestre con 1. Nombre y Descripcin Naturaleza Precdigo: Cdigo de un Entero solo digito que va Tamao: 1 antepuesto de la numeracin correspondiente a la carrera. Los datos se representan mediante un cdigo de 1 dgito. 1 o 0: X

Datos Especficos

Presentacin

Cuadro 17. Naturaleza NA-03 NA-03 Objetivos asociados Descripcin Datos Especficos Nivel OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo Esta naturaleza representa los niveles de educacin de pre-grado y post-grado. Nombre y Descripcin Naturaleza Cdigo: Almacena de Entero manera univoca la Rango: 1-20 informacin sobre el cdigo que identifica el nivel Nombre: Almacena Cadena informacin sobre el nombre que identifica al nivel.

34

Cuadro 18. Requisito RA-05 RA-05 Objetivos Asociados Descripcin DATOS PERSONALES BSICOS NAVEGANTE EXTERNO OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo. OBJ-04: Consultar informacin de acuerdo al perfil del usuario El sistema deber almacenar la informacin correspondiente a los datos bsicos de las empresas. Nombre y Descripcin Nit: Almacena de manera univoca la informacin sobre el documento que lo identifica. Nombre: Almacena informacin sobre el nombre del usuario. Direccin: Almacena informacin sobre la direccin de residencia del usuario. Fecha Registro: Almacena la informacin de la fecha de registro del usuario. Actividad Econmica: Almacena la actividad econmica. Pas: Almacena informacin sobre el pas de residencia del usuario. Departamento: Almacena informacin sobre el departamento de residencia del usuario. Municipio: Recoge el Municipio en el cual reside actualmente. Telfono: All se almacena el telfono donde puede contactarse al usuario. Email: Direccin de correo electrnico Web: Sitio Web de la empresa Representante: Persona que representa la empresa Contacto: Persona para comunicarse sobre la solicitud anunciada Naturaleza Entero Rango:12 Cadena

Cadena Fecha Formato: dd/mm/aaaa Enumerado Valores: M-F RA-03 NA-04 Cadena Entero Rango: 12 Cadena Cadena Cadena Cadena

35

Cuadro 19. Requisito RA-06 RA-06 Objetivos Asociados DEPARTAMENTO OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo. OBJ-04: Consultar informacin de acuerdo al perfil del usuario. OBJ-07: Administrar el sistema El sistema deber almacenar la informacin correspondiente a los departamentos. Nombre y Descripcin Naturaleza Cdigo Pas: Almacena de manera univoca Cadena la informacin sobre el cdigo que lo identifica. Nombre Pas: Almacena informacin sobre el Cadena nombre que identifica al departamento.

Descripcin

Datos Especficos

Modelo de requisitos de actores: Actividad 3- Identificar y definir los actores. Tarea 3.1- Identificar y definir a los actores bsicos del sistema. Para la definicin de actores se propone el uso de patrones, de la misma manera que en los requisitos de almacenamiento de informacin. En este caso, cada actor se define mediante un patrn similar al del siguiente cuadro: Cuadro 20. Patrn para la definicin de actores

36

Identificacin y definicin del primer actor. Este actor conocido como Navegante Externo es el que se ha identificado como la empresa solicitante. Cuadro 21. Actor AC-01 AC-01 Objetivos asociados Descripcin NAVEGANTE EXTERNO OBJ-03: Adecuar el sistema al perfil de usuario. El sistema deber prever el tratamiento de los usuarios que pertenecen al grupo descrito como navegante externo y que se refiere a personas que se conectan al sistema como entidades que no pertenecen a la universidad y que estn interesadas en llenar vacantes laborales.

Identificacin y definicin del segundo actor: Cuadro 22. Actor AC-02 AC-02 Objetivos asociados Descripcin NAVEGANTE INTERNO OBJ-03: Adecuar el sistema al perfil de usuario. El sistema deber preveer el tratamiento de los usuarios que pertenecen al grupo descrito como navegante interno y que se refiere a personas que se conectan al sistema porque tiene alguna relacin con la universidad.

Tarea 3.2- Identificar y definir la generalizacin de actores. Cuando se estudian los actores para un sistema navegacional, en muchos casos, se pueden identificar relaciones de especializacin entre actores. Un actor especializado es todo actor que se puede definir a partir de los actores bsicos o de otros actores especializados mediante una relacin de generalizacin

37

Figura 1. Modelo de generalizacin de actores

A continuacin mostraremos la generalizacin de actores de AC-02 usando los patrones ya acostumbrados. El primer actor heredado de Navegante interno es el administrador del sistema, el cual le har soporte y mantenimiento a este sistema. Cuadro 23. Actor AC-03 AC-03 Objetivos asociados Clasificacin Descripcin Administrador OBJ-03: Adecuar el sistema al perfil de usuario. Este es uno de los posibles roles dentro del sistema cuando se hace una clasificacin de los actores en base al navegante interno que se conecta en el sistema. El sistema deber prever el tratamiento de los usuarios que pertenecen al grupo descrito como administrador y que se refiere a personas que se conectan al sistema para darle el soporte y mantenimiento al portal. AC-02

Hereda de

38

El segundo actor derivado es Estudiante, el cual se refiere a un alumno matriculado de la universidad en Pre-Grado o Post-Grado. Cuadro 24. Actor AC-04 AC-04 Objetivos asociados Clasificacin Descripcin Estudiante OBJ-03: Adecuar el sistema al perfil de usuario. Este es uno de los posibles roles dentro del sistema cuando se hace una clasificacin de los actores en base al navegante interno que se conecta en el sistema. El sistema deber prever el tratamiento de los usuarios que pertenecen al grupo descrito como estudiante y que se refiere a personas que se conectan al sistema como alumnos matriculados. AC-02

Hereda de

El tercer actor derivado es el Egresado, el cual se refiere a toda aquella persona que haya obtenido un titulo universitario de la UFPS. Cuadro 25. Actor AC-05 AC-05 Objetivos asociados Clasificacin Descripcin EGRESADO OBJ-03: Adecuar el sistema al perfil de usuario. Este es uno de los posibles roles dentro del sistema cuando se hace una clasificacin de los actores en base al navegante interno que se conecta en el sistema. El sistema deber prever el tratamiento de los usuarios que pertenecen al grupo descrito como egresado y que se refiere a personas que se conectan al sistema porque han obtenido su titulo profesional con la universidad. AC-02

Hereda de

El cuarto actor derivado es el Director de Plan de Estudios, el cual tiene a cargo una carrera universitaria dentro de la UFPS.

39

Cuadro 26. Actor AC-06 AC-06 Objetivos asociados Clasificacin Descripcin DIRECTOR PLAN DE ESTUDIOS OBJ-03: Adecuar el sistema al perfil de usuario. Este es uno de los posibles roles dentro del sistema cuando se hace una clasificacin de los actores en base al navegante interno que se conecta en el sistema. El sistema deber prever el tratamiento de los usuarios que pertenecen al grupo descrito como Director Plan de Estudios y que se refiere a personas que se conectan al sistema para encontrar informacin, tanto de los navegantes externos e internos. AC-02

Hereda de

Tarea 3.3- Identificar y definir la incompatibilidad entre actores. Una X en la interseccin de una fila y una columna de la siguiente tabla indica que los actores correspondientes son incompatibles. El smbolo (-) indica la imposibilidad de definir incompatibilidad entre un actor y l mismo. Cuadro 27. Matriz de descripcin de la incompatibilidad de actores Actores AC-01 AC-02 AC-03 AC-04 AC-05 AC-06 AC-01 AC-02 X AC-03 X AC-04 X X AC-05 X X X AC-06 X X X X -

Modelo de requisitos funcionales: Actividad 4 Identificar y definir los requisitos funcionales. Se describe a continuacin: Tarea 4.1 Disear los diagramas de casos de uso. Los diagramas de casos de uso es una de las tcnicas ms aceptadas como tcnica de definicin de
40

requisitos. En ellos aparecen dos elementos importantes, el caso de uso en si y los actores. Esta figura muestra un ejemplo de cmo un actor interacta con el sistema mediante el caso de uso. Figura 2. Patrn de un actor y su interaccin con el sistema

Fuente: STALLINGS William. Comunicacin y redes de computadores: Mxico: Prentice Hall, 1995. A continuacin la siguiente tabla muestra el patrn a seguir para identificar los requisitos funcionales en nuestro sistema. Cuadro 28. Ejemplo de requisito funcional

41

Aplicado al proyecto se puede empezar a crear los requisitos funcionales como lo muestran los siguientes cuadros: Cuadro 29. Requisito RF-01
RF-01 Objetivos Asociados Descripcin Actores Secuencia normal REGISTRAR EL PERFIL OBJ-03: Adecuar el sistema al perfil de usuario. El sistema deber comportarse tal y como se describe en el siguiente caso de uso ofreciendo al usuario poder identificarse y navegar de acuerdo al perfil registrado en el sistema. Actor caso de Uso Actor del Sistema Actor A AC-01 AC-02 Paso Accin 1 El usuario solicita la pantalla de inicio de sesin. 2 El usuario ingresa la identificacin al sistema. 3 El sistema valida la identificacin y otorga los permisos correspondientes y los enlaces.

Cuadro 30. Requisito RF-02

RF-02 Objetivos Asociados Descripcin Actores Secuencia normal Registrar la informacin sobre el perfil acadmico y laboral. OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-04: Consultar informacin de acuerdo al perfil del usuario El sistema deber comportarse tal y como se describe en el siguiente caso de uso ofreciendo al usuario poder ingresar los criterios que considere deben aparecer en su perfil. Actor caso de Uso Actor del Sistema Actor A AC-04 AC-05 Paso Accin 1 El usuario solicita un formulario de registro. 2 El sistema muestra el formulario. 3 El usuario completa los campos de acuerdo a su perfil acadmico y laboral. 4 El sistema realiza el ingreso adecuado al sistema gestor de base de datos para generar la solicitud deseada por el usuario.

42

Cuadro 31. Requisito RF-03

RF-03 Objetivos Asociados REGISTRAR LA INFORMACIN SOBRE SOLICITUDES DE TRABAJO. OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo. OBJ-04: Consultar informacin de acuerdo al perfil del usuario. OBJ-07: Administrar el sistema. El sistema deber comportarse tal y como se describe en el siguiente caso de uso ofreciendo al usuario poder ingresar las solicitudes de trabajo que requiera bajo los criterios que considere deben aparecer. Actor caso de Uso Actor del Sistema Actor A AC-01 Paso 1 2 3 4 Accin El usuario solicita un formulario de registro. El sistema muestra el formulario. El usuario completa los campos de acuerdo a su necesidad de puesto de trabajo. El sistema realiza el ingreso adecuado al sistema gestor de base de datos para generar la solicitud deseada por el usuario.

Descripcin

Actores Secuencia normal

Cuadro 32. Requisito RF-04

RF-04 Objetivos Asociados Descripcin Actores MOSTRAR LAS SOLICITUDES DE TRABAJO. OBJ-06: Consultar solicitudes de puestos de trabajo. OBJ-07: Administrar el sistema El sistema deber comportarse tal y como se describe en el siguiente caso de uso ofreciendo al usuario poder ver las solicitudes de trabajo vigentes. Actor caso de Uso Actor del Sistema Actor A AC-04 AC-05 AC-06 Paso Accin 1 El usuario solicita ver las solicitudes de trabajo. 2 El sistema realiza la bsqueda adecuada al sistema gestor de base de datos para generar la solicitud deseada por el usuario 3 El sistema muestra la tabla con las solicitudes encontradas. 43

Secuencia normal

Cuadro 33. Requisito RF-05 RF-05 Objetivos Asociados Descripcin Actores Secuencia normal MOSTRAR LOS PERFILES LABORALES. OBJ-05: Consultar Hojas de Vida. El sistema deber comportarse tal y como se describe en el siguiente caso de uso ofreciendo al usuario poder solicitar las ofertas laborales Actor caso de Uso Actor del Sistema Actor A AC-01 AC-06 Paso Accin 1 El usuario solicita ver los perfiles laborales. 2 El sistema realiza la bsqueda adecuada al sistema gestor de base de datos para generar la solicitud deseada por el usuario 3 El sistema muestra la tabla con los perfiles encontrados.

Cuadro 34. Requisito RF-06 RF-06 Objetivos Asociados Descripcin Actores Secuencia normal ADMINISTRAR DATOS DEL SISTEMA. OBJ-07: Administrar el sistema. El sistema deber comportarse tal y como se describe en el siguiente caso de uso ofreciendo al usuario la posibilidad de habilitar, modificar o eliminar informacin del sistema. Actor caso de Uso Actor del Sistema Actor A AC-03 Paso Accin 1 El usuario solicita los datos de una opcin. 2 El sistema resuelve la peticin. 3 El sistema muestra en pantalla la informacin. 4 El usuario escoge lo que desea, puede ser habilitar, modificar o eliminar alguna informacin del sistema.

Identificar y definir los requisitos de interaccin. Se describe a continuacin:

44

Actividad 5- Identificar y definir los requisitos de interaccin. Tarea 5.1- Identificar y definir las frases. Conocer cmo el usuario quiere recuperar la informacin es un aspecto que puede ayudar a mejorar el desarrollo. La manera en la que se modela cmo el usuario desea recuperar la informacin es mediante las frases. Una frase representa un criterio de recuperacin de informacin en el sistema. Cuadro 35. Frase FR-01 FR-01 Objetivos Asociado s Cuerpo RECUPERACIN DE DATOS DEL NAVEGANTE INTERNO OBJ-05: Consultar Hojas de Vida. OBJ-03: Adecuar el sistema al perfil de usuario Descripcin RA-01.Documento de Identidad debe ser exactamente__________________ RA-01.Nombre. Termino debe contener la siguiente cadena _____________ RA-02.Cdigo Carrera. Termino debe contener la siguiente cadena_______________ RA-02.Nombre. Termino debe contener la siguiente cadena___________ RA-02.Nivel. Termino debe contener la siguiente cadena__________ RA-02.Fecha Fin. Termino debe contener la siguiente cadena__________ RA-03.Fecha Inicio. Termino debe contener la siguiente cadena____________ Actores AC-06 AC-06 AC-01 AC-06 AC-01 AC-06 AC-01 AC-06 AC-01 AC-06 AC-01 AC-06

45

Cuadro 36. Frase FR-02 FR-02 Objetivos Asociados Cuerpo Recuperacin Solicitudes de puestos de trabajo OBJ-06: Consultar solicitudes de puestos de trabajo. OBJ-03: Adecuar el sistema al perfil de usuario Descripcin RA-04.Nombre Profesin.Termino debe contener la siguiente cadena _____________ RA-04.Descripcin. Termino debe contener la siguiente cadena _____________ RA-04.Fecha finalizacin. Termino debe contener la siguiente cadena_____________ RA-04.Pas. Termino debe contener la siguiente cadena_____________ RA-04.Municipio. Termino debe contener la siguiente cadena___________ RA-04.Nombre entidad. Termino debe contener la siguiente cadena__________

Actores AC-02 AC-06 AC-03 AC-02 AC-06 AC-03 AC-02 AC-06 AC-03 AC-02 AC-06 AC-03 AC-02 AC-06 AC-03 AC-02 AC-06 AC-03

Tarea 5.2- Identificar y definir los prototipos de visualizacin. Cuando se definen los prototipos de visualizacin de datos, se hace referencia a qu datos se le muestran a cada uno de los actores y qu funcionalidad se le asocia a cada mdulo de presentacin de la informacin. Adems, los prototipos de visualizacin permiten expresar las posibilidades de navegacin que existen en el sistema. Para conseguir estos prototipos, es aconsejable hacer un estudio de los objetivos y de las entrevistas. Adems, el tener definidos los requisitos y las frases de las tareas anteriores ayuda a identificarlos mejor. Los siguientes cuadros, definen el prototipo para ingresar la informacin necesaria para crear una solicitud de puesto de trabajo y realizar la bsqueda que corresponda con las hojas de vida existentes.

46

Cuadro 37. Prototipo de visualizacin PV-01 PV-01 Objetivos Asociados Actores Descripcin Solicitud de trabajo datos generales OBJ-06: Consultar solicitudes de puestos de trabajo. AC-02 Navegante Interno El sistema deber permitir la visualizacin de los datos concretos que se muestran a continuacin y la navegacin expresada y que representa la informacin que se muestra a los usuarios sobre las solicitudes de trabajo.

Frases Informacin visualizada

FR-02 Recuperacin Solicitudes de puestos de trabajo RA-04.Nombre Profesin. RA-04.Descripcin. RA-04.Habilidades. RA-04.Vacantes. RA-04.Jornada. RA-04.Fecha finalizacin. RA-04.Pas. RA-04.Municipio.

Prototipos de salida Prototipos de entrada

RA-04.Nombre entidad. PV-02 (de Vuelta) PV-02

Este cuadro, me define el prototipo para ingresar la informacin necesaria para crear una solicitud de puesto de trabajo por parte de un navegante externo.

47

Cuadro 38. Prototipo de visualizacin PV-02 PV-02 Objetivos Asociados Actores Descripcin SOLICITUD DE TRABAJO -- DATOS EMPRESA OBJ-06: Consultar solicitudes de puestos de trabajo. AC-02 Navegante Interno El sistema deber permitir la visualizacin de los datos concretos que se muestran a continuacin y la navegacin expresada y que representa la informacin que se muestra a los usuarios sobre las empresas que hacen solicitudes de trabajo. FR-02 Recuperacin solicitudes de puestos de trabajo RA-05.Nit. RA-05.Nombre. RA-05.Direccin. RA-05.Fecha Registro. RA-05.Actividad Econmica. RA-05.Pas. RA-05.Departamento. RA-05.Municipio. RA-05.Telfono. RA-05.Email. RA-05.Web. RA-05.Representante. RA-05.Contacto. PV-02 PV-01

Frases Informacin Visualizada

Prototipos de Salida Prototipos de entrada

48

Cuadro 39. Prototipo de visualizacin PV-03 PV-03 Objetivos Asociados Actores Descripcin Hojas de vida OBJ-05: Consultar Hojas de Vida. AC-02 Navegante Externo AC-06 Director de Plan de Estudios El sistema deber permitir la visualizacin de los datos concretos que se muestran a continuacin y la navegacin expresada y que representa la informacin sobre los estudiantes o egresados FR-01 Recuperacin de Datos del Navegante Interno RA-01 Documento de Identidad RA-01 Nombre RA-01 Sexo RA-01 Telfono RA-01 e-mail RA-02 Nombre RA-02 Nivel RA-02.Semestre RA-03 Nombre Empresa RA-03 Cargo RA-03 Fecha fin RA-03 Idioma Prototipos de salida Prototipos de entrada Modelo de requisitos no funcionales. Actividad 6- Identificar y definir los requisitos no funcionales Tarea 6.1- Identificar y definir los requisitos no funcionales. Dentro de los requisitos no funcionales, se pueden incluir requisitos como: Los requisitos de comunicaciones del sistema, como requisitos tcnicos relativos a las comunicaciones que debe soportar el sistema. Por ejemplo, el tipo de protocolo que usa para las comunicaciones.

Frases Informacin visualizada

49

Los requisitos de fiabilidad, son los que establecen los factores que se requieren para la fiabilidad del software en tiempo de explotacin. La fiabilidad mide la probabilidad del sistema de producir una respuesta satisfactoria a las demandas del usuario. Por ejemplo, determinar qu tasa de fallos mxima por meses se permite. Los requisitos de entorno de desarrollo, que describen si existen restricciones en las herramientas, lenguajes de programacin, sistemas operativos, etc. que se van a usar en el desarrollo del sistema. Los requisitos de portabilidad, que definen qu caractersticas debe tener el software para que sea fcil de usar en otro entorno. Cuadro 40. Requisito no funcional RNF-01 RNF-01 Objetivos Asociados Entorno de desarrollo OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo. OBJ-03: Adecuar el sistema al perfil de usuario El desarrollo se realizara en PHP4 Las bases de datos usadas sern sobre Mysql El asistente codificador ser Macromedia Dreamweaver 8

Descripcin

Cuadro 41. Requisito no funcional RNF-02 RNF-02 Objetivos Asociados Portabilidad OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo. OBJ-03: Adecuar el sistema al perfil de usuario Por ser desarrollo Web la aplicacin correr bajo cualquier navegador

Descripcin

50

Cuadro 42. Requisito no funcional RNF-03

RNF-03 Objetivos Asociados Descripcin FIABILIDAD OBJ-01: Ofrecer la creacin de hojas de vida. OBJ-02: Ofrecer la creacin de solicitudes de puestos de trabajo. OBJ-03: Adecuar el sistema al perfil de usuario Por ser desarrollo Web la aplicacin estar disponible a mltiples usuarios en diferentes vistas por lo que el servidor sobre el cual se monte la aplicacin deber soportar un trfico mediano, el protocolo ser TCP/IP.

Actividad 7- Validar los requisitos. Tarea 7.1- Realizar la matriz de rastreabilidad. La realizacin de la matriz de rastreabilidad o trazabilidad es una tcnica que permite validar los resultados obtenidos en la especificacin de requisitos. La matriz de rastreabilidad es una tabla en la que se presentan enfrentados los objetivos y los requisitos, de forma que se pueda detectar cuales son los objetivos que son alcanzados, bien parcialmente o bien en su totalidad, al cumplirse un requisito del sistema. Cuadro 43. Matriz de rastreabilidad
OBJ-01 * * * * * OBJ-02 OBJ-03 OBJ-04 * * * * * * OBJ-05 OBJ-06 OBJ07

RA-01 RA-02 RA-03 RA-04 RA-05 RA-06 AC-01 AC-02 AC-03 AC-04 AC-05 AC-06 RF-01 RF-02 RF-03 RF-04 RF-05 RF-06

* * * *

* * * *

* *

* * * * * * * * *

* * *

* *

51

Cuadro 44. Fases, actividades y tareas de NDT

Siguiendo la secuencia de Fases en NDT, se tiene que desarrollar el Anlisis, mediante las Actividades de realizacin de Modelo Conceptual, Modelo de Navegacin y Validacin de Prototipos, pero como ya habamos nombrado en el numeral 2.1. La Metodologa OOHDM contiene estas actividades en sus primeras 3 fases, el objetivo de estas es el mismo. Por esta razn solo se usara NDT hasta aqu y se proceder a continuar con OOHDM ya que el desarrollo de este proyecto se basa principalmente en esta metodologa y NDT solo era usada para cubrir una debilidad en la fase de requisitos.
52

Cuadro 45. Comparacin de las 3 fases de NDT y OOHDM Anlisis de NDT Modelo conceptual Modelo de navegacin Validacin de Prototipos Metodologa OODHM Modelo conceptual Modelo de navegacin Diseo de Interfaz Abstracta

Nota: Tambin es bueno recordar que los casos de uso fueron ya realizados en el numeral 2.1.3 Modelo de requisitos funcionales, Tarea 4.1.

53

3. DISEO DE LA APLICACIN UTILIZANDO LA METODOLOGA OOHDM El Mtodo de Diseo Hipermedia Orientado a Objetos es un modelo para construir aplicaciones grandes de hipermedia, como sitios Web y sistemas de informacin, quioscos interactivos, presentaciones de multimedia, etc.. OOHDM comprende cuatro actividades diferentes: Diseo Conceptual. Diseo de navegacin. Diseo de Interfaz Abstracta. Implementacin. Cada etapa define un esquema objeto especfico en el que se introducen nuevos elementos (clases). Diseos ms modulares y reutilizables. La interfaz disea primitivas pueden ser fcilmente asignada a aplicaciones no orientada a objetos, o entornos como HTML. Diseo Conceptual. Esta fase se corresponde con la fase de anlisis y diseo de las metodologas orientadas a objetos. Aqu se construye un diagrama de clases y objetos que representan el dominio del sistema, sus relaciones, jerarquas, comportamiento, atributos, etc. Para esto suele emplearse la tcnica de modelado de objetos OMT o el lenguaje de modelado UML. Se construye un esquema conceptual representado por los objetos del dominio o clases y las relaciones entre dichos objetos.

54

El modelo OOHDM propone un esquema conceptual basado en clases, relaciones y subsistemas. Relaciones entre clases enlaces Para producir el Esquema de Clase Conceptual; se puede usar UML. Las clases son descritas por un conjunto de atributos y mtodos, organizadas en jerarquas. No importa el tipo de usuario y las tareas realizadas por ellos. Diseo Navegacional. En sta etapa se construye un modelo de navegacin consistente en objetos y clases navegacionales desde una perspectiva tambin orientada a objetos. OOHDM define sus propios elementos de lenguaje de modelado para sta fase, siguindose por los lineamientos del lenguaje UML. Actualmente se estudia la posibilidad de ampliar el UML con algunos de los conceptos el OOHDM referentes a la navegacin. Los componentes navegacionales definidos por OOHDM son nodos, objetos y clases navegacionales, contextos y esquemas navegacionales. Por lo general el modelo de navegacin se construye fcilmente a partir de los casos de uso obtenidos en las fases de captura de requerimientos y a partir del modelo de clase. Es posible que por cada objeto o clase del modelo conceptual aparezca un objetos o una o varias clases navegacionales que corresponden a vistas de navegacin del esquema conceptual. Diseo de Interfaz Abstracta. Define la estructura y el comportamiento de la interface del sistema hipermedia con el usuario. Este modelo es abstracto e independiente de la implementacin final del sistema. Se distinguen tres diagramas: Vistas de Datos Abstractos, Diagrama de Configuracin y Diagramas de Estado. La ADV proporciona un modelo orientado a
55

objetos de los elementos navegacionales y de presentacin con los que tiene contacto el usuario. El Diagrama de Configuracin representa los eventos del sistema que pueden ocurrir sobre los objetos de la ADV. El Diagrama de estados muestra los diferentes estados en que puede encontrarse un objeto de la ADV, tales como oculto, desactivado, ampliado, reducido, normal, etc, as como los eventos que originan dichos cambios de estado. Implementacin. Esta fase se resume a implementar cada uno de los modelos obtenidos durante el diseo en alguna tecnologa hipermedia especfica. Puesto que los modelos son independientes de la plataforma de implementacin, pequeos cambios en el diseo pueden ser fciles de implementar nuevamente en cualquier lenguaje de marcas y/o de programacin. A continuacin se describe las etapas del proceso de desarrollo de la aplicacin Web utilizando la metodologa OOHDM y la Tcnica NDT. Sin embargo, los anexos presentan la descripcin detallada de esta metodologa y la tcnica a seguir. 3.1 DISEO CONCEPTUAL Diagrama de Clases. Los diagramas de clases son una vista arquitectnica del sistema que permiten describir las caractersticas estticas de los objetos y las interrelaciones que se dan entre estos. Los siguientes diagramas de clases describen cada uno de los paquetes en que se organiza la vista arquitectnica del portal. En la figura se plantea el diagrama de clases para los navegantes o actores (AC01 y AC-02).

56

Figura 3. Diagrama de clases navegante

En la figura planteamos el diagrama de clases para la hoja de vida que corresponde a los Actores AC-03 y AC-04 (Estudiantes y egresados). Se tienen en cuenta los aspectos ya mencionados de Datos Bsicos, Cursos, Formacin Acadmica, Idiomas y Experiencia laboral.

57

Figura 4. Diagrama de clases hojas de vida

En la figura se plantea el diagrama de clases para la solicitud la cual es usada por el Navegante Externo (AC-02) para cumplir con el Objetivo OBJ-02.

58

Figura 5. Diagrama de clases solicitud

A continuacin la figura con todos los diagramas que se han planteado.

59

Figura 6. Diagrama de clases completo

60

Diagrama de Secuencias. Los diagramas de secuencia proporcionan una vista dinmica del sistema y se constituyen en artefactos que muestran la realizacin de un caso de uso. Un diagrama de secuencias muestra un escenario en particular del sistema en el que un conjunto de objetos interactan para un cumplir un caso de uso haciendo nfasis en el flujo de ejecucin a travs del tiempo. El siguiente diagrama de navegacin muestra como el usuario ingresa al portal desde su navegador escribiendo la URL asignada. Figura 7. Diagrama de secuencias entrar a portal

Este diagrama de navegacin muestra el inicio de sesin para cualquier usuario, el inicio de sesin es obligatorio para cualquier usuario.

61

Figura 8. Diagrama de secuencia iniciar sesin

Este diagrama de navegacin muestra como el usuario navega a travs de una parte del sitio a otra mediante la solicitud que se haga. Figura 9. Diagrama de secuencia navegar

62

Este diagrama de navegacin muestra como el usuario inserta datos o un nuevo registro, se aclara que todas las solicitudes de insercin de datos usaran el mismo diagrama de secuencias ya que habr uniformidad en el tratamiento de las vistas y el manejo de la informacin. Figura 10. Diagrama de secuencia insertar datos

Este diagrama de navegacin muestra como el usuario edita datos o los actualiza, se aclara que todas las solicitudes de actualizacin de datos usaran el mismo diagrama de secuencias ya que habr uniformidad en el tratamiento de las vistas y el manejo de la informacin.

63

Figura 11. Diagrama de secuencia editar datos

Este diagrama de navegacin muestra como el usuario elimina registros, se aclara que todas las solicitudes de eliminacin de datos usaran el mismo diagrama de secuencias ya que habr uniformidad en el tratamiento de las vistas y el manejo de la informacin. Figura 12. Diagrama de secuencia eliminar datos

64

Este diagrama de navegacin muestra como el usuario busca registros, esto aplica para bsqueda de hojas de vida, o para buscar solicitudes de las empresas, se hace tambin una extensin de este diagrama incluyendo una peticin que se comunique con el SIA de la UFPS, en caso de que la informacin de ciertos perfiles este all, se aclara que todas las solicitudes de bsqueda de datos usaran el mismo diagrama de secuencias ya que habr uniformidad en el tratamiento de las vistas y el manejo de la informacin. Figura 13. Diagrama de secuencia buscar datos

El siguiente diagrama muestra el cierre de sesin.

65

Figura 14. Diagrama de secuencia cerrar sesin

3.2 DISEO NAVEGACIONAL En esta etapa de la metodologa se pretende desarrollar una topologa navegacional que permita a la aplicacin ejecutar todas las tareas requeridas por el usuario. La idea principal es unificar una serie de tareas para obtener el diseo navegacional de la aplicacin. El siguiente diseo navegacional muestra como desde un men principal me puedo dirigir a cualquier seccin y desde esa seccin al men principal u otra seccin. Recordemos que cuando se trato el tema de sitio Web se propuso la estructura Web basada en red la cual permitira libremente ir a cualquier parte del sitio.

66

Figura 15. Diagrama navegacional navegante interno

Este diagrama navegacional muestra dos opciones principales que tiene el director de plan de estudios para realizar una bsqueda, mediante la persona digitando su documento de identidad o sus apellidos, para el caso de empresa mediante su nit, o nombre, el objetivo en ambos caso es obtener la informacin que se haya ingresado al sistema del objeto buscado.
67

Figura 16. Diagrama navegacional director plan de estudios Este diagrama navegacional muestra la bsqueda segn el criterio ya definido, este criterio corresponde al tipo de vacante que este ingresando, al ejecutar esta bsqueda el sistema tendr como ndice el cdigo y luego los detalles de la persona. Figura 17. Bsqueda estudiante o egresado por parte del navegante externo

Este diagrama navegacional le permite al Navegante interno (Estudiante y Egresado) buscar las solicitudes ingresadas por los navegantes externos, el orden va de manera ascendente por la fecha de ingreso y luego permite ir a los detalles de la misma. Figura 18. Bsqueda de empresa por parte del navegante estudiante y navegante egresado

68

3.3 DISEO DE INTERFAZ ABSTRACTA La interfaz abstracta del portal se diseo de una manera evolutiva, es decir que el usuario va cada vez ingresando mas informacin relevante bajo un men horizontal, pero de igual manera la informacin se puede llenar en cualquier orden. Se usaron los colores corporativos de la UFPS y se trato de evitar el exceso de pantallas de navegacin sin perder la sencillez de su usabilidad. Esta interfaz corresponde a la que el usuario ve una vez ingresa la direccin URL en su navegador o por medio de un enlace. Aqu se muestra el formulario de inicio de sesin con los campos de nombre de usuario, clave y el tipo de usuario. Figura 19. Diagrama de interfaz abstracta principal modelo grafico

Esta interfaz es general para las diferentes opciones del navegante interno y navegante externo, aqu se presentan los formularios de insercin de datos de acuerdo a la categora seleccionada y para el rea II se ha definido que se va a ir mostrando como va quedando la informacin que se va guardando, esto evita generar otro enlace para ver informacin, adicional en cada tem que se muestra se crean dos opciones: modificar y eliminar las cuales me permiten modificar dicho tem o suprimirlo, esto tambin me evita crear otro men para modificar un dato o eliminarlo.

69

Figura 20. Diagrama de interfaz abstracta ingresar-modificar-eliminar

Esta interfaz me permite ver el resultado de una bsqueda de acuerdo a los criterios establecidos, la seccin de bsqueda es nombrada en la figura como opcin bsqueda y el resultado es una lista filtrada por el criterio. Figura 21. Diagrama de interfaz abstracta bsqueda modelo grafico

70

Este diagrama es la ampliacin de la bsqueda una vez el usuario se interesa por algn resultado del listado de la figura anterior. Figura 22. Diagrama de interfaz abstracta bsqueda detalle modelo grafico

Este diagrama varia del anterior, porque cuenta con dos opciones para ingresar un criterio, por su identificacin o nombre, ya sea le caso de una persona o empresa. Pero el resultado se presenta de la misma manera y el enlace de Detalles tambin es igual al mostrado anteriormente. Figura 23. Diagrama de interfaz abstracta bsqueda navegante director plan de estudios modelo grafico

71

4. CONCLUSIONES Un portal se constituye en la mejor forma de integrar tecnologas, metodologas y estrategias en la bsqueda de un mejoramiento de los procesos de una institucin, la cual aparte de tener claros los objetivos acadmicos tambin se debe preocupar por el diseo de estrategias que hagan mas fuerte el vinculo estudiante empresa. La conjuncin de metodologas y tecnologas orientadas a objetos para el desarrollo de software, tecnologas hipermediales orientadas a objetos y el modelo orientado a objetos del documento DOM, adicionado a Frameworks para el cdigo final o simplificacin del mismo hacen del desarrollo Web una forma de desarrollo capaz de avanzar al ritmo que la sociedad lo requiere. La utilizacin de una metodologa de desarrollo orientado a objetos acompaada de una Arquitectura en capas, permite asegurar la creacin de software portable y reutilizable, que contiene una alta abstraccin del sistema real y mantiene en sus componentes una vista conceptual especializada del mundo real que se modela. El modelo de objetos del documento DOM consigue una abstraccin conceptual muy importante del texto escrito. Un portal puede ser el sitio donde convergen distintos tipos de necesidades de distintos usuarios pero con un tema comn, y lograr identificar cada un de esas necesidades, abstraerlas y modelarlas da como resultado una tecnologa capaz de proporcionar la satisfaccin de obtener resultados esperados. Un portal de empleo debe ser de interfaz sencilla y agradable, capaz de obtener de las distintas partes que interactan con el lo mas relevante de sus necesidades y con ello hacer que la informacin que se almacene cuente con el mayor grado de importancia a fin de que al realizar los procesos de bsqueda sea exitoso el objetivo que las partes en un principio quieren lograr al ingresar.

72

5. RECOMENDACIONES Teniendo en cuenta que la tecnologa evoluciona en todos los mbitos de la ingeniera de sistemas, se hace necesario que este Portal evolucione tambin, toda la universidad esta involucrada en este aspecto y mas aun los estudiantes del Plan de Estudios de Ingeniera de Sistemas quienes mediante su alto grado de innovacin pueden mejorar cualquiera de los aspectos ac presentados y entregados. No queda por dems decir que as como de la prensa escrita en la bsqueda de oportunidades pasamos al procesamiento Web de la informacin, tambin es muy importante hacer seguimiento de las tendencias de la gente, los gustos por las nuevas tecnologas y los comportamientos sociales emergentes que cada vez se desprende mas de los computadores convencionales y se traslada a la telefona mvil inteligente, medir esta nueva tendencia es una labor futura a integrar si se considera necesario a este portal. A su vez la programacin ha evolucionado a travs del tiempo y de la POO que es la ultima tendencia se ha refinado y se ha creado una capa por encima del cdigo comn que hemos conocido trasladando varias de esas tareas largas a los Framework situacin que tambin evolucionara dando mayor rapidez de respuesta y mejores interfaces de usuario como mejor conectividad. Los entes directivos de la universidad deben tener en cuenta que este portal es para beneficio de la comunidad universitaria y mayor efectividad de las empresas en sus bsquedas pero la recepcin de comentarios por cada uno de los participantes dar mayor confiabilidad al sistema y algo muy importante como la proteccin de nuestra comunidad ante engaos o malas intenciones de gente que desea aprovechar estos medios los cuales por ser virtuales complican la veracidad, pero queda como tarea aunar esfuerzos con los gremios y representantes de diversos sectores a fin de lidiar con la inseguridad en la red.

73

BIBLIOGRAFA LPEZ AFANADOR, Rubn Daro y GMEZ REY, Carlos Andrs. Diseo e implementacion de una aplicacin multiplataforma que sistematice los procesos que desarrolla el centro de servicios de informacion de la Universidad Francisco de Paula Santander. Trabajo de grado. Ingeniero de Sistemas. San Jos de Ccuta: Universidad Francisco de Paula Santander. Facultad de Ingeniera. Departamento de Ingeniera de Sistemas, 2004. 323 p. ROGER, Pressman. Ingeniera del software, un enfoque prctico. Mxico: McGraw-Hill, 2002. 501 p. STALLINGS William. Comunicacin y redes de computadores: Mxico: Prentice Hall, 1995. 518 p. VERA CONTRERAS, Milton Jess y HERNANDEZ MOLINA, Mabel. Creacin de un portal academico como herramienta didctica de apoyo a los procesos educativos en los planes de estudio de pregrado modalidad presencial en la Universidad Francisco de Paula Santander que integre nuevas tecnologas de comunicacin e informacin. Trabajo de grado. Ingeniero de Sistemas. San Jos de Ccuta: Universidad Francisco de Paula Santander. Facultad de Ingeniera. Departamento de Ingeniera de Sistemas, 2003. 214 p.

74

ANEXOS

75

Anexo A. Implementacin Una vez terminadas las etapas anteriores, ya se posee un completo conocimiento del dominio del problema. As entonces, se ha identificado la informacin que ser mostrada, como estar organizada y cuales funciones permitir ejecutar la aplicacin, y una idea bsica de cmo se vern las interfaces. Diseo de base de datos Modelo Entidad Relacin. En la figura se ve la relacin entre navegante interno y sus datos de domicilio bsicos. Modelo de relacin navegante interno-datos bsicos

A continuacin en los cuadros se muestran en detalle el nombre de sus campos, con el tipo de dato, tipo de llave y tabla padre o dependiente.
76

Estructura de la Tabla Pais

Tabla Pais Estructura de la Tabla 'Depto'

Tabla depto Estructura de la Tabla Carrera

Tabla carrera Estructura de la Tabla Usuario

Tabla Usuario

77

Estructura de la Tabla NiDbasic

Tabla NiDbasic La figura, muestra el Modelo entidad relacin del navegante interno y los datos acadmicos (idiomas, capacitaciones y estudios superiores).

78

Modelo entidad Educacin

relacin

Navegante

interno-Capacitacin,

Idiomas

A continuacin las tablas muestran en detalle los campos de las tablas navegante interno y los datos acadmicos (idiomas, capacitaciones y estudios superiores).

79

Estructura de la Tabla 'Nieducacion'

Tabla NiEducacion Estructura de la Tabla 'Capacitacin'

Tabla Capacitacin Estructura de la Tabla 'Idioma'

Tabla Idioma

80

Estructura de la Tabla NiIdioma

Tabla NiIdioma La figura muestra el modelo de la relacin del navegante_i con la experiencia laboral.

Modelo entidad relacin navegante interno, Experiencia laboral A continuacin la tabla, muestran en detalle los campos de las tablas navegante interno y la experiencia laboral.
81

Estructura de la Tabla 'NiExplab'

Tabla NiExplab Aqu la figura muestra el modelo entidad relacin de navegante_i, con datos adicionales como la comunidad, alguna discapacidad, vehculos y licencias.

Modelo entidad relacin navegante interno-datos adicionales La figura nos muestra todas las tablas ya enunciadas de manera relacionadas para el navegante interno (estudiantes y egresados).

82

Modelo entidad relacin navegante interno completo En la siguiente figura trataremos al navegante externo y sus datos bsicos.

83

Modelo entidad relacin navegante externo-datos bsicos La tabla muestra en detalle los campos de la tabla de datos bsicos para el navegante externo.

84

Estructura de la Tabla 'NeDbasic'

Tabla NeDbasic Aqu en la figura vemos las relaciones que se generan cuando el navegante externo crea una solicitud de vacante ingresando datos acadmicos.

85

Modelo entidad relacin solicitud de navegante externo La tabla muestra en detalle los campos de la tabla solicitud, la cual se emplea para el ingreso de puestos de trabajo que requiera una empresa.

86

Estructura de la Tabla 'Solicitud'

Tabla Solicitud Aqu en la figura vemos todo el MER del sistema SELECT

87

Modelo entidad relacin solicitud de navegante externo

En este captulo solo hacemos referencia al MER y la descripcin de cada una de las tablas, la creacin de dichas tablas a nivel de lenguaje SQL en el Manejador de base de datos se encuentra en el Anexo A como parte complementaria. 88

Anexo B. Arquitectura ARQUITECTURA MVC Modelo Vista Controlador (MVC). Es un estilo de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de control en tres componentes distintos. El estilo de llamada y retorno MVC, se ve frecuentemente en aplicaciones Web, donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la pgina. El modelo es el Sistema de Gestin de Base de Datos y la Lgica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. Dentro de este aspecto, se puede basar la arquitectura en el modelo MVC (Controlador => Modelo => Vista) con el fin de fragmentar la programacin. La figura muestra un ejemplo sencillo de una peticin MVC. Una peticin MVC bsica

Modelo: Esta es la representacin especfica de la informacin con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema tambin puede operar con ms datos no relativos a la presentacin, haciendo uso integrado de otras lgicas de negocio y de datos afines con el sistema modelado.

89

Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista. Marcos entra a nuestro sitio mediante la URL www.example.com/items/listar. Se carga el Controlador tems para ejecutar la accin de Listar. El controlador solicita al modelo que le entregue un arreglo con todos los tems que hay almacenados en la base de datos. Una vez que posee dicha informacin le indica a la vista que va a utilizar la plantilla correspondiente al listado de tems y le provee el arreglo con todos los usuarios. La vista, por su parte, toma el arreglo de tems y los muestra uno a uno en la plantilla que le indico el controlador. Finalmente Marcos recibe el listado de tems; lo observa un instante y decide que quiere agregar un nuevo tem por lo que hace click en un enlace que lo lleva a la URL www.example.com/items/agregar. Se repite el proceso desde el paso 1 pero con la nueva URL. Por qu utilizar MVC? Porque es un patrn de diseo de software probado y se sabe que funciona. Con MVC la aplicacin se puede desarrollar rpidamente, de forma modular y mantenible. Separar las funciones de la aplicacin en modelos, vistas y controladores hace que la aplicacin sea muy ligera. Estas caractersticas nuevas se aaden fcilmente y las antiguas toman automticamente una forma nueva. El diseo modular permite a los diseadores y a los desarrolladores trabajar conjuntamente, as como realizar rpidamente el prototipado.
90

Esta separacin tambin permite hacer cambios en una parte de la aplicacin sin que las dems se vean afectadas. Estructura de archivos de SELECT. As se vern sern los ficheros y carpetas que deberas ver:
/select/ o o o o o o o o o o o o

/connections /style /jquery /imagenes /index.php

/home
/director /estudiante /empresa /modelos /vistas

/controladores

La Carpeta connections Contiene el archivo de conexin al servidor MySQL La carpeta Style Contiene el archivo con las hojas de estilo CSS La carpeta jquery Contiene los archivos de este framework de Javascript La carpeta imgenes Contiene los archivos grficos que se usan en el portal La carpeta director Contiene los archivos que se usan al ingresar al sistema como Director de Plan de estudios. La carpeta Estudiante
91

Contiene los archivos que se usan al ingresar al sistema como Estudiante o Egresado. La carpeta Empresa Contiene los archivos que se usan al ingresar al sistema como Empresa. La carpeta Modelos Contiene las sentencias que recaen sobre la base de datos, que son administradas por el Sistema Manejador de Base de Datos. La carpeta Vistas Contienen la interfaz grafica que se le presenta la usuario, en ella visualizara el contenido y las diferentes opciones de interaccin con el sistema. La carpeta Controladores Contiene los controladores que reciben las acciones a realizar desde la vista y las despacha al SMBD. Convenciones de los nombres de archivos. Modelos. Los archivos que contienen una clase inician con la letra minscula c, seguido del nombre de la clase. Las clases dentro de su codificacin tambin tienen esta convencin. Los mtodos de las clases usan una sola palabra y se nombran de acuerdo a la funcin que realicen, como por ejemplo, guardar, eliminar consultar. Vistas. Las vistas se nombran con la palabra VIS_, luego sigue el usuario que la usa, ne(navegante externo), ni (navegante interno), ad (administrador), dp(director de plan) seguido del nombre de la interfaz que la invoco, Datos bsicos (dbasicos), datos capacitacin (dcapacitacion), en algunas ocasiones cuando la vista es solo de consulta, o cuyo resultado es una lista de registro le anteponemos la letra c. As pues una vista que cumple la funcin de ser un formulario para guardar los datos
92

bsicos de un estudiante se llamara asi. VIS_NIDBASICOS.PHP, si lo que deseamos es una vista que me muestre los datos de educacin de ese estudiante, se nombrar Vis_cnideducacion.php. Controladores Los controladores inician con el tipo de usuario que los usa ne(navegante externo), ni (navegante interno), ad (administrador), dp(director de plan) seguido de la accin que realizan y finalizan con la palabra Cont, si es un usuario que aun no ha iniciado sesin, este controlador inicia directamente con la accin o formato que lo usa, por ejemplo un controlador que sea usado por el administrador para incluir una noticia en el portal se llamara adConsejoCont.php Cdigo fuente Configuracin de conectividad a la base de datos. Como parte de la implementacin Orientada a objetos lo primero que se codifica en lenguaje estructurado es la conexin a la base de datos. class DBManager{ var $conect; function DBManager(){ } function conectar() { if(! ($con=@mysql_connect("localhost","usr3333_rootsel","admin10sel"))) { echo"Error al conectar a la base de datos"; exit(); } if (!@mysql_select_db("usr3333_select",$con)) { echo "error al seleccionar la base de datos"; exit(); } $this->conect=$con; return true; }
93

} Desarrollo CRUD (Create, Read, Update y Delete) Crear, Obtener, Actualizar y Borrar. La mayora del desarrollo se centra en estas 4 acciones, ya que cada formulario o partes de el requieren como base el uso sincronizado de estas, a continuacin se mostrara como SELECT usa MVC. Se va a usar como ejemplo el cdigo que muestra la siguiente interfaz, correspondiente al ingreso de una Capacitacin para un usuario egresado. La siguiente figura muestra una interfaz lista para ingresar datos en la parte superior, en la parte inferior muestra la opcin de ver, editar y tambin eliminar.

Interfaz Ingresar Capacitacin Interfaz Este es el cdigo HTML que se requiere para construir el formulario de capacitacin, se identifican 3 partes, la primera carga el men horizontal de opciones, la segunda parte carga el formulario con los campos para ingresar la informacin y la tercera parte muestra la lista con los datos ya guardados junto con las opciones de editar y eliminar <table border="0" cellpadding="0" cellspacing="0" width="975">
94

<tr> <td colspan="9" bgcolor="#FFFFFF"> <?php include('../vistas/head_est.htm'); ?> </td> </tr> <td colspan="8" bgcolor="#FFFFFF"> <?php include('../vistas/vis_nicapacitacion.php'); ?> <br> <tr><td align="center"> <?php $controlador = '../controladores/nicapacitacionCont.php'; //Incluimos el controlador o detenemos todo si no existe if(is_file($controlador)){ require_once $controlador; concapacitacion(); } else die('El controlador no existe'); ?></td></tr> </td> </tr> </table> Este es el cdigo HTML que se requiere para construir el formulario de capacitacin, se identifican 3 partes, la primera carga el men horizontal de opciones, la segunda parte carga el formulario con los campos para ingresar la informacin y la tercera parte muestra la lista con los datos ya guardados junto con las opciones de editar y eliminar Controlador Se usara el controlador nicapacitacionCont.php que corresponde a la tercera parte de la interfaz, en el se coordinan las actividades de acceso a datos, paso de parmetros y creacin de vistas de forma coordinada. <?php function concapacitacion() { //Incluye el modelo que corresponde include_once("../modelos/cNiCapacitacion.php"); //Crea el objeto de la clase correspondiente $objnicapa=new cCapacitacion; //la variable $listacap consulta todos los datos de capacitacion
95

$listacap= $objnicapa->consultar($_SESSION['MM_Username']); //Pasa a la vista toda la informacin que se desea representar require '../vistas/vis_cnicapacitacion.php'; } ?> Modelo Aqu se describe el modelo que es invocado por el controlador cuyo objetivo es crear el objeto cCapacitacion y ejecutar el mtodo consultar() <?php //Conexin a la Base de datos include_once("DBManager.php"); //implementamos la clase empleado class cCapacitacion{ //constructor function cCapacitacion(){ } // consulta los empledos de la BD function consultar($Num_ident){ //creamos el objeto $con a partir de la clase DBManager $con = new DBManager; //usamos el metodo conectar para realizar la conexion if($con->conectar()==true){ $query = "select ni.* , p.Desc_pais, d.Desc_depto from nicapacitacion ni, pais p, depto d where ni.Num_ident='$Num_ident' and ni.id_pais=p.id_pais and ni.id_depto=d.id_depto order by ni.Fecha_fin"; $result = @mysql_query($query); if (!$result) return false; else return $result; } } Vista Se finaliza con la creacin de la vista, para crearla se usa la variable $listacap que se asigno en el controlador y cuyo contenido le fue pasado por medio del llamado
96

al modelo. <table> <?php while($rowcap = mysql_fetch_array($listacap)){ ?> <tr> <td><div align="center"><?php echo $rowcap['Titulo']; ?></div></td> <td><div align="center"><?php echo $rowcap['Institucion']; ?></div></td> <td><div align="center"><?php echo $rowcap['Tiempo']; ?></div></td> <td><div align="center"><a href="edi_capacitacion.php?Id_capacitacion=<?php echo $rowcap['Id_capacitacion']; ?>"> Ver/Editar </a> </div></td> <td><div align="center"><a href="eli_capacitacion.php?Id_capacitacion=<?php echo $rowcap['Id_capacitacion']; ?>"> Eliminar </a></div></td> </tr> <?php } ?> </table>

97

SNTESIS DEL DESARROLLO Ac vemos como todo el proceso de ingeniera converge en todas sus fases.

Desarrollo de las distintas fases

98

Anexo C. Pruebas PRUEBAS DE CAJA BLANCA En programacin, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un mdulo. Entre las tcnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecucin), pruebas sobre las expresiones lgico-aritmticas, pruebas de camino de datos (definicin-uso de variables), comprobacin de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones mximas, mximas menos uno y ms uno. En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los mtodos de la clase Mtodos de prueba de caja blanca. Algunos de los mtodos empleados en las pruebas de caja blanca son los siguientes: Prueba del camino bsico. Es una tcnica la cual le permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba obtenidos del conjunto bsico garantizarn que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. Algunos elementos y conceptos utilizados alrededor de ste mtodo son los siguientes: -Grafo de flujo o grafo del programa: representa el flujo de control lgico de un programa y se utiliza para trazar ms fcilmente los caminos de ste. (Cada nodo representa una o ms sentencias procedimentales y cada arista representa el flujo de control) -Complejidad ciclomtica: es una mtrica de software que proporciona una medicin cuantitativa de la complejidad lgica de un programa. Cuando se usa en el contexto de las pruebas, el clculo de la complejidad ciclmatica representa el nmero de caminos independientes del conjunto bsico de un programa. Esta
99

medida ofrece al probador de software un lmite superior para el nmero de pruebas que debe realizar para garantizar que se ejecutan por lo menos una vez cada sentencia. -Camino independiente: cualquier camino del programa que introduce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva condicin. De forma general, los pasos que se debe seguir para la obtencin de los casos de prueba en este mtodo, son los siguientes: 1. Emplear el diseo o el cdigo para elaborar el grafo de flujo. 2. Determinar la complejidad ciclomtica del grafo de flujo. 3. Determinar un conjunto bsico de caminos linealmente independientes. 4. Preparar los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico.

Prueba de la estructura de control: dentro de ste tipo de prueba se contempla el mtodo del camino bsico mencionado anteriormente pero adems existen otras pruebas asociadas que permiten ampliar la cobertura de la prueba y mejorar su calidad. Estas son:

Prueba de condicin: es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa. Algunos conceptos empleados alrededor de esta prueba son los siguientes: -Condicin simple: es una variable lgica o una expresin relacional ( E1 < operador - relacional > E2). -Condicin compuesta: esta formada por dos o ms condiciones simples, operadores lgicos y parntesis.

100

En general los tipos de errores que se buscan en una prueba de condicin, son los siguientes: -Error en operador lgico (existencia de operadores lgicos incorrectos, desaparecidos, sobrantes). -Error en variable lgica. -Error en parntesis lgico. -Error en operador relacional. -Error en expresin aritmtica. Prueba del flujo de datos. Selecciona caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa. Prueba de bucles. Es una tcnica que se centra exclusivamente en la validez de las construcciones de bucles (bucles simples, anidados, concatenados y no estructurados). o Bucles simples. Se les aplica el siguiente conjunto de pruebas: -Pasar por alto totalmente el bucle. -Pasar una sola vez por el bucle. -Pasar dos veces por el bucle. -Hacer m pasos por el bucle con m < n (donde n es el nmero mximo de pasos permitidos por el bucle). -Hacer n - 1, n y n + 1 pasos por el bucle. o Bucles anidados. Si se empleara el mismo enfoque de prueba de bucles simples a los bucles anidados, el nmero de pruebas aumentara considerablemente por lo cual Beizer sugiere emplear el siguiente
101

enfoque: -Comenzar por el bucle ms interior. Establecer o configurar los dems bucles con sus valores mnimos. -Llevar a cabo las pruebas de bucles simples para el bucle ms interior, mientras se mantienen los parmetros de iteracin de los bucles externos en sus valores mnimos. Aadir otras pruebas para valores fuera de rango o excluidos. -Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mnimos y los dems bucles anidados en sus valores tpicos. -Continuar hasta que se hayan probado todos los bucles. o Bucles concatenados. Estos bucles se pueden probar utilizando el enfoque de bucles simples, siempre y cuando cada uno de los bucles sea independiente del resto de lo contrario se debe emplear el enfoque de bucles anidados. o Bucles no estructurados. Siempre que sea posible estos bucles deben redisearse. Desarrollo de prueba de camino bsico: Adoptamos la prueba de camino bsico como primera medida para diagramar el sitio y las diferentes opciones de navegabilidad. Para tal fin se construyo un mapa del sitio de acuerdo a los distintos usuarios que se loguean, en la figura 31 vemos el mapa para la pagina principal y de la figura vemos el mapa para cada una de las opciones que se pueden tomar.

102

Camino bsico la pagina principal

Camino bsico para login estudiante

103

Camino bsico para login empresa

Camino bsico para login director de plan de estudios

104

Camino bsico para registro de empresas La figura muestra el camino bsico que se adopto para probar un formulario sencillo, se conoce ya que en una misma vista tendremos varias funciones.

OPCION MENU

Agregar

Modificar

Consultar

Eliminar

Camino bsico para una interface con informacin La figura es la interface Estudiante/Educacin, la cual viendo en detalle contiene las 4 opciones enunciadas en el camino bsico, un botn insertar (opcin Agregar), un link Ver/Editar (opcin Modificar), un link Eliminar (opcin Eliminar) y una lista bajo el formulario (Opcin consultar).

105

Interface con informacin y las opciones disponibles para el usuario Aqu se ve como se despliega una lista con diferentes datos, el recorrido de esta lista corresponde a una prueba que veremos mas adelante llamada Prueba de Bucles. Con cada opcin entramos a cada una de ellas y observamos que el resultado sea el esperado, para lo cual seguimos cada camino y una vez sea ejecutada la accin revisamos en nuestra base de datos. Este procedimiento es igual para el resto de vistas que tenga nuestro sistema.

Agregar

A continuacin la figura muestra como escribimos informacin en el formulario y luego de darle clic en Insertar esta se ingresa a la base de datos.

Interface con informacin lista para insertar

Base de datos con el nuevo registro

106

Consultar

En la figura se ve la consulta especfica de datos de educacin para el usuario que est en el sistema.

Consulta que proporcin la interface Ahora vemos en la figura que el resultado es el mismo que se obtiene mediante una sentencia SQL.

Ejecucin de SQL sobre datos de educacin de un estudiante Modificar

Para este ejemplo usamos el ltimo ingreso que fue el dePostgrado/Especializacin en Gerencia de Negocios/Bogota y lo vamos a cambiar por Postgrado/Especializacin en Gerencia de Mercados/Medelln. La figura muestra como hago el proceso en el formulario y luego constato con la Base de datos que si se realizo con xito.

107

Formulario para modificar datos

Vista de la base de datos con los datos ya modificados Eliminar

La eliminacin es ubicar el registro que se desea y dar clic sobre el link eliminar, la figura muestran la opcin en la interfase y su alteracin en la Base de datos. Se eliminara el registro de Postgrado.

Vista con la opcin Eliminar

Vista de la base de datos con el registro eliminado

108

Anexo D. A1 Tcnica desarrollo navegacional NDT y sus patrones Requisitos de almacenamiento de informacin. Definen qu informacin se va a manejar en el sistema y cmo se relacionan entre s. NDT permite tambin definir nuevas naturalezas de datos que se vayan a utilizar en el sistema. Se describe a continuacin las actividades y tareas a desarrollar ACTIVIDAD 1-Obtener informacin sobre el entorno de trabajo y definir objetivos En la primera actividad de la ingeniera de requisitos, el equipo de desarrollo debe hacer un acercamiento al entorno donde se va a implantar el sistema. Debe establecer el vocabulario a utilizar, los usuarios y clientes que van a participar en el proyecto y los objetivos del mismo. Para todo ello, se propone realizar tres tareas: Tarea 1.1- Obtener informacin sobre el dominio del problema El objetivo de esta tarea es conocer el dominio del problema. Antes de comenzar las reuniones y entrevistas con los clientes, es necesario conocer el entorno de trabajo y familiarizarse con el vocabulario a utilizar, as como identificar los objetivos generales que pretenden alcanzar con la implantacin del nuevo sistema. Tarea 1.2- Preparar y realizar las reuniones y entrevistas De todas las tcnicas que se pueden aplicar en la ingeniera de requisitos, es probablemente la realizacin de entrevistas la ms general y la que mejores resultados suele dar. En esta tarea se debe planificar cundo se harn las entrevistas, quines sern los participantes y cules sern los objetivos a obtener en cada una de ellas. Realmente en NDT las entrevistas se realizan a lo largo de todo el proceso, as, como se ver ms adelante para capturar y definir los requisitos de almacenamiento de informacin, por ejemplo, es necesario contar con la
109

colaboracin de los usuarios. Es una tarea que se realiza de manera paralela a todas las dems. Tarea 1.3- Identificar y definir los objetivos del sistema El estudio de estos objetivos es esencial para todo el desarrollo del flujo de trabajo. A medida que se va desarrollando la especificacin de requisitos, los objetivos se pueden ir refinando y concretando de manera que cada vez se vayan identificando mejor los requisitos del sistema. Al fin y al cabo, un requisito no es ms que una necesidad que el sistema debe cubrir para poder alcanzar uno o varios objetivos de los impuestos por el usuario En la Tabla A.1 se presenta el modelo usado para la recoleccin de los objetivos del sistema, los campos con ( * ) son opcionales. <nombre descriptivo> <numero de la versin actual> Nombre autor: <nombre del autor> Cargo: <cargo del autor> Organizacin: <organizacin del autor> Nombre autor: <nombre del autor> Cargo: <cargo del autor> Organizacin: <organizacin del autor> Fuentes* Nombre fuente: <nombre de la fuente> Cargo: <cargo del autor> Organizacin: <organizacin del autor> Nombre fuente: <nombre de la fuente> Cargo: <cargo del autor> Organizacin: <organizacin del autor> Descripcin El sistema deber <descripcin del objetivo a cubrir por el sistema> Subobjetivos* OBJ-<x>: <nombre del subobjetivo> Importancia* <importancia del objetivo> Urgencia* <urgencia del objetivo> Estado* <estado del objetivo> Estabilidad* <estabilidad del objetivo> Comentarios* <comentarios adicionales> Tabla A. 1 Patrn para la definicin de los objetivos OBJ-<id> Versin * Autores*

110

ACTIVIDAD 2- Identificar y definir los requisitos de almacenamiento de informacin Una vez identificados los objetivos, NDT propone identificar los requisitos que el sistema debe cumplir para alcanzarlos. NDT Los requisitos de almacenamiento se definen mediante dos elementos: los requisitos de almacenamiento de informacin y las naturalezas Tarea 2.1- Identificar y definir los requisitos de almacenamiento de informacin En esta tarea se determinan todas las necesidades de almacenamiento que se detecten durante la realizacin de las entrevistas. La idea esencial de los requisitos de almacenamiento de informacin es la de dar respuesta a preguntas como qu informacin debe almacenar el sistema? o con qu informacin va a trabajar el sistema?. Tarea 2.2-Identificar y definir las nuevas naturalezas La naturaleza define el dominio de dicho dato especfico. Permite delimitar el conjunto de valores y los detalles estructurales que tiene el dato especfico. El concepto de naturaleza, aunque muy cercano, no coincide con el concepto de tipo de dato. La naturaleza representa un dominio como un conjunto de valores que tienen un significado concreto dentro del sistema sin entrar en detalles de bajo nivel, es el punto de vista que el usuario tiene sobre el dominio y la estructura de la informacin. Cada naturaleza, a su vez, se define mediante un nombre que de manera breve debe expresar su significado. Dentro del metamodelo, es posible definir tres tipos de naturalezas: 1. Naturalezas predefinidas, que representan un conjunto de dominios que se presuponen predefinidos en cualquier sistema y que en el modelo de la figura 4.1 viene representado por la clase NaturalezaPredefinida. Existen varias naturalezas predefinidas representadas como clases hijas en el metamodelo. En la tabla 4.1 se presenta el conjunto de estas naturalezas predefinidas junto con su significado y la descripcin de sus propiedades. Como ejemplo, vulvase al caso del sistema de la universidad. El nombre del alumno podra tener asignada una naturaleza de Cadena. Esto significa que el nombre para el usuario final tendr la estructura de conjunto de caracteres alfanumricos. Hay que tener en cuenta que la naturaleza, como se ha dicho, no es el tipo del dato especfico en el sentido en el que se entiende en el lenguaje de programacin, pero no el sentido amplio del lenguaje de programacin, puesto que no se indica que el tipo de este atributo sea implementado ms adelante como una cadena, sino que, en especificacin de requisitos, el usuario la entiende como tal.
111

El tipo final del dato especfico o incluso la decisin de si este dato especfico se acaba implementando como un campo concreto es tarea del grupo de diseadores e implementadores del sistema.

Naturalezas predefinidas. Propiedades y significados Nuevas naturalezas, que son nuevos dominios que se definen de manera concreta para el sistema que se est modelando. En el diagrama de clases de la figura 4.1 viene representado mediante la clase NuevaNaturaleza. Cada nueva naturaleza viene descrita mediante un identificador, un nombre, que hereda de la naturaleza, y una descripcin, cuyos significados son los mismos que para los requisitos de almacenamiento vistos anteriormente. Pero, adems, tiene otros atributos propios que no tienen por qu tomar valor en todos los casos, y que son:
112

el dominio, que representa el conjunto de valores posibles que toma la naturaleza. un conjunto de restricciones, que expresan restricciones que debe cumplir la naturaleza la presentacin que restringe formas concretas de cmo se debe representar. Adems de esto, cada nueva naturaleza tiene asociado un conjunto de datos especficos cuyo significado es similar al que tienen en los requisitos de almacenamiento de informacin. Como ejemplo, recordemos el caso del DNI del alumno. Imagnese que se desea restringir, de manera concreta la forma de este dato que, adems, va a ser usado en otros requisitos de almacenamiento como el profesor o el personal de administracin. Pues se definira una nueva naturaleza de nombre DNI cuyos datos especficos podran ser el nmero y la letra. Su dominio ira en el dominio posible de los DNI, como restriccin se indicara la frmula mediante la que se calcula la letra del DNI en Espaa, y como presentacin se podra optar por hacer una presentacin en la que aparezcan primero los ocho nmeros del DNI separados por puntos, luego un guin y por ltimo la letra. Todo esto se puede expresar tanto en lenguaje natural o usando un lenguaje, entendible tanto por los usuarios y como por el grupo de desarrollo, ms formal. Por ejemplo, indicando que la presentacin del DNI se hace como XX.XXX.XXX-X. Requisito de almacenamiento. Una naturaleza posible puede ser a su vez un requisito de almacenamiento. Esto significa que el dominio de esta naturaleza viene representado por el conjunto de elementos que, de manera abstracta, representa el requisito de almacenamiento. Por ejemplo, el caso de almacenar el tutor de proyecto de un alumno que sera de naturaleza Profesor, otro requisito de almacenamiento del sistema.

Tabla A. 2.- Patrn para definir los requisitos de Almacenamiento

113

Tabla A. 3 Patrn para definir las nuevas naturalezas El siguiente modelo importante en el tratamiento de la navegacin viene representado por las necesidades de trabajo con diferentes roles de usuario. La estructura navegacional de un sistema software puede cambiar de manera sustancial dependiendo del perfil de la persona que en cada momento interacte con l. La definicin del sistema de navegacin debe basarse en los diferentes roles de usuario que pueden interactuar con el sistema para que se adecue a las necesidades establecidas por cada uno de ellos. ACTIVIDAD 3- IDENTIFICAR Y DEFINIR LOS ACTORES Esta actividad se basa en cuatro tareas en la que se definen los actores bsicos, la derivacin entre actores, la incompatibilidad y la generalizacin. Tarea 3.1- Identificar y definir a los actores bsicos del sistema Un actor bsico es todo actor que se identifica de forma individual atendiendo a algn tipo de criterio de clasificacin a la hora de interaccionar con el sistema. Cada actor bsico corresponde a un rol individualizado de interaccin con el sistema software. Un actor derivado es todo actor que se puede definir a partir de otros actores, como conjuncin de los roles correspondientes a los actores componentes. El rol asociado a un actor derivado asume los roles correspondientes a los actores que lo componen. Sin embargo, para que la definicin de un actor derivado tenga sentido, ste debe ser un rol que aada algn aspecto independiente o alguna funcionalidad propia. Dos actores se dice que son incompatibles cuando sus roles asociados no pueden ser asumidos conjuntamente por un mismo usuario cuando interacta con el sistema. La incompatibilidad se puede presentar entre actores del mismo grupo
114

(mismo criterio de clasificacin) o de grupos diferentes (diferentes criterios de clasificacin). Para la definicin de actores se propone el uso de patrones, de la misma manera que en los requisitos de almacenamiento de informacin. En este caso, cada actor se define mediante un patrn similar al de la tabla 4.4. Los campos que aparecen en el patrn son fcilmente identificables desde el metamodelo de la figura X.Y. El identificador se aconseja que comience por las siglas AC y vaya seguido de un nmero nico. El nombre, la clasificacin y la descripcin, recogen los valores de los atributos correspondientes descritos en el metamodelo.

Tabla A. 4 Patrn para la definicin de actores Tarea 3.2- Identificar y definir la generalizacin de actores Cuando se estudian los actores para un sistema navegacional, en muchos casos, se pueden identificar relaciones de especializacin entre actores. Un actor especializado es todo actor que se puede definir a partir de los actores bsicos o de otros actores especializados mediante una relacin de generalizacin Aparece un nuevo campo, hereda de, que no aparece de manera explcita en el metamodelo como un atributo. Mediante este campo se recoge las relaciones de generalizacin del sistema. Si el actor identificado mediante AC-0i es padre del actor identificado mediante AC-0j, en el patrn de definicin de AC-0j se cumplimenta el campo hereda de con una referencia a AC-0i. Adems, cada relacin de generalizacin se debe representar de manera grfica usando la notacin de UML, tal y como se muestra en el ejemplo de la figura 4.3.

115

Definicin de generalizacin entre actores Tarea 3.3- Identificar y definir la incompatibilidad entre actores Otra de las relaciones que se establecen entre actores es la relacin de incompatibilidad. Para definir la incompatibilidad entre actores se propone hacer uso de una matriz similar a la mostrada abajo. Cada fila y cada columna corresponden a un actor del sistema, de manera que en cada fila se indican las incompatibilidades que presente el actor correspondiente con los dems actores del sistema. Tanto las filas como las columnas se etiquetan mediante el identificador que se ha asignado al actor en su patrn de definicin. Para evitar redundancias, slo se estudia la diagonal superior de la matriz, puesto que si se estudiase tambin la inferior, se obtiene una matriz simtrica que complica la comprensin del significado y en la que no se aporta ninguna informacin adicional.

116

La disposicin de actores por fila y columna se ordena de igual forma en ambos casos, reflejando una estructura plana en la que no se diferencian los grupos de actores. Se aconseja, por motivos de claridad, que los actores de un mismo grupo de clasificacin aparezcan juntos en las filas y columnas de la tabla anterior. Una X en la interseccin de una fila y una columna de la tabla indica que los actores correspondientes son incompatibles. El smbolo - indica la imposibilidad de definir incompatibilidad entre un actor y l mismo.

Matriz de descripcin de la incompatibilidad de actores Modelo de requisitos funcionales La estructura funcional de un sistema expresa las posibilidades funcionales, tanto las internas como las que se realizan para interactuar con el exterior, que debe ofrecer el sistema. El modelo que se presenta en este apartado va a representar las posibilidades funcionales que debe ofrecer el sistema durante la navegacin. Estas posibilidades funcionales van a depender directamente del actor que en cada momento interacte con el sistema. Por ello, cuando se presenta el modelo se detecta la relacin con el modelo anterior. Se propone que cada caso de uso de cada diagrama, sea, adems, definido mediante un patrn similar al de la tabla siguiente.

117

P atrn para definir los requisitos funcionales En este patrn, algunos campos como el identificador, que en este caso se propone que comience por RF y vaya seguido por un nmero secuencial, el nombre, la descripcin, la precondicin, la poscondicin y la frecuencia esperada se derivan directamente del metamodelo. El resto de campos recoge la informacin referente a las otras clases del metamodelo. As, el campo actores recoge la lista de los actores funcionales del caso de uso y los actores del modelo de actores que representa cada uno de ellos. Por ejemplo, si en el caso de uso existe el actor ActorDelCasoDeUso y este papel puede ser jugado por los actores identificados en el modelo de actores visto en el apartado anterior con los identificadores AC-01 y AC-02 y nombrados respectivamente Actor 1 y Actor 2, en el patrn del caso de uso, en la columna actores quedara como: Actividad 4- Identificar y definir los requisitos funcionales. En las actividades anteriores se estudia qu se almacena en el sistema y quines pueden hacer uso de esa informacin. Pero en los sistemas tambin hay que recoger qu se va a poder hacer con la informacin y las posibilidades funcionales del mismo.

118

Los requisitos funcionales responden a la pregunta de qu se puede hacer en el sistema? Tarea 4.1- Disear los diagramas de casos de uso Los diagramas de casos de uso es una de las tcnicas ms aceptadas como tcnica de definicin de requisitos. En ellos aparecen dos elementos importantes, el caso de uso en si y los actores. Los actores son definidos en NDT en la actividad 3, as que desde los casos de uso lo que aparece es una referencia a esas definiciones. En los diagramas en NDT pueden aparecer dos tipos de actores: Actores que fueron definidos en la actividad 3. En este caso, en el diagrama de casos de uso se nombra al actor con el identificador del actor en su correspondiente patrn, AC-x. Actores que sean genricos. stos se nombran como Actor1, Actor2, etc. Estos actores normalmente representan diversos tipos de actores de los definidos en la actividad 3. La tabla A.8 que se ve abajo muestra el patrn para definir los casos de uso.

119

Patrn para definir los casos de uso Modelo de requisitos de interaccin Actividad 5- Identificar y definir los requisitos de interaccin. El modelo de interaccin recoge la manera en la que los actores van a interactuar con el sistema
120

durante la navegacin. Esta idea de interaccin recoge varios aspectos que incluyen la forma en la que se visualizan los datos, las posibilidades de navegacin y de ejecucin de la funcionalidad o la manera en la que se recupera la informacin. Por esta razn, desde el modelo de requisitos de interaccin se hace referencia a todos los modelos anteriores. El modelo de interaccin se compone de dos submodelos a su vez, formado por lo que se denominan Frases y Prototipos de Visualizacin. La otra clase importante de este metamodelo son los prototipos de visualizacin que se representan mediante la clase PrototipoDeVisualizacin. Cada prototipo de visualizacin tiene un identificador nico, un nombre que lo representa y una descripcin que expresa su significado. Cada uno de ellos son accesibles por un conjunto de actores del sistema, que recoge el grupo de roles de actores que pueden hacer uso del prototipo durante la navegacin. Tarea 5.1- Identificar y definir las frases Conocer cmo el usuario quiere recuperar la informacin es un aspecto que puede ayudar a mejorar el desarrollo. La manera en la que se modela cmo el usuario desea recuperar la informacin es mediante las frases. Una frase representa un criterio de recuperacin de informacin en el sistema.

Patrn para la definicin de las frases Por otro lado, el lenguaje para la definicin de las frases no debe ser muy concreto o difcil de entender pues los patrones de las frases deben ser evaluados por los usuarios del sistema. En este sentido se propone hacer uso de la propuesta BNL (Bounded Natural Language). Este lenguaje se basa en definir los criterios de consulta que el usuario desea obtener a travs del lenguaje natural. Esto permite que los resultados obtenidos sean fcilmente entendibles por el cliente. Sin embargo, si el lenguaje permitido
121

para representar las necesidades de recuperacin fuese totalmente abierto, la variabilidad del lenguaje natural podra hacer que los resultados obtenidos fueran tan ambiguos que no fuesen tiles. Para evitar estos problemas, BNL propone una solucin intermedia basada en lo que denomina frases. Es decir, los criterios de recuperacin de informacin se van a describir mediante una serie de frases. Estas frases tienen tres elementos, que son bastante cercanos a los que se han ido viendo en todos los patrones de definicin de requisitos presentados: - Estructuras fijas que no se pueden modificar - Huecos a rellenar por los clientes en las consultas - Conceptos que sirven para determinar qu se desea consultar. Aunque BNL no fue desarrollado por sus autores como tcnica de ingeniera de requisitos, ni se ha propuesto como tcnica para ninguna metodologa de desarrollo, resulta muy adecuada si se adapta a la definicin de los criterios de recuperacin en los sistemas navegacionales. BNL permite recoger las necesidades de recuperacin de informacin de una manera fcil de comprender para el usuario y permite definir las necesidades de recuperacin que van a ser esenciales para el estudio de la navegacin. En la tabla A.10. Se recogen los posibles cuerpos de las frases dependiendo de la naturaleza del dato especfico para cada una de las naturalezas predefinidas

122

Frases asociadas a cada naturaleza

123

Tarea 5.2- Identificar y definir los prototipos de visualizacin Cuando se definen los prototipos de visualizacin de datos, se hace referencia a qu datos se le muestran a cada uno de los actores y qu funcionalidad se le asocia a cada mdulo de presentacin de la informacin. Adems, los prototipos de visualizacin permiten expresar las posibilidades de navegacin que existen en el sistema.

Patrn para la recoleccin de prototipos de visualizacin

Modelo de requisitos no funcionales Actividad 6- Identificar y definir los requisitos no funcionales. En todas las etapas anteriores se han descrito todas las necesidades de almacenamiento, de funcionalidad y de interaccin del sistema. Sin embargo, en cualquier tipo de proyecto software aparecen una serie de necesidades que no se pueden catalogar en las anteriores.

124

En esta actividad se identifican y recogen todas estas necesidades que han quedado fuera de las clasificaciones anteriores. Aunque NDT est centrado en el tratamiento de la navegacin y este tipo de requisitos no es influyente en la definicin de modelos para el tratamiento de la navegacin, es necesario, si se desea ofrecer una metodologa til, permitir al equipo de desarrollo expresar otro tipo de requisitos no contemplados en los anteriores. Tarea 6.1- Identificar y definir los requisitos no funcionales Dentro de los requisitos no funcionales, se pueden incluir requisitos como: Los requisitos de comunicaciones del sistema, como requisitos tcnicos relativos a las comunicaciones que debe soportar el sistema. Por ejemplo, el tipo de protocolo que usa para las comunicaciones Los requisitos de fiabilidad, son los que establecen los factores que se requieren para la fiabilidad del software en tiempo de explotacin. La fiabilidad mide la probabilidad del sistema de producir una respuesta satisfactoria a las demandas del usuario. Por ejemplo, determinar qu tasa de fallos mxima por meses se permite. Los requisitos de entorno de desarrollo, que describen si existen restricciones en las herramientas, lenguajes de programacin, sistemas operativos, etc. que se van a usar en el desarrollo del sistema. Los requisitos de portabilidad, que definen qu caractersticas debe tener el software para que sea fcil de usar en otro entorno. Actividad 7- Validar los requisitos Tras la identificacin y la descripcin de requisitos es necesario validarlos. A la hora de validar los requisitos NDT propone realizar revisiones con los clientes a los resultados obtenidos o incluso la ejecucin de auditoras, la realizacin de tesauros u ontologas que permitan validar los resultados, o incluso la aplicacin de herramientas propias de la empresa.

125

Tarea 7.1- Realizar la matriz de rastreabilidad La realizacin de la matriz de rastreabilidad o trazabilidad es una tcnica que permite validar los resultados obtenidos en la especificacin de requisitos. La matriz de rastreabilidad es una tabla en la que se presentan enfrentados los objetivos y los requisitos, de forma que se pueda detectar cuales son los objetivos que son alcanzados, bien parcialmente bien en su totalidad, al cumplirse un requisito del sistema.

Al terminar de desarrollar la matriz, se debe cumplir que todo objetivo sea alcanzado por al menos un requisito. As se valida que realmente se pueden cumplir todos los requisitos. Pero por otro lado, hay que comprobar que todos los requisitos sirven para alcanzar, al menos, un objetivo. Esto valida la existencia del requisito puesto que no tendra sentido un requisito que no sirve para alcanzar un objetivo del sistema. A.2 DISEO NAVEGACIONAL Una vez que las clases de navegacin se han decidido, es necesario estructurar el espacio de navegacin que se pondr a disposicin de los usuarios. En OOHDM, esta estructura se define mediante la agrupacin de objetos de navegacin en conjuntos llamados contextos. Cada definicin de contexto incluye: los elementos
126

que contiene la especificacin de su estructura de navegacin interior; un punto de entrada, las restricciones de acceso de usuario en trminos de clases y las operaciones; y las estructuras de acceso. Hay seis formas diferentes de definir los contextos: 1. Clase simple derivada - incluye todos los objetos de una clase que satisfacen alguna propiedad, por ejemplo, "edificios con direccin = Ro de Janeiro". Una variante de este tipo es la consulta a base de contexto, en el cual el usuario define la propiedad en tiempo de navegacin.

Figura A. 1

. Clase derivada

2. Grupo de Clase derivada - Es un conjunto de contextos de la clase simple derivada, donde la definicin de propiedad de cada contexto tiene parmetros, por ejemplo, "Edificio por lugar" (la ubicacin puede variar).

Figura A. 2. Grupo de clase derivada

3. Enlace Simple derivado - Incluye todos los objetos relacionados con un objeto determinado, por ejemplo, "los edificios diseados por Oscar Niemeyer". Grficamente, lo mismo que 1. 4. Grupo de Enlace derivado - Un conjunto de contextos de Enlaces derivados, cada uno de los cuales se obtienen variando la fuente de los elementos de la relacin, por ejemplo, "Edificios diseados por el arquitecto" (vara arquitecto). Grficamente, lo mismo que 2. 5. Arbitraria Es un conjunto enumerado, por ejemplo, una visita guiada. Grficamente, lo mismo que 1 6. Dinmico - es un conjunto donde los elementos cambian durante la navegacin, por ejemplo, la historia, la cesta de la compra.

Figura A. 3. Dinamico

127

En cualquiera de lo anterior, si hay una estructura definida para el acceso, la notacin grfica correspondiente contiene un pequeo cuadrado negro en la esquina superior izquierda. Asociadas a los contextos, hay estructuras de acceso (ndices). Que se indican grficamente por:

Figura A. 4. Estructuras de Acceso

La estructura de navegacin de la aplicacin se define en un contexto en el diagrama, que muestra todas las estructuras de acceso y contextos definidos para esta aplicacin, y la posible navegacin entre ellos. La Figura 4 muestra el diagrama de la arquitectura del sitio.

Segn este esquema, la aplicacin del men principal dispone de cuatro ndices: Arquitectos permite el acceso a una lista alfabtica de arquitectos, que pueden ser recorridos en cualquier momento para permitir el acceso a los edificios, agrupados por aos. Edificios permite el acceso a los edificios, agrupados por su nombre. Categoras permite el acceso a los edificios por categoras (monumentos, hoteles, centros de convenciones, etc ...) Adems, los edificios tambin pueden ser agrupados de acuerdo con el arquitecto que los diseo. Este contexto, slo se puede acceder desde otros contextos, tales como arquitectos. Cabe sealar tambin que, cuando se mira en un edificio en cualquiera de los contextos, es posible "cambiar" el contexto. Por ejemplo, mientras se mira a un edificio por un determinado arquitecto, es posible navegar hasta la "prxima construccin en la misma categora", con independencia de su arquitecto. Una vez que los contextos se han definido, es posible ampliar la definicin de las clases de navegacin especificando "decoradores", es decir, atributos que slo son visibles cuando se accede a un objeto dentro de un contexto dado. Tales atributos estn definidos en "InContext" clases. x.y. De acuerdo a los casos de uso y teniendo en cuenta la recopilacin de 3 sitios especializados en ubicacin laboral se procede a generar un primer desarrollo de Diseo navegacional.
128

A continuacin las diferentes secciones de los tres portales para el rea de usuarios. elempleo zonajobs Registro en Sistema Datos de contacto Informacin Personal Experiencia Laboral Educacin Formal Educacin Educacin no formal e Idiomas Idiomas Experiencia Laboral Otros conocimientos Objetivo Laboral Previsualizacin sena Datos bsicos Autenticacin Educacin Capacitacin Idiomas Experiencia Laboral Intereses ocupacionales Otros datos Sntesis

Tabla A. 5- Cuadro de otros portales y sus secciones

Para tener una idea mas clara de que debera tener el sistema se diseo la siguiente matriz elempleo X X X X X X zonajobs X X X X X X X Sena X X X X X X X X X

Registro en sistema Informacin Personal Estudios Formales Estudios no formales Idiomas Experiencia Laboral Inters Laboral Otros Datos Vista Previa

Tabla A. 6. Cuadro de similitudes de los portales evaluados

Aqu se ven que los tres portales tienen 5 reas en comn.

129

A.3 PROTOTIPOS DE INTERFAZ La siguiente figura me muestra el prototipo para la pantalla de inicio o de inicio de sesin.

Figura A. 5. Prototipo inicio de Sesin

A continuacin vemos el prototipo de men para el usuario que permitir navegar por las diferentes opciones de su perfil.

Figura A. 6. Prototipo Men Navegante interno (Estudiante-Egresado)

Ac un prototipo de ingreso de datos bsicos.

130

Figura A. 7. Prototipo Ingreso de datos

Ac se ve un prototipo donde estn las casillas para ingresar datos, y los links para modificar o eliminar.

Figura A. 8. Prototipo Ingreso datos, modificacin y eliminacin

Ac se presenta el prototipo del men para el usuario externo (empresa), que usara para navegar por las diferentes opciones.

Figura A. 9. Prototipo men navegante externo

131

Ac un prototipo de ingreso de datos bsicos.

Figura A. 10. Prototipo de Ingreso de datos navegante externo

Figura A. 11. Prototipo de resultados para navegante externo

Figura A. 12. Prototipo de ampliacin de resultados

132

A.4 IMPLEMENTACION MER Implementacin capa de Almacenamiento

Tabla Usuario, esta tabla se usa para mantener la informacin de los cdigos y claves de los usuarios que ingresan al sistema. o Id_usuario: Identificador del usuario, se autoincrementa. o Cdigo: Cdigo que identifica al usuario en el sistema. o Clave: Clave del usuario dentro del sistema. o Desc_tipo: Describe el tipo de usuario (Estudiante, Egresado, Director, Administrador).

Tabla A. 7. Sentencia SQL para crear la Tabla de sistema Usuario

Tabla Navegante_i, esta tabla se usa para mantener la informacin bsica del navegante interno (Estudiante y/o egresado). o Num_ident: Identificador del navegante, de acuerdo al caso podr identificarse en el sistema con cdigo universitario o su cedula. o Id_tus: Identificador del tipo de usuario o Doc_ident: Numero del documento de identidad o Prim_nombre: Primer nombre de la persona o Seg_nombre: Segundo nombre de la persona o Prim_ape: Primer apellido de la persona o Seg_ape: Segundo apellido de la persona o Genero: Sexo de la persona (masculino-femenino) o Fecha_nac: Fecha de nacimiento de la persona o Est_civil: Estado civil de la persona o Email: Correo electronico de la persona o Direccion: Direccion de residencia de la persona o Telefono1: Primer telefono de contacto de la persona o Ext1: Extension de Telefono1 o Telefono2: Segundo telefono de contacto de la persona o Ext2: Extension de Telefono2 o Tel_cel: Telefono celular de la persona
133

o Id_depto: Departamento de residencia de la persona o Id_pais: Pais de residencia de la persona

Tabla A. 8. Sentencia SQL para crear la Tabla de sistema NiDbasic

Tabla Carrera, esta tabla se usa para mantener la informacin de las carreras ofertadas por la universidad. o Id_carrera: Identificador de la carrera, asignado por la UFPS. o Desc_carera: Nombre de la carrera.

Tabla A. 9. Sentencia SQL para crear la Tabla Carrera

134

Tabla Pais, esta tabla se usa para mantener la informacin de los pases del mundo. o Id_pais: Identificador del pais, se autoincrementa. o Desc_pais: Aqu se guarda el nombre del pais.

Tabla A. 10. Sentencia SQL para crear la Tabla de sistema Pas

Tabla Depto, esta tabla se usa para mantener la informacin de los departamentos o estados de un pas. o Id_depto: Identificador del departamento, se autoincrementa. o Id_pais: Identifica a que pas pertenece dicho departamento (Relacionada con la tabla Pais). o Desc_depto: Aqu se guarda el nombre del departamento.

Ta bla A. 11 Sentencia SQL para crear la Tabla de sistema Depto

Tabla NiEducacion, esta tabla se usa para mantener la informacin de los estudios superiores del Navegante interno (Estudiante y/o Egresado). o Id_educacionp: Identificador del registro estudio, se autoincrementa. o Titulo: Titulo obtenido al finalizar los estudios. o Id_nivel: Identifica el nivel del registro estudio (Primaria, Bachillerato, Pregado, Postgrado). o Institucion: Institucin de la cual se grado. o Fecha_fin: Fecha en la que recibi el grado. o Id_pais: Pas en el cual hizo el estudio. o Id_depto: Departamento en el cual hizo el estudio.
135

o Municipio: Municipio en el cual hizo el estudio. o Num_ident: Numero de identidad del navegante al que pertenece el registro. (Se relaciona con la tabla Usuario).

Tabla A. 12. Sentencia SQL para crear la Tabla de sistema NiEducacion

Tabla Idioma, esta tabla se usa para mantener los registros de usuario de los diferentes navegantes que ingresan al portal. o Id_idioma: Identificador para los idiomas, se autoincrementa. o Tipo_idiom: Identifica el idioma o dialecto o Descripcin: Nombre del idioma o dialecto.

Tabla A. 13. Sentencia SQL para crear la Tabla de sistema Idioma

Tabla NiIdioma, esta tabla se usa para mantener la informacin de un usuario Interno (Estudiante-Egresado) y los idiomas o dialectos que maneja y su nivel. o Num_ident: Numero de identidad del usuario interno o Id_idioma: Codigo del idioma (se obtiene de la relacin con la tabla Idioma) o Nha: Nivel que habla el idioma o dialecto o Nee: Nivel que escribe el idioma o dialecto
136

o Nea: Nivel que escucha el idioma o dialecto

Tabla A. 14. Sentencia SQL para crear la tabla de sistema NiIdioma

Tabla Capacitacion, esta tabla se usa para mantener la informacin de los estudios adicionales del Navegante interno (Estudiante y/o Egresado). o Id_capacitacion: Identificador del estudio, se autoincrementa. o Num_ident: Identificacin del navegante al que pertenece el registro de la capacitacin. o Tiempo: Duracin de la capacitacin. o Institucion: Institucin de la cual se capacito. o Fecha_fin: Fecha en la que recibi la capacitacin. o Id_pais: Pas en el cual hizo el estudio o Id_depto: Departamento en el cual hizo el estudio o Municipio: Municipio en el cual hizo el estudio

Tabla A. 15. Sentencia SQL para crear la Tabla de sistema NiCapacitacion

Tabla NiExplab, esta tabla se usa para mantener la informacin de la experiencia laboral del Navegante interno (Estudiante y/o Egresado). o Id_exp:lab: Identificador de la experiencia laboral, se autoincrementa.
137

o Num_ident: Identificacin del navegante al que pertenece el registro de la experiencia laboral. o Cargo: Cargo que desempeo. o Fec_in: Fecha inicial de labores. o Fec_fin: Fecha final de labores. o Id_pais: Pas en el cual laboro o Id_depto: Departamento en el cual laboro. o Municipio: Municipio en el cual laboro. o Logrosmet: Logros obtenidos. o Funciones: Funciones que realizo.

Tabla A. 16. Sentencia SQL para crear la Tabla de sistema NiExplab

Tabla NiDadic, esta tabla se usa para mantener la informacin de datos adicionales del Navegante interno (Estudiante y/o Egresado). o Id_adicional: Identificador del dato adicional, se autoincrementa. o Num_ident: Identificacin del navegante al que pertenece el registro dato adicional. o Discapacidad: Registra la discapacidad. o Comunidad: Registra a cual comunidad pertenece. o Vehiculo: Registra que tipo de vehiculo tiene. o Licencia: Registra que tipo de licencia de conduccin posee.

138

Tabla A. 17. Sentencia SQL para crear la Tabla NiDadic

Tabla Navegante_e, esta tabla se usa para mantener la informacin bsica del navegante externo (Empresa). o Nit: Numero de identificacin tributaria de la empresa. o Nombre: Nombre de la empresa. o Act_economica: Actividad econmica de la empresa. o Fecha_reg: Fecha dada por el sistema sobre la fecha de vinculacin. o Nomb_repres: Nombre de la persona que representa la empresa. o Id_pais: Identificador del pas de la empresa. o Id_depto: Identificador de departamento de la empresa. o Municipio: Municipio de la empresa. o Id_sector: Identificador del sector de la empresa. o Direccion: Direccin de la empresa. o Telefono1: Telfono principal. o Ext1: Extension de contacto. o Telefono2: Telfono alterno. o Ext2: Extensin alterna. o Fax: Fax de la empresa. o Email: Email de la persona de contacto. o Web: Direccin del sitio Web de la empresa. o Nom_contac: Nombre de la persona de contacto.

139

Tabla A. 18. Sentencia SQL para crear la Tabla de sistema NeDabasic

Tabla Sector, esta tabla se usa para mantener la informacin de los sectores a los cuales pertenece un navegante externo (Empresa). o Id_sector: Identificador del sector, se autoincrementa o Descripcin: Nombre del sector.

Tabla A. 19 Sentencia SQL para crear la Tabla de sector.

Tabla Solicitud, esta tabla se usa para mantener la informacin de las solicitudes a vacantes que una empresa realiza. o Id_solicitud: Identificador de solicitud, se autoincrementa. o Titulo: Titulo del clasificado. o Descripcion: Describe el contenido de la vacante. o Nit: Numero de identificacin de la empresa que hace la solicitud. (se relacina con la tabla Navegante_e. o Desc_cargo: Nombre del cargo vacante. o Funciones: Funciones propias del cargo vacante.
140

o o o o o o o o o o o o

Habilidades: Habilidades requeridas para este cargo Meses_exp: Meses de experiencia requeridos para ocupar este cargo. Vacantes: Numero de vacantes disponibles. Fecha_lim: Fecha en la que se cierra la solicitud Observaciones: Datos adicionales que la empresa quiera aclarar. Id_pais: Identifica el pais donde se ejecutara el contrato. Id_depto: Identifica el departamento donde se ejecutara el contrato. Municipio: Identifica el municipio donde se ejecutara el contrato. Fecha: Fecha en la que se guarda la solicitud. Fecha_lim: Fecha en la que caduca el clasificado o solicitud. Salario: Salario para esta vacante. Aprobado: Valor que indica si este clasificado fue o no aprobado por la UFPS.

Tabla A. 20. Sentencia SQL para crear la Tabla de sistema Solicitud

Tabla NeNivel, esta tabla se usa para mantener la informacin de los diferentes niveles de educacin superior. o Id_nivel: Identificador de nivel, se autoincrementa. o Id_solicitud: identificador de la solicitud

Tabla A. 21. Sentencia SQL para crear la Tabla de sistema NeNivel

Tabla NeJornada
141

Tabla A. 22. Sentencia SQL para crear la Tabla de sistema NeJornada

Tabla NeIdioma

Tabla A. 23. Sentencia SQL para crear la Tabla de sistema NeIdioma

Tabla NeCarrera

Tabla A. 24. Sentencia SQL para crear la Tabla de sistema NeCarrera

142

A.5 DISEO METODOLOGICO A.5.1. Enfoque Investigativo LA INVESTIGACION APLICADA Se toma esta investigacin ya que es una estrategia donde se observa y reflexiona sistemticamente sobre realidades (tericas o no) usando para ello diferentes tipos de documentos. Indaga, interpreta, presenta datos e informaciones sobre un tema determinado de cualquier ciencia, utilizando para ello, una metdica de anlisis; teniendo como finalidad obtener resultados que pudiesen ser base para el desarrollo de la creacin cientfica. A.5.2. Poblacin y Muestra Poblacin Estudiantes dos ltimos semestres Ing. De sistemas (35 dcimo y 37 Noveno) y egresados de la Universidad francisco de Paula Santander dos ltimos aos de Ingeniera de Sistemas (61) y Empresas de la regin norte de Santander (10). Fuente: Oficina del egresado-Bienestar universitario UFPS. Muestra

Muestra aleatoria simple a estudiantes de ltimos semestres de la Universidad Francisco de Paula Santander (20 personas), en ingeniera de sistemas, egresados de la Universidad Francisco de Paula Santander (10 personas) en ingeniera de sistemas, sin distincin de sexo o edad, empresas que manejen algn medio en su bsqueda de personal (5 empresas), sin distincin de tamao. Variables Criterios de bsqueda de personal usado por las empresas. Uso de medios para buscar empleo por parte de estudiantes y egresados. Aceptacin de uso del portal para egresados, estudiantes y empresas. A.5.3 Tcnicas de recoleccin de datos Investigacin documental (Libros, Documentos, Foros Especializados) La observacin (directa, participante) La entrevista cualitativa (no estructurada) La encuesta A.5.4 Fuentes de Informacin Las fuentes de informacin primaria a tener en cuenta son: Oficina del Egresado UFPS Direccin de Admisiones y registro
143

Diversos planes de estudio de la UFPS Departamentos de Talento Humano del sector privado

Las fuentes de informacin secundaria a tener en cuenta son: Sitios Web de oferta de empleo

144

A.5.5 Cronograma de Actividades

145

A.6 ENCUESTAS USADAS EN LA RECOLECCION DE INFORMACION COMO PARTE DEL DISEO METODOLOGICO PROPUESTO A.6.1 PLANTILLA DE ENCUESTA A ESTUDIANTES DE LTIMOS SEMESTRE DE LA UNIVERSIDAD FRANCISCO DE PAULA SANTANDER SI 1. A tenido algn empleo formal en los ltimos dos aos? 2. 3. Se ha inscrito en alguna empresa o cooperativa para que lo ubiquen en alguna labor o trabajo? 4. A buscado empleo a travs de medios digitales como peridicos en la Web o bolsas de empleo en la Web? a. Si respondi si, Ha sido convocado? 5. Ya realizo su prctica empresarial? a. Si respondi si, Fue vinculado all? 6. Considera que usted como estudiante de la UFPS tendr mayores opciones de ser vinculado frente a egresados de otras universidades? 7. Seria ideal que la universidad contara con un portal de empleos en Internet? NO

146

A.6.2 PLANTILLA DE ENCUESTA A EGRESADOS DE LA UNIVERSIDAD FRANCISCO DE PAULA SANTANDER SI 1. A tenido algn empleo formal en los ltimos dos aos? 2. Se ha inscrito en alguna empresa o cooperativa para que lo ubiquen en alguna labor o trabajo? 3. A buscado empleo a travs de medios digitales como peridicos en la Web o bolsas de empleo en la Web? a.Si respondi si, Ha sido convocado? 4. Cuando realizo su practica empresarial fue vinculado all? 5. Considera que usted como egresado de la UFPS tendr mayores opciones de ser vinculado frente a egresados de otras universidades? 6. Seria ideal que la universidad contara con un portal de empleos en Internet?

NO

147

A.6.3 PLANTILLA DE ENCUESTA A DIRECTORES DE TALENTO HUMANO DEL SECTOR PRIVADO SI NO 1. A contratado egresados de la UFPS en los ltimos 12 meses? 2. A contratado estudiantes o practicantes de la UFPS en los ltimos 12 meses? 3. Para la contratacin utiliza: Contratacin directa___ Contratacin Indirecta___ Ambas____ 4. A buscado personal a travs de medios digitales como bolsas de empleo en la Web? a. Si respondi si, Ha tenido xito por all? 5. A contratado estudiantes que hayan realizado all su practica empresarial? 6. Considera que estn mejor preparados o con mayores opciones de ser vinculados las personas de la UFPS frente a egresados de otras universidades? 7. Si la UFPS le brindara acceso a un portal Web donde pueda encontrar el personal que necesita lo usara?

A.6.4 FORMATO DE INSCRIPCION DE EGRESADOS USADO POR LA OFICINA DEL EGRESADO VICERRECTORIA DE BIENESTAR UNIVERSITARIO

A continuacin se anexa el formato que usa la oficina del egresado como parte de la vinculacin a su base de datos, esta base de datos fsica (papel) tiene como objeto ofrecer los datos bsicos de perfil de un egresado a las distintas empresas que recurren a esta oficina.

148

149

A.6.5 TABULACION DE RESULTADOS Y GRAFICAS La siguiente tabla muestra los resultados de la encuesta a estudiantes de ltimos semestres de la Universidad Francisco de Paula Santander.
Pregunta P1 P2 P3 P4
A tenido algn empleo formal en los ltimos dos aos? Se ha inscrito en alguna empresa o cooperativa para que lo ubiquen en alguna labor o trabajo? A buscado empleo a travs de medios digitales como peridicos en la Web o bolsas de empleo en la Web? Ya realizo su practica empresarial Considera que usted como estudiante de la UFPS tendr mayores opciones de ser vinculado frente a egresados de otras universidades? Seria ideal que la universidad contara con un portal de empleos en Internet? Si respondi si a P3, Ha sido convocado? Si respondi si a P4, Fue vinculado all?

SI NO %Si %No 12 8 60 40 2 16 12 18 4 8 10 80 60 90 20 40

P5 P6 P3.A P4.A Total

17 20 8 2

85

15 0 50 83

0 100 8 10 50 17

20
Tabla A. 25. Tabulacin de resultados encuesta a estudiantes ltimos semestres UFPS

La siguiente es la grafica de los resultados de la encuesta.

Figura A. 13. Resultados de la encuesta a estudiantes ltimos semestres UFPS

150

La siguiente es la grafica de los resultados de la encuesta para el numeral 3.A y 4.A.

Figura A. 14. Resultados de la encuesta a estudiantes ltimos semestres UFPS-preguntas P3.A y P4.A

Analisis: Se nota que la gran mayoria de lso encuestados ya hacen uso de medios tecnologicos para buscar empleo, de los cuales la mitad de esos caso han sido exitosos ya que los han convocado a presentarse. Tambien se nota que a pesar de que un poco mas de la mitad ya realizo su practica empresarial no lograron engancharse alli, pero este mismo numero de personas que ya realizaron su practica es el mismo numero de personas que han tenido empleo en el ultimo ao, por lo cual no se ve impactado negativamente la no contratacion en indicadores de no empleo. A su vez la gran mayoria de encuestados ven que salir de egresado de la UFPS representa una ventaja significativa frente a otros egresados de otras univarsidades. Y en cuanto al nivel de aceptacion de un medio tecnologico para ellos por parte de la universidad en la busqueda de empleo se noto un total respaldo.

151

La siguiente tabla muestra los resultados de la encuesta a egresados de la Universidad Francisco de Paula Santander.
% SI NO SI %NO 25 5 83,3 16,7 14 16 46,7 53,3

Pregunta P1 P2

P3 P4

A tenido algn empleo formal en el ltimos ao? Se ha inscrito en alguna empresa o cooperativa para que lo ubiquen en alguna labor o trabajo A buscado empleo a travs de medios digitales como peridicos en la Web o bolsas de empleo en la Web? Cuando realizo su practica empresarial fue vinculado all? Considera que usted como egresado de la UFPS tendr mayores opciones de ser vinculado frente a egresados de otras universidades? Seria ideal que la universidad contara con un portal de empleos en Internet?
Si respondi si a P3, Ha sido convocado?

26 5

4 86,7 25 16,7

13,3 83,3

P5 P6 P3.a Total

19 28 12

11 63,3 2 93,3 8 46,2

36,7 6,7 30,8

30
Tabla A. 26. Tabulacin de resultados encuesta egresados UFPS

La siguiente es la grafica de los resultados de la encuesta.

152

Figura A. 15. Resultados de la encuesta a egresados UFPS

La siguiente es la grafica de los resultados de la encuesta para el numeral 3.A.

Figura A. 16. Resultados de la encuesta a egresados UFPS-pregunta P3.A

Analisis: Se nota que la gran mayoria de los encuestados ya hacen uso de medios tecnologicos para buscar empleo, de los cuales a diferencia de los estudiantes mas de la mitad de esos casos han sido exitosos ya que los han convocado a presentarse. Lo que indica que a un egresado se le facilita mas la obtencion de trabajo que un estudiante de ultimo semestre. Tambien en cuanto a formalizar un empleo en el mismo sitio despues de una practica empresarial se nota un mismo comportamiento que con los estudiantes ya que muy pocos lograron engancharse alli, pero este mismo numero de personas que ya realizaron su practica es el mismo numero de personas que han tenido empleo en el ultimo ao, por lo cual no se ve impactado negativamente la no contratacion en indicadores de no empleo. A su vez la gran mayoria de encuestados ven que ha sido mas beneficioso salir de egresado de la UFPS aunque este porcentaje no es tan grande como en los estudiantes lo cual puede suponer que hay egresados que han perdido una oportunidad laboral frente a otros egresados de una manera que no se esperaban. Y en cuanto al nivel de aceptacion de un medio tecnologico para ellos por parte de la universidad en la busqueda de empleo se noto un respaldo casi total.

153

La siguiente tabla muestra los resultados de la encuesta a Directores talento humano sector privado.
Pregunta P1 P2 P3 SI 5 5 2 1 2 5 3 2 NO % Si %No 100 100 40 20 40 100 60 0 40 0 0

A contratado egresados de la UFPS en los ltimos 12 meses? A contratado estudiantes o practicantes de la UFPS en los ltimos 12 meses? Para la contratacin utiliza: Directa Indirecta Ambas A buscado personal a travs de medios digitales como bolsas de empleo en la Web? A contratado estudiantes que hayan realizado all su practica empresarial? Considera que estn mejor preparados o con mayores opciones de ser vinculados las personas de la UFPS frente a egresados de otras universidades? Si la UFPS le brindara acceso a un portal Web donde pueda encontrar el personal que necesita lo usara? Si respondi si a P4, Ha tenido xito por all? 5

P4 P5

P6

80

20

P7 P4.A Total

5 5 0

100 100

0 0

Tabla A. 27. Tabulacin de resultados encuesta Directores talento humano sector privado

La siguiente es la grafica de los resultados de la encuesta.

154

La siguiente es la grafica de los resultados de la encuesta para 4.A.

Figura A. 17. Resultados de la encuesta a Directores talento humano sector privado

Figura A. 18. Resultados de la encuesta a Directores talento humano sector privado-pregunta P4.A

Las dos primeras preguntas muestran que la contratacion de personas egresadas, estudaintes o practicantes de la UFPS cuentan con la total credibilidad y respaldo por parte del sector privado. En cuanto al uso de medios tecnologicos para cubrir vacantes, todos lo dirtectores manifestaron si haberlos usado y tambien haber tenido xito en sus convocatorias realizadas por alli. Tambien se nota que la mayoria confia en el talento UFPS frente a otras hojas de vida que son presentadas por otros egresados y esto se confirma tanto en la pregunta 1 y 2 como en la 5, en la cual la mayoria ha contratado practicantes luego de haberlas terminado. En cuanto a la idea de querer usar un portal tecnolgico de parte de la UFPS se recibio un total apoyo a la idea y al uso de la misma.

155

156

A.7 MANUALES A.7.1 Manual de Instalacin

Para comenzar se revisa dentro del CD-ROM la carpeta Instaladores, figura A.20

Figura A. 19. Carpetas contenidas en el CD-ROM

Se escoge para iniciar el archivo appserv-win32-2.5.10_1.exe el cual tambin podemos conseguir en Internet del sitio http://www.appservnetwork.com/, esta versin contiene los siguientes programas Apache 2.2.4 PHP 5.2.3 MySQL 5.0.45 phpMyAdmin-2.10.2

Figura A. 20. Carpetas contenidas en el CD-ROM

Luego de que la instalacin haya finalizado se va al navegador y escribimos http://localhost y si aparece la siguiente pantalla indicara que la instalacin es correcta.

157

Figura A. 21. Pantalla de localhost

En caso de alguna falla se recomienda instalar el archivo mysql-gui-tools-5.0-r12win32.msi el cual tambin se puede conseguir en http://dev.mysql.com/downloads/gui-tools/5.0.html. Esta instalacin contiene los siguientes componentes: Administrador Migration toolkit Query Browser System Tray Monitor Ejecutamos el System Tray Monitor, el cual se ubica en Inicio/MySQL, este habilitara un icono en la parte inferior izquierda. La figura 23 y 24 muestra como ver esta opcin.

Figura A. 22. Ejecucin de System Tray Monitor

Luego de ejecutarlo aparecer el icono en la parte inferior izquierda como muestra la figura 24

158

Figura A. 23. Icono System Tray Monitor activo

Este icono nos muestra el estado de la instancia MySql, si esta en verde la instancia esta corriendo correctamente, en caso de aparecer en rojo significa que la instancia no esta corriendo por lo cual hay que configurarla, damos clic derecho sobre el icono y escogemos Configure Instance esto abrir el siguiente cuadro.

Figura A. 24. Icono System Tray Monitor inactivo

Se verifica la pestaa Configure service y se rectifica que las rutas concuerden con la carpeta donde quedo el MySQL instalado.

159

Figura A. 25. Ventana Configure Service

En caso de seguir el servicio sin funcionar, es mejor reinstalar el MySQL de forma separada o remitirse al manual de MySQL que se encuentra en la ruta cdrom\select\Manual\index.html. Para acceder a los manuales de instalacin solo es dirigirse a la carpeta donde este la aplicacin y buscar la carpeta Manual, all abrimos esta carpeta y ejecutamos en nuestro navegador el archivo Index.html La figura A.20 nos muestra dicha carpeta junto a las dems que componen nuestro sistema.

160

Figura A. 26. Ruta donde se ubican los manuales de instalacin

La figura A.28 nos muestra el contenido del archivo Index.html visto por un navegador

Figura A. 27. Men con las opciones de manual de instalacin visto desde un navegador.

Si ya nos aparece la pantalla de la figura A.22 procedemos a restaurar la copia de seguridad, que se encuentra en CD-Rom/select/ BD.sql, este archivo tiene el formato MySqlDump el cual lo podemos restaurar usando Sql-Yog que ya previamente se instalo. Damos clic derecho sobre la base de datos que se debera llamar SELECT, y se escoge Restore from SQL Dump
161

Se escoge la ruta que ya se enuncio y se da sobre Restore. En caso de error

Figura A. 28. Restaurar base de datos desde Sql-yog

En caso de error SQLyog al restaurar la base de datos, SqlYog genera un archivo con los errores encontrados y la lnea a la que le corresponde, para visualizarlo se da clic en Open Error File

Figura A. 29. Ventana error al restaurar base de datos desde Sql-yog

Despus de haber restaurado la base de datos, se procede a guardar los archivos del sistema SELECT, estos estn ubicados en CD-ROM\Select, se copia la carpeta completa en: Unidad destino:\appserv\www. (La unidad destino
162

corresponde donde se haya instalado). Con esto finaliza la instilacin del sistema, para comprobar que la correcta instalacin se entra al navegador y se digita: http://localhost/select. La cual mostrara la pantalla de inicio.

Figura A. 30. Pantalla de inicio del sistema Select

Una vez en la pantalla de inicio podremos ingresar por medio de los siguientes usuarios iniciales. Estudiante: Usuario: 123 Clave: 123 Egresado: Usuario: 111 Clave: 111 Empresa: Usuario: 222 Clave: 222 Director plan: Usuario: 444 Clave: 444 Administrador:Usuario: adm Clave: adm

163

A.7.2 Manual del usuario

A.7.2.1 USUARIO ESTUDIANTE/EGRESADO: Se debe digitar la direccin asignada para este servicio, la cual nos desplegara la pagina principal mostrada por la figura A.32.

Figura A. 31. Pagina principal de la opcin Estudiante/Egresado

Para ingresar como estudiante debemos escribir: En el campo Cdigo: Su cdigo dentro de la universidad. En el campo Clave: Su clave dentro de la universidad. En el caso de ser egresado: En el campo Cdigo: Su cdigo dentro de la universidad. En el campo Documento: Su nmero de documento de identidad Datos bsicos: Una vez ingresado y validado por el sistema este lo direccionara a la siguiente pantalla de datos bsicos.

164

Figura A. 32. Pagina de datos bsicos.

Esta pantalla se divide en 2 partes que se explican a continuacin: La zona azul, es el men de navegacin, all estn los links que me permitirn ir llenando los diferentes formularios y un ultimo link (Resultados) que permiten ir a una pantalla donde encontrar los clasificados vigentes. La zona verde son los datos bsicos del estudiante o egresado, en negrilla el sistema ya predeterminadamente carga la informacin que extrae del sistema de la universidad, por lo que solo resta completar los campos vacios. Hay que aclarar que los campos con (*) a su lado derecho son obligatorios para que el formulario sea correctamente guardado. Cuando un campo con (*) hace falta saldr alguno de los siguientes mensajes:

Figura A. 33. Mensaje comn cuando faltan datos en un formulario.

165

Figura A. 34. Pagina de datos bsicos cuando la informacin esta completa.

Aqu ya la pantalla de datos bsicos esta llena, una vez hecho esto solo es dar clic en el botn Insertar. Y mostrara lo siguiente, Registro grabado correctamente encima del formulario.

Figura A. 35. Mensaje comn cuando la informacin ha sido guardada.

166

Educacin Se llega all haciendo clic en el men, link Educacin

Figura A. 36. Pantalla de datos de educacion.

Esta opcin permite guardar la informacin de los estudios realizados por una persona, adicional este formulario contiene debajo una planilla donde se muestran los datos que se van guardando, ya que una persona puede tener varios estudios realizados, y dentro de esta planilla se cuenta con las opciones VER/EDITAR y ELIMINAR, que me permitirn ver la informacin completa del estudio escogido o eliminarlo si deseo. Al dar clic sobre VER/EDITAR, como vemos, me carga el formulario con los datos que se haban guardado. Si se desea modificar algo solo es cambiarlo y dar clic en Insertar.

167

Figura A. 37. Formulario de datos de educacin diligenciado.

Si se desea eliminar, solo es dar clic en Eliminar, y el me regresara a la misma pantalla solo que la planilla ya no contendr el registro que se borro, Nota: El sistema no pregunta por confirmacin antes de eliminar. Idiomas Llegamos all haciendo clic en el men, link Idiomas

Figura A. 38. Formulario de idiomas.

168

Esta opcin permite guardar la informacin de los idiomas y dialectos que conoce una persona, adicional permite detallar en que niveles lo domina, en su forma escrita, oral y de escucha.

Capacitacin Se llega all haciendo clic en el men, link Capacitacin

Figura A. 39. Formulario capacitacin.

Esta opcin permite guardar la informacin de las capacitaciones como lo son cursos, talleres, seminarios, congresos y dems. El formulario cuenta con la opcin de discriminar el tiempo en horas, das, semanas, meses o aos, para poder lograr ser mas detallado el ingreso de esta informacin.
169

Experiencia Laboral Se llega all haciendo clic en el men, link Experiencia Laboral.

Figura A. 40. Formulario Experiencia laboral.

Esta opcin permite guardar la informacin de las experiencias laborales de una persona, las funciones que realizaba y los logros, dando una mayor informacin cuando este perfil sea visitado. Datos Adicionales Llegamos all haciendo clic en el men, link Datos Adicionales.

170

Figura A. 41. Formulario Datos adicionales.

Esta opcin permite guardar la informacin de ciertos datos adicionales que pueden ser importantes para ayudar en la seleccin. Como si posee vehiculo, la licencia, si pertenece a alguna comunidad especial o si posee alguna discapacidad. Resultados Se llega all haciendo clic en el men, link Resultados.

Figura A. 42. Vista de resultados.

Esta opcin permite consultar las solicitudes que han ingresado las empresas, y se dividen en dos opciones, Vacantes de mi carrera, solicitudes propias de la carrera y Vacantes en general, que no van enfocadas a una carrera en especial.

171

A continuacin se ve un ejemplo de estas dos partes, la primera parte es para Ingeniera de sistemas y la segunda es una solicitud para cualquier persona.

Figura A. 43. Vista de resultados expandida.

A su vez se pueden ver mas detalles de la propuesta y los datos de la empresa y en caso de que sea de inters, postularme. Con esa opcin la empresa recibir una notificacin para que vean el perfil de la persona.

172

A.7.2.2 Manual del usuario Empresa

Registrarse Se debe digitar la direccin asignada para este servicio, una vez aceptemos nos desplegara la pagina principal la cual es mostrada por la figura A.45.

Figura A. 44. Pagina principal.

En la pantalla principal se da clic en Registre su empresa. Este mostrara la siguiente pantalla.

173

Figura A. 45. Pagina de registro de empresa.

En este formulario se ingresan los datos principales de una empresa, Nit, nombre, actividad comercial, domicilio, etc. Al final existen unas condiciones que deben ser aceptadas las cuales constituyen trminos para garantizar un buen uso del sistema y proteccin de las personas que en lo posible sean contactadas a travs de este medio. Los campos con (*) a la derecha son obligatorios para que se pueda guardar la informacin. Una vez registrado correctamente, se da clic en PAGINA PRINCIPAL y se procede a ingresar al sistema de la siguiente manera.

174

Figura A. 46. Pagina de principal empresa

Escribir En el campo Nit: El nit de la empresa. En el campo Clave: Su clave registrada. Una vez se ingresa correctamente el sistema se ubica en la seccin de Datos bsicos

175

Figura A. 47. Pagina de datos basicos

All aparecen precargados todos los datos que se ingresaron al registrar la empresa, y pueden a su vez ser modificados, a excepcin del NIT y la fecha en la que se registro la empresa. Cabe Solicitudes Llegamos all haciendo clic en el men, link Solicitudes.

176

Figura A. 48. Pagina de datos bsicos

En este formulario se crearan todas las solicitudes de empleo que una empresa requiera. Se describe el trabajo, el pago, el tipo de jornada, el nivel acadmico que se requiere y las carreras a las que se enfoca la solicitud. Debajo del formulario se mostraran todas las solicitudes que ya tenga la empresa guardada y si se desea modificarla o eliminarla se puede hacer desde all. Resultado Se llega all haciendo clic en el men, link Resultado.

Figura A. 49. Pagina de resultados

Esta opcin permite a la empresa en tiempo real hacer la bsqueda de sus candidatos, el sistema los divide en dos, los primeros opcionados, que son los que
177

prcticamente cumplen con los requisitos de Nivel acadmico, de Idiomas, de Conocimientos y los segundos opcionados que son aquellos que estn muy cerca de cumplir todos los requisitos. Cuando se da clic en VER PRIMEROS OPCIONADOS Se despliega lo siguiente:

Figura A. 50. Pagina de resultados expandida

El nombre de la persona completo, su carrera y un link llamado mas detalles que permite ver su hoja de vida completa. Tambin cuenta con un link Contactar, el cual al darle clic enviara un mail, avisando que dicha empresa lo requiere para cumplir con la solicitud.

178