Download Universidad Tecnológica de Querétaro

Universidad Tecnológica
de Querétaro
Firmado digitalmente por Universidad Tecnológica de
Querétaro
Nombre de reconocimiento (DN): cn=Universidad
Tecnológica de Querétaro, o=Universidad Tecnológica de
Querétaro, ou, [email protected], c=MX
Fecha: 2013.10.09 13:13:11 -05'00'
UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO
Nombre del proyecto
“NOVEMQoD”
Empresa:
NOVEM CAR INTERIOR DESIGN MÉXICO S.A. de C.V.
Memoria que como parte de los requisitos para obtener el título de:
TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA
INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS
Presenta:
DUARTE CRUZ ALEJANDRO ABRAHAM.
Asesor de la UTEQ
Asesor de la organización
Ing. Elizabeth Medina Sánchez
Ing. Miriam Cecilia Hernández Ordaz
Santiago de Querétaro, Qro., Octubre del 2013.
Resumen.
Los procesos de producción, mantienen documentos como herramientas
adicionales que proveen al personal involucrado, de la información oficial de la
empresa, para el desempeño de sus labores ordinarias. Estos documentos son
sujetos a modificaciones de acuerdo a diversos factores, tales como las
necesidades del cliente de la empresa o de acuerdo a las normas de calidad
aplicadas para determinado producto. Por lo que no existe un documento fijo para
un proceso específico. Sin embargo todo documento generado, debe ser
aprobado por el proceso de calidad. Por lo que el objetivo de este proyecto es el
desarrollo y la implementación de una herramienta informática para el
departamento de calidad; que permita el control sobre las diferentes clases de
documentos existentes y utilizados dentro de los procesos de producción de la
empresa. El sistema ofrece servicios de control de cambios, mediante la gestión
de usuarios, dentro de grupos o roles bien definidos, con sus diferentes alcances
dentro del sistema para cada uno de ellos. Los alcances permiten el control sobre
las actividades realizadas en los documentos generados y/o previamente
almacenados; asimismo ofrecen al coordinador del proceso de calidad, un
absoluto control sobre la gestión de solicitudes de cambios sobre el documento
utilizado en la fecha dentro de su proceso pertinente, mediante la recepción de
notificaciones de solicitudes de cambios, hechas por el dueño de un documento
explícito. El dueño se define a cualquier usuario del sistema que generare y/o
modifique un documento existente, en base a un formato ya definido. Dentro de
las funciones de esta gestión de solicitudes, el sistema le permite al coordinador
de calidad, la aprobación o rechazo del documento propuesto para ser
implementado en la línea de producción referente al proceso involucrado.
Asimismo consultar cuales son las versiones de documentos actuales y el historial
de los mismos que han sido elaborados durante un lapso de tiempo definido.
También le permite notificar de la resolución final sobre la solicitud, mediante
correo electrónico. Todo esto para incrementar el control de versiones y obtener
un análisis preciso de las metodologías utilizadas en producción.
2
3
Dedicatorias.
A mis padres, hermanos, amigos y al personal docente que labora en la
Universidad Tecnológica de Querétaro, sin ellos, nada de esto sería posible y en
especial a todas las personas que día a día laboran en la Universidad, destacando
la importancia de su trabajo, por muy sencillo que parezca. A través de ellos
aprendí a observar los pequeños detalles de gente leal, honesta, responsable y
dedicada a su trabajo. Gracias a todos y cada uno de ustedes, por su humildad,
sencillez, tenacidad y sobre todo por su valor único como seres humanos. Y es
que en realidad, el aprendizaje ha comenzado a partir de ahora, la formación
humana, desde siempre, el valor y trabajo digno es parte del día a día que he visto
reflejado aquí en la UTEQ.
4
Agradecimientos.
A todos los Dioses habidos y por haber por darme una
nueva oportunidad día a día.
A mi señora Madre por su amor incondicional y su
naturaleza totalmente femenina.
A mi señor padre, mi mejor compañero de equipo. Jefe:
juntos lo hicimos posible.
A todo el personal de la Universidad Tecnológica de
Querétaro.
¡Gracias!
5
ÍNDICE
1. RESUMEN .......................................................................................................................2
2. DESCRIPTION... ..............................................................................................................3
3. DEDICATORIAS .............................................................................................. ………….4
4. AGRADECIMIENTOS ......................................................................................................5
5. ÍNDICE .............................................................................................................................6
I. INTRODUCCIÓN ..............................................................................................................7
II.ANTECEDENTES .............................................................................................................9
III. JUSTIFICACION ...........................................................................................................10
IV. OBJETIVOS..................................................................................................................11
V. ALCANCE ......................................................................................................................12
VI. ANÁLISIS DE RIESGOS...............................................................................................14
VII. FUNDAMENTACION TEÓRICA ..................................................................................16
VIII. PLAN DE ACTIVIDADES ............................................................................................18
IX. RECURSOS MATERIALES Y HUMANOS ....................................................................19
X. DESARROLLO DEL PROYECTO..................................................................................20
XI. RESULTADOS OBTENIDOS ........................................................................................29
XII. CONCLUSIONES Y RECOMENDACIONES ...............................................................30
XIII. ANEXOS
XIV. BIBLIOGRAFÍA
6
I. INTRODUCCIÓN.
Dentro de los procesos industriales o de cualquier otro ramo que actualmente son
implementados por empresas nacionales o extranjeras; existe la necesidad de
adquirir el control de todo el conjunto de elementos que desempeñan un papel
fundamental dentro del proceso de producción, con la finalidad de administrar y
optimizar el consumo de recursos necesarios inherentes al objetivo de la empresa.
Además se requiere mantener evidencia objetiva de las distintas metodologías que
se han implementado a lo largo del ciclo de vida empresarial y en concreto, el ciclo
de vida de determinado producto manufacturado en la misma.
Estos requerimientos facultan al personal involucrado de información veraz,
oportuna y objetiva sobre sus metodologías y muestran claramente el resultado de
cada una de ellas, pudiendo tener un eficiente flujo de información entre los
departamentos y/o procesos administrativos y los procesos de producción,
quienes finalmente son los productores de los bienes o productos.
El adecuado control de estos elementos, definen dos conceptos fundamentales en
la empresa: por un lado incrementan las posibilidades de modificar los procesos
de producción con base en los elementos que se reflejan en el historial de
metodologías implementadas y por otro lado, permiten la apertura de todo un
abanico de posibilidades concretas basadas en los aspectos ya definidos. Por otro
lado, no se puede omitir una de las necesidades frecuentes dentro del ramo
industrial. La vital importancia de contar con una serie de requerimientos que en
su conjunto son evaluados para ser proveedores certificados, de los bienes o
insumos que producen.
Estas certificaciones están fundamentadas en una serie de requerimientos que
muchas veces producen áreas de oportunidad para la mejora en aspectos
administrativos, con el fin de garantizar que el producto que ahí se desarrolla,
reúne los parámetros requeridos por determinada ISO.
Desde el momento en el que se adquiere un completo control sobre los elementos
informativos, se incrementa la claridad de la información de todo el personal
7
involucrado, de tal manera que aunque existan modificaciones a los lineamientos
establecidos para la producción, siempre se pueda tener la seguridad que existe
una eficaz sincronización entre lo que “se debería hacer” y lo que realmente se
hace en el nivel de producción.
8
II.
ANTECEDENTES
Novem Car Interior Design México, es una empresa alemana que abre sus líneas
de producción en esta ciudad de Querétaro, en el año 2012. Por lo que aún tiene
muchos procesos y lineamientos en estado de desarrollo constante.
Cada uno de ellos, ya organizados eficientemente mediante el establecimiento de
prioridades, en torno a la mejora constante del personal que ahí labora, con objeto
de alcanzar y medir los altos estándares solicitados por sus estrictos clientes, tales
como BMW, AUDI, GM. Para sus modelos automotrices de lujo. Uno de esos
procesos que tienen alta prioridad es el de alcanzar la certificación en la ISO/TS
16949:2009, por lo que actualmente se encuentra dentro de este contexto.
En el punto que se desarrolla este proyecto, es el elemento concerniente a la
necesidad de unificar los distintos procesos de producción mediante los elementos
que fungen como elemento dinámico entre los departamentos de calidad,
ingeniería, los process experts de cada proceso, y demás departamentos
administrativos involucrados, en el desarrollo del producto final.
9
III. JUSTIFICACIÓN.
Las certificaciones suelen traer innumerables beneficios, no solo económicos, sino
también para conjuntar los diversos aspectos que intervienen en el desarrollo de
un producto específico, mediante la estandarización de los procesos involucrados
en ello. Esto permite un alcance superior para efectos de control en los procesos,
mediante las auditorías establecidas en el tiempo que se dictamine por parte de
Novem Car. Sin embargo, uno de los grandes y principales motivos de No
Conformidades al momento de ser auditados para alcanzar alguna certificación; es
sin duda el control de la documentación para los procesos en producción. Por lo
que la implementación del software Alfresco constituye un respaldo robusto para el
control
de
esta
documentación,
incrementando
considerablemente
posibilidades de adquirir la certificación y estandarizar los procesos.
10
las
IV. OBJETIVOS.
 Obtener la certificación ISO TS 16949.
 Reducir las No Conformidades durante las auditorías por parte de terceros,
al Departamento de Calidad.
 Estandarizar la documentación en los procesos de producción mediante el
uso de plantillas para generar documentos nuevos o actualizaciones de los
mismos.
 Garantizar la confiabilidad del sistema con la adecuada implementación del
servicio HTTP y HTTPS, en un servidor dentro de la intranet corporativa.
 Garantizar documentos únicos e irrepetibles mediante el control de
versiones establecido por la configuración avanzada de la aplicación.
 Reducir el tiempo invertido en el Control de Documentos, mediante la
implementación de una interfaz gráfica de usuario, sencilla e intuitiva.
 Delimitar las responsabilidades entre el Departamento de Calidad y los
expertos de proceso como consecuencia de mantener un registro objetivo
de los pormenores durante la evaluación de documentos candidatos a ser
Controlados por el Sistema.
 Garantizar el control del archivo histórico de versiones para consultar y
restaurar esas mismas versiones obsoletas en cualquier momento que sea
requerido.
 Coadyuvar a incrementar los altos estándares de calidad requeridos por el
cliente.
11
V. ALCANCE.
El marco de alcance se delimita desde el punto inicial, basado en el Control de
Documentos anterior; implementado mediante hojas de cálculo en Excel y su
combinación con las características de Microsoft Sharepoint, en específico con la
capacidad de poder abrir documentos en modo de Solo Lectura por aquellos
usuarios que no sean Administradores del Sistema de Gestión de Calidad de
Novem Car. Dentro de este concepto se toman los aspectos básicos ya descritos
para delimitar una área de responsabilidad aplicada directamente a la
funcionalidad del Software que se implementa dentro de la empresa.
Además todas las características de flujos de trabajo adquieren mucha mayor
fuerza, desde el momento de que el sistema implementado sustituye los
numerosos correos electrónicos, los cuales eran la base primordial para la
comunicación entre los Expertos de Proceso y el Personal del Departamento de
Calidad.
Asimismo la estructura primaria ha sido rediseñada para proveer todo un conjunto
de datos organizados minuciosamente, tomando en cuenta ambos extremos de
este flujo de trabajo: Departamento de Calidad y Usuarios de Procesos;
garantizando que los documentos previamente desarrollados y aprobados por el
Coordinador del Sistema de Gestión de Calidad, sean exactamente los mismos
que se implementaron en el software, y además contengan los nuevos diseños
que a raíz de este proyecto, se ha tomado la decisión de estandarizarlos,
mediante el uso de plantillas completamente actualizadas en estricto apego a los
requerimientos de los manuales y guías procedentes de Novem Car Alemania.
Todo lo anterior, aplicando las políticas de privacidad para cada uno de los
Procesos involucrados en la documentación para la fabricación del Producto Final,
mediante la creación de Cuentas de Usuario debidamente validadas para proveer
de seguridad dentro de la aplicación que se ejecuta en la intranet corporativa de
Novem Car México.
12
Asimismo, con el fin de disminuir los tiempos de aprobación, se contempla la
creación de reglas específicas para cada una de las localizaciones de los
documentos, tales como la creación de firmas gestionadas por Certificados de
Autoridad perfectamente adaptados a las necesidades de Novem Car y con su
periodo de caducidad y renovación.
Sin dejar de mencionar la conversión automática de formatos de Microsoft Office a
documentos con formato PDF, y con el objeto de garantizar la autenticidad del
documento, se insertan marcas de agua, y un código cifrado mediante el algoritmo
SHA-256, mismo que puede ser consultado por el personal del Departamento,
desde el Gerente, hasta los Auditores de Calidad, con el fin de estar en
condiciones confiables de poder determinar la posible falsificación y/o alteración
de los datos que ya se habían validado.
Este mismo código cifrado, provee de identificadores únicos para cada
documento, sin importar si se mantiene el mismo nombre durante la transición de
las versiones que se generen durante el periodo de validez del documento.
Se provee además de una base sólida para garantizar la fiabilidad del sistema y
acciones automatizadas para la creación de copias de respaldo en frío; de todos
los documentos existentes en el Sistema de Gestión de Calidad y su base de
datos, garantizando que, en caso de desastre, se restauren cualquiera de las
versiones anteriores de Documentos existentes en el momento de hacer el
backup. Finalizando en la entrega del documento debidamente validado y en
formato PDF al personal responsable, quedando evidencia totalmente objetiva de
esta condición. El proyecto finaliza con el Sistema Alfresco debidamente instalado,
configurado y con los documentos almacenados en él; asimismo con la entrega
del manual de usuario para administración del sistema y manual de usuario
estándar.
13
VI. ANÁLISIS DE RIESGOS.
 El cambio de formatos durante la migración de los documentos hacia el
software.
o Se deberán requerir los nuevos formatos y transformar los
documentos al nuevo formato.
 Incompatibilidad con navegadores web con los certificados personalizados
generados para la comunicación.
o Solicitar al IT Manager, la actualización de Internet Explorer 9.0 a la
versión más reciente.
 Duplicidad de los documentos existentes antes de la implementación.
o Filtrar y detectar los documentos duplicados, comenzando de
manera ascendente de acuerdo al Mapa de Procesos.
 Que el usuario no esté familiarizado con el uso de navegadores web y su
contenido.
o Capacitación en el uso de navegadores web.
o Capacitación en el uso de sesiones de usuario.
 Múltiples capacitaciones en aspectos elementales del uso y medidas de
seguridad con aplicaciones web.
o Realizar evaluaciones al personal capacitado, para detectar áreas de
oportunidad, eficientando el temario de capacitación.
14
 Que existan modificaciones a las versiones ya aprobadas por el
Departamento de Calidad.
o Limitar y registrar los documentos que sean actualizados durante la
migración.
 Que los documentos de algún proyecto específico fallen a raíz de cortes de
electricidad, fallos de funcionabilidad en la aplicación, fallos en la seguridad
de la aplicación.
o Gestionar la adquisición de elementos tales como No-Break para el
soporte del sistema con cortes de energía.
o Gestionar
el
uso
de
medios
de
almacenamiento del respaldo del sistema.
15
soporte
externos
para
VII.
FUNDAMENTACIÓN TEÓRICA.
El OpenSource beneficia la colaboración en el desarrollo de Software, haciendo
que las aplicaciones sean de óptima calidad. Se demuestra que el modelo de
distribución de Software es sustentable, sin forzar el cobro del desarrollo. Es
posible trabajar en una empresa con aplicaciones OpenSource. Las pequeñas y
medianas empresas al utilizar estas herramientas, evitan la piratería de software.
La posibilidad de poder mejorar las aplicaciones sin depender del fabricante está
haciendo que los gobiernos de algunas naciones desarrolladas, y en vías de
desarrollo apoyen el OpenSource. La licencia de código abierto permite
explícitamente: utilizar el programa para cualquier propósito y sin limitaciones,
estudiar cómo funciona, redistribuir copias del programa (no se paga por la
licencia) y/o Modificarlo. Tomando como referencia estos estatutos declarados en
la por OpenSource, se han tomado extensiones de una aplicación existente en el
mercado bajo el nombre de Alfresco Community Edition; la cual se encuentra
desarrollada en Java Enterprise Edition; con Spring Framework, quien se encarga
de implementar el patrón de diseño Modelo Vista Controlador (MVS).
Las aplicaciones desarrolladas en Java Enterprise Edition, poseen una
arquitectura multicapa, mismas que tienen el objetivo de delimitar las funciones de
cada una de ellas, contemplando aspectos de escalabilidad con el fin de estar en
facultad de poder realizar modificaciones al sistema desarrollado, directamente
sobre una sola capa, sin necesidad de alterar la estructura original del resto de la
aplicación.
Al menos se deben manejar tres capas, la capa DAO (Data Access Object), la
capa de Negocio y la capa de Presentación. Los accesos a la base de datos de la
aplicación, se han manejado sobre el paradigma de Aplicaciones Orientadas a
Aspectos, con ayuda del framework Hibernate, mismo que implementa las
características de la API de persistencia de Java, mediante una variante del
lenguaje tradicional SQL; llamado JPQL (Java Persistence Query Language).
16
El cual funciona mediante el uso de Mapeo por medio de anotaciones y ficheros
XML dentro de las clases de la capa DAO (Data Access Object), con la
implementación de estas anotaciones pertenecientes a la API de Java EE, dentro
de una clase, se obtienen clases de tipo Entity, las cuales, necesitan tener
atributos encapsulados y métodos simples que no implementen ninguna otra
interfaz más que la Serializable, la cual permite la serialización (conversión a
binarios) de los datos para poder ser transmitidos mediante la red. A las clases
que tienen los atributos descritos anteriormente se les conoce como clases POJO
(Plain Old Java Object). Estas clases permiten ser mapeadas mediante una
Unidad de Persistencia descrito en un archivo XML dentro de la estructura de un
proyecto tradicional Java EE. Esta unidad de persistencia, posee atributos
mediante tags, los cuales describen los datos almacenados dentro del contenedor
de aplicaciones, en este caso Apache Tomcat, que se utilizarán para gestionar la
conexión a bases de datos. Las aplicaciones Enterprise Edition incorporan
características basadas en CORBA (Common Object Request Broker Architecture)
para poder trabajar con diferentes lenguajes de programación, por lo que la
intercomunicación del sistema, no está limitado hacia aplicaciones Java, y además
se pueden realizar aplicaciones ejecutándose en Granjas de Servidores, mediante
el uso adecuado de CORBA.
Otra de las ventajas que se han aprovechado, es la extensión de Java EE para
desarrollar Web Services SOAP y RestFul, en el caso concreto de esta aplicación
se ha utilizado REST (Representational Estate Transfer Protocol) por las
características de diseño de la API de Alfresco, que ya expone estos SOAP-WS
para
implementar
módulos
de
aplicaciones
mediante
el
uso
de
AMP
(Alfresco Module Package), mismas que incluyen archivos XML que describen las
funcionabilidades del módulo desarrollado y que permiten tomar los web services
ya implementados con Alfresco para obtener los datos necesarios de las capas
más profundas de la aplicación, en el caso de la capa DAO, quien es la encargada
de accesar a la base de datos para realizar operaciones de persistencia y/o
recuperación de objetos persistentes.
17
VIII PLAN DE ACTIVIDADES
Plan de actividades diseñado con el objetivo de conocer los requerimientos de la empresa, conocer que es exactamente
un documento y adquirir el conocimiento para implementar la aplicación y los módulos que sean requeridos.
18
IX RECURSOS MATERIALES Y HUMANOS
Para el desarrollo y la instalación del servidor en la intranet de Novem se requiere:
Hardware:
Computadora con 8 GB de RAM,
Disco Duro de 500 GB
Procesador Intel Core I5 a 3.2 Ghz
Software:
Se requiere de un JDK 1.6 o superior.
Entorno de desarrollo integrado Eclipse con soporte de JavaEE 6.
API de Alfresco.
Microsoft Office.
Contenedor de aplicaciones Catalina Tomcat 7.3
SGBD PostgreSQL.
Código Fuente de Alfresco.
Plugins Eclipse (Log4J; Hibernate, SpringFramework).
Recursos Humanos:
Auditoras de Calidad
Personal relacionado con documentación.
Coordinador de auditorías.
Gerente de Calidad.
Desarrollador de Software.
19
X. DESARROLLO DEL PROYECTO.
CAPA DAO (Data Access Object).
Mapeo de Clases Entidad y sus funciones derivadas.
Durante las entrevistas al personal involucrado con la elaboración de
documentación controlada por el Departamento de Calidad, se observó en los
resultados que muchas personas desconocen el cambio de versiones entre los
formatos que dan origen a un documento bajo su responsabilidad; por lo que la
aplicación ha tomado como base esta necesidad de mantener la sincronización de
todas estas modificaciones mediante notificaciones en cada uno de los
componentes del lado de la capa de presentación del Software que se
implementa. De esta manera, todo aquél usuario debidamente autenticado, se
encontrará con una serie de elementos que le proporcionan información oportuna
para sus intereses. Esto se realiza desde el inicio de la sesión por parte del
usuario en el sistema. Una vez que haga una autenticación exitosa, el sistema
realizará una consulta al SGBD PostgreSQL, para determinar el tipo de usuario
que está ingresando y su rol específico dentro del sistema; con base en ello, todos
los roles están debidamente asociados a una serie de aspectos, mismos que se
determinan mediante mensajes y el uso de Interceptores entre objetos todos los
acontecimientos que se
han realizado;
tomando
como
parte
de esos
acontecimientos, la fecha, hora y usuario que desencadena esta acción
disparadora en el sistema. Siendo ingresados mediante la asociación entre los
aspectos y el rol del usuario, a la base de datos; misma que posee sus clases
entidad para la asociación entre las tablas de la BDD y las instancias de la clase
entidad que de ella se deriven. Una vez realizada esta consulta, se procede a
enviar los datos resultantes a la capa de negocio, misma que determinará todas
aquellas instancias asociadas entre la vista y la capa DAO, para que esos datos
sean transferidos a la capa de presentación, para dar lugar al correcto
direccionamiento de los datos en el lugar apropiado.
20
El mapeo de las clases Entidad y las Tablas de la Base de datos, se realiza como
se indica a continuación.
El mapeo de Clases Entity con la BDD mediante anotaciones.
La API de Java EE 6, nos provee de una serie de anotaciones que están
diseñadas para que el mapeo entre dos elementos sea bastante sencilla y a su
vez flexible y robusta para que el contenedor de aplicaciones determine
exactamente cuál es la función de cada instancia de la clase y sus acciones
adecuadas, en relación con la asociación de la base de datos y su interacción con
las otras tablas; todo de acuerdo al diseño ya previsto para ello. Por lo tanto,
tomando como principio la interacción de instancias de clases con otros objetos de
distintas clases, misma que produce un resultado, se puede afirmar que las
instancias de una clase entidad, interactúan con otras clases entidad; entonces,
las tablas de la base de datos, interactúan las unas con las otras en función de las
cardinalidades que se hayan implementado durante su construcción.
Componentes en el mapeo de Clases y Tablas de la BDD.
Las clases POJO deben ser totalmente independientes de otras interfaces, debido
a que las interfaces como tal, no siempre pueden ser transferidas mediante la red;
ya que su funcionamiento depende totalmente de la clase que implementa sus
funciones y ellas pueden depender de otras clases o interfaces. Esto dejaría a una
interfaz determinada, totalmente inservible, debido a la ausencia de componentes
esenciales para su funcionamiento y que no pudieron ser transferidos. Por lo que
necesariamente deben ser totalmente autónomas e independientes. La única
interfaz que debe ser implementada fortuitamente es la interfaz Serializable,
misma que permite la adecuada codificación de la clase que la implementa, para
ser transferida mediante la red, y pueda ser decodificada adecuadamente en el
sitio destino, es lo que se conoce como serialización.
21
Sin esta interfaz, la transferencia de estos datos resultaría inservible al no poder
ser serializada para su transferencia y posterior interpretación.
Las Tablas de la base de datos, corresponden a una arquitectura totalmente
ordinaria: Tablas con atributos e identificadores de cada una de las tuplas
(conjunto de datos u objetos) que almacenan los registros en ella referenciados.
Aunque como se sabe, las buenas prácticas en el diseño de un esquema de base
de datos, es fundamental para el correcto funcionamiento del sistema, debido a
que están completamente asociadas a las clases Entidad de la aplicación JavaEE.
La conjunción de los dos elementos descritos anteriormente, se hace posible
gracias a un tercer elemento fundamental: La Unidad de Persistencia de Java;
misma que se encuentra ubicada dentro de la arquitectura del proyecto JavaEE y
que no es otra cosa más que un fichero decorado con tags correspondientes a un
XML, esto aplica el mismo criterio y reglas que en el código HTML: Un tag puede
contener uno o más tags dentro de su interior, a quienes determina como un
atributo del elemento que está siendo señalado por medio de ese archivo XML.
Por lo tanto como parte de la estructura de la unidad de persistencia, se tienen los
siguientes elementos básicos: Versión del fichero XML, Atributos de la unidad de
persistencia, proveedor del mapeo entre clases y Tablas, mismo que se conoce
como ORM (Object Relational Mapping) y que establece el mapeo entre los
elementos referenciados para facultar el uso de JPQL (Java Persistence Query
Language), que es una derivación del SQL ordinario, añadiéndole el enfoque de
Consultas Orientadas a Objetos. El nombre de la unidad de persistencia, tipo de
transacción (local o por JNDI), Clases mapeadas, y las propiedades del JNDI
(recomendado) o directamente los datos de conexión a la base de datos (No
recomendado). JNDI (Java Naming Directory Interface) es el acrónimo que hace
referencia a una instancia de un componente del contenendor de aplicaciones que
se utiliza (es el mismo que da soporte al protocolo HTTP) y que contiene citada la
instancia. Por lo que dentro de este tag se hace referencia a la instancia existente
dentro del contenedor de aplicaciones; misma que puede ser creada mediante la
consola de administración del contenedor de aplicaciones Java.
22
Es altamente recomendado el uso de un JNDI por la confidencialidad de los
elementos clave para el acceso a la base de datos, tales como la URL, el nombre
del usuario y la contraseña. De esta manera, se mantiene esa confidencialidad a
todos los desarrolladores involucrados en el desarrollo del proyecto, sin revelar
estos datos altamente sensibles. Como se puede apreciar, mediante esta unidad
de persistencia, se establece la asociación de las clases referenciadas dentro de
los tags y las tablas a las que se conecta el proveedor de mapeo (ORM) con los
datos utilizados por los atributos del tipo de transacción que se esté empleando.
Patrones de diseño utilizados.
El patrón de diseño que se implementa para la transferencia entre las tres capas
(DAO, Negocio y Presentación) que conforman la aplicación, es DTO (Data
Transfer Object), que en realidad es una copia exacta de las clases y los atributos
de cada una de las clases Entity, dentro de la capa de transferencia destino; esto
es con la finalidad de que determinadas clases, puedan transferir mediante
retornos de métodos, aquellos objetos que deseen ser transferidos. Sin este
patrón de diseño, los datos de la capa DAO, no podrían ser transportados a la
capa de Negocio, ya que las clases Entity, corresponden a un proyecto ajeno a la
aplicación alojada en el lado del servidor. Por otro lado, cada una de las clases
Entity está relacionada a una unidad de persistencia que las controla; para ello se
implementa el patrón de diseño Facade que proporciona una única interfaz
principal, misma que determina la conexión con la unidad de persistencia y de esta
“fachada” implementa clases abstractas que pueden regresar determinadas
consultas a la base de datos, mediante el lenguaje JPQL, que utiliza la sintaxis de
objetos, esto es, se obtiene una instancia de una clase entity (previamente
relacionada con la tabla de base de datos y esta instancia puede hacer uso de
métodos relacionados con las operaciones CRUD de las bases de datos.
23
Estos métodos de consulta, son implementados mediante una clase abstracta que
es la raíz dentro de la escala jerárquica de las clases Entidad, y el resto de clases
heredan esos métodos para cada una de las tablas a las que se encuentren
asociadas mediante el mapeo ya descrito. Este patrón de diseño está diseñado
para evitar las múltiples instancias de la clase Abstracta, para cada una de las
clases Entidad que de ella dependen.
Es importante mencionar que esta clase abstracta (fachada), contiene una
anotación hacia el nombre de la unidad de persistencia que se encuentra
referenciado en el archivo “persistence.xml”. De ahí que una vez obteniendo una
instancia de alguna de las clases que heredan de la clase abstracta, se pueda
establecer la conexión a la base de datos, sin necesidad de hacer múltiples
llamadas a la Unidad de Persistencia creada anteriormente.
Capa de Negocio
La capa de negocio proporciona todas las reglas que entren en juego dentro del
límite del usuario autenticado. Esta capa de Negocio es alimentada por datos
provenientes de los métodos getters de las clases Entity, mismas que están
contenidas dentro de la capa DAO. El patrón de diseño que se utiliza para estos
elementos, como ya se mencionó es el DTO.
La capa de negocio delimita los límites de acuerdo al rol definido en users.xml del
contenedor de aplicaciones Catalina Tomcat. Estos roles están definiendo el
alcance que posee un usuario dentro del acceso a la base de datos y a la
aplicación, además este mismo fichero posee el depósito de claves de acceso
completamente cifradas, para obtener un certificado de seguridad emitido por la
empresa que posee el sistema implementado. Esto con la finalidad de garantizar
las conexiones cifradas dentro de la intranet corporativa, mediante el uso del
protocolo HTTPS y SSL.
24
Lo anteriormente descrito, corresponde al primer filtro para definir el rol de los
usuarios dentro del sistema, el siguiente filtro en el que se sustenta la capa de
negocio, proviene directamente de la base de datos, donde se encuentran
establecidas las asociaciones entre cada uno de los usuarios del sistema y su rol
desempeñado en cada uno de los espacios que sean creados en el Sitio Web
Alfresco. De esta asociación entre la tabla de usuarios, y los roles del sistema,
surge la base para la definición de las acciones correspondientes; las limitantes
que sean establecidas, son totalmente adaptables; esto es, cada uno de los sitios
deben ser totalmente modificables de acuerdo al rol que se requiera; en
conclusión: un sitio puede tener un rol predeterminado; sin embargo al momento
de añadir un grupo de usuarios Colaboradores, puede establecerse un nuevo rol,
sobrescribiendo al inicial; por ejemplo ese grupo de Colaboradores, podrá ser
añadido como Administrador de ese sitio específico.
Las reglas de negocio, están basadas fundamentalmente en el rol ya descrito, por
lo que las acciones sobre cada uno de los documentos, están perfectamente
limitadas a lo establecido por el administrador del sistema. Sea cual fuere el grupo
al que se pertenezca, la aplicación está diseñada para crear flujos de trabajo en
distintas formas, tales como Aprobación de un Documento, Revisión en Conjunto,
Asignación de una tarea específica a uno o muchos usuarios y administrar los
recursos que son empleados para esa actividad.
Los roles.
Las representaciones que en el sistema mantienen un marco de acción están
sustentadas en la acción y delimitación efectiva de los roles de usuario. Esto es
con el objetivo de presentar una interfaz gráfica de usuario, totalmente adecuada a
cada uno de estos papeles específicos. Por lo que esta definición puede ser
asociada a un conjunto de usuarios, que delimitan las acciones. Los roles que
contiene el sistema por default, son los siguientes:
25

Administradores de Aplicación
Está destinado a todos aquellos usuarios que tengan acceso a la
administración de la aplicación, a la base de datos del sistema, capacidad
de crear y eliminar sitios, documentos, elaborar estructuras de directorios,
crear,
suspender
y
eliminar
cuentas
de
usuario
del
sistema,
configuraciones de correo electrónico, etc. La definición de este rol está
enteramente ligada al grupo Alfresco_Administrators y la de EMAILCONTRIBUTORS, este es el grupo root.

Administradores de Sitio.
Está diseñado para todos aquellos usuarios del sistema, que poseen
capacidad de enviar invitaciones a otros usuarios, para unirse a los sitios
que ellos administran. Este tipo de usuarios no tienen acceso a eliminación
de documentos, sin embargo pueden agregar al nodo de un documento,
versiones posteriores al documento. Tampoco pueden eliminar cuentas de
usuario, aunque pueden expulsar a algún elemento del sitio al que
administran.

Colaboradores
Poseen los derechos de modificar nuevas versiones del documento,
dejando por un lado todos aquellos derechos anteriormente descritos.
Pueden delegar actividades a terceros e incluso están autorizados a crear
tareas en conjunto y reportar avances en los proyectos designados a todos
los usuarios que les deleguen actividades específicas mediante el sistema.

Contribuidores.
Es el personal que tiene derecho a modificar directamente todos los
aspectos de documentación, sin embargo tienen la limitante de que no
pueden designar tareas a otras personas, aunque pueden reportar las
tareas que les fueron asignadas por los roles superiores a estas cuentas.
26

Consumidores
Son todos aquellos usuarios finales del sistema, que únicamente pueden
descargar documentos, recibir flujos de trabajo y reportarlos sin hacer
cambios dentro de la estructura general de la administración del proyecto.
No están autorizados a realizar cambios de documentación, sin embargo
pueden iniciar flujos de trabajo para enviar a revisión y posible posterior
aprobación todos los documentos que sean elaborados por ellos.
Enterprise Java Beans.
Los EJB son objetos característicos de las aplicaciones Enterprise. Estos objetos
son similares a cualquier otra instancia de clases, sin embargo poseen una
arquitectura que les define la funcionabilidad orientada a aplicaciones Cliente –
Servidor, por lo que sus instancias no son iguales a las de una clase ordinaria,
sino que se inyectan mediante el uso de anotaciones características de Java
@EJB. Estos Enterprise Java Beans poseen ciclos de vida distintos de acuerdo al
diseño de la aplicación. Esto es, mientras el recolector de basura de Java SE
adquiere el control sobre un objeto y decide cuando eliminarlo, en los EJB’s
pueden ser administrados directamente por el contenedor de aplicaciones. Esto
permite objetos persistentes aún en memoria, por ejemplo a lo largo de una sesión
de usuario. Los Enterprise Java Beans mantienen la información que está
relacionada con ellos y son los responsables de guardar los datos que son
enviados a través de las diversas capas de la aplicación Java. Sus ciclos de vida
son los siguientes: EJB’s de sesión, EJB’s de Aplicación y EJB’s Singleton. Estos
últimos se utilizan para datos que son accesados concurrentemente durante la
sesión de un usuario. Es importante mencionar que los EJB’s no son instanciados
como tal, sino que se hace mediante la inyección en tiempo real de la aplicación,
por lo que el consumo de recursos de la aplicación disminuye considerablemente.
27
Los EJB’s pueden hacer uso de interceptores, mismos que “interceptan” algún
evento que inicia con una acción disparadora y pueden también efectuar acciones
bajo distintos argumentos, tales como la invocación de métodos que a su vez,
desencadenan la inyección de otros EJB’s, mismos que seguirán siendo
persistentes, mientras el EJB que los invocó, mantenga su estado conversacional
con el contenedor de aplicaciones. A esto se le conoce como CDI, (Context and
Dependency Injection) por lo que este ciclo de vida está regido directamente con
el contexto que le haya invocado.
Capa de Presentación
La capa de presentación está desarrollada en Java Server Pages, misma que
mantienen la arquitectura jerárquica, esto es: se pueden desarrollar plantillas y las
vistas que “heredan” de la principal, pueden implementar fragmentos de código
JSP dentro de su contenido, mediante el uso de la sintaxis de JSP indicando el
sitio en el que deberá incorporarse el fragmento de código almacenado en la
plantilla. A diferencia del código HTML, JSP provee de una serie de anotaciones,
mismas que pueden hacer referencia hacia componentes nativos dentro de la API
de JavaEE 6. Todos los valores y datos que sean introducidos en los
contenedores de la vista, están asociados directamente a la capa de negocio, con
una comunicación bidireccional, mediante el uso de Managed Beans. Estos son
objetos efímeros que establecen un puente de comunicación con los EJB a los
que se encuentran asociados dentro del método del Managed Bean. Por lo tanto,
toda la información que se procesa desde la interaz gráfica de usuario hasta la
capa de negocio, es gracias a la acción de los Managed Beans.
28
XI. RESULTADOS OBTENIDOS.
Se consiguió la implementación del Sistema de Administración de Contenidos
Alfresco, dando como resultado los siguientes puntos:

Estandarización de la documentación en los procesos de producción
mediante el uso de plantillas para generar documentos nuevos o
actualizaciones de los mismos.

Se garantizan documentos únicos e irrepetibles mediante el control
de versiones dentro del Sistema Gestor de Contenidos.

Se disminuyó el tiempo invertido en el Control de Documentos,
mediante la implementación de una interfaz gráfica de usuario,
sencilla e intuitiva y además de la conversión a PDF con códigos QE
conteniendo la URL del documento origen.

Se delimitaron las responsabilidades entre el Departamento de
Calidad y los expertos de proceso como consecuencia de mantener
un registro objetivo de los pormenores durante la evaluación de
documentos candidatos a ser Controlados por el Sistema, al hacer
uso de los foros y wikis proporcionadas por el Sistema Gestor de
Contenidos.

Se garantiza el control y disponibilidad del archivo histórico de
versiones para consultar y restaurar esas mismas versiones
obsoletas en cualquier momento que sea requerido.

Se incrementaron los altos estándares de calidad requeridos por el
cliente, reflejados en los resultados de la auditoría hecha por General
Motors.
29
XII. CONCLUSIONES Y RECOMENDACIONES
Las aplicaciones web, proveen de diversas características que cubren los
requerimientos por parte del cliente; sin embargo uno de los factores
preponderantes en esta dualidad, corresponde enteramente a la experiencia por
parte del desarrollador de software y más aún cuando el recurso humano está
limitado únicamente al desarrollador.
Por lo que suele ser motivo de que no se cumplan los tiempos previstos en el
desarrollo del proyecto. La recomendación que se hace es evaluar la factibilidad
del proyecto con base en la investigación de mercado, para saber si existe alguna
herramienta ya creada con anterioridad, y esto para presentar un análisis de la
relación costo-beneficio al cliente.
Determinadas actividades suponen una serie de actividades dentro del desarrollo,
y
durante
el
mismo
surgen
diversas
circunstancias
que
pueden
ser
contraproducentes para los tiempos establecidos. Esto es un motivo muy digno de
detenerse unos momentos y preguntarse ¿Es realmente factible el desarrollo de
este proyecto? ¿Tengo que buscar una alternativa ya existente en el mercado?
En su defecto, negociar los tiempos de entrega, de tal manera que se contemplen
los inconvenientes que se puedan presentar durante el desarrollo del proyecto.
En el caso concreto del proyecto, se han cubierto los objetivos que se propusieron
al inicio del proyecto. Aunque el software soporta la instalación sobre arreglos de
discos RAID, se recomienda que los índices del motor de búsquedas, sean
manejados directamente desde el contenedor de documentos para obtener un
mejor performance en las funcionabilidades del motor.
Asimismo los requerimientos de la empresa avanzan a pasos agigantados; por lo
que se recomienda ampliamente mantener la visión de que el software necesita
crecer junto con la empresa, de tal manera que muchos de los procesos que son
aún necesarios los recursos humanos, puedan ser automatizados mediante
mejoras constantes en los módulos AMP.
30
Esto me lleva a sugerir a las futuras generaciones que evidentemente el software
es, de alguna manera un ser “vivo” el cual requiere que se le moldee y se le den
los cuidados necesarios durante la concepción del mismo, de tal manera que
nunca se pierda de vista el objetivo fundamental de la aplicación.
31
XIII. ANEXOS
Tabla: Breve tabla comparativa de servidores Web del mercado.
Servidor
Disponibilidad
Precio
Apache
Unix/Linux, Windows
Libre.
95/98/NT/2000/XP/Vista/7/8
Bea Weblogic
Windows NT, Sun Solaris, HP- Comercial, desde
UX, IBM AIX, Linux, OS/400,
2.000.000 pts.
Compaq Tru64 Unix, SGI IRIX Aproximadamente.
y Siemens Reliant Unix
Enhydra
Windows NT/2000, Unix/Linux Libre.
Jigsaw
Unix/Linux, Windows
Libre.
95/98/Millenium y NT/2000
Coldfusion
Windows 95/98/NT/2000,
Comercial, desde
Linux, Solaris y HP-UX
260.000 pesos.
aproximadamente.
IIS
Windows
Comercial, desde 20.000
NT/2000/XP/Vista/7/8
pesos aproximadamente.
NCSA HTTPd
Unix/Linux, Windows 3.x,NT
Libre.
iPlanet
HPUX, Solaris, IBM AIX,
Comercial, desde
Compaq Tru64 Unix, SGI
300.000 pesos
IRIX, Windows NT/2000
aproximadamente.
Unix/Linux
Comercial, desde
Zeus
340.000 pesos
aproximadamente.
32

1
Cuadro comparativo de las ventajas de Java frente a PHP.
Característica comparada
Tipos de Datos
PHP
boolean, integer, float, string,
array, object
2
Java
boolean, char, byte, short, int,
long, float, double, String, array,
Object
Ganador:
Java al soportar mayor cantidad
de tipos de datos.
1
Característica comparada
Nombres de las variables
PHP
Las variables son representadas
por una muestra del dólar seguida
por el nombre de la variable.
2
Java
El nombre variable es sensible a
mayúsculas.
Ganador:
Java al ser más práctico el que
no haya carácter especial para
comenzar
el
nombre
El nombre variable
mayúsculas,
posibilidades
variables.
33
variable.
es sensible a
ampliando
de
las
nombrar
1
Característica comparada
Declaración de las variables
PHP
Se declara la variable cuando se
crea. Su tipo se implica del valor
asignado. Una variable
puede
cambiar su tipo si se asigna un
nuevo valor.
2
Java
Es conveniente que un programa
pequeño
no
requiera
declaraciones
variables globales,
pero para
software grande,
esto es
el
contraproducente. Las
variables que cambian sus
tipos
basados
muy
en su
peligrosas
valor son
en
programas
grandes.
1
Característica comparada
Variables globales
PHP
PHP tiene una gran cantidad de
variables predefinidas.
2
Java
Java no tiene variables globales.
Java.
Las
variables
globales
introducen bugs. posibles en
software grande.
34
Característica comparada
Una variable que contiene el
nombre de otra variable
1
PHP
Soportado
2
Java
No soportado
Ganador
PHP
Característica comparada
Uso de bibliotecas externas
1
PHP
PHP
incluye
bibliotecas.
Bibliotecas de la importación de
Java
2
Java
Java.
Incluyendo
bibliotecas
puede
introducir
ediciones
variables
del
paquetes se
alcance. Los
estructuran mejor
que bibliotecas incluidas
Ganador
Java
35
XIV. BIBLIOGRAFÍA
Manuales e Instrucciones de trabajo.
Instrucción de Trabajo de la empresa Novem Car Interior Design México
(Impreso).
Manual de Gestión de Documentos Novem Car Interior Design México Rev 01
2012 (Electrónico).
Ayudas Visuales de la empresa (Electrónico).
Referencias de Internet.
Eric Jendrock, Ricardo Cervera-Navarro, Ian Evans, Devika Gollapudi, Kim
Haase, William Markito, Chinmayee Srivathsa, (4 de Julio de 2013), The Java
EE
6
Tutorial.
Informática.
Disponible
en:
http://docs.oracle.com/javaee/6/tutorial/doc/
Ubaldo Acosta (20 Junio 2010) Global Mentoring, Disponible en:
http://globalmentoring.com.mx/curso-javaee/
Comunidad open source Alfresco (30 julio 2013), Foros Alfresco, disponible en:
http://forums.alfresco.com/es
Ernesto Castillo (1º agosto 2013) OpenSource Las ventajas y alcances de un
sistema que comparte el conocimiento, disponible en:
http://www.emb.cl/gerencia/articulo.mvc?xid=98
36
Alejandro Mellado García (3 de agosto 2013) Opensource, alternativas para la
Empresa,
disponible
en:
http://www.inf.uct.cl/~amellado/archivos/pre_os_empresa.pdf
Microsoft Corporation (15 de mayo 2013) ¿Qué es sharepoint? Disponible en:
http://office.microsoft.com/es-mx/sharepoint-server-help/que-es-sharepointHA010378184.aspx
Anabell
Comas
(25
junio
2013)
Java
o
PHP
http://www.revista.unam.mx/vol.7/num12/art104/dic_art104.pdf
37
disponible
en: