Está en la página 1de 100

UNIVERSIDAD TECNOLGICA DE LA SELVA

DESARROLLO DE LOS REQUISITOS ESTABLECIDOS PARA DISEAR LA ARQUITECTURA BASE DE SISTEMAS ORIENTADOS A PROCESOS DE NEGOCIOS Y FLUJOS DE TRABAJO

TESINA

QUE PARA OBTENER EL TTULO DE

INGENIERO EN TECNOLOGAS DE LA INFORMACIN

PRESENTA

Mariano Prez Prez

ASESOR EMPRESARIAL Y ACADMICO

MC. Armando Mndez Morales

OCOSINGO, CHIAPAS; ABRIL, 2012

AGRADECIMIENTO

Al terminar esta etapa de mi vida, quiero expresar un profundo agradecimiento a quienes con su ayuda, apoyo y compresin me alentaron a lograr esta hermosa realidad. A Dios. Por todo lo que me ha dado en la vida, de darme la oportunidad de seguir adelante con mis metas y sobre todo el bien estar de mi seres queridos. A mis padres. Agradezco infinitamente a mi padre Jos Prez pech y a mi madre Manuela Prez Paciencia por todo el amor, cario y apoyo moral que siempre he recibido incondicionalmente de ellos. El haber culminado mi carrera profesional, es como darme el regalo ms grande de mi vida, que a pesar de las carencias familiares y problemas de salud, nunca dejaron de apoyarme, aun cuando era difcil de estar conmigo, siempre estuvieron ah. Han estado conmigo en las buenas y en las malas, en mis triunfos y derrotas, siempre supieron cmo guiarme en el camino correcto. Ello me decan, que siempre hay una forma de salir adelante y eso me haca sentir ms comprometido y orgulloso de tener unos padres como los mos. Gracias pap y gracias mam, siempre los llevar en mi corazn y espero que no solo estn orgullosos de m, sino tambin de ustedes porque este triunfo tambin es de ustedes. A mis hermanas. Agradezco a mi hermana Estela Prez Prez porque ha hecho todo lo posible para sacar adelante a mi familia junto con mis padres, y sobre todo siempre estuvo apoyndome durante mi carrera. A mi hermana Juana Prez Prez que siempre me abri las puertas en mis estudios, a pesar de que ella nunca fue a la escuela, siempre nos motivo y nos empujo a salir adelante, con su dedicacin y esfuerzo al trabajo

siempre me apoyo cuando la necesitaba. Y a mi hermana Vernica Prez Prez por ser tambin mi amiga, siempre me apoy cuando nadie lo haca, me dio la amistad que yo necesitaba de una familia y me supo cuidar desde que yo era nio. Gracias hermanas, siempre estarn en mi corazn. A mi hermanito. Agradezco a mi hermanito Fernando Prez Prez por apoyarme durante mi formacin profesional, con su esfuerzo y dedicacin ha podido sacar adelante la nuestra agrupacin musical. Gracias A la Universidad Tecnolgica de la Selva. Agradezco a la universidad por ser una casa de estudios de calidad, que se han formado profesionales de xito. Gracias a la Universidad, por haberme cobijado a lo largo de mi carrera, por la enseanza que me dio a travs de sus excelentes catedrticos y a la excelencia de su plan de estudios. A la Secretaria Acadmica. Agradezco a la Lic. Leydy Roxana Zepeda Ruiz por darme el apoyo y la oportunidad de impartir asesoras de programacin en JAVA en febrero del 2011 y en Mayo -Agosto del mismo ao, tambin pude impartir cursos de programacin en PHP. De todo corazn muchas gracias. A mi asesor. Agradezco al MC. Armando Mndez Morales por el apoyo que me ha brindo, no solo durante la estada, sino a lo largo de mi carrera profesional. Por la gran confianza que me ha tenido desde el ao 2010, cuando empec a desarrollar el Sistema de control de pagos de la Universidad Tecnolgica de la Selva. Siempre estar agradecido. A La Mtra. Xochitl Clemente Parra. Agradezco por apoyarme en los tiempos que necesitaba de ella, como gestionar las asesoras de programacin en JAVA y los cursos de programacin en PHP. De todo corazn muchas gracias. II

RESUMEN

El proyecto Desarrollo de los requisitos establecidos para disear la arquitectura base de sistemas orientados a procesos de negocios y flujos de trabajo fue desarrollado con la finalidad de crear una arquitectura de cdigo fuente bsica para ser empleada en el desarrollo de sistemas basados en el modelo de procesos de negocios, permitiendo la administracin de las actividades y la secuencia de cada una de ellas en un mismo proceso, en lo que intervienen varios actores, de algn modo reconfigurar los procesos sin la necesidad de modificar el sistema, apoyar a la coordinacin de las personas en la ejecucin de las actividades asignadas, mejorando la calidad y rapidez del servicio en la institucin.

Para implementar el modelo de procesos de negocios de un sistema, tambin se requiere la utilizacin de flujos de trabajos conocidos como Workflow.

El resultado de este trabajo de investigacin consiste en la realizacin de los requisitos especificados en el documento de requisitos, la comparacin entre empresas que operan de forma funcional vs empresas que operan de forma orientada a procesos, la elaboracin del manual tcnico para desarrollar un nuevo mdulo empleando la arquitectura base desarrollada y la elaboracin del diagrama para representar de forma resumida la generacin de nuevos mdulos orientados a procesos.

III

NDICE DE CONTENIDO

I. INTRODUCCIN .............................................................................................................. 1 II. ANTECEDENTES ........................................................................................................... 2 II.1. Marco terico. ........................................................................................................... 2 II.1.1. Procesos de Negocio. ...................................................................................... 2 II.1.2. Bizaggi ................................................................................................................ 6 II.1.3. Flujos de trabajo (workflows) ........................................................................ 11 II.1.4. ProcessMaker ................................................................................................. 13 II.1.5. Frameworks ..................................................................................................... 16 II.1.6. Spring Roo. ...................................................................................................... 17 II.1.7. ZK Framework ................................................................................................. 18 II.1.8. JSTL .................................................................................................................. 20 II.1.9. JPA (Java Persistence API) .......................................................................... 23 II.1.10. Glassfish ........................................................................................................ 25 II.1.11. Sistema de control de versiones (Subversin) ........................................ 26 II.1.12. Metodologa Scrum ...................................................................................... 28 II.2. Marco referencial. .................................................................................................. 33 II.2.1. Actividad econmica de la institucin.......................................................... 33 II.2.2. Bienes y/o servicios........................................................................................ 33 II.2.3. Ubicacin Geogrfica de la empresa (nivel estatal y municipal). ........... 35 II.2.3.1. Nivel Estatal. ............................................................................................ 35 II.2.3.2. Nivel Municipal. ........................................................................................ 36 II.2.4. Giro y tamao de la Institucin. .................................................................... 37 II.2.5. rea de influencia (rea especfica de mercado). ..................................... 38 II.2.6. Objetivos de la empresa. ............................................................................... 39 II.2.6.1. Objetivo general....................................................................................... 39 II.2.6.2. Objetivos especficos. ............................................................................. 39 II.2.6.3. Misin. ....................................................................................................... 40 II.2.6.4. Visin. ........................................................................................................ 40 II.2.7. Poltica de calidad. ......................................................................................... 41 II.2.8. Organigrama de la Institucin ....................................................................... 41 II.2.10. rea de la empresa en donde se desarrolla el proyecto ....................... 42 II.3. Planteamiento del problema................................................................................. 42 II.4. Objetivos .................................................................................................................. 43 II.4.1. Objetivo General ............................................................................................. 43 II.4.2. Objetivos Especficos ..................................................................................... 43 II.5. Justificacin............................................................................................................. 44 III. METODOLOGA ........................................................................................................... 45 III.1. Enfoque metodolgico ......................................................................................... 45 III.2. Mtodo de recoleccin de datos......................................................................... 46 III.3. Definir el Universo (poblacin) y el tamao de muestra................................. 49 III.4. Recopilacin de datos .......................................................................................... 50 IV. ANLISIS DE RESULTADOS Y DISCUSIN ........................................................ 52 IV

IV.1. Anlisis de resultados en la encuesta. .............................................................. 52 IV.2. Resultados del proyecto. ..................................................................................... 62 IV.2.1. Comparacin entre empresas que operan de forma funcional vs empresas que operan de forma orientada a procesos. ....................................... 62 IV.2.3. Manual para desarrollar un nuevo mdulo empleando la arquitectura base desarrollada. ..................................................................................................... 64 IV.2.4. Estructura visual o diagrama para representar de forma resumida la generacin de nuevos mdulos orientados a procesos. ..................................... 85 V. CONCLUSIONES Y RECOMENDACIONES. .......................................................... 86 VI. REFERENCIAS DOCUMENTALES. ........................................................................ 88 Anexos ................................................................................................................................. 89

NDICE DE FIGURAS

Figura II.1.- Proceso de Negocio. ..................................................................................... 2 Figura II.2.- Interaccin entre una Actividad y su entorno. ........................................... 3 Figura II.3.- pasos para construir una solucin en Bizagi. ............................................ 6 Figura II.4.- Sistema de Workflow. .................................................................................. 11 Figura II.5.- Tipos de Workflow ........................................................................................ 12 Figura II.6.- Modelo en que ayudan los Process Maker. ............................................. 15 Figura II.7.- Ejemplo de Inicio de sesin utilizando los Process Maker. ................... 15 Figura II.8.- Aplicacin web con Spring.......................................................................... 18 Figura II.9.- Aplicacin web con Framework ZK. .......................................................... 19 Figura II.10.- Cdigo comparativo de JSP y JSTL. ...................................................... 22 Figura II.11.- Arquitectura Hibernate. ............................................................................. 24 Figura II.12.- Distribuciones y contribuyentes de Glassfish. ....................................... 25 Figura II.13.- FrameWorks y aplicaciones relacionadas a Glassfish. ....................... 26 Figura II.14.- Sistema de Control de Versiones. ........................................................... 27 Figura II.15.- Proceso de Scrum. .................................................................................... 28 Figura II.16.- Proceso de la metodologa SCRUM. ...................................................... 32 Figura II.17.- Ubicacin de la institucin a nivel Estatal. ............................................. 35 Figura II.18.- Ubicacin de la institucin a nivel Estatal. ............................................. 36 Figura II.19.- Organigrama general de la universidad tecnolgica de la selva. ...... 41 Figura III.1.- Evaluacin de conocimiento en desarrollos de software...................... 48 Figura III.2.- Encuesta aplicada al personal docente. .................................................. 51 Figura IV.1.- Creacin de un nuevo paquete. ............................................................... 67 Figura IV.2.- Asignar nombre del paquete. .................................................................... 67 Figura IV.3.- Creacin de la entidad a partir de la base de datos ............................. 68 Figura IV.4.- Seleccin del nombre de la entidad. ....................................................... 68 Figura IV.5.- Seleccin de paquete para la entidad. .................................................... 69 Figura IV.6.- Seleccionar el tipo de mapeo de la entidad. .......................................... 69 Figura IV.7.- Copiando clases de entidad...................................................................... 70 Figura IV.8.- Cdigo fuente del mtodo getYsetParameters. ..................................... 71 Figura IV.9.- Cdigo fuente del mtodo getParamsBusq............................................ 71 Figura IV.10.- Cdigo fuente del mtodo getParamsForm. ........................................ 72 Figura IV.11.- Cdigo fuente de la entidad BuscarGral. .............................................. 73 Figura IV.12.- Cdigo fuente de la entidad BuscarParticular. .................................... 74 Figura IV.13.- Cdigo fuente de la entidad CrearNuevo. ............................................ 75 Figura IV.14.- Cdigo fuente de la entidad Eliminar. ................................................... 76 Figura IV.15.- Cdigo fuente de la entidad GuardarCambios. ................................... 77 Figura IV.16.- Cdigo fuente de la entidad GuardarNuevo. ....................................... 78 Figura IV.17.- Copiando los archivos JSP's .................................................................. 79 Figura IV.18.- Librerias importadas en el archivo JSP. ............................................... 80 Figura IV.19.- Inicializacin de las etiquetas ZK y windows. ...................................... 80 Figura IV.20.- Cambio de nombre y funcin del form. ................................................. 81 Figura IV.21.- Cargar una lista en el JSP con ZK y JSTL. .......................................... 81 VI

Figura IV.22.- Manejo de los botones en ZK. ................................................................ 82 Figura IV.23.- Creacin de pginas por medio de botones a traves de forEach. ... 83 Figura IV.24.- Etiquetas para la visualizacin de los datos de consulta. .................. 83

NDICE DE TABLA

Tabla III.1.- Muestra poblacional considerado en la investigacin. .......................... 49 Tabla IV.1.- Empresas funcionales vs Empresas por procesos. ............................... 63 Tabla 0.1.- Documento de requisitos.............................................................................. 91

VII

NDICE DE GRAFICAS

Grfica IV.1.- Evaluacin del nivel de conocimiento de aplicaciones. ...................... 52 Grfica IV.2.- Evaluacin del nivel de uso de Framework de aplicaciones.............. 53 Grfica IV.3.- Evaluacin de del uso de Framework para php. .................................. 53 Grfica IV.4.- Evaluacin de Frameworks para php. ................................................... 54 Grfica IV.5.- Evaluacin del uso de Framework para java........................................ 55 Grfica IV.6.- Evaluacin de Frameworks para java.................................................... 55 Grfica IV.7.- Evaluacin del modo de la reutilizacin de cdigos desarrollados. .. 56 Grfica IV.8.- Evaluacin del nivel de utilidad del uso de los Framework. ............... 56 Grfica IV.9.- Evaluacin del porque es de mucha utilidad los Framework. ............ 57 Grfica IV.10.- Evaluacin de utilizacin de Modelado de Proceso. ......................... 58 Grfica IV.11.- Evaluacin de herramientas utilizadas en el diseo de procesos. . 58 Grfica IV.12.- Etapa de utilizacin de herramientas para disear procesos. ......... 59 Grfica IV.13.- Evaluacin de elementos de un Sistema de Gestin de Procesos.59 Grfica IV.14.- Evaluacin de la fuente de informacin para resolver la encuesta. 60 Grfica IV.15.- Evaluacin en qu etapa se define el Modelo de Negocios. ........... 61 Grfica IV.16.- Empresa con estructura organizacional funcional. ............................ 62 Grfica IV.17.- Empresa con estructura organizacional por procesos...................... 63 Grfica IV.18.- Generacin de nuevos mdulos orientados a procesos. ................. 85

VIII

I. INTRODUCCIN
I.1. Introduccin

El presente proyecto consiste en el desarrollo de los requisitos establecidos para disear un sistema que contempla la arquitectura base de codificacin de sistemas orientados a procesos de negocios y flujos de trabajo. Los procesos consisten de una serie de actividades realizadas por diferentes personas que desempean diferentes roles y responsabilidades. A continuacin se hace mencin de los temas a abordar en cada uno de los captulos siguientes:

Captulo I. Introduccin; se describen los datos generales de la creacin del proyecto, a s mismo para la ubicacin practica del lector, de manera que se tenga un panorama general de lo que contiene el documento.

Captulo II. Antecedentes; es donde se plantean los modelos, teoras y conceptos relacionados con el proyecto que se pretende realizar.

Captulo III. Metodologa, se describe de manera general el proceso a seguir en cada una de las etapas del trabajo a realizar, donde aplicaremos mtodos y tcnicas de recopilacin de informacin para medir el grado de conocimiento de los Framework de aplicacin.

Captulo IV. En esta sesin se realizara el anlisis de resultados y discusin, donde presentamos los resultados, que se obtienen de las encuestas aplicadas a los docentes, interpretando los resultados en grficas.

Captulo V. Conclusiones y recomendaciones, es donde se describen series de afirmaciones y sugerencias el servicio del departamento. 1

II. ANTECEDENTES

II.1. Marco terico.

II.1.1. Procesos de Negocio.

Un proceso de negocio es un conjunto estructurado de actividades que tomando una o varias clases de entradas, crean una o varias salidas que tienen valor para un cliente. Los procesos describen cmo se ejecuta el trabajo dentro de la organizacin y se caracterizan por ser observables, medibles, mejorables y repetitivos. Estructuralmente, un proceso de negocio est constituido por un conjunto de actividades que es ejecutado colaborativamente por un grupo de trabajadores de distintas especialidades. As, la actividad, como elemento bsico, mediante relaciones o dependencias con otras actividades conforma la estructura de un proceso de negocio.

Los procesos de negocios representan el flujo de trabajo y de informacin a travs del negocio.

Figura II.1.- Proceso de Negocio.

Los procesos de negocio son una secuencia lgica y cronolgica de las acciones

que se deben realizar, cada vez que se produce el suceso que lo origina en una organizacin de cualquier tipo. Este proceso se debe ejecutar en forma eficaz y eficiente. Para realizar estos trabajos, las empresas identifican cargos, los cuales son ocupados y desarrollados por personas. Los cargos se estructuran por funcionalidad y por jerarqua, formando una estructura organizacional.

Es importante resaltar que cada actividad que forma parte de un proceso de negocio, implica ocupar tiempo, incurrir en un costo y entregar un producto o servicio de calidad. Una actividad implcita el concepto sistmico, que consiste en una entrada, un proceso y una salida, que a la vez est relacionada con otra u otras con las cuales interacta, formando as un conjunto de partes interrelacionadas.

La actividad significa un trabajo que se debe realizar segn la organizacin de los recursos disponibles y las normas o reglas definidas para dicho trabajo, cuando se recibe una entrada (Input) para generar una salida (output). La entrada proviene de una accin que la precede y la salida se entrega a la accin que prosigue a aquella que ya realiz el trabajo. En trminos fsicos la actividad es una unidad de trabajo, tambin llamada estacin de trabajo.

En la figura siguiente se presenta esta interaccin.

Figura II.2.- Interaccin entre una Actividad y su entorno.


1

http://dbf.cl/Material Docente/Libro/CapituloLosprocesosdenegocio.pdf

Al analizar un proceso, se estudian todas las actividades que lo conforman y el flujo operacional del mismo. De ese modo se comprende y se pueden introducir mejoras, si fuere el caso. El anlisis consiste en estudiar la secuencia de un objeto que requiere ser tratado, en los aspectos siguientes:

Input: De que unidad proviene. Frecuencia con que se recibe. Espacio que debe recorrer el objeto, entre una estacin de trabajo y otra. Tiempo del transporte.

Proceso (actividad / accin): Calidad de la recepcin. Acciones de transformacin o logsticas sobre el input, formando el output del proceso (si corresponde). Acciones de control o gestin (procesos o trabajos) que se realizan en la actividad, sobre el objeto, como son: hacer clculos, acceder algn otro documento, clasificar, ordenar, analizar, almacenar, registrar, comunicarse, decidir, llenar un formulario y/o generar un informe del evento que se est realizando. Que output se genera.

Output: A quien se le entrega el resultado de la actividad. Frecuencia de entrega. Espacio a recorrer y tiempo del trayecto del objeto, entre una estacin de trabajo y otra. Expectativas sobre el servicio que espera el receptor del output. 4

Administracin de procesos de negocio (Bussiness Process Management).

Administracin de procesos de negocio es un conjunto de mtodos, herramientas y tecnologas utilizados para disear, representar, analizar y controlar procesos de negocio operacionales. BPM es un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologas de la informacin con metodologas de proceso y es una colaboracin entre personas de negocio y tecnlogos para fomentar procesos de negocio efectivos, giles y transparentes.
2

La administracin de procesos de negocio abarca personas, sistemas, funciones,

negocios, clientes, proveedores y socios. Combina mtodos ya probados y establecidos de gestin de procesos con una nueva clase de herramientas de software empresarial.

Modelar un proceso de negocio.

Modelar el proceso de negocio es una parte esencial de cualquier proceso de desarrollo de software. Permite al analista capturar el esquema general y los procedimientos que gobiernan el negocio. Este modelo provee una descripcin de dnde se va a ajustar el sistema de software considerado dentro de la estructura organizacional y de las actividades habituales. Tambin provee la justificacin para la construccin del sistema de software.

Un modelo preliminar del negocio, permite al analista capturar los eventos, las entradas, los recursos y las salidas ms importantes vinculadas con el proceso de negocio. Es posible construir un modelo completamente trazable mediante la posterior conexin de elementos de diseo (tales como los casos de uso) al modelo de negocio a travs de conectores de implementacin, desde la generalidad del proceso de negocio a los requisitos funcionales y eventualmente a los artefactos de software que se construirn realmente.
2

http://www.konradlorenz.edu.co/images/publicaciones/suma_digital_sistemas/bpm.pdf

II.1.2. Bizaggi

Bizagi es la solucin lder BPM que permite disear, modelar, integrar, automatizar y

monitorear los procesos de negocio por medio de un ambiente grfico sin necesidad de programar.

Bizagi BPM trata sobre la generacin automtica de una aplicacin web, la cual est basada y activada mediante un diagrama de proceso sin que se requiera alguna programacin. La Suite Bizagi BPM maneja el ciclo completo de vida de un proceso de negocio: Modelar, Automatizar, Ejecutar, y Mejorar. Cada una de estas fases est manejada por componentes diferentes, que permiten, mediante el uso de un ambiente grfico y dinmico, la construccin de una solucin basada en procesos. La siguiente figura explica los pasos para construir una solucin en Bizagi.

Figura II.3.- pasos para construir una solucin en Bizagi.

Modelar.

La Suite Bizagi BPM tiene el Modelador de Procesos Bizagi es una

aplicacin que permite diagramar y documentar los procesos de una forma gil y simple. ste a su vez, presenta los procesos de negocio usando un estndar aceptado mundialmente, el cual es ms comnmente conocido como BPMN (Business Process Modeling Notation).
3

http://wiki.bizagi.com/es/index.php?title=Main_Page

Automatizar. Es convertir todas las actividades de proceso en una aplicacin tecnolgica. Bizagi Studio es la herramienta usada para automatizar los procesos que fueron definidos en el Modelador de Procesos Bizagi sin que se requiera algo de programacin. Bizagi ofrece un conjunto de herramientas que genera un modelo asociado a un proceso de negocio (diagrama de flujo, reglas de negocio, interfaz de usuario, entre otros.). Este modelo es almacenado en una base de datos, y es interpretado y ejecutado en produccin a travs de una aplicacin web mediante el servidor BPM de Bizagi sin la necesidad de cdigo.

Ejecutar. El servidor de Bizagi BPM es el motor que ejecuta y controla los procesos de negocio construidos en Bizagi Studio, basado en una coleccin de componentes que ofrecen todas las funcionalidades necesarias para una administracin efectiva de procesos de negocio en la organizacin. El servidor BPM de Bizagi, vela por la exactitud y la adecuacin de la ejecucin en las distintas tareas y actividades que intervienen en el proceso de negocio; mediante el control y la verificacin de tareas terminadas en el momento correcto, por la persona o recurso correcto, y de acuerdo a los lineamientos, objetivos y otras reglas fundamentales de la organizacin.

Mejorar. El Servidor BPM de Bizagi tiene un conjunto completo de reportes de rendimiento e indicadores sobre los procesos que le permitirn analizar su negocio, identificar cuellos de botella y sus causas, e identificar oportunidades de mejora en sus procesos. Las mejoras pueden ser hechas tambin, usando Bizagi Studio para generar una nueva versin del proceso sin que se requiera algo de programacin y la aplicacin web muestra los cambios automticamente

Aplicaciones y uso de Bizaggi

Bizaggi sigue un modelo de "no cdigo" que permite crear aplicaciones basadas en procesos, coordinando gente y sistemas sin la necesidad de programacin. Bizaggi puede ser utilizado para diagramar y automatizar cualquier tipo de proceso, desde el ms simple hasta el ms complejo. 7

Business Process Model and Notation (BPMN)


4

Business Process Model and Notation (BPMN) es una notacin grfica que describe

la lgica de los pasos de un proceso de Negocio. Esta notacin ha sido especialmente diseada para coordinar la secuencia de los procesos y los mensajes que fluyen entre los participantes de las diferentes actividades.

BPMN proporciona un lenguaje comn para que las partes involucradas puedan comunicar los procesos de forma clara, completa y eficiente

BPD es un diagrama diseado para representar grficamente la secuencia de todas las actividades que ocurren durante un proceso, basado en la tcnica de Flow Chart, incluye adems toda la informacin que se considera necesaria para el anlisis.

BPD es un diagrama diseado para ser usado por los analistas, quienes disean, controlan y gestionan procesos. Dentro de un Diagrama de Procesos de Negocio (BPD) se utiliza un conjunto de elementos grficos, agrupados en categoras, que permite el fcil desarrollo de diagramas simples y de fcil comprensin, pero que a su vez manejan la complejidad inherente a los procesos de negocio.

Elementos de BPMN clasificados en 4 categoras:

Objetos de flujo. Son los principales elementos grficos que definen el comportamiento de los procesos. Dentro de los objetos de flujo encontramos: Eventos: Sucede durante el curso de un proceso de negocio, afectan el flujo del proceso y usualmente tienen una causa y un resultado. Los eventos se encuentran clasificados en 3 tipos.

http://www.bizagi.com/esp/descargas/BPMNbyExample.pdf

Eventos de inicio. Eventos intermedios Eventos de fin.

Dentro de BPMN existen muchas formas de iniciar o finalizar un proceso e igualmente existen muchas cosas que pueden llega a suceder durante el transcurso del proceso, por lo tanto existen diferentes tipos de eventos de inicio, eventos de fin y eventos intermedios. Actividades: Estas representan el trabajo que es ejecutado dentro de un proceso de negocio. Las actividades pueden ser compuestas. Los tipos de actividades existentes son:

Tareas.

Subprocesos.

Tambin existen diferentes tipos de tareas (Simple, automticas, manuales, de usuario, entre otras) y de subprocesos (embebido, reusable, entre otros.) que nos permiten diagramar con ms profundidad los procesos suministrando ms informacin y claridad al lector. Compuertas: Son elementos del modelado que se utilizan para controlar la divergencia y la convergencia del flujo.

Existen 5 tipos de compuertas:

Compuerta Exclusiva. Compuerta Basada en eventos. 9

Compuerta Paralela. Compuerta Inclusiva. Compuerta Compleja.

Objetos de Conexin. Son los elementos usados para conectar dos objetos del flujo dentro de un proceso. Las lneas de secuencia conectan los objetos de flujo, y las asociaciones, que son las lneas punteadas que nos permiten asociar anotaciones dentro de algunos flujos.

Existen 3 tipos de objetos de conexin:

Lneas de Secuencia. Asociaciones. Lneas de Mensaje.

Canales. Son elementos utilizados para organizar las actividades del flujo en diferentes categoras visuales que representan reas funcionales, roles o responsabilidades.

Pools. Acta como contenedor de un proceso. El nombre del pool puede ser el del proceso o el del participante.

Lanes. Es una subdivisin del Pool y representa los diferentes participantes al interior de una organizacin

Artefactos: Los artefactos son usados para proveer informacin adicional sobre el proceso. 10

Existen 3 tipos:

Objetos de Datos. Grupos. Anotaciones.

II.1.3. Flujos de trabajo (workflows)

Flujo de trabajo es un conjunto de mtodos y tecnologas que nos ofrece las facilidades de modelar y gestionar los diversos procesos que ocurren dentro de la empresa. Las cuales apuntan a poder reaccionar tan rpido como sea posible.

El flujo de trabajo controlado y coordinado activamente por el sistema de workflow. El control incluye el monitoreo de pasos de trabajo individuales y el inicio de procesos para escalar las tareas que lleguen a su fecha de vencimiento.

El sistema de workflow cubre todos los aspectos del proceso.

Figura II.4.- Sistema de Workflow.

11

El flujo de trabajo se origina debido a que no somos eficientes en actividades como: buscar un documento entre cientos, tener presentes los vencimientos de las tareas que se tiene que realizar dentro de ciertos plazos.

Flujo de trabajo ha pasado por varias etapas, al principio lo hacan de manera manual donde se le haca difcil determinar el estado de las tareas y el hecho de determinar el proceso a seguir. Se manejaban grandes cantidades de documentos en forma manual. Generando la necesidad de un mayor control y coordinacin de la informacin. Esto se solucion con la creacin de los sistemas de informacin donde se poda manejar y administrar toda la informacin. Pero se necesitaba an mejor el flujo de la informacin, incrementar la eficiencia, optimizar la productividad, acortar los tiempos de procesos, tener un mejor control sobre estos, reducir los costos y mejorar la gestin.

Tipos de Workflow.

Los workflow estn basados en el tipo de procesos que soportan. Se puede categorizar de acuerdo a la ocurrencia del proceso en: muy repetitivos o de una sola ejecucin. Como se observa en la siguiente figura.

Figura II.5.- Tipos de Workflow

12

Workflow de Produccin. Automatiza los procesos repetitivos del negocio, y es necesario un manejo de datos estructurados. Necesita altas prestaciones para tener alto grado de informacin, y bajos tiempos de respuestas para responder a la gran cantidad de peticiones en los procesos. Se maneja como un flujo diverso de transacciones que trabajan sobre el ncleo del negocio.

Workflow de Colaboracin. Este tiene mucho que ver con la participacin de la gente para lograr una meta en comn. Estos tipos de workflow estructuran o semiestructuran business process donde participa la gente. Involucra tambin el uso de documentos los cuales son los contenedores de la informacin que siguen la ruta de esto paso a paso adems de las acciones que se toman sobre ellos. Mantener la integridad de los documentos es clave.

Workflow Administrativo. Maneja proceso administrativos de soporte muy repetitivo y estandarizado, tales como reportes de compra, de venta, pedidos y entre otros. Y se utiliza cuando existen diversos usuarios para la distribucin de la informacin.

Workflow Ad Hoc. Cuando tratan proceso ms administrativos como revisiones y aprobaciones.

II.1.4. ProcessMaker

ProcessMaker es una herramienta de negocio en software libre que permite a las

organizaciones pblicas y privadas para automatizar el documento intensivo, basado en los procesos de aprobacin a travs de sistemas tales como finanzas, recursos humanos y operaciones. Una aplicacin basada en web, permite a los usuarios a travs de mltiples sitios para crear y compartir workflows, personalizar formularios, manejar procesos, y mejorar la presentacin de informes.
5

http://www.ecuaportales.com/mado/index.php/software-de-aplicacion/colaborativas/104-process-maker

13

ProcessMaker incluye herramientas para disear formularios, crear documentos, asignar roles y usuarios, crear reglas de enrutamiento, la interconexin con sistemas de terceros, incluida la inteligencia empresarial (BI), gestin de documentos (DMS), gestin de contenidos (CMS) y la planificacin de recursos empresariales (ERP) sistemas a travs de una arquitectura orientada a servicios (SOA), y para asignar un proceso individual de forma rpida y fcilmente.

A pesar de que funciona en forma semejante a un workflow, ProcessMaker contiene una funcionalidad ms avanzada. ProcessMaker permite al usuario crear, modificar, e integrar aplicaciones directamente desde un Web-Browser. Con ProcessMaker los usuarios pueden crear aplicaciones que llenan y complementan funcionalidades faltantes en sistemas CRM, ERP, entre otros. Adems, ProcessMaker se integra sin dificultad a otros productos mediante una interfaz de Web Services. ProcessMaker se presenta a los usuarios en una forma unificada, a pesar de que se estn usando diferentes sistemas internamente. Los usuarios pueden usar inmediatamente plantillas (templates) prediseadas de muchos procesos generales, o los pueden crear desde cero, segn las necesidades de la empresa.

Caractersticas de Process Maker: ProcessMaker facilita la optimizacin de flujos de trabajo y las operaciones de negocio. Creacin mapas de flujos de trabajo, o se pueden elegir de una plantilla. Diseo formularios personalizados para los procesos de tu organizacin. Llenado de informacin de otros formularios, de bases de datos, y fuentes externas a travs de web-services. Seguimiento del progreso de casos para identificar demoras y

embotellamientos. Anlisis de resultados para aumentar eficiencia y eficacia.

14

ProcessMaker es ligero, extremadamente eficiente, e implica los gastos generales

ms bajos de cualquier BPM en la industria. Los clientes empresariales de ProcessMaker disfrutan de un pleno apoyo, la suite BPM es de calidad superior con los beneficios aadidos de cdigo abierto. Tenemos clientes en los 5 continentes, en 15 idiomas diferentes y de una variedad de industrias, incluyendo finanzas, telecomunicaciones, y gubernamentales que usan el software ProcessMaker para sus flujos de trabajo.

Figura II.6.- Modelo en que ayudan los Process Maker.

Figura II.7.- Ejemplo de Inicio de sesin utilizando los Process Maker.


6

http://www.efectra.net/efectraweb/index.php/es/productos/bpm-processmaker

15

II.1.5. Frameworks

Framework es una abstraccin de un componente de software para resolver un problema en un contexto, es construida por la experiencia del desarrollador. No confundir con un patrn que es para resolver un problema en cualquier contexto. En general los Framework son soluciones completas que contemplan herramientas de apoyo a la construccin (ambiente de trabajo o desarrollo) y motores de ejecucin (ambiente de ejecucin).

Frameworks de Java en el mbito especifico de aplicaciones Web tenemos a: Struts, Java Server Faces, o Spring. Estos frameworks de Java en la prctica son conjuntos de libreras (APIs) para desarrollar aplicaciones Web, ms libreras para su ejecucin (o motor), y ms un conjunto de herramientas para facilitar esta tarea (debuggers, ambientes de desarrollo como Eclipse, entre otros).

Otros ejemplos de frameworks para mbitos especficos: mbito: Web services => Framework: Axis. mbito: Interfaz de Usuario Web Dinmica => FrameWork: Ajax DWR mbito: Procesos de Negocio => BPMS (WebSphere, AquaLogic, o Oracle).

Existen frameworks para desarrollar juegos, aplicaciones mdicas, aplicaciones empresariales, aplicaciones de escritorio, dispositivos mviles, entre otros. Aplicacin genrica que interacta con nuestro desarrollo y que a la vez es configurable.

Objetivos de usar frameworks. Acelerar el proceso de desarrollo. Reutilizar cdigo ya existente. Promover buenas prcticas de desarrollo como el uso de patrones. 16

II.1.6. Spring Roo.

Spring Roo es una herramienta RAD (Rapid Application Development) extensible para Java basada en Spring Framework. Bsicamente es un generador de cdigo avanzado, que se utiliza desde la lnea de comandos invocando sentencias. La idea de Spring Roo es incrementar la productividad del desarrollador Java sin comprometer la integridad estructural o la flexibilidad de la solucin. No contiene un componente Runtime. Esto es muy importante, no solo porque no ata la solucin al Framework, sino porque no genera overhead. Se puede eliminar fcilmente.

Est construido con una serie de plugins (al estilo de Maven). Fue diseado pensando en la usabilidad. Los comandos son contextuales; tiene los comandos "hint" y "help" para consultar el uso rpidamente y la tecla TAB para autocompletar. Est basado en scripts, por lo que en caso que se cometer un error, se puede hacer rollback. Todos los comandos escritos se van guardando automticamente (log.roo).

Caractersticas Spring Roo.

Permite desarrollar una aplicacin Web en minutos, generando un archivo war. Construye dos capas: la de persistencia y la de presentacin. Para agregar la capa de negocio, se pueden agregar las clases manualmente a los controladores generados con Roo. Permite generar un modelo de datos complejo, incluyendo validaciones. Tiene soporte de seguridad out-of-the-box.

Generacin de cdigo

Es un generador de cdigo hibrido, utilizando generacin activa y pasiva. Utiliza generacin pasiva para generacin de archivos java y XML. Utiliza generacin activa para la meta data con la ayuda de los tags @Roo* y modifica gradualmente .aj y los jsp. 17

Sincroniza los cambios entre Roo y las modificaciones realizadas al cdigo (roundtrip). Spring Roo no interviene en runtime, solo lo hace en tiempo de desarrollo. Una vez creado el proyecto con Spring Roo, podra eliminarse y seguir trabajando con un IDE.

Figura II.8.- Aplicacin web con Spring.

II.1.7. ZK Framework

ZK es un FrameWork de cdigo abierto para desarrollo de pginas web. ZK se cre gracias a una comunidad de desarrolladores que se han propuesto que la implementacin de interfaces de usuario (GUI) en Ajax sea mucho ms fcil y cmoda de implementar y de desarrollar. Su implementacin est basada en lenguaje Java, pero se puede conectar con cualquier backend escrito en cualquier otro lenguaje.

18

ZK permite desarrollar aplicaciones web AJAX similar a como se desarrollaba en las aplicaciones de escritorio (como ser, con Swing en Java). El ncleo de ZK es un mecanismo conducido por eventos basado en AJAX, sustentado sobre 70 componentes XUL y 80 componentes XHTML, y un lenguaje de marcacin para disear interfaces de usuario. Los programadores disean las pginas de su aplicacin en componentes XUL/XHTML ricos en caractersticas, y los manipulan con eventos disparados por la actividad del usuario final. Es similar al modelo de programacin encontrado en las aplicaciones basadas en GUI de escritorio.

ZK utiliza el acercamiento llamado centrado en el servidor para la sincronizacin de componentes y el pipelining entre clientes y servidores se haga automticamente por el motor, y los cdigos de Ajax sean completamente transparentes para los desarrolladores de aplicaciones web. Por lo tanto, los usuarios finales obtienen una interaccin y respuesta similar a las de una aplicacin de escritorio, mientras que la complejidad del desarrollo es similar a la que tendra la codificacin de aplicaciones de escritorio.

Adems de la programacin basada en componentes y orientacin a eventos, de manera similar a Swing, ZK soporta un lenguaje de marcacin para la definicin de una potente interfaz de usuario llamada ZUML.

Figura II.9.- Aplicacin web con Framework ZK.

19

II.1.8. JSTL

Java Server Pages Standard Tag library (JSTL) es un conjunto de libreras de

etiquetas simples y estndares que encapsulan funcionalidad habitualmente utilizada en aplicaciones Web. Soportan funciones como iteraciones, procesamiento condicional, procesamiento XML, internacionalizacin, etc. Su uso est extendido debido sobre todo a que se integran en las pginas JSP de forma sencilla y limpia, adems de proporcionar la mayora de funcionalidades necesarias en un JSP.

La librera JSTL (JSP Standard Tag Library) es un componente dentro de la especificacin del Java 2 Enterprise Edition (J2EE) y es controlada por Sun MicroSystems. JSTL no es ms que un conjunto de libreras de etiquetas simples y estndares que encapsulan la funcionalidad principal que es usada comnmente para escribir pginas JSP.

Las etiquetas JSTL estn organizadas en 4 libreras: CORE: Comprende las funciones script bsicas como loops, condicionales, y E/S. Estos Tags como su nombre lo implica (core), conforman las funcionalidades bsicas de JSTL, entre las que se encuentran: ciclos, definicin de variables, condicionales y otras funcionalidades. XML: Estos Tags son empleados para la manipulacin de XML dentro de JSPs. FML: Este tipo de Tags son empleados para dar formato especifico a elementos dentro de JSPs, estos formatos incluyen aquellos para fechas, monedas y nmeros. SQL: Tags empleado para interactuar con base de datos dentro de JSPs . Basado en los principios de MVC, el uso de estos Tags en JSPs resulta en

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

20

una psima decisin de diseo, ya que estara mezclando el Modelo (base de datos) con la Vista de presentacin JSPs.

La librera JSTL es distribuida como un conjunto de archivos JAR que simplemente tenemos que agregarlo en el classpath del contenedor de servlets.

Ventajas e inconvenientes del uso de JSTL frente a scriptlets

La especificacin JSP ahora se ha convertido en una tecnologa estndar para la creacin de sitios Web dinmicos en Java, y el problema es que han aparecido algunas debilidades: Aunque es ms potente que las etiquetas JSTL, el cdigo Java embebido en scriptlets es desordenado. Un programador que no conoce Java no puede modificar el cdigo Java embebido, anulando uno de los mayores beneficios de los JSP. Permitir a los programadores que escriben la lgica de presentacin que actualicen el contenido de la pgina. El cdigo de Java dentro de scriptlets JSP no pueden ser reutilizados por otros JSP, por lo tanto la lgica comn termina siendo re-implementado en mltiples pginas. La recuperacin de objetos fuera del HTTP Request y Session es complicada. Es necesario hacer el Casting de objetos y esto ocasiona que tengamos que importar ms Clases en los JSP.

Los JSTL pueden agregar mayor sobrecarga en el servidor. Los scriptlets y las libreras de etiquetas son compilados a servlets, los cuales luego son ejecutados por el contenedor. El cdigo Java embebido en los scriptlets es bsicamente copiado en el servlet resultante. En cambio, las etiquetas JSTL, causan un poco ms de cdigo en el servlet. En la mayora de casos esta cantidad no es mensurable pero debe ser considerado. 21

Figura comparativa de cdigo JSP y JSTL

Figura II.10.- Cdigo comparativo de JSP y JSTL.

22

II.1.9. JPA (Java Persistence API)

El Java Persistence API (JPA) es un framework de Java EE que permite gestionar la informacin almacenada en sistemas gestores de bases de datos relacionales desde Java, de una forma sencilla. Para ello, posee tres elementos de programacin: El conjunto de clases de acceso a los datos (API), sustituyendo a JDBC. JPQL (Java Persistence Query Language): un lenguaje propio de creacin de consultas muy similar a SQL. Se crean las consultas preparadas (similar a las Prepared Statement) asociadas a cada entidad mediante anotaciones del tipo. La transicin transparente para el programador del modelo relacional al modelo orientado a objetos. Los APIs permiten mapear una clase Java (Bean) con una tabla de la base de datos y facilitan mucho el trabajar con la persistencia de los objetos (usando mtodos del estilo a select, insert, update y delete).

JPA se puede escribir el cdigo de la clase, aunque no exista la tabla correspondiente en la base de datos. JPA se encargara de crear la tabla del modelo de datos, es decir, solo se escribe el cdigo y JPA con su mecanismo de persistencia ya se encargara de crear las tablas, si no existen y si existen pues las usa.

JPA est compuesta por 6 partes:

1. Requerimientos para los objetos del modelo de dominio. 2. Metadatos. 3. API. 4. Consultas. 5. Modelo del ciclo de vida. 6. Callbacks. 23

APIs. Se basan en las interfaces definidas en el paquete javax.persistence Interfaces clave: EntityManager Query

En un contexto EJB (Application Server), el EntityManager es: Inyectado dentro de los EJB. Integrado con el contexto transaccional activo.

Figura II.11.- Arquitectura Hibernate.

24

II.1.10. Glassfish

Glassfish es un servidor de aplicaciones de software libre desarrollado por Sun Microsystems, compaa adquirida por Oracle Corporation, que implementa las tecnologas definidas en la plataforma Java EE y permite ejecutar aplicaciones que siguen esta especificacin. La versin comercial es denominada Oracle Glassfish Enterprise Server (antes Sun Glassfish Enterprise Server) . Es gratuito y de cdigo libre, se distribuye bajo un licenciamiento dual a travs de la licencia CDDL y la GNU GPL.

Glassfish est basado en el cdigo fuente donado por Sun y Oracle Corporation, ste ltimo proporcion el mdulo de persistencia TopLink. Glassfish tiene como base al servidor Sun Java System Application Server de Oracle Corporation, un derivado de Apache Tomcat, y que usa un componente adicional llamado Grizzly que usa Java NIO para escalabilidad y velocidad.

Distribuciones y contribuyentes de Glassfish

Figura II.12.- Distribuciones y contribuyentes de Glassfish.

25

FrameWork y aplicaciones relacionada a Glassfish

Figura II.13.- FrameWorks y aplicaciones relacionadas a Glassfish.

II.1.11. Sistema de control de versiones (Subversin)

Un sistema de control de versiones es un software que administra el acceso a un

conjunto de ficheros, y mantiene un historial de cambios realizados. El control de versiones es til para guardar cualquier documento que cambie con frecuencia, como una novela, o el cdigo fuente de un programa.

Subversin puede acceder al repositorio a travs de redes, lo que le permite ser usado por personas que se encuentran en distintas computadoras. A cierto nivel, la posibilidad de que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboracin. Se puede progresar ms rpidamente sin un nico conducto por el cual deban pasar todas las modificaciones.
8

http://recursostic.educacion.es/observatorio/web/es/software/software-general/548-luis-garcia

26

Existen multitud de sistemas de control de versiones, el ms popular es CVS (Concurrent Versions System). CVS tuvo el merito de ser el primer sistema usado por el movimiento de cdigo abierto para que los programadores colaboraran remotamente mediante el envo de parches.

Esto es lo que aporta un sistema de control de versiones a un equipo: Actualiza ficheros modificados. El cliente recorre nuestro cdigo y sincroniza nuestra copia local con el repositorio. Copias de seguridad centralizadas. Solo el administrador debe preocuparse de realizar copias de seguridad en el repositorio. Esto se automatiza fcilmente con una tarea cron o similares. Historial de cambios. El repositorio guarda registro de todos los cambios realizados. Es posible recuperar cualquiera de las versiones anteriores de cualquier fichero. Si alguien borra todos los ficheros, podemos volver atrs y recuperar su contenido. Acceso remoto. Es posible acceder remotamente al repositorio. No es necesario que el equipo este dentro de la misma LAN. Seguridad. Es posible otorgar diferentes permisos sobre diferentes ramas del proyecto. Por ejemplo, estableciendo permiso universal de lectura, y permiso de escritura solo a ciertos usuarios.

Desarrollar un proyecto de software implica invertir mucho tiempo y dinero. No proteger nuestra inversin con un sistema de control de versiones es irresponsable y denota un grave desconocimiento del desarrollo de software.

Figura II.14.- Sistema de Control de Versiones.

27

II.1.12. Metodologa Scrum

SCRUM es una forma de gestionar proyectos de software. No es una metodologa de anlisis, ni de diseo, como podra ser RUP, es una metodologa de gestin del trabajo. Existen numerosas propuestas metodolgicas que inciden en distintas dimensiones del proceso, las metodologas tradicionales se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos (documentacin, programas, entre otros) que se deben producir, y las herramientas que se usarn.

En contraposicin estn las metodologas giles que se centran especialmente en el factor humano o el producto de software, es decir, dan mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque est mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad.

Scrum es una de las ms famosas metodologas agiles y se basa en un proceso iterativo e incremental. El esqueleto de Scrum se muestra en la siguiente figura.

Figura II.15.- Proceso de Scrum.

28

El crculo inferior representa una iteracin del desarrollo de las actividades que ocurren una tras otra. El producto de cada iteracin es un incremento en el producto. El crculo superior representa la reunin diaria que ocurre durante la iteracin, en la cual los miembros individualmente del grupo conocen, inspeccionan las actividades y hacen los cambios apropiados. Como resultado de la iteracin queda una lista de requerimientos. Este ciclo se repite durante todo el proyecto.

Este esqueleto opera de esta manera:

1. Al comienzo de la iteracin, el equipo revisa qu es lo que debe hacer. 2. Luego, selecciona lo que cree que puede hacer para tener un incremento y un potencial prototipo funcional al trmino de la iteracin. 3. El equipo se separa y hace su mejor esfuerzo por el resto de la iteracin. Cuando sta termina, el equipo presenta el incremento de la funcionalidad que construy, de manera que los otros miembros del equipo puedan revisar las funcionalidades y hacer las modificaciones oportunamente al proyecto.

SCRUM es una metodologa propuesta por los japoneses Hirotaka Takeuchi e Ikujijo Nonaka, un modo de desarrollo de carcter adaptable y orientado a las personas antes que a los procesos, que controla de forma emprica y adaptable la evolucin del proyecto con las siguientes prcticas de la gestin gil: Revisin de las iteraciones. Desarrollo incremental, en el proyecto no se trabaja con diseo o abstracciones. Desarrollo evolutivo, intenta predecir en las fases inciales cmo ser el resultado final y sobre dicha prediccin realizar el diseo, la estructura del producto no es realista, porque las circunstancias obligaran a remodelarlo muchas veces. Auto-organizacin, los equipos son auto-organizados, con margen de decisin suficiente para tomar las decisiones que consideren oportunas. 29

Y colaboracin entre todos segn su conocimiento y no segn su rol o puesto.

El resultado final en esta metodologa se consigue de forma iterativa e incremental. Al comienzo de cada iteracin (sprint) se determina qu partes se van a construir, tomando como criterios la prioridad para el negocio, y la cantidad de trabajo que se podr abordar durante la iteracin. Dichas iteraciones se presentan en las etapas de Especulacin, Exploracin y Revisin; y debido a que, segn este tipo de modelos de desarrollo nunca se termina un producto, se presentan de forma infinita pudiendo llegar a la etapa de cierre solo cuando se desee enviar al mercado una versin funcional del producto.

Reglas bsicas.

SCRUM tiene un conjunto de reglas muy pequeo y muy simple y est basado en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin. El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto iteracin a iteracin y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa.

Por otro lado, los desarrolladores encuentran un mbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivacin de los integrantes del equipo.

Elementos bsicos de SCRUM: Una lista con las funcionalidades de la aplicacin ordenadas de mayor a menor importancia. Esta lista se llama "Product Backlog". No hace falta que esta lista contenga todas las funcionalidades inicialmente. De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y son anotadas en una lista que se llama "Sprint Backlog". Estas tareas sern realizadas en el siguiente mes. 30

Adems de estos elementos tenemos unas cuantas reglas bsicas y sencillas que tenemos que cumplir: Una vez que se pasan las tareas ms prioritarias del "Product Backlog" al "Sprint Backlog", estas no se pueden cambiar, esto quiere decir, que el trabajo de un mes queda fijado. Esta es la regla ms importante de todas. Al final del mes, periodo denominado "Sprint", se tiene que tener un ejecutable con las funcionalidades del "Sprint Backlog". Todo el equipo puede aadir funcionalidades al "Product Backlog", pero slo una persona puede ordenarlo. A esta persona se le denomina "Product Owner". Es el responsable del producto final. Cada da se hace una reunin de menos de 15 minutos, en la que se rene todo el equipo: ingenieros y gestor (llamado "SCRUM Master") en la que cada miembro del equipo expone slo los siguientes temas: Qu es lo que se hizo el da anterior? Qu es lo que se va a hacer hoy? Qu impedimentos tengo para realizar mi trabajo?

Slo se tratan estos temas para que la reunin sea rpida y no malgastar el tiempo de los dems. Si se tiene que tratar otro tema se hace otra reunin slo con las personas implicadas Al final del mes, es decir, al final del Sprint, se presenta el producto y se toman del "Product Backlog" las funcionalidades para cubrir en el siguiente mes.

La calidad en este caso, se logra y se mantiene de forma continua, pues se involucra al cliente durante todo el tiempo que tarde el desarrollo, permitindole hacer aportes que enriquezcan y generen nuevas funcionalidades y/o caractersticas al producto que se est desarrollando.

31

SCRUM es sencillo, pero duro como una piedra, y se encuentra siempre mucha resistencia: Los jefes de proyecto no querrn comenzar los proyectos sin tenerlo todo perfectamente identificado, acotado y planificado. Los desarrolladores no querrn la responsabilidad de estimar las

funcionalidades y demostrar el producto. Los gerentes no querrn dejar tranquilo al equipo durante los Sprints. Entre otros.

Hay en torno a un 40% de empresas que no lo consiguen en absoluto y un 20% que solo consiguen un modelo hbrido de SCRUM, que les permite mejorar en su trabajo pero queda lejos del autntico poder de SCRUM desencadenado.

Proceso del SCRUM.

Figura II.16.- Proceso de la metodologa SCRUM.

32

II.2. Marco referencial.

II.2.1. Actividad econmica de la institucin.

La Universidad Tecnolgica de la Selva es una institucin de educacin Superior, orientada hacia el desarrollo acadmico, en donde los principales actores son docentes y estudiantes, se abordan los aspectos relacionados a los Planes y Programas de Estudio, la Programacin Cuatrimestral, el Desarrollo Acadmico referenciado al personal docente, la Capacidad Acadmica enfocada desde la visin de los Cuerpos Acadmicos y la Competitividad Acadmica como sustento de la prestacin de los servicios educativos de calidad a favor de los alumnos (Selva, U. T., 2006). La universidad Tecnolgica de la Selva fue creada el 19 de noviembre de 1997, mediante Decreto Gubernativo No-184-A-97, con el propsito de ser una alternativa viable de educacin superior, en la regin y en la entidad (Selva, U. T., 2006).

II.2.2. Bienes y/o servicios.

Los perfiles profesionales sesgados hacia la enseanza y hacia la formacin de conocimientos y habilidades, resultan insuficientes en un entorno social que ha sufrido transformaciones fundamentales y ante una sociedad que reclama mejores respuestas a su crecientes necesidades. La construccin de nuevos ambientes de aprendizajes y ampliacin de los perfiles de los profesionistas y de los posgraduados que forman las universidades, es una tarea que requiere replantearse e intensificarse, y en ella la vinculacin en general, y en especial la vinculacin con el sector productivo y de servicios de una nueva relevancia, pues debe reconocerse que no es la universidad la que determina cuales son los conocimientos importantes, 33

si no que se trata ms bien de conceptos sociales que son reformulados continuamente en respuesta a los cambios sociales y tecnolgicos. (Selva, U. T., 2006). La construccin de profesionales dentro del sector productivo es uno de los objetivos de esta casa de estudios que generalmente est aplicando modelos educativos como lo fue bajo las categoras del saber, saber hacer y el ser; con estricto apego a los atributos del modelo educativo que son: Polivalencia, mpetu, Flexibilidad, Pertinencia y Continuidad; ahora rige el modelo basado en competencias donde el modelo visualiza a los estudiantes en un contexto integral, a travs de un enfoque a resultados de competitividad y sustentabilidad, la mejora continua, innovacin, flexibilidad y agilidad y, la creacin de valor, como principios que de una organizacin que lo hacen nico, creando una gran brecha respecto a los modelos cotidianos (Selva, U. T., 2006). En la actualidad la Universidad Tecnolgica bajo la categora 5A CINE UNESCO imparte educacin de nivel superior de tipo tecnolgico, para formar tcnicos superiores universitarios, ingenieros tcnicos e ingenieros, de los distintos perfiles acadmicos (Selva, U. T., 2006). En el nivel de tcnico superior universitario, la UTSelva oferta las siguientes carreras: Agrobiotecnologa, Procesos Alimentarios, Sistemas Informticos, Redes y Telecomunicaciones, Multimedia y Comercio Electrnico, Recursos Humanos, Evaluacin de Proyectos, Hotelera y Turismo Alternativo (Selva, U. T., 2006). Adems la comunidad estudiantil que egresa como tcnico superior en tecnologas de la informacin puede cursar una licencia profesional en Seguridad en Redes y Software Libre, para obtener el ttulo de ingeniero tcnico (Selva, U. T., 2006). Ante la demanda estudiantil, la Universidad Tecnolgica de la Selva inici en el ao 2010 a ofrecer carreras de nivel licenciatura, actualmente preside las siguientes; Ingeniera en Tecnologas de la Informacin, Ingeniera en Innovacin y Desarrollo 34

Empresarial, Ingeniera en Biotecnologa, Ingeniera en Procesos Bioalimentarios, Ingeniera en Proyectos Productivos Sostenibles, Ingeniera en Desarrollo Turstico (Selva, U. T., 2006).

II.2.3. Ubicacin Geogrfica de la empresa (nivel estatal y municipal).

II.2.3.1. Nivel Estatal.

Chiapas es uno de los 31 estados que, junto con el Distrito Federal, conforman las 32 entidades federativas de Mxico. Localizado en el sureste de Mxico, se convirti en el 19 estado de Mxico el 14 de septiembre de 1824. Este se localiza desde la costa del pacifico hasta sus agrestes y escarpadas sierras, pasando imponentes caones, insondables selvas, volcanes, planicies y sembrados.

Figura II.17.- Ubicacin de la institucin a nivel Estatal.

35

Abarca un territorio de 73,724 kilmetros cuadrados de superficie, la entidad se ubica airosa en la base del sureste de nuestra Repblica, limitando al norte con el Estado de Tabasco, al este con la Repblica de Guatemala, al sur con el Ocano Pacfico y al oeste con los Estados de Oaxaca y Veracruz.

II.2.3.2. Nivel Municipal.

La Universidad Tecnolgica de la Selva se encuentra ubicada en el Entronque Tonina Km. 0.5 de la Ciudad de Ocosingo, Chiapas. El municipio de Ocosingo es el ms extenso del estado y actualmente el nmero 27 entre los municipios de mayor superficie en el pas, con una extensin actual de 9,138.48 Km2, despus de que en 1990 le fueron derivados 163.08 Km2 de la superficie del actual municipio de San Juan Cancuc y posteriormente, en el proceso de re municipalizacin efectuado en 1999, las de Benemrito de las Amricas y Marqus de Comillas, que en total suman 1,553.6 Km2.

Figura II.18.- Ubicacin de la institucin a nivel Estatal.

36

Ocosingo colinda al norte con el municipio de Chiln y Palenque, al este y sur con la repblica de Guatemala; al suroeste con el de Altamirano y Las Margaritas y al oeste con los de Sital, San Juan Cancuc y Oxchuc.

II.2.4. Giro y tamao de la Institucin.

La Universidad Tecnolgica de la Selva en el que a travs de la administracin de sus recursos, del capital y del trabajo, se producen bienes y/o servicios educativos tendientes a la satisfaccin de las necesidades de la comunidad estudiantil. De acuerdo a la prestacin que brinda esta casa de estudios indican que su giro pertenece a Servicios de Educacin Pblica Descentralizado, donde el capital

pertenece al Estado y generalmente su finalidad es satisfacer las necesidades de carcter social, en la cual se desarrollan actividades que compiten al Estado y que son de inters social, pero que est dotando personalidad y patrimonio (Selva, U. T., 2006). La Universidad Tecnolgica de la Selva ha crecido enormemente durante los ltimos aos, aumentando el nmeros de empleados a 200 aproximadamente que laboran en esta institucin y ascendi el nmero de estudiantes a 2,500 aproximadamente (Selva, U. T., 2006). La UTSelva es una institucin que oferta servicios educativos de calidad, al estar evaluada, acreditada y certificada bajo la norma ISO 9001-2000, la cual especifica los requisitos para un sistema de gestin de la calidad en una organizacin (Estandarizacin, O. I., s.f.) (Selva, U. T., 2006). En la actualidad la UTSelva imparte educacin de nivel superior de tipo tecnolgico para formar tcnicos superiores universitarios, ingenieros tcnicos e ingenieros 37

competentes y comprometidos con el desarrollo socioeconmico de la entidad (Selva, U. T., 2006). La estructura organizacional de la Universidad contempla los siguientes

departamentos para la administracin eficientemente de sus recursos: Administracin y Finanzas, Vinculacin, Planeacin y Evaluacin, Servicios Escolares, Servicios Bibliotecarios, Sistema de Gestin de la Calidad, y Servicios Generales y control patrimonial. Conjuntamente la gestin educativa se delega en cuatro divisiones: Divisin de Tecnologas de la Informacin, Carrera de Administracin rea Empresas Tursticas, Carrera de Administracin, Evaluacin de Proyectos y Divisin de Agroalimentos. Con un total aproximado de 200 colaboradores en la Universidad (Selva, U. T., 2006).

II.2.5. rea de influencia (rea especfica de mercado).

El rea de influencia de la Universidad Tecnolgica de la Selva comprende cuatro regiones econmicas, con 28 municipios: Regin I Centro, Regin II Altos, Regin III Fronteriza y Regin VI Selva (Selva, U. T., 2006). Dentro de estas regiones econmicas, se encuentran inmersos los s iguientes Municipios: Venustiano Carranza, Altamirano, Amatenango del Valle, Chalchihuitan, Chamula, Chanal, Chenalho, Huistn, La Raizar, Mitoctic, Oxchuc, Pantelh, Las Rosas, San Cristbal de las Casas, Tenejapa, Teopisca, Zinacantan, Comitn; Las Margaritas, Chiln, Ocosingo, Palenque, Sabanilla, Sital, Tila, Tmbala, Yajaln y San Juan Cancn (Selva, U. T., 2006). Generalmente los alumnos que ingresan a la Universidad provienen de familias de bajo y medio nivel; de las instituciones como: COBACH, CBTA, CECYT, CBTIS, TELEBACHILLERATO y Preparatorias Particulares, entre otras (Selva, U. T., 2006).

38

II.2.6. Objetivos de la empresa.

II.2.6.1. Objetivo general

Ofrecer a los egresados de nivel medio superior, servicios educativos de calidad certificada, que aseguran el compromiso del personal docente, administrativo y directivo para la mejora continua en la formacin de Tcnicos Superiores Universitarios.

II.2.6.2. Objetivos especficos.

Impartir una educacin integral que aspire siempre a la excelencia en lo cientfico y tecnolgico complementando una formacin humanstica. Mantener una vinculacin con el sector productivo, que se dar desde la incorporacin del sector en el cuerpo de gobierno de la institucin, hasta en la determinacin de requerimientos de empresas y organismos para la creacin de nuevas carreras, programas de investigacin y educacin continua. Conservar relaciones armnicas con el sector econmico, pblico y social, procurando una participacin constante y permanente mediante la aportacin de alternativas de solucin a sus problemas, a travs de sus funciones sustantivas y de acuerdo a su capacidad y recursos. Adoptar estructuras administrativas, acadmicas y jurdicas que le permitan realizar sus funciones con eficiencia y eficacia, y que le permitan adecuarse a los requerimientos del momento histrico que vive. Planear a corto, mediano y largo plazo, sern instrumentos que siempre guiarn las acciones y actividades de la Universidad. 39

Tomar en cuenta el principio de excelencia acadmica, ofreciendo oportunidad de formacin a los jvenes, sin importar su condicin econmica, poltica o social, sin ms limitaciones que la capacidad derivada de sus recursos de profesores y planta fsica. Ser un reto permanente para sus administradores el mantener el equilibrio financiero, revisando anualmente las cuotas fijadas para la prestacin de servicios, logrando la participacin de los Gobiernos Federal y del Estado de Chiapas, e incentivando la colaboracin del sector productivo.

II.2.6.3. Misin.

Brindar educacin superior tecnolgica de calidad, realizar investigacin aplicada y difundir los valores de la cultura, para formar profesionales integro, competitivos y emprendedores, comprometidos con el desarrollo del pas y con el uso sustentable de los recursos naturales.

II.2.6.4. Visin.

En el 2020, la Universidad Tecnolgica de la selva ser la institucin de educacin superior tecnolgica ms reconocida en Chiapas por la competitividad y posicionamiento de sus egresados en los sectores pblicos, social y privado; por la investigacin aplicada que desarrolle y transfiera la plata productiva; as como la preservacin y difusin de la cultura que realice en beneficio de la comunidad.

40

II.2.7. Poltica de calidad.

El compromiso del personal docente, administrativo y directivo que laboramos en la universidad Tecnolgica de la Selva, radica en la mejora continua de nuestras funciones con una excelente actitud de servicios, para satisfacer las expectativas de alumnos, trabajadores, sector productivo y sociedad en su conjunto.

II.2.8. Organigrama de la Institucin

Figura II.19.- Organigrama general de la universidad tecnolgica de la selva.

41

II.2.10. rea de la empresa en donde se desarrolla el proyecto

La Universidad Tecnolgica de la Selva, es una institucin de excelencia en la formacin de Tcnicos Superiores Universitarios e ingenieros, y responde con una educacin de calidad para lograr que sus egresados se posicionen en el mercado laboral, participando con responsabilidades en el desarrollo de la regin y del estado.

El proyecto se realizar en la Divisin de Tecnologa de la Informacin y Comunicacin para trabajar directamente con el docente de tiempo completo MC. Armando Mndez Morales, en un proyecto financiado por el Programa de Mejoramiento del Profesorado (PROMEP) de la Subsecretara de Educacin Superior con numero de oficio de carta de liberacin PROMEP/103.5/10/5323, para realizar un proyecto denominado Sistema de Control Presupuestal y Gestin de Viticos basado en Procesos de Negocios y Flujos de Trabajo (SiPreVia-PF).

II.3. Planteamiento del problema

Muchas veces nos hemos enfrentado situaciones que nos obligan a dar un sin fin de pasos para realizar ciertos trmites administrativos. En varios casos esto se debe al deficiente control y manejo de la informacin, es decir, para obtener un resultado de cierta solicitud es procesado por varias personas, el cual, se obtiene un resultado en un determinado tiempo, incluyendo los tiempos que ocupa una persona en mandar y recibir la solicitud.

Actualmente la Universidad Tecnolgica de la Selva cuenta con aplicaciones de escritorio y aplicaciones web, capaces de realizar y controlar las actividades u operaciones de los usuarios en un enfoque tradicional. Un sistema con enfoque tradicional viene siendo como: Dar de alta un nuevo registro, modificar los datos del registro, buscar los datos del registro y eliminar los datos registrados. Y 42

ocasionalmente todas las actividades mencionadas anteriormente son realizadas en un solo modulo del sistemas

Hasta hoy en da, existen muchas actividades que son realizadas de forma manual, que suele ser muy laboriosos y costos en tiempo.

II.4. Objetivos

II.4.1. Objetivo General

Desarrollar los requisitos establecidos para disear la arquitectura base de sistemas orientados a procesos de negocios y flujos de trabajo, creando una estructura de cdigos por medio de clases reutilizables para los futuros mdulos de un nuevo sistema, permitiendo a los futuros desarrolladores reutilizar el cdigo fcilmente, adems de generar las interfaces visuales del usuario empleando el framework zk para proporcionar una presentacin ms comn al usuario.

II.4.2. Objetivos Especficos

Realizar el desarrollo de los requisitos especificados en el documento de requisitos9, emitido por el maestro M.C. Armando. Mndez Morales. Elaborar un manual tcnico donde se describa los pasos/procedimiento para generar las altas, bajas, consultas, modificaciones, empleando la arquitectura base desarrollada.

Vase el apartado Anexo A Documento de Requisitos

43

Comparar empresas que operan de forma funcional vs empresas que operan de forma orientada a procesos. Elaborar una estructura visual o diagrama para representar de forma resumida la generacin de nuevos mdulos orientados a procesos.

II.5. Justificacin

La realizacin de esta investigacin, se pretende efectuar una aportacin de carcter terico, el diagnostico general y especifico, que se realizo en la Divisin de Tecnologas de la Informacin y Comunicacin, se obtuvo la definicin del siguiente proyecto: Desarrollo de los Requisitos Establecidos para Disear la Arquitectura Base de Sistemas Orientados a Procesos de Negocios y Flujos de Trabajo.

Mediante el anlisis se pretende el desarrollo de aplicaciones basadas en modelo de procesos de negocios y flujos de trabajo: Permitir la implementacin tcnica de procesos de negocio. Controlar y coordinar activamente el flujo de trabajo por el sistema. Monitorear las actividades individuales y el inicio de cada proceso. Integrar las funciones de comunicacin y colaboracin de las personas en un grupo de trabajo.

Se pretende obtener los sistemas como herramienta de control y coordinacin, ya que el objetivo es automatizar la secuencia o flujo de actividades, mediante una serie de operaciones que incluyen: su definicin, en la que se establece el flujo de actividades a seguir; su ejecucin, en la que la informacin y los recursos llegan al usuario que le corresponde en el momento adecuado; y su gestin, para llevar a cabo un continuo seguimiento y la administracin del proceso en su totalidad. 44

III. METODOLOGA

III.1. Enfoque metodolgico

Existen mtodos de recopilacin de informacin las cuales son el mtodo cuantitativo y cualitativo, la cual permite realizar la recopilacin y procesamiento de la informacin a travs de la investigacin documental e investigacin de campo, con el fin de evaluar y analizar el ambiente donde se desea realizar dicha investigacin. De acuerdo al objetivo del proyecto que se desarrolla el sistema de: Desarrollo de los Requisitos Establecidos para Disear la Arquitectura Base de Sistemas Orientados a Procesos de Negocios y Flujos de Trabajo, se eligi el mtodo cualitativo, debido a la forma de recolectar la informacin para el desarrollo del proyecto; aplicando encuestas para evaluar la satisfaccin del usuario. El enfoque cualitativo, a veces referido como investigacin naturalista,

fenomenolgica, interpretativa o etnogrfica, es una especia de paraguas en la que se incluye una variedad de concepciones, visiones, tcnicas y estudios no cuantitativos. El enfoque cualitativo utiliza la recoleccin de datos sin medicin numrica para descubrir o afinar preguntas de investigacin en el proceso de interpretacin (Hernndez, R., 2006).

A continuacin se presentan algunas de las caractersticas ms importantes de este mtodo: 1) El investigador plantea un problema, pero no sigue un proceso claramente definido. Sus planteamientos no son tan especficos como en el enfoque cuantitativo(Hernndez, R., 2006). 45

2) Se

utiliza

primero

para

descubrir

refinar

preguntas

de

investigacin(Hernndez, R., 2006). 3) Bajo la bsqueda cualitativa, en lugar de iniciar con una teora particular y luego voltear al mundo emprico para confirmar si esta es apoyada por los hechos, el investigador comienza examinando el mundo social y en este proceso desarrolla una teora coherente con lo que observa que ocurre. Dicho de otra forma, las investigaciones cualitativas se fundamentan ms en un proceso inductivo (explorar y describir, y luego generar perspectivas tericas)(Hernndez, R., 2006). 4) En la mayora de los estudios cualitativos no se prueban hiptesis, estas se generan durante el proceso y van refinndose conforme se recaban ms datos o son resultado del estudio(Hernndez, R., 2006). 5) El enfoque se basa en mtodos de recoleccin de datos no estandarizados. No se efecta una medicin numrica, por lo que el anlisis no es estadstico. La recoleccin de los datos consiste en obtener las perspectivas y puntos de vista de los participantes. Tambin resultan de inters las interacciones entre individuos, grupos y colectividades (Hernndez, R., 2006).

III.2. Mtodo de recoleccin de datos

a) El mtodo que se utilizar para la evaluacin de conocimiento en desarrollos de software al desarrollador ser mediante la investigacin no experimental ya que esta se basa en la investigacin y la observacin de sus comportamientos, para ello se eligi una tcnica, que nos ayudar a conocer mejor la naturaleza del problema que est asumiendo actualmente el departamento. b) Las tcnicas e instrumentos utilizados en la investigacin se describen y presentan detalladamente a continuacin:

46

La encuesta: es un estudio de observacin en el cual el investigador no deber alterar el medio ni controlar el proceso que est en observacin.

Los datos que se conseguirn sern a partir de realizar un conjunto de preguntas ordenadas dirigidas a una muestra especfica o al conjunto total de la poblacin de la universidad. En estudio, que servir para obtener informacin determinada de una muestra poblacional. En donde el investigador debe seleccionar las preguntas ms convenientes, de acuerdo con la naturaleza de la investigacin.

Estas son las razones de implementar esta tcnica ya que podemos obtener respuestas sin poner nerviosos a los encuestados donde quizs las respuestas sean ms claras y mejores porque las preguntas no son dirigidas personalmente a la persona sino que simplemente tiene que contestarlas como que si se tratara de un examen.

La encueta ser aplicada a los docentes que estn familiarizados con el uso de programas de leguajes de programacin y desarrolladores de sistemas, con el nico propsito de obtener informacin til para la saber el nivel de conocimiento en desarrollos de sistemas as como tambin para identificacin de fallas en los procesos que estn a disposicin para aplicar una alternativa de solucin.

A continuacin se presentan los diseos de los formatos a emplear durante el proceso de la recoleccin de datos para el saber el grado de conocimiento en desarrollo de sistemas.

Encueta No 1. Encuesta sobre tecnologas alusivas al desarrollo de aplicaciones y procesos de negocio.

Esta encuesta va dirigida a los usuarios que estn familiarizados con el uso de programas de leguajes de programacin y desarrolladores de aplicaciones web: 47

Figura III.1.- Evaluacin de conocimiento en desarrollos de software.

c) Procedimiento de la aplicacin de la encuesta y observacin directa: 48

Encuesta:

1. Elaborar la encuesta dirigida al personal docente del rea de TIC. 2. Solicitar la autorizacin con la Jefa del departamento, para aplicar la encuesta. 3. Presentarse a aplicar la encuesta. 4. Explicar el motivo de la encuesta a los encuestados. 5. Cierre de la aplicacin 6. Analizar los resultados de los datos obtenidos de la encuesta. 7. Generar las grficas de resultados obtenidos. 8. Interpretar los resultados de las grficas.

III.3. Definir el Universo (poblacin) y el tamao de muestra.

Universo.

El estudio fue realizado al departamento de la Divisin de Tecnologas de la Informacin y Comunicacin (TIC). De este universo se tom una muestra poblacional nicamente a los docentes de T.I.C. Las encuestas se aplicaran al 10 % del personal docente de la divisin (que en su totalidad son 20 personas).

A continuacin se presenta la Poblacin muestral que se consider en la investigacin:

Muestra poblacional Docentes de T.I.C. Totalidad Porcentaje de la poblacin.

Muestra Total 22 22 100%

Encuesta a aplicar (muestreo) 22 encuestas 22 encuestas

Tabla III.1.- Muestra poblacional considerado en la investigacin.

49

Calculo poblacional.

Para aplicar la encuesta al personal docente de T.I.C., no fue necesario sacar una muestra poblacional, ya que son pocos, tomando como el 100% en total. Por lo tanto encuestamos a los 22 docentes que imparten la materia de anlisis de diseo y programacin.

III.4. Recopilacin de datos

Una vez definida la poblacin, se aplic la tcnica: encuesta y de esta manera obtuvimos la informacin ms relevante para desarrollar el proyecto. La encuesta fue aplicada el da 18 de abril del presente ao, siendo las 12:00 horas del da, el cual fue aplicado a los docentes de la divisin de T.I.C., directamente con los docentes que imparten clases de anlisis de diseo y programacin, ya que son las personas que se encuentran ms familiarizados con los desarrollos de sistemas.

El total de encuestados fueron 22 encuestas.

A continuacin se presenta un ejemplo de las encuestas aplicadas al personal docente:

50

Figura III.2.- Encuesta aplicada al personal docente.

51

IV. ANLISIS DE RESULTADOS Y DISCUSIN

IV.1. Anlisis de resultados en la encuesta.

A continuacin se presenta el anlisis e interpretacin de los resultados, con la finalidad de obtener opiniones del personal docente de la divisin de Tecnologas de la Informacin y Comunicacin en La Universidad Tecnolgica de la Selva y reforzar el conocimiento para el desarrollo de sistemas orientados a procesos de negocios, flujos de trabajo y la utilizacin de Frameworks.

Los resultados obtenidos se representan en grficas de columna.

1. Conoce Frameworks de desarrollo de aplicaciones?


100% 80% 90%

Porcentaje

60%

40% 20% 0%
Nivel de conocimiento de aplicaciones
Grfica IV.1.- Evaluacin del nivel de conocimiento de aplicaciones.

SI 10% NO

De acuerdo al diagnostico, en la grfica anterior se visualiza que el 90% de docentes de T.I.C. tienen el conocimiento en el manejo de los Frameworks en el desarrollo de aplicaciones, y el 10% no se encuentran familiarizados con esta aplicacin.

52

2. Utilizan un Framework de desarrollo de aplicaciones?


70%

60%
40%

60%
Porcentaje

50%
40%

30% 20%
10%

SI
NO

0%

Nivel de uso de Framework de aplicaciones

Grfica IV.2.- Evaluacin del nivel de uso de Framework de aplicaciones.

En la grfica anterior, se visualiza que el 60% de los docentes de T.I.C. utilizan los Framework para el desarrollo de aplicaciones y el 40% de los docentes no utilizan los Frameworks.

3. Utilizan Framework para php?


90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 80%

Porcentaje

20%

SI NO

Evaluacin del uso de Framework para php

Grfica IV.3.- Evaluacin de del uso de Framework para php.

En la grfica anterior, se visualiza que el 80% de los docentes utilizan los Framework para php, y el 20% no lo utilizan. 53

La siguiente es una pregunta abierta, y se interpreto de la siguiente manera:

4. Que Frameworks conoce para php?


100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 90% 80% 80% 80% 90% 70% 30% 10% 10% SI NO 90%

Porcentaje

10%

20%

20%

20%

Frameworks
Grfica IV.4.- Evaluacin de Frameworks para php.

En la grfica anterior se visualiza las respuestas de los docentes que asignaron en la pregunta abierta, sobre el uso de los Frameworks ms conocidos para php.

Como se muestra en la grfica, el Framework ms conocido para php, es el ZK indicando que el 80% de los docentes tienen el conocimiento del Framework, despus Zend Framework con el 30% de docentes con conocimiento, luego estn Zen y Seagull con el 20% de docentes con conocimiento, por ltimo, tenemos a PhpNuke, CakePhp y Booba con 10% de docentes que conocen los Frameworks.

Estos fueron resultados segn las respuestas de los docentes, aunque realmente el Framework ZK est basada en lenguaje Java y no en php.

54

5. Utilizan Framework para java?


60% 50% 50% 50%

Porcentaje

40% 30% 20% 10% 0% Evaluacin del uso de Framework para java
Grfica IV.5.- Evaluacin del uso de Framework para java.

SI NO

En la grfica se visualiza, que el 50% de los docentes utilizan Framework para Java y el 50% no los utilizan.

La siguiente grfica es de una pregunta abierta:

6. Que Frameworks conoce para java?


100% 90% 80% 80% 70%

Porcentaje

80% 60% 40% 20% 0% Netbeans SEAM Spring 10% 30% 20% 20%

SI NO

Struct

Frameworks para java


Grfica IV.6.- Evaluacin de Frameworks para java.

En la grfica anterior se visualiza, los Frameworks ms utilizados para Java, est el Netbeans con 90%, despus Struct con 30%, por ltimo, est SEAM y Spring con un 20%. 55

7. Cmo reutiliza sus cdigos desarrollados? Mediante:


80% 70% 60% 50% 40% 30% 20% 10% 0%

69% Clases propias Reuso de Frameworks Aplicando Patrones de Diseo Otros Evaluacin del modo de la reutilizacin de cdigos desarrollados

Porcentaje

23% 8% 0%

Grfica IV.7.- Evaluacin del modo de la reutilizacin de cdigos desarrollados.

En la grfica anterior se visualiza, el 69% de los docentes utilizan las Clases Propias, para la reutilizacin de los cdigos desarrollados, el 23% los reutiliza aplicando Patrones de Diseo y el 8% los reutilizan con el Reuso de Framework.

8. Cree que tenga alguna utilidad el uso de Frameworks?


100%
Porcentaje

90%

80% 60% 40% 20% 0% 10% SI


NO

Nivel de utilidad del uso de los Framework

Grfica IV.8.- Evaluacin del nivel de utilidad del uso de los Framework.

En la grfica anterior muestra que el 90% de los docentes de T.I.C. afirman que al desarrollar sistemas con los Framework son de mucha utilidad y el 10% no creen que sean de mucha utilidad. 56

En esta pregunta afirman o rechazan la utilidad del uso de los Framework y se explica el porque de la respuesta.

A continuacin se menciona el porque afirman que son de mucha utilidad los Framework y se interpreta en la siguiente grfica:

Grfica IV.9.- Evaluacin del porque es de mucha utilidad los Framework.

En la grfica anterior se visualiza que el 80% de los docentes afirman que al utilizar los Frameworks, ayudan a proporcionar facilidad de reutilizacin del cdigo fuente de la aplicacin, el 90% de los docentes dicen que porque tienen una estructura definida, el 90% de los docentes dicen que ayudan en el uso de de programas, el 90% de los docentes dicen que ayudan en la administracin de los cdigos y el 90% de los docentes dicen que facilitan el desarrollo del sistema.

57

9. Desarrolla Modelado de Procesos?


70% 60% 50% 40% 30% 20% 10% 0% 60% 40% SI NO

Porcentaje

Nivel de aplicacin de desarrollo de Modelado de Proceso

Grfica IV.10.- Evaluacin de utilizacin de Modelado de Proceso.

En la grfica anterior se visualiza, el 60% de los docentes de T.I.C. desarrollan Modelado de procesos, y el 405 de los docentes no desarrollan modelado de procesos.

10. Que herramienta utiliza para disear procesos?


80% 70% 60% 50% 40% 30% 20% 10% 0% 70% Visio Word 20%
10% Bizzagi

Porcentaje

0%

Otros

Herramientas ms utilizadas para el diseo de procesos

Grfica IV.11.- Evaluacin de herramientas utilizadas en el diseo de procesos.

En la grfica anterior se visualiza, que el 70% de los docentes utiliza la herramienta de Visio, el 20% utiliza Bizzagi y el 10% Word como herramienta para desarrollar los diseos de Procesos. 58

Grfica IV.12.- Etapa de utilizacin de herramientas para disear procesos.

En la grfica se visualiza que el 45% de los docentes hacen uso de las herramientas en el momento de realizar los Diseo, 36% en Anlisis y 9% en Documentacin.

La siguiente grfica es de una pregunta abierta el cual se interpreta de acuerdo a las respuestas de los docentes.

12. Cules son los elementos de un Sistema de Gestin de Procesos (Bussiness Process Management)?
90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
80%

Porcentaje

20%
10%

Procesos, Subprocesos , Procedimientos Procesos, Actividades y Roles Estado de iteraciones

Sistema de Gestin de Procesos


Grfica IV.13.- Evaluacin de elementos de un Sistema de Gestin de Procesos.

59

En la grfica anterior se visualiza algunas respuestas que los docentes indicaron como los sistemas de gestin de procesos.

13. Mencione algunos ejemplos de sistemas de tipo BPM-Bussiness Process Management


100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 90%

80%

80%

Porcentaje

10%

20%

20% SI N0

Analizar parte del sistema

ERP

Procesos de alguna empresa, como realizar las ventas

BPM-Bussiness Process Management

En la grfica anterior se visualiza, algunos ejemplos de sistemas de tipo BPMBussiness Proccess Management que los docentes respondieron.

14. Indique la fuente de informacin que utiliz para poder contestar estas preguntas:
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

80%

90%

80%

Porcentaje

20%

10%

20%

0%

SI NO

Fuente de informacin que utilizaron para resolver la encuesta


Grfica IV.14.- Evaluacin de la fuente de informacin para resolver la encuesta.

60

En la grfica anterior se observa que el 90% de los docentes resolvieron la encuesta por Experiencia del uso de los Framework, el 80% respondieron la encuesta con la ayuda de Internet y el 20% con el apoyo de Libros.

Grfica IV.15.- Evaluacin en qu etapa se define el Modelo de Negocios.

En la grfica anterior se visualiza que el 50% de los docentes, definen el Modelado de Negocio en la etapa de Anlisis del ciclo de Desarrollo de Software y el 50% durante la etapa de Diseo.

Por medio de las encuestas aplicadas se pudo conocer y medir el grado de conocimiento que tiene el personal docente de la divisin de Tecnologas de la Informacin y Comunicacin, sobre el desarrollo de sistemas orientados a procesos de negocios y flujos de trabajos, el uso de los Frameworks y los beneficios en su utilizacin.

En base a los resultados obtenidos, ayudara a los futuros desarrolladores de sistemas, ya que se pudo crear la arquitectura base de sistemas orientados a procesos de negocios y flujos de trabajo, donde facilitar la creacin de nuevos mdulos, en solo, reutilizar el cdigo fuente de los mdulos pre-creados. 61

IV.2. Resultados del proyecto.

IV.2.1. Comparacin entre empresas que operan de forma funcional vs empresas que operan de forma orientada a procesos.

Una empresa con estructura funcional comprende la forma en que se dividen, agrupan y coordinan las actividades en una organizacin, as como las relaciones entre los gerentes y los empleados. Se analizan los factores que determinan el nmero de niveles en la estructura de una organizacin y las caractersticas de la estructura actual.

La organizacin por funciones rene, en un departamento, a todos los que se dedican a una actividad o a varias relacionadas, que se denominan funciones.

Grfica IV.16.- Empresa con estructura organizacional funcional.

Una empresa con estructura organizacional por procesos son tan eficientes como lo son sus procesos. La mayora de las empresas y/o las organizaciones que han tomado conciencia de esto han reaccionado ante la ineficiencia que representa las 62

organizaciones departamentales, potenciando el concepto del proceso, con un foco comn y trabajando con una visin de objetivo en el cliente.

Grfica IV.17.- Empresa con estructura organizacional por procesos.

A continuacin se muestra una tabla donde se puede observar la diferencia entre empresas funcionales vs empresas por procesos.

Empresas funcionales vs Empresas por procesos Funcionales: Los empleados son el problema. Hacer mi trabajo. Comprender mi trabajo. Procesos: El proceso es el problema. Ayudar que se hagan las cosas. Saber que lugar ocupa mi trabajo en el proceso. Evaluar a los individuos. Control de los empleados. Quin cometi el error? Corregir errores. Evaluar el proceso Desarrollo de las personas Qu permiti el error? Reducir la variacin.

Tabla IV.1.- Empresas funcionales vs Empresas por procesos.

63

IV.2.3. Manual para desarrollar un nuevo mdulo empleando la arquitectura base desarrollada.

64

ndice de contenido.

65

I. INTRODUCCIN.

El siguiente artculo est dirigido a desarrolladores que tengan la oportunidad de utilizar el cdigo fuente de la arquitectura base de sistemas orientados a procesos de negocios y flujos de trabajo. No voy a explicar toda la estructura del cdigo fuente, ni conceptos que se han utilizado en la construccin, ni voy explicar Javadoc, nada por el estilo. Pero si alguien necesita saber ms informacin sobre los conceptos antes mencionados, les recomiendo revisar otros artculos y/o tutoriales en la red que tambin estn muy buenos.

El objetivo es explicar cmo crear un nuevo mdulo para una sola entidad / entidades relacionadas del sistema, reutilizando los cdigos de los mdulos de la arquitectura base: creacin de la clase JPA para la persistencia de la base de datos, creacin de las clases o controladores y los archivos JSPs.

La intencin es profundizar lo suficiente para poder ayudar a la construccin de nuevas aplicaciones orientados a procesos de negocios de La Universidad Tecnolgica de la Selva o instituciones y empresas que tengan los privilegios de utilizar el cdigo fuente. Proporcionando la informacin del uso de las clases de los mdulos pre-creados, uso de las entidades de persistencias creadas a partir de la base de datos, controladores, entre otros.

El artculo es un manual para desarrolladores que tienen conocimientos sobre: JPA, Servlet, Herencia, Objetos, Framework ZK, entre otros.

Antes de comenzar con la configuracin del ambiente de desarrollo, primero deber conseguir los siguientes programas y plugins. NetBeans.MySQL. MySQL Workbench. Framework ZK archivo .nbm. 66

II. CREACIN DE UN NUEVO MDULO.

II.1. Creacin de paquete de clases para un nuevo mdulo.

Paso 1. Crear un mdulo llamado tprocesoactividad. Clic derecho, ir en opcin nuevo, elegir a Java Package que significa paquete java.

Figura IV.1.- Creacin de un nuevo paquete.

Paso 2. Asignar el nombre del paquete tprocesoactividad, debe ser exactamente igual que el nombre de la tabla en la BD.

Figura IV.2.- Asignar nombre del paquete.

67

II.2. Crear la clase entidad a partir de la base de datos.

Paso 1. Clic derecho, nuevo y elegir clase entidad a partir de la base de datos.

Figura IV.3.- Creacin de la entidad a partir de la base de datos

Paso 2. Seleccionar el nombre de la tabla tprocesoactividad, clic en el botn Agregar, seleccionar la casilla donde dice Incluir tablas relacionadas y siguiente.

Figura IV.4.- Seleccin del nombre de la entidad.

68

Paso 3. Seleccionar el paquete tprocesoactividad creado anteriormente y siguiente.

Figura IV.5.- Seleccin de paquete para la entidad.

Paso 4. Seleccionar el tipo de mapeo que se requiere para generar la clase, en este caso se utilizar de tipo List, en la opcin java.util.List, activar las casillas donde dice: nombre completo de tablas de la base de datos y atributos para generar tablas y clic en el botn terminar.

Figura IV.6.- Seleccionar el tipo de mapeo de la entidad.

69

Paso 5. Copiar las clases de los modulo ya creados, utilizaremos el modulo de usuarios, seleccionamos las clases, copiar y pegar en el paquete tprocesoactividad.

Figura IV.7.- Copiando clases de entidad.

Despus de pegar las clases, hay que renombrarlos con esta nomenclatura:

Nombre de la tabla en la base de datos + Action + Nombre de la operacin.

El nombre de la tabla en la base de datos siempre tiene que iniciar con maysculas, a diferencia en el nombre de los paquetes que inicia con minscula: TprocesoactividadParams.java TprocesoactividadActionBuscarGral.java TprocesoactividadActionBuscarParticular.java TprocesoactividadActionCrearNuevo.java TprocesoactividadActionEliminar.java TprocesoactividadActionGuardarCambios.java TprocesoactividadActionGuardarNuevo.java

70

II.3. Creacin de clase de entidad Params.

Cada vez que se desarrolle las funcionalidades (bsqueda, altas, modificacin y eliminacin) de una nueva entidad, se crear en el paquete con el mismo nombre de la entidad con la terminacin Params, quedando como ejemplo el siguiente nombre: TprocesoactividadParams.java

El mtodo getYsetParameters, permite obtener el valor de los objeto del archivo jsp, comparando los tipos de datos en la base de datos.

Figura IV.8.- Cdigo fuente del mtodo getYsetParameters.

El mtodo getParamsBusq, hace uso del mtodo anterior, mandando el nombre de los objetos jsp y el nombre de la clase de mapeo que hace uso para cargar los datos obtenidos.

Figura IV.9.- Cdigo fuente del mtodo getParamsBusq.

71

El mtodo getParamsForm, sirve para obtener los valores teclados en los objetos jsp, ya sea, para hacer un nuevo registro o modificacin de datos. Tambin hace la validacin de los campos, indicando la longitud del campo y si acepta valore nulos. Si se presenta algn error, este mando un mensaje indicando cual fue el error en la operacin.

Figura IV.10.- Cdigo fuente del mtodo getParamsForm.

Despus de la validacin de datos, entonces, se crea un objeto de la clase de mapeo, en este caso, es la clase Tprocesoactividad, y enseguida se almacena los datos ya obtenidos, en los mtodos correspondientes. 72

II.4. Creacin de clase de entidad BuscarGral.

Se crear en el paquete una clase con el mismo nombre de la entidad con la terminacin BuscarGral, por ejemplo: TprocesoactividadActionBuscarGral.java, este es ejecutado para mostrar los datos de la tabla correspondiente. Desde aqu se obtiene los parmetros de bsqueda, la lista de pginas a mostrar y se cargan los datos para hacer la bsqueda, por ejemplo: los tipos de actividades.

Figura IV.11.- Cdigo fuente de la entidad BuscarGral.

73

II.5. Creacin de clase de entidad BuscarParticular.

Se crear una clase en el paquete con el mismo nombre de la entidad con la terminacin BuscarParticular. Quedando como ejemplo el siguiente nombre: TprocesoactividadActionBuscarParticular.java.

Esta clase se utiliza para obtener los datos de un registro seleccionado, verificando que el nombre del elemento contenga chk al principio. Esta nomenclatura es asignada desde el archivo Tprocesoactividad.jsp. Asigna el valor del evento actual ev, con Tprocesoactividad/GuardarNuevo, para que al momento de guardar los cambios, se ejecute la clase TprocesoactividadActionGuardarCambios.

Figura IV.12.- Cdigo fuente de la entidad BuscarParticular.

74

II.6. Creacin de clase de entidad CrearNuevo.

Se crear una clase en el paquete con el mismo nombre de la entidad con la terminacin CrearNuevo. Por ejemplo: TprocesoactividadActionCrearNuevo.java.

Esta

clase,

se

utiliza

para

cargar

los

datos

mostrar en

el

archivo

frmNuevoprocesoactividad.jsp en forma de listas, se carga los tipos de actividades y las Urls, para poder seleccionar cuando se registra una nueva actividad. Tambin tiene la funcin de asignar el valor del eve nto actual ev, se deja con el valor de Tprocesoactividad/GuardarNuevo, para que al momento de guardar los datos, automticamente se ejecute la clase TprocesoactividadActionGuardarNuevo.

Figura IV.13.- Cdigo fuente de la entidad CrearNuevo.

75

II.7. Creacin de clase de entidad Eliminar.

Se crear una clase en el paquete con el mismo nombre de la entidad con la terminacin Eliminar. Por ejemplo: TprocesoactividadActionEliminar.java.

La clase se utiliza para obtener el id de un registro seleccionado, verificando que el nombre del elemento contenga chk al principio. Esta nomenclatura es asignada desde el archivo Tprocesoactividad.jsp.

Figura IV.14.- Cdigo fuente de la entidad Eliminar.

Cuando es encontrado algn elemento con esta nomenclatura, entonces se ejecuta el objeto objAccesoABD.destroy, destroy es el mtodo que elimina los datos del registro seleccionado. 76

II.8. Creacin de clase de entidad GuardarCambios.

Se crear una clase en el paquete con el mismo nombre de la entidad con la terminacin GuardarCambios. Quedando como ejemplo el siguiente nombre: TprocesoactividadActionGuardarCambios.java.

La clase se utiliza para poder editar los datos de un registro, y se ejecuta despus de la clase procesoactividadActionBuscarParticular, crea un objeto de la clase Tprocesoactividad para almacenar temporalmente los datos, entonces se ejecuta el objeto objAccesoABD.edit, edit es el mtodo que se encarga de modificar los datos del registro. Despus vuelve a cargar todo los datos al JSP.

Figura IV.15.- Cdigo fuente de la entidad GuardarCambios.

77

II.9. Creacin de clase de entidad GuardarNuevo.

Se crear una clase en el paquete con el mismo nombre de la entidad con la terminacin GuardarNuevo. Quedando como ejemplo el siguiente nombre: TprocesoactividadActionGuardarNuevo.java.

Esta clase se encarga de crear nuevos registros, crea un objeto de la clase Tprocesoactividad para almacenar los datos temporalmente y hace una comparacin de los tipos de datos en la base de datos, verifica si existe un id a registrar, se ejecuta el objeto objAccesoABD.create, create es el mtodo que se encarga de crear el registro. Despus vuelve a cargar los datos y le asigna el valor del ev con Tprocesoactividad/GuardarCambios.

Figura IV.16.- Cdigo fuente de la entidad GuardarNuevo.

78

II.10. Creacin de archivos JSPs para un nuevo modulo.

Para crear un nuevo modulo, tambin reutilizaremos los cdigos de los archivos jsp, seleccionamos, le damos copiar y pegar en la misma carpeta web pages, luego renombraremos a TprocesousuarioList.jsp con Tprocesoactividad.jsp y a

frmNuevoprocesousuario.jsp con frmNuevoprocesoactividad.jsp. as, como se ve en la imagen.

Figura IV.17.- Copiando los archivos JSP's

II.11. Creacin del archivo JSP para la consulta de datos.

Se crear un archivo para la consulta de datos, el cual, nos permitir el acceso de la visualizacin de datos de la base de datos, acceso a crear nuevos registros, modificar los datos y eliminar. Este archivo JSP tendr el mismo nombre de la entidad. Quedando como ejemplo el siguiente nombre: Tprocesoactividad.jsp.

79

El archivo Tprocesoactividad.jsp debe de tener estas libreras, para funciones la aplicacin, sobre todo, las libreras del Framework ZK.

Figura IV.18.- Librerias importadas en el archivo JSP.

Se abre la etiqueta <z:page zscriptLanguage="java">, para que las etiquetas de ZK funcionen correctamente. Luego se el Windows overlapped, para los mensajes, despus el Windows normal para realizar la operaciones.

Figura IV.19.- Inicializacin de las etiquetas ZK y windows.

80

Se le cambia el id y nombre del form con tprocesoactividadListForm, para poder hacer submit al momento de realizar la bsqueda de los datos.

Figura IV.20.- Cambio de nombre y funcin del form.

En la parte superior, se ha creado un textbox llamado busq_idProcesoActividad, se le ha asignado un prefijo busq, indicando es una caja de texto para bsqueda.

Aqu se est utilizando un control de tipo bandbox, que sigue la misma nomenclatura, se le asigna el tipo de actividad como su valor cargado desde el Servlet. Despus se carga los tipos de actividades en un listbox, con valor que contiene la variable tprocesoactividadListTipos, recorriendo por medio de un forEach.

Figura IV.21.- Cargar una lista en el JSP con ZK y JSTL.

81

En un archivo JSP solo debe existir un botn de tipo submit, aunque tenga varios form e intentes asignarle un submit a cada uno de ellos, siempre marcar error, esto se debe por la utilizacin de la etiquetas ZK. Es por eso, que estos dos botones, forzosamente estn indicando a que form tienen que hacerle un submit.

Con el cdigo Clients.evalJavaScript se puede cambiar el valor de un objeto en ZK. En este ejemplo estamos indicando a que form pertenece los objetos para poder cambiarle de valor, al no indicarle el form no admite el cambio de los valores. El cdigo utilizado es precisamente cdigos de ZK, muy parecido a cdigos JavaScript que la mayora conocemos.

Figura IV.22.- Manejo de los botones en ZK.

Aqu se obtiene la lista de pginas, que ha obtenido nuestra consulta, la listaUrls es la variable que se ha creado desde la clase TprocesoactividadActionBuscarGral, ahora, se recorre por medio de un forEach, visualizndolos en botones, se carga la etiqueta y de manera oculta se genera el numero de pagina y el evento que pertenece cada botn. Para que al momento de darle clic, eso mismo se ejecute.

82

Figura IV.23.- Creacin de pginas por medio de botones a traves de forEach.

A continuacin los cdigos que se utiliza para la visualizacin de los datos en la consulta.

Primero se crea los encabezados de la lista, que nos sirve, para saber que datos son las que visualizamos. Despus se agrega el contenido de la lista por medio de forEach, obteniendo la lista de actividades obtenidas desde el controlador.

Figura IV.24.- Etiquetas para la visualizacin de los datos de consulta.

83

En esta parte es donde se crea la nomenclatura de la eliminacin y modificacin, se crea un objeto de tipo checkbox, que se va generando de a cuerdo al nmero de registro, cuando un uno de los checkboxs es seleccionado toma el valor del id de registro que pertenece.

II.11. Creacin del archivo JSP para las altas y modificaciones.

El archivo frmNuevoprocesoactividad.jsp, tiene las mismas configuraciones que el ejemplo anterior, la diferencia es que es utilizado para hacer un nuevo registro y modificar datos. Los objetos se crean con un prefijo param_ indicando que son para manipular datos en la base de datos.

Las etiquetas que tiene como value=${requestScope.msgerr_segn el campo que corresponda} son para visualizar mensajes de error durante el proceso de registro. 84

IV.2.4. Estructura visual o diagrama para representar de forma resumida la generacin de nuevos mdulos orientados a procesos.

A continuacin mostraremos el flujo de la generacin de nuevos mdulos orientados a procesos.

Grfica IV.18.- Generacin de nuevos mdulos orientados a procesos.

85

V. CONCLUSIONES Y RECOMENDACIONES.
V.1. Conclusin

El proyecto Desarrollo de los requisitos establecidos para disear un sistema que contempla la arquitectura base de codificacin de sistemas orientados a procesos de negocios y flujos de trabajo, se ha concluido satisfactoriamente y est preparado para ser empleado en el desarrollo de futuros sistemas de informacin con requisitos de empleo de sistemas de open source, ya que en su desarrollo se emple mysql, glassfish, zk framework y tecnologa jsp.

Con los nuevos sistemas orientados a procesos de negocios, facilitar la interaccin de los usuarios, quienes tendrn la disponibilidad de funciones del sistema en el momento que se requiera, de acuerdo al flujo de actividades apegadas al diseo del proceso que corresponda. Esto permitir que los usuarios ahorren tiempo en la realizacin de sus actividades diarias ya que sabrn especficamente que tareas tienen que realizar.

El sistema orientado a procesos de negocios, incluye el men de inicio de proceso y la gua para cada uno de ellos, bandeja de entraba de tareas, modulo de registro de usuarios, modulo de registro de roles, modulo de registro de procesos y modulo de registro de actividades.

Finalmente el resultado de este proyecto consisti en la generacin de varios mdulos debidamente estructurados, para que los futuros desarrolladores puedan reutilizar los cdigos fcilmente, sin la necesidad construir desde cero aspectos tcnicos como realizar la paginacin, bsquedas con mltiples filtros, aspectos de presentacin y validacin de datos, entre otros.

86

V.2. Recomendaciones

La continuidad de este proyecto, se requiere hacer funcionar el modulo de la bandeja de entrada de tareas o actividades. Realizar el seguimiento del desarrollo del mdulo de envo de mensajes. Separar la arquitectura base en un proyecto independiente para generarlo de forma de biblioteca de funciones o framework, para que pueda ser integrado en nuevos proyectos. Integrar un diseador visual de procesos en ambiente web (tal como signavio). Desarrollar los mdulos para la gestin de procesos, de forma que cuando los usuarios que tengan que realizar alguna actividad, pero que stos no la puedan realizar por motivo de faltas u otra razn, entonces el administrador de procesos pueda redireccionar el flujo de trabajo a otras personas.

87

VI. REFERENCIAS DOCUMENTALES.

Selva, U. T. (2006). Programa Integral de Fortalecimientos Institucional. Ocosingo, Chiapas. Lpez Yebes E. (2005.). Creacin de pginas Web con FrontpageExpress. Naucalpan de Jurez, Edo. De Mxico: Pearson Education de Mxico, S. A. de C. V. Roberto Hernndez Sampieri, C. F. (2006). Metodologa de la Investigacin 4a Edicin. Mxico, D. F.: Mc Graw Hill. Grafeuille Ernesto (2008). Una Introduccin a Scrum. Mike Cohn. Garca Prez, F. &. (2000.). Informtica de Gestin y Sistemas de Informacin. Espaa, Madrid.: MvGraw-Hill.

Referencias de internet. http://www.bizagi.com/ http://www.tools-live.com/process-maker.html http://www.ecuaportales.com/mado/index.php/software-deaplicacion/colaborativas/104-process-maker http://www.efectra.net/efectraweb/index.php/es/productos/bpm-processmaker http://www.dosideas.com/wiki/Spring_Roo http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=jstlJSF http://www.fing.edu.uy/inco/cursos/tsi/TSI2/teorico/Clase5a-JPA.pdf 88

Anexos
Anexo A. Documento de requisitos

Lista de requisitos establecidos para el desarrollo del proyectos. Num. 01 Fecha 04-ene-12 Descripcin de requisito Hacer que los archivos JPS, se pueda cargar datos mediante servelts. Crear las opciones de bsqueda en el mdulo de WebArqBase. Crear las opciones con bsqueda en forma dinmica, mediante clases en java. Crear el mdulo de editar, nuevo y eliminar datos en los mdulos Crear la paginacin de los datos obtenidos en la consultas. Separar las pginas en bloques de 10 en 10 de los 06 17-ene-12 datos obtenidos desde la base de datos, a travs algoritmos de programacin. 07 20-ene-12 Modificar el mdulo de nuevo y editar en Window modal. Modificar el nombre de las variables creadas 08 22-ene-12 anteriormente, con nombre de variables entendibles para futuro desarrolladores. 09 25-ene-12 Creacin de mtodos y clase, para la validacin de los datos que insertan en la base de datos. Investigar cmo crear un sistema con interface visual de correo. 89 Real

02

05-ene-12

03

06-ene-12

04

09-ene-12

05

13-ene-12

10

27-ene-12

11

08-feb-12

Crear un prototipo del sistema con interface visual de correo. Crear un prototipo de manejo de pestaas en el

12

15-feb-12

sistema, para visualizar ms detalles de un registro o alguna operacin a realizar.

13

21-feb-12

Depurar los el proyecto, eliminado paquetes, clases y mtodo, que no estn en uso. Hacer funcionar el comportamiento de iniciar sesion y cerrar sesion. Crear el mdulo de usuarios (busqueda, nuevo,

14

24-feb-12

15

25-feb-12

modificar y eliminar) pero sin pestaas de subinformacin relacionada (roles). Elaborar la consulta SQL para obtener los datos de las actividades asociadas a los inicios de procesos y

16

26-feb-12

as formar la jerarqua de procesos y actividades a emplear en el despliegue de men de opciones en la pgina principal del sistema. Cuando se presione sobre alguna de las actividades,

17

27-feb-12

mostrar mediante la llamada al controlador que corresponda, la pgina jsp de la operacin solicitada. En el action que corresponda, se subirn en la sesin (request) un conjunto de variables que permitirn el

18

27-feb-12

acceso de lectura o escritura a las etiquetas HTML encontradas en las JSP, para poder delimitar la escritura a ciertas partes del sistema.

19

06-mar-12

Desarrollar el catlogo de Actividades con la opcin de bsqueda general. Desarrollar el mdulo de altas, modificaciones

20

06-mar-12 particulares y eliminacin de actividades del catlogo anterior. 90

Generar un nico archivo JPAController y eliminar todos los paquetes de excepciones, depurar la clase 21 08-mar-12 action. Dejar solamente las paginas jsp y paquetes tProcesoUsuario, tProcesoRol, tProcesoActividad, y las relacionadas a las sesiones. 22 08-mar-12 Separar la bandeja de actividades del usuario del JSP home. En la lista de tareas, permitir seleccionar toda la fila para editar la actividad. En la lista de tareas, no hacer visible los ids de los campos. Cuando se agregue una nueva actividad, deshabilitar 25 15-mar-12 el campo Id, ya que este se obtendr despus de hacer la instruccin create o insert. 26 21-mar-12 En la lista de tareas poner un ttulo referente a la LISTA DE TAREAS. Verificar y/o corroborar las tablas de la base de datos del documento de comisin Sincronizar el diseo de la BD con la estructura de la misma Desarrollar el proceso de Diseo de Procesos, que 29 23-mar-12 consiste en Agregar nuevo Proceso, Agregar

23

12-mar-12

24

12-mar-12

27

22-mar-12

28

23-mar-12

actividades, Secuenciarlas.
Tabla 0.1.- Documento de requisitos.

91