universidad central del ecuador - … · 2013-06-25 · en primer a mi madre por haberme apoyado...

i

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA, CIENCIAS, FÍSICA Y MATEMÁTICA

Carrera de Ingeniería Informática

AUTOMATIZACIÓN DEL SEGUIMIENTO DE PROYECTOS Y CONTRATOS

REALIZADOS EN EL INSTITUTO SUPERIOR DE INVESTIGACIONES (ISI), EN LA

FACULTAD DE INGENIERÍA EN GEOLOGÍA, MINAS, PETROLEOS Y

AMBIENTAL.

MÓDULO: AUTOMATIZACIÓN DE SEGUIMIENTO DE PROYECTOS

TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE

INGENIERO INFORMÁTICO

AUTOR: Jorge Paul Quishpe Pila TUTOR: Ing. Aldrin Flores

Quito, 12 de Mayo del 2013

ii

DEDICATORIA

Mi tesis la de dedico, a la Institución por brindarme todos los conocimientos

adecuados para formarme como un profesional para poder contribuir al

desarrollo del país.

A todos los ingenieros de la Facultad de Ingeniería en Geología, Minas,

Petroleos y Ambiental que nos brindaron el apoyo y colaboración necesaria

para poder realizar con existo el proyecto.

A mi madre que me brindo todo el apoyo necesario, incluso en los momentos

más difíciles.

A mis amigos que supieron ayudarme durante todo el transcurso en esta

prestigiosa Universidad y a mis compañeros de trabajo que me brindaron su

apoyo durante el desarrollo del proyecto.

iii

AGRADECIMIENTO

En primer a mi Madre por haberme apoyado durante todos estos años de

carrera; en segundo lugar mis hermanos a mis amigos; por siempre haberme

dado su fuerza y apoyo que me han ayudado a llegar hasta donde estoy ahora.

Agradezco a mis profesores por todo el conocimiento impartido, a todas las

personas quienes me brindaron el apoyo para el desarrollo de esta tesis.

Por último a la Universidad Central del Ecuador, a la Facultad de Ingeniería

Informática que me supo acoger para poder formarme como un profesional.

viii

CONTENIDO

CAPÍTULO I ............................................................................................................. 1

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

1.2 FORMULACIÓN DEL PROBLEMA ....................................................... 2

1.3 OBJETIVOS ........................................................................................... 4

1.3.1 GENERAL .......................................................................................... 4

1.3.2 ESPECIFICOS ................................................................................... 5

1.4 ANTECEDENTES .................................................................................. 5

1.5 METODOLOGÍA. ................................................................................... 6

1.6 ALCANCE .............................................................................................. 7

1.7 RESULTADOS ESPERADOS ................................................................ 9

CAPÍTULO II ...........................................................................................................10

MARCO TEÓRICO .................................................................................................10

2.1 APLICACIÓN WEB ...............................................................................10

2.2 ARQUITECTURA N-CAPAS .................................................................12

2.3 INGENIERÍA WEB BASADA EN UML - UWE .......................................14

2.3.1 DÍAGRAMA DE SECUENCIA ............................................................16

2.3.2 DÍAGRAMAS DE ESTADOS .............................................................18

2.4 PATRÓN DE DISEÑO ..........................................................................19

2.4.1 PATRÓN DE DISEÑO J2EE ..............................................................20

2.5 CASOS DE USO ...................................................................................24

2.6 HERRAMIENTAS ..................................................................................27

2.6.1 JAVA......................................................................................................27

2.6.2 JBOSS ...................................................................................................27

2.6.3 ECLIPSE ...............................................................................................29

2.6.4 POSTGRESQL ......................................................................................31

2.6.5 RICHFACES ..........................................................................................36

2.6.6 JSF ........................................................................................................36

2.6.7 EJB ........................................................................................................37

CAPÍTULO III ..........................................................................................................39

3.1 ESPECIFICACIÓN DE REQUERIMIENTOS .........................................39

3.1.1 CAPTURA DE REQUERIMIENTOS ..................................................39

3.1.2 DEFINICIÓN DE REQUERIMIENTOS ...............................................39

CAPÍTULO IV .........................................................................................................56

4.1 MODELO LÓGICO CONCEPTUAL ......................................................56

ix

4.2 DIAGRAMAS DE SECUENCIA .............................................................57

4.3 DIAGRAMAS DE ESTADOS .................................................................62

CAPÍTULO V ..........................................................................................................67

IMPLEMENTACIÓN Y PRUEBAS ..........................................................................67

5.1 IMPLEMENTACIÓN ..............................................................................67

5.2 PRUEBAS .............................................................................................77

5.2.1 PRUEBAS DE CAJA BLANCA ..........................................................77

5.2.2 PRUEBAS DE INTEGRACIÓN ORIENTADA A OBJETOS ...............79

5.2.3 PRUEBAS DE INTERFAZ .................................................................80

5.2.4 PRUEBAS DE VALIDACIÓN .............................................................80

5.2.5 PRUEBAS BASADAS EN ERRORES ...............................................81

CAPÍTULO VI .........................................................................................................82

CONCLUSIONES Y RECOMENDACIONES ..........................................................82

6.1 CONCLUSIONES .................................................................................82

6.2 RECOMENDACIONES .........................................................................84

BIBLIOGRAFÍA .......................................................................................................85

ANEXOS ................................................................................................................87

Anexo A ..............................................................................................................88

Anexo B ..............................................................................................................90

Anexo C ..............................................................................................................91

Anexo D ..............................................................................................................97

Anexo E ............................................................................................................ 112

x

LISTADO DE FIGURAS

Figura. 2.1: Arquitectura n-capas………………………………………………. 12

Figura. 2.2: Diagrama de Ingeniería Web basada en UML…………………. 14

Figura. 2.3: Elementos de un diagrama de secuencia…………………..…… 17

Figura. 2.4: Ejemplo de diagrama de estado………………………………….. 18

Figura. 2.5: Catálogo de patrones de Core J2EE Patterns………………….. 24

Figura. 2.6: Diagrama de Casos de Uso………………………………………. 24

Figura. 2.7: Arquitectura de PostgreSQL………………………………………. 31

Figura. 3.1: Caso de Uso Proyecto…………………………………………….. 40

Figura. 3.2: Caso de Uso Actividad……………………………………………. 43

Figura. 3.3: Caso de Uso Recurso…………………………………………….. 46

Figura. 3.4: Caso de Uso Avance Proyecto…………………………………… 49

Figura. 3.5: Caso de Uso Control Actividad…………………………………… 53

Figura. 4.1: Diagrama de Clases…………………………………………….…. 56

Figura. 4.2: Diagrama de Secuencia Proyecto………………………………... 57

Figura. 4.3: Diagrama de Secuencia Actividad………………………………... 58

Figura. 4.4: Diagrama de Secuencia Recurso………………………………… 59

Figura. 4.5: Diagrama de Secuencia Avance Proyecto………………………. 60

Figura. 4.6: Diagrama de Secuencia Control Actividad………………….…… 61

Figura. 4.7: Diagrama de Estados Proyecto…………………………………… 62

Figura. 4.8: Diagrama de Estados Actividad…………………………………... 63

Figura. 4.9: Diagrama de Estados Recurso…………………………………… 64

Figura. 4.10: Diagrama de Estados Avance…………………………………… 65

Figura. 4.11: Diagrama de Estados Control Actividad………………………... 66

xi

LISTADO DE TABLAS

Tabla 2.1: Capa de Presentación……………………………………………….. 21

Tabla 2.2: Capa de Negocios……………………………………………………. 22

Tabla 2.3: Capa de Integración…………………………………………………. 23

Tabla 2.4: Limites de PostgreSQL……………………………………………… 35

Tabla 5.1: Pruebas de Integración……………………………………………… 79

Tabla 5.2: Prueba de Interfaz…………………………………………………… 80

xii

RESUMEN



FACULTAD DE INGENIERÍA EN GEOLOGÍA, MINAS, PETROLEOS Y AMBIENTAL

El presente proyecto muestra la importancia y eficiencia de tener un

repositorio automatizado de información, además el control que se debe

realizar al seguimiento de los procesos.

Principalmente el proyecto permite mediante una aplicación web facilitar el

manejo y control eficiente de la información de los procesos que maneja

actualmente en el Instituto Superior de Postgrado de la Facultad de Ingeniería

en Geología, Minas y Petróleos de la Universidad Central del Ecuador (ISI-

FIGEMPA), tanto para el seguimiento de proyectos y contratos. Reduciendo

en su totalidad el papeleo y adecuándose a nuevas tecnologías de

Información.

DESCRIPTORES:

APLICACIÓN WEB / JSF / EJB / JPA / HIBERNATE / POSTGRESQL /

IREPORT / FUSION CHARTS / SEGUIMIENTO / PROYECTOS

xiii

ABSTRACT



FACULTAD DE INGENIERÍA EN GEOLOGÍA, MINAS, PETROLEOS Y AMBIENTAL

The present Project shows the importance and efficience of having an

automated repository of information, also the control that must be applied to

the monitoring process.

Mainly, this Project lets to make easy the manage and control of efficient

information of process applied in the Instituto Superior de Postgrado de la

Facultad de Ingeniería en Geología, Minas y Petróleos de la Universidad

Central del Ecuador (ISI-FIGEMPA), through a web application; used to both

monitoring of projects and contracts. Reducing paperwork whole, adapting to

new information technologies.

DESCRIPTORS:

WEB APPLICATION / JSF / EJB / JPA / HIBERNATE / POSTGRESQL /

IREPORT / FUSION CHARTS / MONITORING / PROJECT

1

CAPÍTULO I

1.1 INTRODUCCIÓN

El desarrollo de nuevas tecnologías informáticas, ayudan a mejorar las

diferentes entidades que hacen uso de estas, aumentando así su

productividad y tiempo de respuesta a las nuevas necesidades que se pueden

presentar en un determinado momento.

Hasta el día de hoy, lo más importante en el desarrollo de aplicaciones Web

han sido las herramientas, pero muy poco se ha dicho y escrito sobre el

proceso de desarrollo. La fácil creación de sitios Web, usando herramientas

básicas, ha hecho que el desarrollo de este tipo de aplicaciones se realice sin

un trabajo serio de análisis y diseño, sin tomar en cuenta que cualquier

sistema de complejidad no trivial, necesita ser analizado y modelado. Las

aplicaciones Web, al igual que otras aplicaciones, necesitan métodos y

técnicas formales de análisis y diseño.

El Instituto Superior de Investigación y Posgrado de la Facultad de Ingeniería

en Geología, Minas, Petróleos y Ambiental de la Universidad Central del

Ecuador (ISI - FIGEMPA), en la actualidad realiza la mayoría de sus procesos

en forma manual, como:

• Búsqueda en archivadores de Documentos pertenecientes a

Contratos o Proyectos.

• Aprobación y control de tiempos del proyecto.

• Recolección de hojas de vidas, para los diversos contratos.

• Asignación de contratos en el proyecto.

• Búsqueda de proyectos en archivadores, entre otros.

Lo que se pretende es la automatización, a través de un sistema informático

que cumpla con los requerimientos del departamento para el correcto

seguimiento de Proyectos y Contratos teniendo un registro digital de dicho

trabajo, es de mucha importancia y de suma urgencia.

El propósito y objetivo de este trabajo es la administración de proyectos.

2

1.2 FORMULACIÓN DEL PROBLEMA

PLANTEAMIENTO DEL PROBLEMA:

ISI - FIGEMPA, actualmente no consta con un sistema Informático que les

permita llevar un registro de todos los proyectos y contratos que administra.

ISI - FIGEMPA lleva un registro de sus investigaciones, seguimientos y

administración de los diferentes proyectos y contratos, pero no cuentan con

una tecnología adecuada para gestionarlos, existiendo la necesidad de crear

un sistema que les permita actualizarse y beneficiarse de la tecnología para

así tener un mejor control de la información.

SEGUIMIENTO DE PROYECTOS:

El seguimiento consiste en el análisis y recopilación de la información a

medida que avanza un proyecto, tiene como objetivo mejorar la eficacia y

eficiencia de sus procesos, como asignación de tiempos y actividades,

búsquedas de proyectos, control y seguimiento de recursos tanto físicos

como económicos, etc.; basándose en metas y actividades planificadas

durante las distintas fases de su desarrollo.

Con la automatización se ayudará a que se siga una línea de trabajo, que

permite a la administración conocer que se está haciendo lo que se había

planificado, determinar si los recursos disponibles son suficientes y están bien

administrados, y si la cantidad y el volumen de trabajo es suficiente y

adecuado para un proyecto.

Por tanto realizar un seguimiento adecuado de los proyectos es importante

para el bienestar no solo de la entidad, sino de todos los involucrados en el

proyecto. Puesto que escuchar un simple “vamos bien”, como respuesta por

parte de todos los recursos no podría ser exactamente eso.

3

PROPUESTA DE SOLUCIÓN:

La solución que se plantea dar es:

Crear un sistema web para automatizar el seguimiento de proyectos y

contratos en ISI - FIGEMPA, donde permita realizar el seguimiento y control

de sus procesos. El proyecto consistirá en dos módulos uno para contratos y

otro para proyectos los cuales serán tratados como sistemas independientes

para luego implementarlos en un solo sistema, que permitirá:

Asignar recursos y actividades a diferentes proyectos.

Búsquedas ágiles de sus contratos y proyectos.

Mantener información puntual de todos los adjuntos en los proyectos y

contratos.

Crear un repositorio de datos en que consten: contratos, proyectos así como

también de currículos de las personas involucradas en proyectos y contratos

anteriores.

Descartar en gran cantidad la utilización de papel (Conciencia con medio

ambiente, registros seguros, no se pierde o daña en obra)

Para el desarrollo del sistema ISI - FIGEMPA facilitará la información y la labor

correspondiente de cómo se manejan los procesos a automatizar para dicha

aplicación. Para lograr lo antes planteado se lo realizará mediante análisis de

los requerimientos que manejan, recolectando datos, realizando diagramas y

unificando procesos.

La aplicación estará dividida en dos módulos:

Seguimiento de Proyectos

Seguimiento de Contratos

Como se mencionó anteriormente el objetivo de este trabajo es la

administración de proyectos.

4

SEGUIMIENTO DE PROYECTOS

El seguimiento de un proyecto permitirá comprobar el estado en el que se

encuentra un trabajo en desarrollo, como:

Revisar su progreso, es decir conocer cómo avanza el proyecto y

si los recursos asignados son suficientes.

Identificar problemas en la planificación y/o en la puesta en

práctica.

Hacer ajustes de modo que se tenga más probabilidades de

encontrar cambios en las actividades o en los recursos que se

utilicen en el proyecto en el momento adecuado.

Consiguiendo con esto proveer una adecuada visibilidad a la administración

sobre la situación del proyecto para identificar oportunamente

cualquier desviación contra lo planeado con el objetivo de tomar

decisiones oportunas para corregirlas.

Por tanto se realizará e implementará un sistema que permita a ISI-FIGEMPA,

automatizar el seguimiento de sus proyectos.

1.3 OBJETIVOS

1.3.1 GENERAL

Realizar el Análisis, Diseño e implementación de una aplicación en

línea que permita optimizar el seguimiento de proyectos y contratos

realizados en ISI-FIGEMPA. Logrando un aporte al desarrollo

tecnológico en dicha facultad y que esto a su vez brinde información

necesaria para su gestión.

5

1.3.2 ESPECIFICOS

Desarrollar los módulos de contratos y proyectos e integrarlos

en un solo sistema.

Desarrollar la sistematización automática del seguimiento de

los diferentes procesos de los proyectos y contratos como

son: control, mantenimiento, aceptación y etapas de

desarrollo.

Sistematizar el flujo, registro y manejo de la información de

proyectos y contratos como: propósitos, objetivos,

metodologías, investigadores, mediante el uso del sistema.

Mantener un historiador de la información de proyectos y

contratos para futuras investigaciones.

Mantener un historiador de los recursos humanos y físicos

que intervienen en cada proyecto y contratos.

Generar reportes, consultas e información que faciliten la

gestión en ISI-FIGEMPA.

1.4 ANTECEDENTES

Si se puede imaginar un proyecto perfecto, con un plan basado en

necesidades y objetivos reales y precisos del cliente y usuarios, una

estimación con técnicas formales basadas en estadísticas de productividad

del equipo y empresa, y un equipo de trabajo sumamente capaz. Todo parece

perfecto, y en teoría no existe forma de que falle.

Pero esto casi siempre no sucede por diversos motivos, entonces como se

conoce cuál es el avance real en un proyecto; en base a que los jefes de

proyecto o la empresa encargada pueden constatar que en verdad el proyecto

avanza. Para esto es necesario tener un control adecuado del proyecto,

verificando en cada una de sus faces el avance que se tuvo.

6

Es por esta razón que todo organización debe realizar o tener un control de

sus procesos, y en el caso de ISI-FIGEMPA lo hacen manualmente, por esto

las organizaciones han implementado sistemas que facilitan esta tarea, que

además brindan un apoyo para llevar este control en sus procesos, y la

Universidad y sobre todo ISI-FIGEMPA, debería contar con un sistema que le

permita tener un control de sus procesos, que les facilite esta tarea.

1.5 METODOLOGÍA.

La metodología que se plantea a utilizar en el desarrollo de esta aplicación

web es:

Ingeniería Web basada en UML (UWE). Ésta cubre todo el ciclo de vida de las

aplicaciones Web centrando además su atención en aplicaciones

personalizadas. Además, describe un diseño sistemático, basado en técnicas,

notación y mecanismos de extensión de UML (Lenguaje Unificado de

Modelado).

Para satisfacer los requerimientos de usuario y las características especiales

que tienen las aplicaciones Web, UWE define vistas especiales representadas

gráficamente por diagramas en UML, tales como el modelo de navegación y

el modelo de presentación. Además, UWE permite que un diseñador Web

pueda también hacer uso de otra técnica de modelado UML que agreguen

otras vistas de la aplicación, en otras palabras, UWE no limita el número de

vistas posibles de una aplicación. Las técnicas de modelado en UML abarcan

la construcción de vistas estáticas y dinámicas de los sistemas de software:

diagramas del objeto y de clase, diagramas de componentes, diagramas de

casos de uso, diagramas de estado y de actividades, de secuencia y

diagramas de la colaboración.

Además de esta colección de diagramas, el UML proporciona mecanismos de

extensión basados en estereotipos. Estos mecanismos de extensión son los

que UWE utiliza para definir estereotipos que son lo que finalmente se

utilizarán en las vistas especiales para el modelado de aplicaciones Web. De

esta manera, se obtiene una notación UML adecuada a un dominio en

7

específico a la cual se le conoce como Perfil UML.

Así como también el uso de herramientas:

Software:

Sistema Operativo Windows 7 de 64 bits.

Visual Paradigm: software de modelado UML que soporta UML,

SysML, ERD, BPMN, DFD, ArchiMate, etc.

ArgoUWE: Herramienta CASE para modelado de aplicaciones

web.

Jboss 7.1.1: Servidor de aplicaciones.

Eclipse Indigo: entorno de desarrollo integrado para java.

PostgresSQL: Sistema de Gestión de Base de Datos

relacional orientado a objetos y libre.

Hardware:

PC portátil: HP Pavilion G4-1285la

PC de escritorio

Impresora

Dispositivos de almacenamiento: flash, discos externos, cd.

Tarjetas y dispositivos de red

1.6 ALCANCE

El proyecto que se propone en el presente documento facilitará el seguimiento

de proyectos y contratos realizados en ISI-FIGEMPA, mediante el registro de

cada uno de ellos. Para lograrlo, el sistema se compondrá de dos módulos:



http://es.wikipedia.org/wiki/Modelo_relacional

http://es.wikipedia.org/wiki/Software_libre

8

SEGUIMIENTO DE PROYECTOS:

Para mantener el seguimiento y control de un proyecto se necesita contar con

información precisa de lo que está ocurriendo en todos sus procesos y en

cada una de sus actividades. Es por eso que se ha visto necesario crear un

sistema para ISI-FIGEMPA, que permita automatizar los procesos que

intervienen en el seguimiento de sus proyectos.

Sin embargo el seguimiento de un proyecto en ISI-FIGEMPA no es una tarea

sencilla, por la cantidad y densidad de recursos que se manejan, además de

los indicadores usados en proyecto, por tanto el seguimiento de los proyectos

en ISI-FIGEMPA se lo hará en base a un cronograma controlando los

entregables y si es posible el presupuesto que implica con el avance del

proyecto, permitiendo al coordinador del proyecto y a las autoridades

encargadas tener un adecuado control del proyecto.

Por lo que será necesario trabajar en conjunto con ISI-FIGEMPA, ya que ellos

actualmente son los que manejan esa información de forma manual, y

conocen como realizan ese seguimiento en cada uno de sus proyectos.

El módulo de proyectos incluirá las siguientes características como parte de

la funcionalidad:

Trazabilidad del proyecto en todo momento (Cuándo se inició,

que se entregó al final de cada fase o en fechas establecidas de

entregas, porcentaje de avances, cuando finalizo).

Almacenamiento de entregables entregados según el

cronograma.

Almacenamiento de anexos a las actividades (tareas registradas

en el sistema en cada proyecto).

Búsqueda de proyecto en un repositorio de proyectos.

Almacenamiento de proyectos.

Anexos a los proyectos

Administración de usuarios y de roles de usuarios

9

Alertas y notificaciones automáticas, que de manera proactiva,

ayuden a controlar el proyecto si un entregable ya llega a su

fecha límite.

Descartar en gran cantidad la utilización de papel (Conciencia

con medio ambiente, registros seguros, no se pierde o daña en

obra)

Extracción de indicadores de estado del proyecto.

Una vez obtenido todo lo necesario para la automatización de los procesos

antes mencionados, se procederá con el desarrollo, pruebas e

implementación del sistema.

1.7 RESULTADOS ESPERADOS

Los resultados que se esperan obtener al desarrollar el sistema son los

siguientes:

Que el sistema ayude a mantener un control adecuado de los

proyectos que se manejan en ISI-FIGEMPA.

Poder extraer indicadores adecuados que permitan realizar un

seguimiento adecuado de los proyectos.

10

CAPÍTULO II

MARCO TEÓRICO

2.1 APLICACIÓN WEB

Una aplicación web es cualquier aplicación que es accedida vía web por una

red como internet o una intranet.

En general, el término también se utiliza para designar aquellos programas

informáticos que son ejecutados en el entorno del navegador (por ejemplo,

un applet de Java) o codificado con algún lenguaje soportado por el navegador

(como JavaScript, combinado con HTML); confiándose en el navegador web

para que reproduzca la aplicación.

Una de las ventajas de las aplicaciones web cargadas desde internet (u otra

red) es la facilidad de mantener y actualizar dichas aplicaciones sin la

necesidad de distribuir e instalar un software en, potencialmente, miles de

clientes. También la posibilidad de ser ejecutadas en múltiples plataformas.1

El éxito espectacular de la web se basa en dos puntales fundamentales: el

protocolo HTTP y el lenguaje HTML. Uno permite una implementación simple

y sencilla de un sistema de comunicaciones que nos permite enviar cualquier

tipo de ficheros de una forma fácil, simplificando el funcionamiento del servidor

y permitiendo que servidores poco potentes atiendan miles de peticiones y

reduzcan los costes de despliegue. El otro nos proporciona un mecanismo de

composición de páginas enlazadas simple y fácil, altamente eficiente y de uso

muy simple2.

Ventajas y Desventajas de una aplicación Web:

1 Alegsa.com.ar, Definición de aplicación web, http://www.alegsa.com.ar/Dic/aplicacion%20web.php, revisado: 17/03/2013. 2 Carles Mateu, Desarrollo de aplicaciones web, http://www.sw-computacion.f2s.com/Linux/004-

Desarrollo_de_aplicaciones_web.pdf

11

Ventajas:

Las aplicaciones web requieren poco o nada de espacio en disco.

Además suelen ser livianas.

No requieren que los usuarios las actualicen, eso es implementado

del lado del servidor.

Proveen gran compatibilidad entre plataformas (portabilidad), dado que

operan en un navegador web.

Desventajas:

Incluso muchas veces requieren las extensiones apropiadas y

actualizadas para operar.

Las aplicaciones web requieren navegadores web totalmente

compatibles para funcionar.

Muchas veces requieren una conexión a internet para funcionar, si la

misma se interrumpe, no es posible utilizarla más. De todas maneras,

en ocasiones, pueden ser descargadas e instaladas localmente para su

uso offline.

Muchas no son de código abierto, perdiendo flexibilidad.

La aplicación web desaparece si así lo requiere el desarrollador o si

el mismo se extingue. Las aplicaciones tradicionales, en general,

pueden seguir usándose en esos casos.

El usuario, en general, no tiene libertad de elegir la versión de

la aplicación web que quiere usar. Un

usuario podría preferir usar una versión más antigua, hasta que

la nueva sea probada.

En teoría, el desarrollador de la aplicación web

puede rastrear cualquier actividad que el usuario haga. Esto

puede traer problemas de privacidad. 3

3 Alegsa.com.ar, Ventajas y Desventajas de una aplicación web, http://www.alegsa.com.ar/Dic/aplicacion%20web.php,

revisado: 17/03/2013.

http://www.alegsa.com.ar/Definicion/de/poco.php

http://www.alegsa.com.ar/Definicion/de/nada.php

http://www.alegsa.com.ar/Definicion/de/espacio.php

http://www.alegsa.com.ar/Definicion/de/disco.php

http://www.alegsa.com.ar/Definicion/de/lado.php

http://www.alegsa.com.ar/Definicion/de/servidor.php

http://www.alegsa.com.ar/Definicion/de/gran.php

http://www.alegsa.com.ar/Definicion/de/compatibilidad.php

http://www.alegsa.com.ar/Definicion/de/entre.php

http://www.alegsa.com.ar/Definicion/de/dado.php

http://www.alegsa.com.ar/Definicion/de/para.php

http://www.alegsa.com.ar/Definicion/de/operar.php

http://www.alegsa.com.ar/Definicion/de/conexion.php


http://www.alegsa.com.ar/Definicion/de/funcionar.php

http://www.alegsa.com.ar/Definicion/de/posible.php


http://www.alegsa.com.ar/Definicion/de/codigo.php

http://www.alegsa.com.ar/Definicion/de/flexibilidad.php

http://www.alegsa.com.ar/Definicion/de/aplicacion.php

http://www.alegsa.com.ar/Definicion/de/mismo.php

http://www.alegsa.com.ar/Definicion/de/general.php

http://www.alegsa.com.ar/Definicion/de/seguir.php

http://www.alegsa.com.ar/Definicion/de/usuario.php


http://www.alegsa.com.ar/Definicion/de/preferir.php

http://www.alegsa.com.ar/Definicion/de/usar.php

http://www.alegsa.com.ar/Definicion/de/hasta.php

http://www.alegsa.com.ar/Definicion/de/teoria.php

http://www.alegsa.com.ar/Definicion/de/aplicacion.php

http://www.alegsa.com.ar/Definicion/de/cualquier.php


http://www.alegsa.com.ar/Definicion/de/traer.php

12

2.2 ARQUITECTURA N-CAPAS

Una arquitectura n-capas es una arquitectura cliente servidor, donde la

principal característica es que permite separar la lógica del negocio de la

lógica de diseño (interfaz de usuario); de esta forma se consigue que si algún

nivel presenta un cambio o modificación solo sea vea afecto divo nivel;

además de tener estructurada la aplicación conociendo exactamente donde

se encuentra cada nivel.

Figura 2.1: Arquitectura n-capas.

Donde la funcionalidad de cada capa es la siguiente:

Capa de presentación

Es responsable de la presentación de los datos, recibiendo los

eventos de los usuarios y controlando la interfaz de usuario.

13

Capa de lógica de negocios

Esta capa es nueva, es decir, no está presente en la arquitectura en

2 capas en forma explícita.

Los objetos de negocios que implementan las reglas de negocios

“viven” aquí, y están disponibles para la capa de presentación.

Esta capa es la clave para resolver los problemas de la arquitectura

en 2 capas

Protege del acceso directo a la información desde la capa de

presentación

Capa de persistencia (Capa de Datos)

Es responsable del almacenamiento de los datos.

Es común reusar sistemas existentes de bases de datos en esta

capa.

Actualmente se usan manejadores relacionales: son avanzados,

permiten el uso de triggers y paquetes. Existen manejadores

Orientados a Objetos.4

La fuerza de la arquitectura n-capas radica en su capacidad de separar tareas

en un nodo central de la red, lo que permite su escalabilidad y fiabilidad;

además de que nos permite trabajar con cliente ligeros, es decir, sin necesidad

de tener grandes recursos para acceder a un aplicación basada en esta

arquitectura, simplemente un dispositivo con acceso a internet, puesto que al

estar separada se distribuye la carga de procesamiento en los clientes.

4 Andrés Vignaga – Daniel Perovich, Arquitecturas y Tecnologías para el Desarrollo de Aplicaciones Web,

http://www.fing.edu.uy/inco/grupos/coal/uploads/Investigaci%F3n/vp01.pdf, Revisado 17/03/2013

14

2.3 INGENIERÍA WEB BASADA EN UML - UWE

Los enfoques de modelos Web son impulsados comúnmente por la

separación o estructura que describe el sistema, como el contenido, la

estructura, presentación y procesos.

Ingeniería Web basada en UML (UWE) es un enfoque que proporciona un

conjunto de elementos web para el modelar la estructura del sistema web.

Estos elementos del modelo y las relaciones entre ellos son especificados por

un metamodelo (modelo de referencia). Los metamodelo UWE se definen

como una extensión conservadora de la metamodelo UML 2.0. Conservador

significa que los elementos del modelo del metamodelo UML no se modifican.

En su lugar, todos los elementos del nuevo modelo del metamodelo UWE

están relacionados por herencia a los elementos del modelo al menos a uno

de los metamodelo UML.

La ventaja es que todas las herramientas estándar de UML CASE que

soportan perfiles UML o mecanismos de extensión de UML se pueden utilizar

para crear modelos de UWE, de aplicaciones web.5

Figura. 2.2: Diagrama de Ingeniería Web basada en UML.

UWE está especializada en la especificación de aplicaciones adaptativas, y

por tanto una de sus características principales es la personalización, como

es la definición de un modelo de usuario o una etapa de definición de

5 Institute for Informatics, Programming and Software Engineering Unit (PST), Ludwig-Maximilians-Universität München,

Germany

15

características adaptativas de la navegación en función de las preferencias,

conocimiento o tareas de usuario.

Otras características relevantes del proceso y método de autoría de UWE son

el uso del paradigma orientado a objetos, su orientación al usuario, la

definición de un metamodelo (modelo de referencia) que da soporte al método

y el grado de formalismo que alcanza debido al soporte que proporciona para

la definición de restricciones sobre los modelos.6

Fases del Desarrollo Web.

Por lo que respecta al proceso de desarrollo de la aplicación, UWE hace un

uso exclusivo de estándares reconocidos como UML y el lenguaje de

especificación de restricciones asociado OCL. Para simplificar la captura de

las necesidades de las aplicaciones web, UWE propone una extensión que se

utiliza a lo largo del proceso de desarrollo. Este proceso de desarrollo está

dividido en cuatro pasos o actividades:

Análisis de Requisitos: Fija los requisitos funcionales de la

aplicación Web para reflejarlos en un modelo de casos de uso.

Diseño Conceptual: Materializado en un modelo de dominio,

considerando los requisitos reflejados en los casos de uso.

Diseño de Navegación: Lo podemos subdividir en:

o Modelo del Espacio de Navegación.

o Modelo de la Estructura de Navegación: Muestra la forma de

navegar ante el espacio de navegación.

Diseño de Presentación: Representa las vistas del interfaz del

usuario mediante modelos estándares de interacción UML.6

Por tanto UWE es un proceso del desarrollo para aplicaciones Web enfocado

sobre el diseño sistemático, la personalización y la generación

semiautomática de escenarios que guíen el proceso de desarrollo de una

6 The Authoring Process of the UML-based Web Engineering Approach (Nora Koch 1,2, Andreas Kraus1, Rolf Hennicker1)

16

aplicación Web. UWE describe una metodología de diseño sistemática,

basada en las técnicas de UML, la notación de UML y los mecanismos de

extensión de UML.

Metodología UWE define vistas especiales representadas gráficamente por

diagramas en UML. Además UWE no limita el número de vistas posibles de

una aplicación, UML proporciona mecanismos de extensión basados en

estereotipos. Estos mecanismos de extensión son los que UWE utiliza para

definir estereotipos que son lo que finalmente se utilizarán en las vistas

especiales para el modelado de aplicaciones Web. De esta manera, se

obtiene una notación UML adecuada a un dominio en específico a la cual se

le conoce como Perfil UML7.

2.3.1 DIAGRAMA DE SECUENCIA

El diagrama de secuencias es un esquema conceptual que permite

representar el comportamiento de un sistema, para lo cual emplea la

especificación de los objetos que se encuentran en un escenario y la

secuencia de mensajes intercambiados entre ellos, con el fin de llevar a cabo

una transacción del sistema. Existen diferentes enfoques que buscan la

generación automática de modelos conceptuales, como el diagrama de

secuencias.8

Elementos del diagrama de secuencias

El diagrama de secuencias hace parte de los diagramas de interacción de la

especificación UML que describen los aspectos dinámicos de un sistema y

muestran la interacción entre los objetos de un sistema y los mensajes

enviados entre ellos, ordenados según su secuencia en el tiempo, sus

elementos son:

7 Ingeniería Web, http://mlozanoavalos.blogspot.com/2009/06/articulo-ingenieria-web.html, Revisado 17/03/2013 8 Generación Del Diagrama De Secuencias De UML 2.1.1 Desde esquemas Pre conceptuales, Revista EIA, ISSN 1794-1237

Número 10, p. 89-103. Diciembre 2008 Escuela de Ingeniería de Antioquia, Medellín (Colombia).

http://mlozanoavalos.blogspot.com/2009/06/articulo-ingenieria-web.html

17

Figura. 2.3: Elementos de un diagrama de secuencia.

Los diagramas de secuencias son útiles para diversos usos como:

El modelado de escenarios de uso. Un escenario de uso es una

descripción de una posible forma en que un sistema se utiliza. La lógica de

un escenario de uso puede ser parte de un caso de uso, por ejemplo, una

secuencia alternativa o un paso completo a través de un caso de uso, tal

como la lógica que describe la secuencia normal de la acción o una parte

de ella. Un escenario de uso también puede ser un paso a través de la

lógica contenida en varios casos de uso.

El modelado de la lógica de los métodos. Los diagramas de secuencias

se pueden utilizar para explorar la lógica de una operación, función o

procedimiento complejos, ya que ofrece una forma de observar las

invocaciones a las operaciones definidas en las clases.

La detección de cuellos de botella en un diseño orientado a objetos. Al

observar los mensajes enviados a un objeto y cuánto se tardan en ejecutar

el método invocado, es posible concluir que es necesario cambiar el diseño

con el fin de distribuirla carga dentro del sistema9.

9 Generación Del Diagrama De Secuencias De UML 2.1.1 Desde esquemas Pre conceptuales, Revista EIA, ISSN 1794-1237

Número 10, p. 89-103. Diciembre 2008 Escuela de Ingeniería de Antioquia, Medellín (Colombia).

18

2.3.2 DIAGRAMAS DE ESTADOS

Los diagramas de estado describen gráficamente los eventos y los

estados de los objetos. Los diagramas de estado son útiles, entre otras

cosas, para indicar los eventos del sistema en los casos de uso.

Un evento es un acontecimiento importante a tomar en cuenta para el

sistema. Un estado es la condición de un objeto en un momento

determinado: el tiempo que transcurre entre eventos. Una transición es

una relación entre dos estados, e indica que, cuando ocurre un evento, el

objeto pasa del estado anterior al siguiente10.

Figura. 2.4: Ejemplo de diagrama de estado.

En UML, los estados se representan mediante óvalos. Las transiciones se

representan mediante flechas con el nombre del evento respectivo. Se

acostumbra poner un estado inicial y un final.

10 Diagramas de estados, http://markblogs-markmendoza.blogspot.com/2010/12/diagramas-de-estado.html, revisado el

12/04/2013

19

En particular, es útil hacer diagramas de estado para describir la secuencia

permitida de eventos en los casos de uso.11

2.4 PATRÓN DE DISEÑO

Los patrones de diseño son el esqueleto de las soluciones a problemas

comunes en el desarrollo de software. Cada patrón describe un problema que

ocurre una y otra vez en nuestro entorno y describe también el núcleo de la

solución al problema, de forma que puede utilizarse un millón de veces sin

tener que hacer dos veces lo mismo, es decir, un patrón de diseño es una

descripción de clases y objetos comunicándose entre sí adaptada para

resolver un problema de diseño general en un contexto particular.12

Categorías de patrones:

De creación: implica el proceso de instanciar objetos.

Estructurales: composición de objetos.

De comportamiento: cómo se comunican los objetos cómo se comunican los

objetos, cooperan y distribuyen las responsabilidades para lograr sus

objetivos.13

Estructura de un patrón

Nombre del patrón.

Describe el problema de diseño, junto con sus soluciones y consecuencias.

Vocabulario de diseño.

Problema.

Describe cuándo aplicar el patrón.

Explica el problema y su contexto.

11 Diagramas de estados, http://markblogs-markmendoza.blogspot.com/2010/12/diagramas-de-estado.html, revisado el

12/04/2013 12 Desing Patterns. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Addison Wesley, 1995. 13 Design patterns, elements of reusable objectoriented software”. Gamma, Helm, Jonhnson, Vlissides Addison Wesley 1995

(traducido al Vlissides. Addison Wesley, 1995 (traducido al español en 2003).

20

Solución.

Elementos que forman el diseño, relaciones, responsabilidades. Elementos

que forman el diseño, relaciones, responsabilidades.

No un diseño concreto, sino una plantilla que puede aplicarse en muchas

situaciones distintas.

Consecuencias.

Resultados, ventajas e inconvenientes de aplicar el patrón.

P.ej.: relación entre eficiencia en espacio y tiempo; cuestiones de

implementación etc.14

2.4.1 PATRÓN DE DISEÑO J2EE

Con la aparición de J2EE, todo un nuevo catálogo de patrones de diseño

apareció. Desde que J2EE es una arquitectura por si misma que involucra

otras arquitecturas, incluyendo servlets, JavaServer Pages, Enterprise

JavaBeans, y más, merece su propio conjunto de patrones específicos para

diferentes aplicaciones empresariales.

De acuerdo al libro "J2EE PATTERNS Best Practices and Design

Strategies", existen 5 capas en la arquitectura J2EE:15

Cliente

Presentación

Negocios

Integración

Recurso

Los 15 patrones de diseño j2ee se dividen en 3 capas:

14 Design patterns, elements of reusable objectoriented software”. Gamma, Helm, Jonhnson, Vlissides Addison Wesley 1995

(traducido al Vlissides. Addison Wesley, 1995 (traducido al español en 2003). 15 Patrones de diseño j2ee, http://blog.portomx.com/wp-content/uploads/2009/07/patrones_de_diseno_j2ee.pdf, revisado:

19/03/2013

http://blog.portomx.com/wp-content/uploads/2009/07/patrones_de_diseno_j2ee.pdf

21

Tabla 2.1: Capa de Presentación

Decorating Filter /

Intercepting Filter

Un objeto que está entre el cliente y los

componentes Web. Este procesa las peticiones y

las respuestas.

Front Controller/

Front Component

Un objeto que acepta todos los requerimientos de

un cliente y los direcciona a manejadores

apropiados. El patrón Front Controller podría

dividir la funcionalidad en 2 diferentes objetos: el

Front Controller y el Dispatcher. En ese caso, El

Front Controller acepta todos los requerimientos

de un cliente y realiza la autenticación, y el

Dispatcher direcciona los requerimientos a

manejadores apropiada.

View Helper

Un objeto helper que encapsula la lógica de

acceso a datos en beneficio de los componentes

de la presentación. Por ejemplo, los JavaBeans

pueden ser usados como patrón View Helper para

las páginas JSP.

Composite view

Un objeto vista que está compuesto de otros

objetos vista. Por ejemplo, una página JSP que

incluye otras páginas JSP y HTML usando la

directiva include o el action include es un patrón

Composite View.

Service To Worker

Es como el patrón de diseño MVC con el

Controlador actuando como Front Controller pero

con una cosa importante: aquí el Dispatcher (el

cual es parte del Front Controller) usa View

Helpers a gran escala y ayuda en el manejo de la

vista.

Dispatcher View Es como el patrón de diseño MVC con el

controlador actuando como Front Controller pero

22

con un asunto importante: aquí el Dispatcher (el

cual es parte del Front Controller) no usa View

Helpers y realiza muy poco trabajo en el manejo

de la vista. El manejo de la vista es manejado por

los mismos componentes de la Vista.

Tabla 2.2: Capa de Negocios

Business Delegate

Un objeto que reside en la capa de

presentación y en beneficio de los otros

componentes de la capa de presentación

llama a métodos remotos en los objetos de

la capa de negocios.

Value Object/ Data

Transfer Object/

Replicate Object

Un objeto serializable para la transferencia

de datos sobre lar red.

Session Façade/

Session Entity Façade/

Distributed Façade

El uso de un bean de sesion como una

fachada (facade) para encapsular la

complejidad de las interacciones entre los

objetos de negocio y participantes en un flujo

de trabajo. El Session Façade maneja los

objetos de negocio y proporciona un servicio

de acceso uniforme a los clientes.

Aggregate Entity Un bean entidad que es construido o es

agregado a otros beans de entidad.

Value Object Assembler Un objeto que reside en la capa de negocios

y crea Value Objets cuando es requerido.

Value List Handler/

Page-by-Page Iterator/

Paged List

Es un objeto que maneja la ejecución de

consultas SQL, caché y procesamiento del

resultado. Usualmente implementado como

beans de sesión.

23

Service Locator

Consiste en utilizar un objeto Service

Locutor para abstraer toda la utilización

JNDI y para ocultar las complejidades de la

creación del contexto inicial, de búsqueda de

objetos home EJB y recreación de objetos

EJB. Varios clientes pueden reutilizar el

objeto Service Locutor para reducir la

complejidad del código, proporcionando un

punto de control.

Tabla 2.3: Capa de Integración

Data Access Object

Service Activator

Consiste en utilizar un objeto de acceso a datos

para abstraer y encapsular todos los accesos a

la fuente de datos. El DAO maneja la conexión

con la fuente de datos para obtener y

almacenar datos.

Service Activator

Se utiliza para recibir peticiones y mensajes

asíncronos de los clientes. Cuando se recibe

un mensaje, el Service Activator localiza e

invoca a los métodos de los componentes de

negocio necesarios para cumplir la petición de

forma asíncrona.

Referencia.16

16Patrones j2ee, http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html, revisado: 19/03/2013

24

Figura. 2.5: Catálogo de patrones de Core J2EE Patterns.

2.5 CASOS DE USO

Los diagramas de casos de uso documentan el comportamiento de un sistema

desde el punto de vista del usuario. Por lo tanto los casos de uso determinan

los requisitos funcionales del sistema, es decir, representan las funciones que

un sistema puede ejecutar. Su ventaja principal es la facilidad para

interpretarlos, lo que hace que sean especialmente útiles en la comunicación

con el cliente.17

Figura. 2.6: Diagrama de Casos de Uso.

17 Diagramas de Casos de Uso, Jesús Cáceres Tello, Dpto. Ciencias de la Computación, http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf, revisado 23/04/2013

25

Elementos básicos

Actores: Los actores representan un tipo de usuario del sistema. Se entiendo

como usuario cualquier cosa externa que interactúa con el sistema. No tiene

por qué ser un ser humano, puede ser otro sistema informático o unidades

organizativas o empresas.

Siempre hay que intentar independizar los actores de la forma en que se

interactúa con el sistema. Por ejemplo un teclado no es un actor en la mayor

parte de los casos, sólo un medio para introducir información al sistema. Suele

ser útil mantener una lista de los usuarios reales para cada actor.

Un actor en un diagrama de casos de uso representa un rol que alguien puede

estar jugando, no un individuo particular por lo tanto puede haber personas

particulares que puedan estar usando el sistema de formas diferentes en

diferentes ocasiones: socio de biblioteca y bibliotecario.18

Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del

sistema que se está desarrollando. Se representan mediante un óvulo. Cada

caso de uso debe detallarse, habitualmente mediante una descripción

textual.18

Asociaciones: Hay una asociación entre un actor y un caso de uso si el actor

interactúa con el sistema para llevar a cabo el caso de uso.19

Un caso de uso debe especificar un comportamiento deseado, pero no

imponer cómo se llevará a cabo ese comportamiento, es decir, debe decir

QUÉ pero no CÓMO. Esto se realiza utilizando escenarios.19

Un escenario es una interacción entre el sistema y los actores, que puede

ser descrito mediante una secuencia de mensajes. Un caso de uso es una

generalización de un escenario.19

18 Diagramas de Casos de Uso, Jesús Cáceres Tello, Dpto. Ciencias de la Computación, http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf, revisado 23/04/2013 19 Diagramas de Casos de Uso, Jesús Cáceres Tello, Dpto. Ciencias de la Computación, http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf, revisado 23/04/2013

26

Tipos de asociaciones

Existen tres tipos de asociación o relaciones en los diagramas de casos de

uso:

Include: Se puede incluir una relación entre dos casos de uso de tipo “include”

si se desea especificar comportamiento común en dos o más casos de uso.

Las ventajas de esta asociación son:

Las descripciones de los casos de uso son más cortas y se entienden mejor.

La identificación de funcionalidad común puede ayudar a descubrir el posible

uso de componentes ya existentes en la implementación.

Las desventajas son:

La inclusión de estas relaciones hace que los diagramas sean más difícil de

leer, sobre todo para los clientes.

Extend: Se puede incluir una relación entre dos casos de uso de tipo “include”

si se desea especificar diferentes variantes del mismo caso de uso. Es decir,

esta relación implica que el comportamiento de un caso de uso es diferente

dependiendo de ciertas circunstancias. En principio esas variaciones pueden

también mostrarse como diferentes descripciones de escenarios asociadas al

mismo caso de uso.

Generalizaciones: En un diagrama de casos de uso también pueden

mostrarse generalizaciones (relaciones de herencia) para mostrar que

diferentes elementos están relacionados como tipos de otros. Son aplicables

a actores o casos de uso, pero para estos últimos la semántica es muy similar

a las relaciones “extend”.20

Límites del sistema: Resulta útil dibujar los límites del sistema cuando se

pretende hacer un diagrama de casos de uso para parte del sistema.20

20 Diagramas de Casos de Uso, Jesús Cáceres Tello, Dpto. Ciencias de la Computación, http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf, revisado 23/04/2013

27

2.6 HERRAMIENTAS

2.6.1 JAVA

Java es una tecnología que se usa para el desarrollo de aplicaciones que

convierten a la Web en un elemento más interesante y útil. Java no es lo

mismo que JavaScript, que se trata de una tecnología sencilla que se usa

para crear páginas web y solamente se ejecuta en el explorador.21

El lenguaje Java se creó con cinco objetivos principales:

1. Debería usar el paradigma de la programación orientada a objetos.

2. Debería permitir la ejecución de un mismo programa en múltiples

sistemas operativos.

3. Debería incluir por defecto soporte para trabajo en red.

4. Debería diseñarse para ejecutar código en sistemas remotos de forma

segura.

5. Debería ser fácil de usar y tomar lo mejor de otros lenguajes

orientados a objetos, como C++.22

La sintaxis de Java se deriva en gran medida de C++. Pero a diferencia de

éste, que combina la sintaxis para programación genérica, estructurada y

orientada a objetos, Java fue construido desde el principio para ser

completamente orientado a objetos. Todo en Java es un objeto (salvo algunas

excepciones), y todo en Java reside en alguna clase (recordemos que una

clase es un molde a partir del cual pueden crearse varios objetos).22

2.6.2 JBOSS

JBoss es un proyecto de código abierto, con el que se consigue un servidor

de aplicaciones basado en J2EE, e implementado al 100% en Java. Por lo

tanto al estar basado en Java, JBoss puede ser utilizado en cualquier sistema

21 Que es Java, Java.com, http://www.java.com/es/download/whatis_java.jsp, revisado 23/04/2013 22 Java, Wikipedia, http://es.wikipedia.org/wiki/Java_(lenguaje_de_programaci%C3%B3n), revisado el 23/04/2013

http://es.wikipedia.org/wiki/C%2B%2B

28

operativo que lo soporte. JBoss implementa todo el paquete de servicios de

J2EE (EJB, JMS, JTS/JTA, Servlets/JSP, JNDI, etc.) y también ofrece

características tales como los clustering, JMX, WebServices y la integración

IIOP, y la principal característica que desde que JBoss está licenciado bajo la

LGPL, puede libremente usarse sin costo alguno en cualquier aplicación

comercial o ser redistribuirlo.23

Características

Open Source.

Escalable.

Alto desempeño.

Arquitectura Modular.

Producto de licencia de código abierto sin coste adicional.

Cumple los estándares.

Confiable a nivel de empresa.

Incrustable, orientado a arquitectura de servicios.

Flexibilidad consistente.

Servicios del middleware para cualquier objeto de Java.

Ayuda profesional 24x7 de la fuente.

Soporte completo para JMX.

Estructura

La Estructura fundamental de JBOSS es la siguiente:

a)bin

Este directorio contiene los ejecutables utilizados por JBOSS, siendo el más

importante el "script" dearranque utilizado por éste (run.sh).24

b)client

Contiene los diversos archivos JAR's que serán utilizados por los distintos

clientes de los EJB's utilizados en JBOSS. Dichos archivos deben

ser agregados a la variable CLASSPATH del sistema donde radica el cliente.24

23 JBoss, http://es.scribd.com/doc/19026497/JBOSS, revisado el 23/04/2013 24 JBoss, http://es.scribd.com/doc/19026497/JBOSS, revisado el 23/04/2013

29

c)server

Este directorio contiene tres sub-directorios nombrados: all, default y minimal;

cada sub-directorio contiene los distintos archivos de configuración necesarios

para ejecutar JBOSS en diferentes modalidades. La ejecución de JBOSS es

relativamente sencilla, dentro del directorio bin de la instalación de JBOSS se

encuentran los archivos de arranque en forma de "scripts" para Shell. El

archivo de ejecución run.sh inicia JBOSS con los parámetros encontrados en

el directorio server/default/conf.24

2.6.3 ECLIPSE

Eclipse es una plataforma de desarrollo open source basada en Java. Es un

desarrollo de IBM cuyo código fuente fue puesto a disposición de los usuarios.

En sí mismo Eclipse es un marco y un conjunto de servicios para construir un

entorno de desarrollo a partir de componentes conectados (plug-in).

Hay plug-ins para el desarrollo de Java (JDT Java Development Tools) así

como para el desarrollo en C/C++, COBOL, etc.25

Ventajas en la utilización de Eclipse26

1- El entorno de desarrollo integrado (IDE) de Eclipse emplea módulos (en

inglés plug-in) para proporcionar toda su funcionalidad al frente de

la Plataforma de Cliente rico, a diferencia de otros entornos monolíticos donde

las funcionalidades están todas incluidas, las necesite el usuario o no.

2- Este mecanismo de módulos es una plataforma ligera para componentes

de software. Adicionalmente a permitirle a Eclipse extenderse usando otros

lenguajes de programación como son C/C++ yPython, permite a Eclipse

trabajar con lenguajes para procesado de texto como LaTeX, aplicaciones en

red como Telnet y Sistema de gestión de base de datos.

25 Eclipse, Dept. Informatica, Universitat de Valencia, http://www.uv.es/~jgutierr/MySQL_Java/TutorialEclipse.pdf,

revisado 23/04/2013 26 Eclipse, entorno de desarrollo integrado,

http://www.ecured.cu/index.php/Eclipse,_entorno_de_desarrollo_integrado, revisado 23/04/2013

http://www.ecured.cu/index.php/Eclipse,_entorno_de_desarrollo_integrado

30

3-La arquitectura plug-in permite escribir cualquier extensión deseada en el

ambiente, como sería Gestión de la configuración. Se provee soporte para

Java y CVS en el SDK de Eclipse. Y no tiene por qué ser usado únicamente

para soportar otros Lenguajes de programación.

4- La definición que da el proyecto Eclipse acerca de su Software es: "una

especie de herramienta universal - un IDE abierto y extensible para todo y

nada en particular".

En cuanto a la utilización de eclipse para la creación de aplicaciones clientes

se puede decir que:

1- Eclipse provee al programador con Frameworks muy ricos para el desarrollo

de aplicaciones gráficas, definición y manipulación de modelos

de Software, Aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing

Framework - Framework para la edición gráfica) es un plug-in de Eclipse para

el desarrollo de editores visuales que pueden ir desde procesadores de texto

wysiwyg hasta editores de diagramas UML, interfaces gráficas para el usuario

(GUI), etc. Dado que los editores realizados con GEF "viven" dentro de

Eclipse, además de poder ser usados conjuntamente con otros plugins, hacen

uso de su interfaz gráfica personalizable y profesional.

2- El SDK de Eclipse incluye las herramientas de desarrollo de Java,

ofreciendo un IDE con un compilador de Java interno y un modelo completo

de los archivos fuente de Java. Esto permite técnicas avanzadas de

refactorización y análisis de código.

3- El IDE también hace uso de un espacio de trabajo, en este caso un grupo

de metadata en un espacio para archivos plano, permitiendo modificaciones

externas a los archivos en tanto se refresque el espacio de trabajo

correspondiente.

31

2.6.4 POSTGRESQL

PostgreSQL es un sistema de gestión de bases de datos objeto-relacional,

distribuido bajo licencia BSD y con su código fuente disponible libremente. Es

el sistema de gestión de bases de datos de código abierto más potente del

mercado y en sus últimas versiones no tiene nada que envidiarle a otras bases

de datos comerciales.

PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez

de multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los

procesos no afectará el resto y el sistema continuará funcionando.27

Figura. 2.7: Arquitectura de PostgreSQL.

27 Postgresql, Sobre PostgreSQL, http://www.postgresql.org.es/sobre_postgresql, revisado 24/04/2013

32

Aplicación cliente: Esta es la aplicación cliente que utiliza PostgreSQL

como administrador de bases de datos. La conexión puede ocurrir vía

TCP/IP ó sockets locales.28

Demonio postmaster: Este es el proceso principal de PostgreSQL. Es

el encargado de escuchar por un puerto/socket por conexiones

entrantes de clientes. También es el encargado de crear los procesos

hijos que se encargaran de autentificar estas peticiones, gestionar las

consultas y mandar los resultados a las aplicaciones clientes28

Ficheros de configuración: Los 3 ficheros principales de

configuración utilizados por PostgreSQL, postgresql.conf, pg_hba.conf

y pg_ident.conf28

Procesos hijos postgres: Procesos hijos que se encargan de

autentificar a los clientes, de gestionar las consultas y mandar los

resultados a las aplicaciones clientes28

PostgreSQL share buffer cache: Memoria compartida usada por

POstgreSQL para almacenar datos en caché28.

Write-Ahead Log (WAL): Componente del sistema encargado de

asegurar la integridad de los datos (recuperación de tipo REDO)28

Kernel disk buffer cache: Caché de disco del sistema operativo28

Disco: Disco físico donde se almacenan los datos y toda la información

necesaria para que PostgreSQL funcione28

Características

La última serie de producción es la 9.2. Sus características técnicas la hacen

una de las bases de datos más potentes y robustos del mercado. Su desarrollo

comenzó hace más de 16 años, y durante este tiempo, estabilidad, potencia,

robustez, facilidad de administración e implementación de estándares han

sido las características que más se han tenido en cuenta durante su


33

desarrollo. PostgreSQL funciona muy bien con grandes cantidades de datos

y una alta concurrencia de usuarios accediendo a la vez al sistema.29

Generales

Es una base de datos 100% ACID

Integridad referencial

Tablespaces

Nested transactions (savepoints)

Replicación asincrónica/sincrónica / Streaming replication - Hot

Standby

Two-phase commit

PITR - point in time recovery

Copias de seguridad en caliente (Online/hot backups)

Unicode

Juegos de caracteres internacionales

Regionalización por columna

Multi-Version Concurrency Control (MVCC)

Multiples métodos de autentificación

Acceso encriptado via SSL

Actualización in-situ integrada (pg_upgrade)

SE-postgres

Completa documentación

Licencia BSD


34

Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-

UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit.

Programación / Desarrollo30

Funciones/procedimientos almacenados (stored procedures) en

numerosos lenguajes de programacion, entre otros PL/pgSQL (similar

al PL/SQL de oracle), PL/Perl, PL/Python y PL/Tcl

Bloques anónimos de código de procedimientos (sentencias DO)

Numerosos tipos de datos y posibilidad de definir nuevos tipos. Además

de los tipos estándares en cualquier base de datos, tenemos

disponibles, entre otros, tipos geométricos, de direcciones de red, de

cadenas binarias, UUID, XML, matrices, etc

Soporta el almacenamiento de objetos binarios grandes (gráficos,

videos, sonido, ...)

APIs para programar en C/C++, Java, .Net, Perl, Python, Ruby, Tcl,

ODBC, PHP, Lisp, Scheme, Qt y muchos otros.

SQL29

SQL92,SQL99,SQL2003,SQL2008

Llaves primarias (primary keys) y foráneas (foreign keys)

Check, Unique y Not null constraints

Restricciones de unicidad postergables (deferrable constraints)

Columnas auto-incrementales

Índices compuestos, únicos, parciales y funcionales en cualquiera de

los métodos de almacenamiento disponibles, B-tree, R-tree, hash ó

GiST

Sub-selects


35

Consultas recursivas

Funciones 'Windows'

Joins

Vistas (views)

Disparadores (triggers) comunes, por columna, condicionales.

Reglas (Rules)

Herencia de tablas (Inheritance)

Eventos LISTEN/NOTIFY

Se puede consultar la lista completa de características disponibles en todas

las versiones en la dirección http://www.postgresql.org/about/featurematrix

Algunos de los límites de PostgreSQL son:31

Tabla 2.4: Limites de PostgreSQL.

Límite Valor

Máximo tamaño base de dato Ilimitado (Depende de tu sistema de almacenamiento)

Máximo tamaño de tabla 32 TB

Máximo tamaño de fila 1.6 TB

Máximo tamaño de campo 1 GB

Máximo número de filas por tabla

Ilimitado

Máximo número de columnas por tabla

250 - 1600 (dependiendo del tipo)

Máximo número de índices por tabla

Ilimitado


36

2.6.5 RICHFACES

RichFaces es una librería de componentes visuales para JSF, escrita en su

origen por Exadel y adquirida por Jboss. Además, RichFaces posee un

framework avanzado para la integración de funcionalidades Ajax en dichos

componentes visuales, mediante el soporte de la librería Ajax4JSF.32

Características:

Se integra perfectamente en el ciclo de vida de JSF,

Incluye funcionalidades Ajax, de modo que nunca vemos el JavaScript

y tiene un contenedor Ajax propio,

Contiene un set de componentes visuales, los más comunes para el

desarrollo de una aplicación web rica (Rich Internet Application), con

un número bastante amplio que cubren casi todas nuestras

necesidades,

Soporta facelets,

Soporta css themes o skins,

Es un proyecto open source, activo y con una comunidad también

activa.

2.6.6 JSF

JSF es un marco de trabajo para crear aplicaciones java J2EE basadas en el

patron MVC de tipo 1. JSF tiene como características principales:33

-Utiliza páginas JSP para generar las vistas, añadiendo una biblioteca de

etiquetas propia para crear los elementos de los formularios.

HTML.

Asocia a cada vista con formularios un conjunto de objetos java

manejados por el controlador (managed beans) que facilitan la

32 RichFaces, Jose Manuel Sánchez Suárez,

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=richFacesJsfIntro, revisado 24/04/2013 33 JSF, Cristóbal González Almirón,

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=IntroduccionJSFJava, revisado 24/04/2013

http://www.adictosaltrabajo.com/usuarios/cristobal-gonzalez

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=IntroduccionJSFJava

37

recogida, mapipulación y visualización de los valores nostrados en los

diferentes elementos de los formularios.

Introduce una serie de etapas en el procesamiento de la petición, como

por ejemplo la de validación, reconstrucción de la vista, recuperación

de los valores de los elementos, etc.

Utiliza un sencillo fichero de configuración para el controlador en

formato xml

Es extensible, pudiendo crearse nuevos elementos de la interfaz o

modificar los ya existentes.

Y lo que es más importante: forma parte del estándar J2EE. En efecto,

hay muchas alternativas para crear la capa de presentación y control

de una aplicación web java, como Struts y otros frameworks, pero solo

JSP forma parte del estándar.

2.6.7 EJB

Un "Java Bean" es un componente utilizado en Java que permite agrupar

funcionalidades para formar parte de una aplicación, esto puede ser: un "Java

Bean" agrupando información personal, datos sobre un pedimento,

requerimientos de ordenes,etc.34

Un "Enterprise Java Bean" también agrupa funcionalidades para una

aplicación, sin embargo, a diferencia de un "Java Bean" un "Enterprise Java

Bean" es un"deployable component", el término "deployable

component" implica que existe un ambiente de ejecución , éste ambiente es

precisamente un "EJB(Enterprise Java Bean) Container" parte de un java

application server .34

Un "Java Bean" requiere ser integrado con otros componentes para que éste

sea funcional, mientras un "Enterprise Java Bean" a través de un "EJB

Container" puede ser activado ("deployed").34

34 EJB: Enterprise Java Beans, http://www.osmosislatina.com/java/ejb.htm, revisado el 24/04/2013

38

Ventajas de EJB ("Enterprise Java Beans")34

Un EJB a través de un "EJB Container" ofrece varios servicios y

funcionalidades no disponibles en un "Java Bean", algunas son las siguientes:

Servicios ("Middleware")34

Esta posiblemente sea la mayor ventaja de un EJB. Cuando se diseña un

componente de Software se deben definir varios servicios para su

funcionamiento, algunos pueden ser:

¿Si ocurre un error que procedimiento debe ejecutarse?

¿Si la base de datos especificada se encuentra desactivada, existe otra

alternativa?

¿No fue posible cumplir exitosamente "x" procedimiento, se deben

retractar sus acciones parciales o re invocar la transacción?

Estos Servicios (comúnmente llamados "Middleware") por lo general son

requeridos además de la lógica contenida en los componentes principales,

obviamente estos servicios ("Middleware") aún deben ser diseñados, sin

embargo, mediante un "EJB Container" se ofrecen estos servicios y es a

través de un "Enterprise Java Bean" que es posible desarrollar los

componentes principales ("lógica de negocios").

39

CAPÍTULO III

3.1 ESPECIFICACIÓN DE REQUERIMIENTOS

La especificación de requerimientos pretende dar una guía de cómo se

tomaron y trataron los requisitos de este proyecto. Además de servir como

apoyo para usuarios, administradores o desarrolladores.

3.1.1 CAPTURA DE REQUERIMIENTOS

La captura de requisitos es la actividad mediante la que el equipo de

desarrollo de un sistema de software extrae, de cualquier fuente de

información disponible, las necesidades que debe cubrir dicho sistema. El

proceso de captura de requisitos puede resultar complejo, principalmente

si el entorno de trabajo es desconocido para el equipo de analistas, y

depende mucho de las personas que participen en él35.

La técnica que se usó para la captura de requisitos en el sistema de

seguimiento de proyectos en el Instituto Superior de Investigación y

Posgrado de la Universidad Central del Ecuador (ISI - FIGEMPA), fue

entrevistas, mediante la colaboración del personal involucrado se consiguió

establecer que se necesitaba un sistema que permita no solo digitalizar la

información, sino también tener la capacidad de realizar un seguimiento de

los proyectos que se realizan en el ISI - FIGEMPA.

3.1.2 DEFINICIÓN DE REQUERIMIENTOS

A continuación se detalla los casos de uso que se establecieron durante la

toma de requerimientos sistema de seguimiento de proyectos en el Instituto

Superior de Investigación y Posgrado de la Universidad Central del Ecuador

(ISI - FIGEMPA):

35 Ingeniería de requisitos en aplicaciones para la web, María José Escalona, Nora Koch, https://www.lsi.us.es/docs/informes/LSI-2002-4.pdf revisado el 03/03/2013

40

Administrador

Ingresar Proyecto

Modificar Proyecto

Eliminar Proyecto Buscar Proyecto

Encargado

<<incluir>>

<<incluir>>

<<incluir>>

PROYECTO:

Figura. 3.1: Caso de Uso Proyecto.

Nombre del Caso de Uso : Ingresar Proyecto

Descripción : Registra la información de un proyecto

Actores : Administrador, Encargado

Precondiciones : El administrador/encargado debe estar logeado

en el sistema

Flujo Principal: 1. El actor selecciona la opción para ingresar un

nuevo proyecto.

2. El sistema despliega el formulario para

ingresar la información.

3. El actor ingresa la información la siguiente

información

Nombre, Tipo de Contrato, Provincia, Cantón,

Empresa, Dirección Empresa, Encargado

Proyecto, Email Encargado, Teléfono, Fecha

Inicio, Fecha Fin, Presupuesto.

41

4. El sistema comprueba la validez de los datos

y los almacena.

Flujo Alternativo: 5. El sistema comprueba la validez de los datos,

si estos son incorrectos despliega un mensaje

de error y permite que se lo corrija.

Pos condiciones : El proyecto ha sido ingresado en el sistema.

Nombre del Caso de Uso : Buscar Proyecto

Descripción : Busca la información de un proyecto

Actores : Sistema, Administrador, Encargado

Precondiciones : El administrador/encargado debe estar

logeado en el sistema.

Flujo Principal: 1. El actor selecciona la opción para buscar un

proyecto.

2. El sistema despliega los campos Nombre de

proyecto para realizar la búsqueda del cliente.

3. El actor ingresa los parámetros de

búsqueda.

4. El sistema comprueba la existencia de los

datos y los despliega.

Flujo Alternativo: 5. El sistema comprueba la existencia de los

datos, si estos no existen despliega un

mensaje de error.

Pos condiciones : El sistema presenta los datos del proyecto.

42

Nombre del Caso de Uso : Modificar Proyecto

Descripción : Modifica la información de un proyecto


Precondiciones : El administrador/encargado debe estar

logeado en el sistema.

El proyecto debe estar ingresado en el

sistema.

Flujo Principal: 1. El actor selecciona la opción para modificar

un proyecto.

2. El actor selecciona el proyecto.

3. El sistema despliega los datos del proyecto.

4. El actor modifica la información del proyecto

Nombre, Tipo de Contrato, Provincia, Cantón,

Empresa, Dirección Empresa, Encargado

Proyecto, Email Encargado, Teléfono, Fecha

Inicio, Fecha Fin, Presupuesto, Estado.

5. El sistema comprueba la validez de los

datos y los actualiza.

Flujo Alternativo: 6. El sistema comprueba la validez de los

datos, si estos son incorrectos despliega un

mensaje de error y permite que se lo corrija.

Pos condiciones : El proyecto ha sido modificado en el sistema.

Nombre del Caso de Uso : Eliminar Proyecto

Descripción : Elimina un proyecto

Actores : Administrador

Precondiciones : El administrador debe estar logeado en el

sistema.

43

El proyecto debe estar ingresado en el

sistema.

Flujo Principal: 1. El actor selecciona la opción para eliminar

un proyecto.


3. El sistema presenta un mensaje de

confirmación.

4. El actor confirma la eliminación.

5. El sistema elimina la información.

Flujo Alternativo: 6. El actor no confirma la eliminación.

Pos condiciones : El proyecto ha sido eliminado del sistema.

ACTIVIDAD:

Administrador

Ingresar Actividad

Modificar Actividad

Eliminar Actividad

Encargado

Figura. 3.2: Caso de Uso Actividad

44

Nombre del Caso de Uso : Ingresar Actividad

Descripción : Registra la información de una actividad



en el sistema e ingresar a un proyecto

Flujo Principal: 1. El actor selecciona la opción para ingresar

una nueva actividad.




información.

Nombre, Fecha Inicio, Fecha Fin, Descripción,

Adjunto.


y los almacena.




Pos condiciones : La actividad ha sido ingresada en el sistema.

Nombre del Caso de Uso : Modificar Actividad

Descripción : Modifica la información de una actividad



en el sistema e ingresar a un proyecto.

45

La actividad debe estar ingresada en el

sistema.


una actividad.

2. El actor selecciona una actividad.

3. El sistema despliega los datos de la

actividad.

4. El actor modifica la información de la

actividad Nombre, Fecha Inicio, Fecha Fin,

Descripción, Estado, Porcentaje, Gasto,

Adjunto.


y los actualiza.




Pos condiciones : La actividad ha sido modificada en el sistema.

Nombre del Caso de Uso : Eliminar Actividad

Descripción : Elimina una actividad



sistema e ingresar a un proyecto.

La actividad debe estar ingresada en el

sistema.

46


una actividad.

2. El actor selecciona la actividad.


confirmación.




Pos condiciones : La actividad ha sido eliminada del sistema.

RECURSO:

Administrador

Ingresar Recurso

Modificar Recurso

Eliminar Recurso

Figura. 3.3: Caso de Uso Recurso.

47

Nombre del Caso de Uso : Ingresar Recurso

Descripción : Registra la información de un recurso



sistema.

Flujo Principal: 1. El actor selecciona la opción para ingresar un

nuevo recurso.




información

Nombre, Descripción.


y los almacena.




Pos condiciones : El recurso ha sido ingresado en el sistema.

Nombre del Caso de Uso : Modificar Recursos

Descripción : Modifica la información de un recurso



sistema.

El recurso debe estar ingresado en el sistema.

48


un recurso.

2. El actor selecciona un recurso.

3. El sistema despliega los datos del recurso.

4. El actor modifica la información de la

actividad Nombre, Descripción.


y los actualiza.




Pos condiciones : El recurso ha sido modificado en el sistema.

Nombre del Caso de Uso : Eliminar Recurso.

Descripción : Elimina un recurso.

Actores : Administrador.


sistema.

El recurso debe estar ingresado en el sistema.


un recurso.

2. El actor selecciona la actividad.


confirmación.




49

Pos condiciones : El recurso ha sido eliminado del sistema.

AVANCE PROYECTO:

Administrador

Buscar Proyecto Encargado

Calcular Avance Fisico

Calcular Avance Presupuestario

Presentar Informacion

<<incluir>>

<<incluir>>

Figura. 3.4: Caso de Uso Avance Proyecto.

50

Nombre del Caso de Uso : Buscar Proyecto

Descripción : Buscar un proyecto

Actores : Administrador/Encargado


en el sistema

Flujo Principal: 1. El actor selecciona la opción para buscar un

proyecto.

2. El sistema despliega los campos Nombre de

proyecto para realizar la búsqueda del cliente.

3. El actor ingresa los parámetros de búsqueda.



Flujo Alternativo: 5. El sistema comprueba la existencia del

proyecto y emite una advertencia en caso de

encontrarlo

Pos condiciones : La información es desplegada.

Nombre del Caso de Uso : Calcular Avance Físico

Descripción : Calcular el avance físico de un proyecto

Actores : Sistema

Precondiciones : Deben estar ingresadas actividades en el

sistema para el proyecto

Flujo Principal: 1. El sistema busca todas las actividades del

proyecto.

2. El sistema toma el avance físico de cada

actividad.

51

3. El sistema calcula el avance mediante la

fórmula:

PorcentajeDia=(100%*duracionActividad(dias))/duracionProyecto(dias)

Avance=Avance+( PorcentajeDia*(PorcentajeActividad/100))

4. El sistema calcula el valor del avance del

proyecto.

Flujo Alternativo: 5. El sistema comprueba que un proyecto no

tiene actividades asignadas y despliega un

mensaje.

Pos condiciones : El sistema ha calculado el avance físico del

proyecto.

Nombre del Caso de Uso : Calcular Avance Presupuestario

Descripción : Calcular el avance presupuestario de un

proyecto

Actores : Sistema

Precondiciones : Deben estar ingresadas los gastos en cada

actividad del proyecto

Flujo Principal: 1. El sistema busca todas las actividades del

proyecto.

2. El sistema toma el gasto de cada actividad.

3. El sistema calcula el avance mediante la

fórmula:

Avance=(∑gastosActividades/presupuesto)*100

4. El sistema calcula el valor del avance del

proyecto.

52

Flujo Alternativo: 5. El sistema comprueba que un proyecto no

tiene actividades asignadas y despliega un

mensaje.

Pos condiciones : El sistema ha calculado el avance

presupuestario del proyecto.

Nombre del Caso de Uso : Presentar Información

Descripción : Presenta la información avance de un proyecto.



en el sistema.

El avance del proyecto debe estar calculado.

Flujo Principal: 1. El actor selecciona la opción ver avance.


3. El sistema presenta la información.

Flujo Alternativo: 4. El actor cancela la operación.

Pos condiciones : La información ha sido presentada.

53

CONTROL ACTIVIDAD:

Administrador

Ingresar Resumen EjecutivoEncargado

Buscar Actividad

Ingresar ObservacionesPresentar Modificaciones

Figura. 3.5: Caso de Uso Control Actividad.

Nombre del Caso de Uso : Buscar Actividad

Descripción : Buscar una actividad



sistema y seleccionar un proyecto.

Flujo Principal: 1. El actor selecciona la opción para buscar

actividad.

2. El sistema despliega las actividades.

3. El actor ingresa los parámetros de búsqueda.



54

Flujo Alternativo: Ninguna

Pos condiciones : La información es desplegada.

Nombre del Caso de Uso : Ingresar Resumen ejecutivo

Descripción : Ingresar resumen ejecutivo



sistema y seleccionar un proyecto y una

actividad.

Flujo Principal: 1. El actor selecciona la opción ingresar nuevo.

2. El sistema despliega un campo de carga de

archivo para el resumen ejecutivo.

3. El actor ingresa el archivo.

4. El sistema comprueba la existencia del

archivo y lo carga.

Flujo Alternativo: 5. El sistema emite un mensaje de error si el

archivo es muy grande o no esta en formato

PDF.

Pos condiciones : El Resumen Ejecutivo se ha cargado.

Nombre del Caso de Uso : Ingresar Observación

Descripción : Ingresar observación



sistema y seleccionar un proyecto y una

actividad.

55

Flujo Principal: 1. El actor selecciona en resumen ejecutivo

editar.

2. El sistema despliega un campo observación.

3. El actor ingresa la observación.

4. El sistema comprueba la existencia de datos

y los almacena.

Flujo Alternativo: 5. El sistema emite un mensaje de error si no

existen datos para q el actor los corrija.

Pos condiciones : La observación ha sido ingresada en el sistema.

Nombre del Caso de Uso : Presentar Modificaciones

Descripción : Presentar las modificaciones del informe

ejecutivo



en el sistema y seleccionar un proyecto.

Flujo Principal: 1. El actor selecciona una actividad.

2. El sistema despliega las actividades.

3. El actor selecciona una actividad.

4. El sistema despliega los resúmenes

ejecutivos con sus modificaciones.

Flujo Alternativo: 5. No se selecciona ninguna actividad

Pos condiciones : El sistema presenta la información.

56

CAPÍTULO IV

4.1 MODELO LÓGICO CONCEPTUAL

Figura. 4.1: Diagrama de Clases.

57

4.2 DIAGRAMAS DE SECUENCIA

PROYECTO:

Figura. 4.2: Diagrama de Secuencia Proyecto.

Buscar Proyecto Modificar Proyecto Crear Proyecto Eliminar Proyecto

Mensaje

Mensaje

Mensaje

Proyecto (dato1, dadato2,….)



Usuario

58

ACTIVIDAD:

Figura. 4.3: Diagrama de Secuencia Actividad.

Buscar Proyecto Modificar Actividad Crear Actividad Eliminar Actividad

Mensaje

Mensaje

Mensaje

Actividad (dato1, dadato2,….)



Usuario

59

RECURSO:

Figura. 4.4: Diagrama de Secuencia Recurso.

Buscar Proyecto Modificar Recurso Crear Recurso Eliminar Recurso

Mensaje

Mensaje

Mensaje

Recurso (dato1, dadato2,….)



Usuario

60

AVANCE PROYECTO

Figura. 4.5: Diagrama de Secuencia Avance Proyecto.

Buscar Proyecto Avance Presupuesto Avance Físico Presentar

Mensaje

Mensaje

Mensaje




Usuario

61

CONTROL ACTIVIDAD:

Figura. 4.6: Diagrama de Secuencia Control Actividad.

Buscar Actividad Ingresar Observación Ingresar Resumen. Presentar

Mensaje

Mensaje

Mensaje




Usuario

62

4.3 DIAGRAMAS DE ESTADOS

PROYECTO

Figura. 4.7: Diagrama de Estados Proyecto.

63

ACTIVIDAD

Figura. 4.8: Diagrama de Estados Actividad.

64

RECURSO

Figura. 4.9: Diagrama de Estados Recurso.

65

AVANCE PROYECTO

Figura. 4.10: Diagrama de Estados Avance.

66

CONTROL ACTIVIDAD

Figura. 4.11: Diagrama de Estados Control Actividad.

67

CAPÍTULO V

IMPLEMENTACIÓN Y PRUEBAS

5.1 IMPLEMENTACIÓN

El análisis realizado en clases, objetos y diagramas finalmente se traduce en

una implementación adecuada y concreta.

La siguiente impele matación hace referencia a crear un Enterprise Project

con Eclipse, además de como los objetos se tradujeron a ser clases (entidades

con atributos semejante), utilizando el lenguaje java.

Desarrollo de Módulos:

Para la creación de un proyecto se usaran tres capas: Persistencia, Servicios,

Vista

Persistencia:

Implementación de una Entidad (Entity) con sus respectivas notaciones.

package figempa.uce.edu.ec.modelo;

import java.io.Serializable;

import javax.persistence.*;

import java.util.List;

/**

* The persistent class for the flujo_trabajo_proyecto database table.

*

68

*/

@Entity

@Table(name="flujo_trabajo_proyecto")

public class FlujoTrabajoProyecto implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@SequenceGenerator(name="FLUJO_TRABAJO_PROYECTO_FPID

_GENERATOR",

sequenceName="FLUJO_TRABAJO_PROYECTO_FP_ID_SEQ",allocationSi

ze=1)

@GeneratedValue(strategy=GenerationType.SEQUENCE,

generator="FLUJO_TRABAJO_PROYECTO_FPID_GENERATOR")

@Column(name="fp_id")

private Integer fpId;

@Column(name="fp_descripcion")

private String fpDescripcion;

@Column(name="fp_estado")

private String fpEstado;

@Column(name="fp_nombre")

private String fpNombre;

//bi-directional many-to-one association to Proyecto

@OneToMany(mappedBy="flujoTrabajoProyecto",cascade=CascadeT

ype.ALL,fetch=FetchType.LAZY )

private List<Proyecto> proyectos;

public FlujoTrabajoProyecto() {

}

public Integer getFpId() {

69

return this.fpId;

}

public void setFpId(Integer fpId) {

this.fpId = fpId;

}

public String getFpDescripcion() {

return this.fpDescripcion;

}

public void setFpDescripcion(String fpDescripcion) {

this.fpDescripcion = fpDescripcion;

}

public String getFpEstado() {

return this.fpEstado;

}

public void setFpEstado(String fpEstado) {

this.fpEstado = fpEstado;

}

public List<Proyecto> getProyectos() {

return this.proyectos;

}

public void setProyectos(List<Proyecto> proyectos) {

this.proyectos = proyectos;

}

/**

* @return the fpNombre

*/

70

public String getFpNombre() {

return fpNombre;

}

/**

* @param fpNombre the fpNombre to set

*/

public void setFpNombre(String fpNombre) {

this.fpNombre = fpNombre;

}

}

Servicios:

Implementación de un Servicio con sus respectivas notaciones.

Interfaz:

package figempa.uce.edu.ec.servicios;


import javax.ejb.Local;

import figempa.uce.edu.ec.modelo.FlujoTrabajoProyecto;

@Local

public interface ServicioFlujoTrabajoProyecto {

/**

* Metodo que permite listar todas las los flujos de trabajo

* @return flujos de trabajo

*/

public List<FlujoTrabajoProyecto> listarFlujoTrabajo();

71

/**

* Metodo que permite buscar un flujo de trabajo

* @param flujoTrabajo

* @return flujo seleccionado

*/

public FlujoTrabajoProyecto buscarFlujoTrabajo(Integer codigo);

/**

* Metodo que permite crear

* @param flujo de trabajo

*/

public void crearFlujoTrabajo(FlujoTrabajoProyecto flujoTrabajo);

/**

* Metodo que permite modificar

* @param flujo de trabajo

*/

public void actualizarFlujoTrabajo(FlujoTrabajoProyecto flujoTrabajo);

}

La siguiente implementación es la de un Stateless el cual extiende de una

clase ServicioFlujoTrabajoProyecto

ServicioFlujoTrabajoProyecto es una interfaz, la cual nos define los servicios

que se usaran.

package figempa.uce.edu.ec.servicios.impl;


import javax.ejb.Stateless;

import javax.persistence.EntityManager;

72

import javax.persistence.PersistenceContext;

import figempa.uce.edu.ec.modelo.FlujoTrabajoProyecto;

import figempa.uce.edu.ec.servicios.ServicioFlujoTrabajoProyecto;

import figempa.uce.edu.ec.util.Constantes;

@Stateless

public class ServicioFlujoTrabajoProyectoImpl implements

ServicioFlujoTrabajoProyecto {

@PersistenceContext(name="ContratosProyectosFigempaEJB")

private EntityManager em;

/* (non-Javadoc)

* @see

figempa.uce.edu.ec.servicios.ServicioFlujoTrabajoProyecto#listarFlujoTrabaj

o()

*/

@SuppressWarnings("unchecked")

public List<FlujoTrabajoProyecto> listarFlujoTrabajo(){

return em.createQuery("select a from FlujoTrabajoProyecto a

where a.fpEstado=:estado order by fpId")

.setParameter("estado",Constantes.ACTIVO

).getResultList();

}

/* (non-Javadoc)

* @see

figempa.uce.edu.ec.servicios.ServicioFlujoTrabajoProyecto#buscarFlujoTrab

ajo(Integer codigoo)

*/

public FlujoTrabajoProyecto buscarFlujoTrabajo(Integer codigo){

return (FlujoTrabajoProyecto) em.createQuery("select a from

FlujoTrabajoProyecto a where a.fpId=:codigo")

73

.setParameter("codigo",codigo).getSingleResult();

}

/* (non-Javadoc)

* @see

figempa.uce.edu.ec.servicios.ServicioFlujoTrabajoProyecto#crearFlujoTrabaj

o(FlujoTrabajoProyecto flujoTrabajo)

*/

public void crearFlujoTrabajo(FlujoTrabajoProyecto flujoTrabajo){

em.persist(flujoTrabajo);

}

/* (non-Javadoc)

* @see

figempa.uce.edu.ec.servicios.ServicioFlujoTrabajoProyecto#actualizarFlujoTr

abajo(FlujoTrabajoProyecto flujoTrabajo)

*/

public void actualizarFlujoTrabajo(FlujoTrabajoProyecto flujoTrabajo){

em.merge(flujoTrabajo);

}

}

Vista:

Implementación de un Bean con sus respectivas notaciones.

package figempa.uce.edu.ec.web.beans.adm;

import java.util.ArrayList;


import javax.annotation.PostConstruct;

import javax.ejb.EJB;

74

import javax.faces.bean.ManagedBean;

import javax.faces.bean.ViewScoped;

import figempa.uce.edu.ec.modelo.Recurso;

import figempa.uce.edu.ec.servicios.ServicioRecurso;

/**

* Bean que toma los datos de la pagina de proyecto

*

* @author Jorge Quishpe.

* @version $Revision: 1.0 $

*

* */

@ManagedBean

@ViewScoped

public class RecursoBean {

@EJB

private ServicioRecurso servicioRecurso;

private List<Recurso> listaRecursos =new ArrayList<Recurso>();

private Recurso recursoNuevo=new Recurso();

private Recurso recursoEdicion=new Recurso();

@PostConstruct

public void init(){

listaRecursos=servicioRecurso.listarRecurso();

}

public void guardarRecurso(){

75

servicioRecurso.crearRecurso(recursoNuevo);

listaRecursos=servicioRecurso.listarRecurso();

recursoNuevo=new Recurso();

}

public void tomarRecurso(Recurso recurso){

recursoEdicion=recurso;

}

public void actualizarRecurso(){

servicioRecurso.actualizarRecurso(recursoEdicion);

recursoEdicion=new Recurso();

}

/**

* @return the listaRecursos

*/

public List<Recurso> getListaRecursos() {

return listaRecursos;

}

/**

* @param listaRecursos the listaRecursos to set

*/

public void setListaRecursos(List<Recurso> listaRecursos) {

this.listaRecursos = listaRecursos;

}

/**

* @return the recursoNuevo

*/

public Recurso getRecursoNuevo() {

return recursoNuevo;

}

76

/**

* @param recursoNuevo the recursoNuevo to set

*/

public void setRecursoNuevo(Recurso recursoNuevo) {

this.recursoNuevo = recursoNuevo;

}

/**

* @return the recursoEdicion

*/

public Recurso getRecursoEdicion() {

return recursoEdicion;

}

/**

* @param recursoEdicion the recursoEdicion to set

*/

public void setRecursoEdicion(Recurso recursoEdicion) {

this.recursoEdicion = recursoEdicion;

}

}

77

5.2 PRUEBAS

5.2.1 PRUEBAS DE CAJA BLANCA

La prueba de la caja blanca es un método de diseño de casos de prueba que

usa la estructura de control del diseño procedimental para derivar los casos

de prueba.

Las pruebas de caja blanca intentan garantizar que:

Se ejecutan al menos una vez todos los caminos independientes de

cada módulo.

Se utilizan las decisiones en su parte verdadera y en su parte falsa.

Se ejecuten todos los bucles en sus límites.

Se utilizan todas las estructuras de datos internas.

Para esta prueba se consideran tres importantes puntos.

Conocer el desarrollo interno del programa, determinante en el análisis

de coherencia y consistencia del código.

Considerar las reglas predefinidas por cada algoritmo, como son para

sentencias (se ejecutan la menos una vez), decisiones (toma

resultados posibles al menos una vez) y condiciones (decisión de todos

los posibles resultados al menos una vez).

Comparar el desarrollo del programa en su código con la

documentación pertinente.36

A continuación se presentan los resultados obtenidos en el log del servidor

de los casos de prueba que se realizaron:

36 Herramientas de Prueba de Software, http://herrorsoft.zxq.net/pruebacajablanca.html, revisado el 01/04/2013

http://herrorsoft.zxq.net/pruebacajablanca.html

78

Ingreso a la aplicación:

17:29:23,667 INFO [stdout] user----jquishpe

17:29:23,668 INFO [stdout] pass----fb03e127d9d53d8ec771b08f3f046815

17:29:23,668 INFO [stdout] rol----ROLE_ADMIN

Ingreso de un proyecto:

21:15:59,052 INFO [stdout] Proyecto->proyecto

21:15:59,071 INFO [stdout] Hibernate:

em.persist(?)

Modificación de un proyecto:

21:20:55,053 INFO [stdout] Proyecto->proyecto


em.merge(?)

Búsqueda de un Proyecto:

21:00:12,986 INFO [stdout] Proyecto----Proyecto 1


select p from Proyecto p where p.proNombre like

: ?

De esta forma se realizaron todas las pruebas en el sistema para conocer si

los métodos y flujos de trabajo estabas funcionando; el log del servidor nos

generó los resultados necesarios en cada caso.

79

5.2.2 PRUEBAS DE INTEGRACIÓN ORIENTADA A OBJETOS

Las pruebas de integración servirán para detectar las fallas de interacción

entre las distintas clases que componen al sistema.

A continuación se mostrara una prueba realizada para el ingreso al sistema:

Tabla 5.1: Pruebas de Integración.

Entrada (usuario,

clave)

Condiciones de

Entrada

Salida Esperada Condiciones de

Salida

(,) IU usuario y clave

ausente

Mensaje usuario y

clave son

requeridos

(jquishpe, ) IU clave ausente Mensaje clave es

requerida

( ,jquishpe) IU usuario ausente Mensaje usuario

es requerida

(jquishpe,

jquishpe)

Base de Datos Mensaje ingreso

correcto

Re direccionar

página principal

(jquishpe,

jquishpe1)

Clase clave

incorrecta

Mensaje error en

ingreso

(jquishpe1,

jquishpe)

Clase usuario

incorrecto

Mensaje error en

ingreso

(jquishpe,

jquishpe)

Base de datos

inactiva

Mensaje error en

ingreso

Son los posibles casos que podrían presentarse y en los que se realizó las

pruebas de integración, puesto que el ingreso de un usuario al sistema

interactúa con varios objetos en el sistema.

De la misma forma se realizó las pruebas en los demás objetos del sistema,

generando los resultados en cada caso correspondiente.

80

5.2.3 PRUEBAS DE INTERFAZ

Para conocer el funcionamiento de la aplicación en los diferentes browser

(navegadores) se realizaron pruebas del funcionamiento en tres navegadores.

A continuación se muestra los resultados obtenidos en cada uno de ellos.

Tabla 5.2: Prueba de Interfaz.

Navegador Tiempo de

respuesta

Visualización de

Formularios

Problemas y

Soluciones

Chrome 26.0. Optimo Optima Ninguno

Explorer 9 Optimo Optima Ninguno

Mozilla 20.0 Optimo Optima Ninguno

5.2.4 PRUEBAS DE VALIDACIÓN

El objetivo de estas pruebas es verificar si la aplicación cumple con todas las

especificaciones solicitadas. Cabe recalcar que estas pruebas se realizaron

una vez que la aplicación estaba en óptimo funcionamiento, durante el tiempo

de ejecución.

Las pruebas que se realizaron en esta sección fue en le ingreso de proyectos,

puesto que es la parte fundamental del mismo.

Los problemas que se solventaron al realizar las pruebas son las siguientes:

El campo email se corrigió para que solo acepte un email correcto

durante su ingreso.

El campo teléfono se lo dejo para que acepte caracteres, en vista de

que los números de teléfono incluyen también extensiones.

Los proyectos puedan asignar actividades y recursos, siempre y

cuando su propuesta sea aprobado.

El campo presupuesto solo acepte números.

81

5.2.5 PRUEBAS BASADAS EN ERRORES

Estas pruebas fueron realizadas durante las revisiones del sistema; se

encontraban errores y se los recreaba para conocer qué problema era la

posible causa; una vez analizados los log del servidor, se llevo pudo conocer

que muchos de los problemas que se suscitaban al momento del envió de

datos a la base, de esta forma resolver los errores encontrados.

82

CAPÍTULO VI

CONCLUSIONES Y RECOMENDACIONES

6.1 CONCLUSIONES

Debido a la necesidad de tener una metodología para el modelado y diseño

de aplicaciones Web que responda adecuadamente a las necesidades

actuales, es que se proponen metodologías que permitan dichas funciones,

UWE, provee una serie de herramientas tanto para diseño y modelado.37

El sistema desarrollado permitirá a la institución tener un control adecuado y

eficiente de todos los proyectos, puesto que consolida en un solo repositorio

de información de rápido acceso y búsqueda, lo que ayudará a la toma ágil y

oportuna de decisiones según sea el caso.

Se pretende con el sistema brindar un soporte al proceso de seguimiento de

proyectos, no en su totalidad sino en los puntos clave eficientemente, como

son revisar avances, actividades, dar a conocer en base a estos factores el

estado en el que se encuentra un proyecto dentro del departamento de

postgrado, consiguiendo de esta forma brindar apoyo para conocer el estado

en el que se encuentran ya que automatizar un proceso no es una tarea fácil,

en vista de que los procesos tienden a cambiar.

La digitalización de información fue otro punto principal en este proyecto; lo

que se consiguió con esto es tener un repositorio de información de todos los

proyectos con los que cuenta el departamento de postgrado; logrando

acelerar búsquedas; conocer que recursos se usaron en cada proyecto y que

personas estuvieron involucradas durante su desarrollo.

37 Metodología UWE, http://mlozanoavalos.blogspot.com/2009/06/articulo-ingenieria-web.html, revisado el

03/93/2013

http://mlozanoavalos.blogspot.com/2009/06/articulo-ingenieria-web.html

83

El sistema en sí, ayudara a tener un control más adecuado de los proyectos,

puesto que ahora los proyectos estarán registrados y con la ayuda de todos

los involucrados con información consistente; con esto se lograra que el

director o encargado del sistema tenga datos reales del estado de todos los

proyectos, además de tener la información digital de que se entregó y de cómo

se están llevando los recursos tanto económicos como físicos en los diferentes

trabajos.

84

6.2 RECOMENDACIONES

Cuando se trata de automatizar un proceso es necesario analizar hasta qué

punto sería necesario y si es conveniente hacerlo, puesto que en ocasiones

no resulta fácil esta tarea.

De acuerdo al desarrollo realizado lo que se recomienda es que todo sistema

involucra una tecnología; es decir para brindar una solución óptima a un

cliente lo primero que se debería analizar que tecnología se usara para la

solución, puesto que el factor crítico durante un desarrollo, investigación, etc.

Es la tecnología en la que se trabaje.

Sera necesario fomentar el uso de la aplicación, puesto que de nada servirá

tener una aplicación, que realice mil tareas de la mejor manera, si no se la da

un buen uso.

Se recomienda que para que el sistema funcione de una forma correcta, lo

más importante es la calidad de información, puesto que si los datos que se

ingresan carecen de sentido; cualquier sistema por mejor que pueda ser, no

presentará y no satisfacerá las necesidades que se esperaban.

85

BIBLIOGRAFÍA

MAX KATZ, IIya Shaikovsky (2012). Practical RichFaces, Second Edition.

ANGHEL, Leonard (2010). JSF 2.0 Cookbook.

GEARY, David. CAY, Horstmann (2010). Core JavaServer™ Faces Third

Edition.

PANDA, Debu. RAHMAN, Reza. LANE, Dereck (2007). EJB 3 in Action.

M. REESE, Richard (2011). EJB 3.1 Cookbook.

OTERO, Cesar. LARSEN, Rob(2012). Professional jQuery™

FREEMAN, Adam (2012). Pro jQuery

Institute for Informatics. Metodología Uwe. [Fecha de Consulta: 1 de agosto

del 2012]. Disponible en: http://uwe.pst.ifi.lmu.de/

Institute for Informatics. Metodología Uwe. [Fecha de Consulta: 1 de agosto del

2012]. Disponible en: http://uwe.pst.ifi.lmu.de/teachingTutorialSpanish.html

ÁLVAREZ VÉLEZ, Juan Carlos. Uwe el camino a la orientación de objetos en la

web. [Fecha de Consulta: 1 de agosto del 2012]. Disponible en: http://tecnologias-

informacion-sistemas.blogspot.com/2009/07/uwe-el-camino-la-orientacion-

objetos-en.html

DE LA ROSA ESCOLANTE, Miguel J. UML-based Web Engineering. [Fecha

de Consulta: 14 de agosto del 2012]. Disponible en:

http://uwespanishblog.blogspot.com/

86

Ingeniería de Software. [Fecha de Consulta: 29 de agosto del 2012].

Disponible en: http://rarguetaingesoft1.blogspot.com/2011/03/uweuml-based-

web-engineering.html

PRESSMAN, Roger S. MCGRAW-HILL, 2005. INGENIERÍA DEL

SOFTWARE, 6ª edición,

CONALLEN, Jim. WESLEY, Addison (2002). BUILDING WEB

APPLICATIONS WITH UML, 2ª edición.

AVDA REINA Mercedes. Universidad de Sevilla. Ingeniería de Requisitos en

Aplicaciones para la Web – Un estudio comparativo. [Fecha de Consulta: 14

de junio del 2012]. Disponible en: http://lsiweb.lsi.us.es/docs/informes/LSI-

2002-4.pdf

87

ANEXOS

88

Anexo A

Presupuesto

ÍTEM

RUBRO

Cantidad

Valor

Unitario

Valor

Rubro

No. Unidad No. $ $

1

RECURSOS INSTITUCIONALES

UCE:

Materias primas:

0 0 0.00

Material de laboratorio

0 0 0.00

Uso de equipos

0 0 0.00

SUBTOTAL RECURSOS INSTITUCIONALES UCE 0.00

2

RECURSOS HUMANOS

Tutor de trabajo de graduación 1 0 0.00

Tribunal de trabajo de graduación 2 0 0.00

Investigadores(Autores de trabajo

de grado) 1 0 0.00

SUBTOTAL RECURSO HUMANOS 0.00

3

RECURSOS MATERIALES

Material de escritorio:

● Resma de papel 3 5 15.00

● Tóner 2 80 160.00

● Copias 1000 0.02 20.00

● Caja de CDs 1 10 10.00

● Lápices 6 0.7 4.20

● Minas 10 0.35 3.50

● Borrador 6 0.22 1.32

Material bibliográfico:

● Internet 6(meses) 21 126.00

● Fotocopias de libros 1000 0.02 20.00

Trascripción borrador trabajo de

grado 300 0.1 30.00

Empastado de trabajo de grado 2(PENDIENTE) 15 30.00

SUBTOTAL RECURSO MATERIALES 420.02

4

OTROS

Movilización 300 0.50 150.00

Alimentación 300 2 600

Gastos varios 100.00

89

SUBTOTAL OTROS 850.00

TOTAL 1270.02

IMPREVISTOS (5%) 60.701

TOTAL DEL PRESUPUESTO 1330.701

RESUMEN DEL FINANCIAMIENTO

UCE (ÍTEM 1 + 2) 0,00

ALUMNOS (ÍTEM 3 + 4) 1330.701

90

Anexo B Cronograma.

91

Anexo C

Manual de Usuario

INTRODUCCIÓN

El presente Manual se orienta exclusivamente al ámbito técnico relacionado

con el sistema de seguimiento para contratos y proyectos de postgrado de

FIGEMPA.

Adicionalmente presenta la descripción de la arquitectura utilizada para la

codificación, así como también el detalle de la implementación.

Al final del documento se incluye una guía con los procedimientos

necesarios para la puesta en producción del proyecto.

1. ARQUITECTURA

Distribución de la aplicación

92

2. INSTALACIÓN DEL SISTEMA

2.1. REQUERIMIENTOS

2.1.1. REQUERIMIENTOS TECNICOS DE HARDWARE

2.1.1.1. A nivel de Servidor

PROCESADOR DE 64BITS DE MÍNIMO 1.5GHZ

4 GB EN RAM

ADAPTADOR DE RED

2.1.1.2. A nivel de Base de Datos

PROCESADOR DE 64BITS DE MÍNIMO 1.5GHZ

4 GB EN RAM

ADAPTADOR DE RED

2.1.2. REQUERIMIENTOS TECNICOS DE SOFTWARE

2.1.2.1. Requerimientos a nivel del sistema operativo

Servidor JBOSS 7.x previamente instalado

2.1.2.2. Requerimientos a nivel de base de datos

PostgreSQL 9 previamente instalado

2.2. PROCESO DE INSTALACIÓN DE COMPONENTES

2.2.1. NOMBRE DEL COMPONENTE:

La aplicación se encuentra empaquetada en el archivo

“ContratosProyectosFigempa.ear” provisto por los

desarrolladores del sistema.

2.2.2. PROCESO DE INSTALACIÓN:

Paso a Paso Acción y Responsable

1. Instalación

de JBoss

Desde el RHEL Obtenemos el paquete de instalación

de JBoss:

#cd /opt

#wget http://download.jboss.org/jbossas/7.1/jboss-as-

7.1.1.Final/jboss-as-7.1.1.Final.zip

93

Descomprimimos en un directorio:

#unzip jboss-as-7.1.1.Final.zip -d /usr/java/

Creamos un enlace simbólico. Este método nos

permitirá cambiar de versiones de JBoss sin modificar

ningún script.

#ln -s /usr/java/jboss-as-7.1.1.Final /opt/java/jboss

Responsable: Infraestructura

2. Configuració

n de Puertos

En la carpeta:

/opt/java/jboss/standalone/configuration

Editar en el archivo standalone.xml el siguiente

párrafo lo puertos que se van a utilizar o mantener los

que vienen por default si no es necesario el cambio

<socket-binding-group name="standard-sockets" default-interface="public" port-

offset="${jboss.socket.binding.port-offset:0}">

<socket-binding name="http" port="8181"/>

<socket-binding name="https" port="8443"/>

<socket-binding name="management-native" interface="management"

port="${jboss.management.native.port:9999}"/>

<socket-binding name="management-http" interface="management"

port="${jboss.management.http.port:9990}"/>

<socket-binding name="management-https" interface="management"

port="${jboss.management.https.port:9443}"/>

<socket-binding name="osgi-http" interface="management" port="8090"/>

<socket-binding name="remoting" port="4447"/>

<socket-binding name="txn-recovery-environment" port="4712"/>

<socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp">

<remote-destination host="localhost" port="25"/>

</outbound-socket-binding>

</socket-binding-group>

3. Instalación

de la

aplicación

Antes de copiar el archivo de la aplicación debemos

copiar el driver para la conexión a la BDD. “postgresql-

9.2-1000.jdbc4” en la carpeta:

/opt/java/jboss/standalone/deployments

94

Vía SSH copiar el archivo

“ContratosProyectosFigempa.ear” en la carpeta:

/opt/java/jboss/standalone/deployments

4. Creación del

DataSource

(cadena de

conexión)

Levantar el JBoss y acceder a la pantalla de

administración del JBoss para configurar el DataSource:

java:jboss/datasources/ FigempaDS

jdbc:postgresql:<nombre de la base de datos>

xml de datasource:

<datasource jta="false" jndi-name="java:jboss/datasources/FigempaDS" pool-

name="FigempaDS" enabled="true" use-ccm="false">

<connection-url>jdbc:postgresql:pcf</connection-url>

<driver-class>org.postgresql.Driver</driver-class>

<driver>postgresql-9.2-1000.jdbc4.jar</driver>

<security>

<user-name>postgres</user-name>

<password>root</password>

</security>

<validation>

<validate-on-match>false</validate-on-match>

<background-validation>false</background-validation>

</validation>

<statement>

<share-prepared-statements>false</share-prepared-statements>

</statement>

</datasource>

5. Creación de

carpetas

Para los archivos adjuntos, será necesario crear los

siguientes directorios en el servidor:

Adjuntos (directorio principal)

ANEXO

CONTRATO

CONTROL

PROPUESTA

PROYECTO

95

3. OPERACIÓN DEL SISTEMA.

3.1. PROCESO DE ESCALAMIENTO DE PROBLEMAS, ERRORES Y

PROBLEMAS COMUNES

Problema / Acción

- En el caso de que haya problemas con la conexión, revisar los

datasources creados en el jboss

- Otros problemas verificar los logs del jboss en el siguiente path

/opt/java/jboss/standalone/log/server.log

- En caso de presentarse problemas al guardar los adjuntos revisar

que las carpetas creadas en el servidor tengan los remisos de

lectura y escritura.

6. En la Utilarchivos.java q se encuentra ubicada en el

paquete figempa.uce.edu.ec.web.util será necesario

cambiar la dirección de la carpeta que se cree:

OutputStream os = new FileOutputStream("D:/Adjuntos/"+ dir +"/" + codigoProyecto

+ "_" + codigoDocumento + "_" + tipo + "." + ext);

Cambiar D: /Adjuntos/ por la dirección que se creó en

el servidor.

Y del mismo en la siguiente línea:

File dir = new File("D:/Adjuntos/"+direccion+"/");

7. Enmascarar la dirección del servidor de producción

donde se colocará el sistema :

http://direccion de servidor:puerto de salida asignado//

Dirección de la aplicación:

ContratosProyectosFigempaWeb/faces/administracion/ingresoAdm.xhtml

96

3.2. Proceso de reporte de incidencias

Problema Acción

Los incidentes son reportados a

través de administrador del sistema

El administrador de aplicaciones

puede revisar y corregir cualquier

problema menor con la aplicación.

97

Anexo D

Manual de Usuario

INTRODUCCIÓN

Con este documento se busca entregar una herramienta de soporte técnico

sobre la creación del Sistema de Seguimiento de Contratos y Proyectos para

el departamento de Postgrado de FIGEMPA.

El Sistema de ContratosProyectosFigempa se lo concibe como una

aplicación Web que permite realizar el seguimiento y la digitalización de

puntos claves tanto para proyectos como contratos en el Postgrado de

FIGEMPA.

Los módulos que contempla la aplicación son:

ContratosProyectosFigempa

o Página de Logeo.

o Proyectos

Información General.

Asignación de Actividades y Recursos.

Ingreso de Propuestas.

Edición Información.


Presentación de Informe

Búsqueda de Proyectos.

o Contratos

Información General.

Asignación de Proyectos.

Ingreso de Proveedores.

Presentación de hojas de Vida.


Presentación de Informe

Búsqueda de Contratos.

98

El desarrollo de estos módulos fue realizado de acuerdo a los requerimientos

y funcionalidad entregada por el departamento de Postgrado en FIGEMPA

HERRAMIENTAS

Para la creación del Sistema ContratosProyectosFigempa, se necesita tener

instaladas las siguientes herramientas:

El kit de desarrollo de Java “JDK” (La versión que se utilizó para el

desarrollo es jdk-7u3-windows-i586.exe);

Eclipse ( Para el desarrollo se utilizó la versión 3.7.x );

Servidor de Aplicaciones jboss-as-7.1.1.Final.

CARGA DEL PROYECTO EN ECLIPSE

Una vez que se encuentren instaladas las herramientas descritas en el

numeral anterior, se procede a cargar el proyecto de java, donde se podrá

crear o se realiza el mantenimiento del sistema

ContratosProyectosFigempa, para lo cual es necesario seguir el siguiente

procedimiento:

1) Iniciar la herramienta de desarrollo Eclipse, desde el menú de Programas

o desde el acceso directo que se crea en el escritorio:

2) Se presenta la ventana donde que pedirá la ubicación de la carpeta donde

se encuentra el proyecto, por defecto se crea una carpeta en la unidad

donde se instalo Eclipse con un path similar a

“Unidad:\eclipse\workspace”; si el proyecto esta en esta ubicación damos

en Ok, caso contrario presionar sobre Browse, y se busca la ubicación de

99

la carpeta que contiene el proyecto, en este caso se tiene una carpeta de

proyectos en la unidad principal:

3) A continuación se presenta la ventana principal de la aplicación, tal como

se indica en la siguiente figura:

4) Cerrar la pestaña Welcome, para ingresar al entorno de desarrollo tal

como se indica en la siguiente figura:

100

5) A continuación se procede a la carga del proyecto para lo cual es

necesario dirigirse a Import en el me File.

6) Luego se presenta un cuadro de diálogo que solicitara que tipo de

proyecto se va a importar, en el cual se debe escoger Existing Projects

into Workspace, como se muestra a continuación:

101

7) Una vez seleccionado el tipo de proyecto a importar, será necesario

ingresar la ubicación en la que se encuentra; presionar en Browse para

ubicar el directorio de proyecto.

8) Una vez seleccionado aparecerá la ubicación del proyecto a importar;

seleccionar la opción Add Project to working sets, que se encuentra

ubicada en la parte inferior, para copiarlo al workspace y finalmente clic en

finalizar.

102

Una vez realizada esta operación con los tres proyectos existentes

(ContratosProyectosFigempa, ContratosProyectosFigempaEJB, ContratosProyectosFigempaWeb)

se presenta el proyecto en el área de explorador de paquetes (Package

Explorer) tal como se puede ver en la siguiente figura:

ESTRUCTURA DE LAS CARPETAS DEL PROYECTO

Una parte fundamental que se debe conocer para la creación del Sistema

ContratosProyectosFigempa, es la estructura de archivos del proyecto, y la

utilización que tiene cada una de ellas, a continuación se presentará una

breve explicación de la estructura.

103

Una vez cargado el proyecto en Eclipse, se presenta el mismo con una

estructura de carpetas que se puede apreciar en la siguiente figura:

ContratosProyectosFigempa

En esta carpeta encontramos el código fuente del proyecto, dividido en

subcarpetas que contienen las diferentes clases de archivos de acuerdo a su

uso. Existen las siguientes subcarpetas que son:

ContratosProyectosFigempaEJB

104

ejbModule, contiene los paquetes de la aplicación como: modelo,

servicios, servicios.impl, util. El formato para nombrar al paquete esta

dado en base a la siguiente especificación para estructurar de una forma

ordenada los paquetes en el proyecto:

figempa.uce.edu.ec. <nombreModulo>.<NombreCapaFuncionalidad>

o En el paquete modelo se encuentran las clases de persistencia que

hacen referencia a las entidades de la Base de Datos a través del

mapeo.

o En el paquete servicios se encuentran las interfaces donde se definen

los diferentes servicios de la aplicación.

o En el paquete servicios.impl se encuentran las implementaciones de

las respectivas interfaces.

105

o En el paquete util se encuentra clases comunes para proyecto como

cifrado de contraseñas, constantes, etc.

El entity de Actividades, se describe de la siguiente manera:

106

o La clase Session contienen la lógica del negocio definida en los

SessionBeans con la implementación del tipo de interfaz Local,

ejecutada desde el lado del servidor.

Interface del Servicio Actividades

Implementación del Servicio Actividades

o La implementación de la lógica del negocio -métodos- se la realiza en

los SessionBeans. Además aquí se describen las referencias de la

persistencia –esquema de Base de Datos que hace referencia al

107

módulo- que se va utilizar, todos los EJB que se van a manejar para

este SessionBean.

o Dentro del META-INF, encontramos un archivo de configuración

denominado persistence.xml.

persistence.xml describe la configuración de la persistencia

que se está manejando para este proyecto, hablamos de un

esquema llamado: FigempaDS. El esquema maneja sus

respectivas entidades.

ContratosProyectosFigempaWeb

En esta carpeta se encontra la capa de presentación del proyecto, dividido

en subcarpetas que contienen las diferentes clases de archivos de acuerdo a

su uso. A continuación se detallan estas carpetas:

108

Java Resources->SRC, contiene archivos con extensión .java, y

corresponde a los bean que brindan la funcionalidad a las páginas XHTML.

Su nombre se define de la siguiente manera: figempa.uce.edu.ec.web.

<nombreBean>. Los cuales guardan información, utilizan un API para

representar componentes de la Interfaz de Usuario y manejar sus estados,

manejar sus eventos; también realizan la validación del lado del servidor, la

conversión de datos y definir la navegación entre páginas. Por cada página

XHTML existe un bean.

109

WebContent.- aquí se encuentran las páginas xhtml, los cuales darán el

aspecto visual al sistema, para cada formulario. La carpeta css contiene los

estilos que son utilizados en las páginas xhtml.

Dentro de la carpeta paginas encontramos las páginas Web que presentan

la interfaz para el usuario.

110

La carpeta CSS, contiene el archivo con los estilos de diseño que se

manejan en el proyecto.

La carpeta WEB- INF, contiene archivos de configuraciones que se detallan

a continuación:

111

faces-config.xml, es el archivo de configuración de jsf.

web.xml, archivo de configuración de componentes del proyecto para el

despliegue de la aplicación, describe al contenedor Web, sus elementos y el

modo en que se accede a los mismos. Además, define aspectos de

seguridad, ficheros de bienvenida, parámetros iniciales y parámetros de

contexto.

112

Anexo E

Manual de Usuario

1. INTRODUCCIÓN

Este manual permitirá dar a conocer las funcionalidades básicas para el Sistema Seguimiento de Proyectos y Contratos para Postgrado de la Facultad de Ingeniería en Geología, Minas, Petróleos y Ambiental.

2. FUNCIONAMIENTO DE LA APLICACIÓN

Acceso a la aplicación.

Acceder a http://direccionServidor/ContratosProyectosFigempaWeb/faces/administracion/ingresoAdm.xhtml, donde se presentará la siguiente pantalla (Fig. 1).

Fig.1

Como se puede observar es la pantalla de ingreso a la administración del sistema; donde se deberá ingresar el usuario y la clave correspondientes; al presionar el botón ingresar el sistema direccionara a la pantalla principal del mismo (Fig. 2), la cual tiene el siguiente menú:

1. Principal: Opción que presenta la pantalla principal del sistema

113

2. Proyectos: Opción que le permite acceder al seguimiento y administración de proyectos académica relativa al nivel Pregrado.

3. Contratos: Opción que le permite acceder al seguimiento y administración de Contratos.

4. Instrucciones: Opción que permite leer instrucciones de uso del sistema.

Fig. 2

2.1 PROYECTOS

Esta pestaña tiene un submenú el cual permitirá acceder tanto como a la

administración y al seguimiento de un proyecto (Fig. 3).

Fig. 3

Esta pantalla consta del siguiente Menú:

Proyectos

Recursos

Informe Proyecto

Avance Proyecto

Control Resumen Ejecutivo

Cerrar Sesión

114

Proyectos: Al seleccionar esta opción se presentara la lista de proyectos

ingresados en el sistema, con su respectivo estado (Fig. 4):

Fig. 4

Además se podrá realizar las siguientes operaciones:

Ingreso de Proyectos: Permite ingresar proyectos nuevos en el sistema; El

botón de ingreso de un nuevo proyecto se encuentra ubicado en la parte

inferior de lista de proyectos (Fig. 5); al presionar el botón aparecerá una

ventana (Fig. 6) con los datos que se deberán ingresar por cada proyecto (hay

que tener en cuenta que el sistema se basa en seguimiento y digitalización de

proyectos por lo que la información que se solicita ingresar en el proyecto es

corta y además fue validada por los usuarios del sistema).

Fig. 5

Búsqueda de Proyectos: se

puede realizar búsquedas por

nombre de proyecto.

Lista de Proyectos

Ingreso de Nuevo

Proyecto

115

Fig. 6

La información de ingreso está correctamente validada para evitar ingresar

información incorrecta o dejar campos vacíos, es decir si se presiona en el

botón aceptar sin tener información se presentaran los siguientes mensajes

de advertencia (Fig. 7)

Fig. 7

Una vez ingresada la información de un proyecto (Fig. 8), existe la opción de

edición, que permitirá cambiar estados en proyectos y a su vez el ingreso de

información digital según el estado (cuando un proyecto cambia a estado

finalizado se debe subir un archivo digital con toda la información relativa de

todo el trabajo realizado (Fig. 9)).

116

Fig. 8

Fig. 9

Subir Propuestas: A un proyecto no se le podra asignar actividades ni

recursos, siempre y cuando se haya subido una propuesta y ademas esta

este en estado aprobada. Una ves ingresado el proyecto aparecera un link

para subir la propuesta del proyecto (Fig. 10).

Fig. 10

Opción de edición

Ingreso Propuesta

117

Al presionar sobre el link se direccionara a la página de ingreso de propuesta

(Fig. 11) la cual tendra las opciones de ingreso y edición respectivamente.

Fig. 11

Asignacion de recursos:Una vez que la propuesta a sido aceptada, se

habilitaran los link de ingreso de recursos y actividades para el proyecto (Fig.

12).

Fig. 12

La asignación de recursos se realiza de la siguiente manera:

En primer lugar se debe crear un recurso; para esto se deberá seleccionar

del submenú de proyectos recursos (Fig. 13), la cual permitirá el ingreso, y

modificación de todos los recursos que existen o con los que cuente la

empresa.

Descripción corta de

propuesta.

Estado de propuesta.

Visualización corta de

propuesta.

Subir propuesta. En este caso

se reemplazara la existente

Edición.

Ingreso Actividades y

Recursos

118

Fig. 13

El ingreso y la edición de un recurso es simplemente la descripción del recurso

(Fig. 14).

Fig. 14

Una vez creado el recurso, para asignarlo a un proyecto se deberá ingresar

en proyectos y seleccionar la opción recursos que se la menciono

anteriormente, la cual presentara los recursos asignados al proyecto (Fig. 15).

Fig. 15

Edición

Nuevo Recurso

Submenú Recurso

Nueva asignación

Editar asignación

Recursos asignados

119

La pantalla de asignación es la siguiente (Fig. 16).

Fig. 16

Asignación de actividades: Para asignar actividades a los proyectos, es

necesario ubicarse el link de actividades que se encuentra en la lista de

proyectos una vez que la propuesta ha sido aceptada. (Fig. 17).

Fig.17

El link re direccionará a la pantalla de asignación de actividades, la cual tiene

las opciones siguientes (Fig. 18):

Link asignación de

actividades

120

Fig. 18

Lista de actividades: actividades asignadas a un proyecto.

Ingreso Nueva Actividad: permite ingresar una nueva actividad, el formulario

de ingreso consta de los siguientes campos (Fig. 19).

Fig. 19

El campo tiene adjunto se refiere si la actividad posea adjuntos durante su

desarrollo(Los archivos adjuntos se deberán subir en formato PDF, y el

tamaño máximo de carga por cada archivo es de 2 M)

Edición de Actividad: permite editar la información de una actividad, así

como también cambiar los estados (finalizada, en proceso, etc.) e ingresar

gastos y porcentajes de avance durante el tiempo de desarrollo (Los días de

desarrollo se calculan automáticamente a partir de las fechas ingresadas en

Lista de actividades

Ingreso nueva

actividad

Edición de

actividades

Ingreso encargado de

actividad

121

el sistema y serán usados para el cálculo del porcentaje de avance del

proyecto) (Fig. 20).

Fig. 20

Si el estado de la actividad es finalizado se pedirá que ingrese el resumen

ejecutivo y el informe económico como se puede observar en la Fig. 20, estos

adjuntos deben ser en formato PDF y de máximo 2 M de tamaño.

Asignación responsable de actividad: Al seleccionar esta opción se presentara

una lista de todas las personas que están asignadas al proyecto de las cuales

se podrá asignar una solo por cada actividad. Las opciones que existen en la

asignación de responsables para actividades son las siguientes (Fig. 21):

122

Fig. 21

Botón asignación: Permite asignar al responsable de la actividad.

Botón Eliminar: una vez asignado un responsable, existe la opción de

eliminar asignación, con la que se podrá quitar y reasignar un responsable a

una actividad.

Las dos opciones tienen un mensaje de confirmación para cada caso.

Informe Proyecto: Presenta todo el informe de un proyecto, es decir que

actividades están asignadas, adjuntos subidos y recursos asignados.

Al seleccionar esta opción se presenta una tabla con la lista de proyectos

(Fig. 22)

Listas de personas

asignadas a un

proyecto

Responsable

Actividad

Botón asignación

123

Fig. 22

Al seleccionar un proyecto se presentara el siguiente informe (Fig. 23)

Fig. 23

Lista de Proyectos

Link de ingreso para

informe

Información General

Propuesta

Actividades

Recursos

124

Avance Proyecto: Presenta el avance físico y económico del proyecto (Fig.

24).

Fig. 24

Fig. 24

Al seleccionar un proyecto se podrá visualizar la lista de actividades con los

porcentajes de avance (Fig. 25).

Fig. 25

Control de Resumen Ejecutivo: Permite realizar un seguimiento del

resumen ejecutivo de cada actividad en los proyecto, si es necesario.

Al seleccionar esta opción se presentara la lista de proyectos (Fig. 26)

Búsqueda de

Proyectos

Lista de Proyectos con

porcentajes de avance

125

Fig. 26

Al escoger las actividades de proyecto se presentara la siguiente pantalla (Fig.

27)

Fig. 27

Lista de Proyectos

Link de acceso a actividades

finalizadas

Lista de actividades finalizadas

Opción que permite resumen

ejecutivo

Historial de resumen ejecutivo

modificado

Ingreso Nuevo resumen

ejecutivo

Visualizar resumen ejecutivo

Ingreso de observaciones de

resumen ejecutivo

126

2.2 CONTRATOS

Esta pestaña tiene un submenú el cual permitirá acceder tanto como a la

administración y al seguimiento de un contrato (Fig. 27).

Fig. 27

Esta pantalla consta del siguiente Menú:

Hojas de Vida

Proveedores

Contratos de Proyecto

Proyectos Asignados

Asignar Proyectos

Cerrar Sesión

Hojas de Vida: Al seleccionar esta opción se presentara la lista de hojas de

vida registradas en el sistema (Fig. 28):

127

Fig. 28

Lista de hojas de vida: Hojas de vida registradas en el sistema.

Editar Hoja de Vida: Permite la edición de la información de las hojas de

vida, al seleccionar esta opción se presenta la siguiente pantalla.

Fig. 29

Se podrá editar toda la información de los usuarios registrados en el sistema.

Lista de Hojas de Vida

Editar Hoja de Vida

Link para acceder contratación

Información general del usuario

registrado

Ingreso de estudios realizados

Ingreso de experiencias

laborales

128

El formulario para estudios realizados es el siguiente:

Fig. 30

El formulario para experiencias laborales es el siguiente:

Fig. 31

Todos los campos solicitados en cada uno de los formularios son obligatorios.

La edición de cada formulario tiene los mismos campos que al ingreso de un

nuevo.

Revisar: Permite visualizar toda la información ingresado por el usuario,

además de existir la opción de contratar si es que cumple con los requisitos

solicitados (Fig. 32).

129

Fig. 32

Al final del formulario se podrán visualizar los siguientes campos (en caso de

que cumpla con los requisitos se puede contratar) (Fig. 33)

Fig. 33

Al contratar a una persona el sistema solicitara que se suba el contrato (Fig.

34), para esto se puede observar el link Subir Contrato, al presionar sobre el

aparecerá una ventana que le permitirá subir el archivo.

Campos solicitados para

contratación

Link para subir contrato

130

Fig. 34

Una vez guardado los cambios se podrá visualizar en la lista de hojas de vida

el contrato subido y el cambio de estado de hoja de vida por contratado (Fig.

35).

Fig. 35

Proveedores: esta opción cuenta permite consultar los proveedores

(empresas que son contratadas en caso de no contar con los recursos

adecuados para un proyecto) con los que trabaja el instituto de postgrado

(Fig. 36).

Visualizar Contrato

Estado hoja de vida

131

Fig. 36

Lista de Proveedores: lista de empresas que se han ingresado en el sistema.

Ingreso Nuevo: permite ingresar un nuevo proveedor en el sistema, el

formulario es el siguiente (Fig. 37).

Fig.37

Todos los campos son obligatorios, en caso de presionar el botón Aceptar

llegando a faltar algún campo se desplegaran los siguientes mensajes (Fig.

38).

Lista de Proveedores

Ingreso Nuevo

Editar Proveedores

Ingreso Contrato

132

Fig. 38

Edición de un Proveedor: esta opción permite editar la información del

proveedor almacena en el sistema (Fig. 39).

Fig. 39

Contrato: Permite ingresar la información básica de un contrato, fechas,

estado, además del archivo digital del contrato (Fig. 40).

Fig. 40

Mensajes de Advertencia

Opción para subir archivo

digital de contrato

133

Si el estado de contrato es CONTRATADO, el sistema pedirá que se suba un

archivo en formato PDF del contrato.

Contratos Proyectos: Permite ingresar al sistema el archivo digital del

contrato de un proyecto (Fig. 41).

Fig. 41

Búsqueda de proyectos: permite filtrar proyectos por nombres.

Lista de Proyectos: lista de proyectos que tiene su propuesta de trabajo

aprobada.

Visualizar Contrato: una vez subido el contrato se lo podrá visualizar

presionando sobre el icono de PDF que aparecerá en el proyecto.

Subir Contrato: permite subir el contrato del proyecto (Fig. 42), al

seleccionarla aparecerá un cuadro de búsqueda en el sistema, para subir el

contrato (el archivo deberá estar en formato PDF)

Lista de Proyectos

Opción para subir archivo

digital de contrato

Búsqueda por nombre de

proyecto Visualizar Contrato

134

Fig. 42

Proyectos Asignados: Permite visualizar un informe de proyectos asignados

a las hoja de vida contratadas.

Al ingresar a esta opción se visualizara lo siguiente (Fig. 43):

Fig. 43

Al presionar sobre el link proyectos se podrá visualizar los proyectos en los

que está trabajando o trabajo el usuario registrado (Fig. 44).

Opción que permite visualizar

los proyectos asignados

135

Fig. 44

En este caso la persona del primer registro está asignada a dos proyectos.

Asignar Proyectos: Permite asignar proyectos a las hojas de vida

contratadas (Fig. 45).

Fig. 45

Asignar recursos humanos: permite asignar el personal que estará

involucrado con el proyecto (Fig. 46), al seleccionar esta opción se podrá

visualizar la siguiente pantalla.

Fig. 46

Búsqueda de proyectos por

nombre

Asignar recursos humanos

Asignar proveedores externos

Personas contratadas

Opción asignar

Personas asignadas al

proyecto Eliminar

136

Personas contratadas: Lista de recursos humanos contratados para

proyectos.

Personas asignadas: Lista de personas asignadas al proyecto escogido.

Eliminar: Opción que permite eliminar a una persona de un proyecto (Fig. 47)

(Al eliminar a una persona de un proyecto solo se lo quitara de la asignación

y no del sistema.)

Fig. 47

Asignar: Opción que permite asignar personal al proyecto (Fig. 48)

Fig. 48

Asignar proveedores externos: permite asignar proveedores en caso de ser

necesario al proyecto (Fig. 49), al seleccionar esta opción se podrá visualizar

la siguiente pantalla.

137

Fig. 49

Proveedores contratados: Lista de proveedores contratados para proyectos.

Proveedores asignados: Lista de proveedores asignados al proyecto

escogido.

Eliminar: Opción que permite eliminar a un proveedor de un proyecto (Fig.

50) (Al eliminar a un proveedor de un proyecto solo se lo quitara de la

asignación y no del sistema.)

Fig. 50

Proveedores asignados al

proyecto

Proveedores contratados Opción asignar

138

Asignar: Opción que permite asignar proveedores al proyecto (Fig. 51)

Fig. 51

Cerrar Sesión: cierra la sesión del sistema.

universidad central del ecuador - … · 2013-06-25 · en primer a mi madre por haberme apoyado...

Documents