Proceso de Implementación
Para ejecutar el presente proyecto se definió un proceso general de desarrollo que actuó como marco de referencia y guía de todas las actividades y producciones resultantes del presente proyecto.
El proceso describe como se divide el proyecto, cuales son las distintas responsabilidades y que actividades desarrolla cada una de estas responsabilidades, como así también el conjunto de artefactos de resultado del mismo.
Para un detalle completo ver: Anexo B – Proceso General de Implementación
E
NTALLAMIENTO DEL PROCESO DE IMPLEMENTACIÓNEl proceso general de implementación describe en forma general el proceso para implementar cualquier tipo de proyecto de tecnología. Pero el mismo debe ser adecuado a las realidades de cada proyecto. Por ello en esta sección se detallan las particularidades del proceso empleado en el presente proyecto.
El presente entallamiento tiene dos particularidades centrales, la primera es que se enmarca dentro de un trabajo de tesis de licenciatura y por lo tanto uno de los principales artefactos a producir es el trabajo de investigación en si. El cual se encuentra en el Capitulo 2 – Fundamentación Teórica la segunda particularidad es el aspecto solitario de implementación del presente proyecto, provocando esto que se haya tomado la decisión de utilizar metodologías, que si bien respetan al PGI, se adaptan mejor a este tipo de situación.
M
ETODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOComo se mencionó, para agilizar la gestión del proyecto, se ha decidido realizar la misma bajo la consigna de las metodologías Agile. Donde para garantizar su correcto uso se ha utilizado la herramienta XPlanner que se ha adaptado perfectamente a la tipología descripta, utilizando en particular la metodología eXtreme Programming (XP).
A continuación se describe brevemente (según Wikipedia) en que consiste dicho paradigma:
La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es la más destacada de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.
Las características fundamentales del método son:
✔ Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
✔ Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un
mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
✔ Frecuente interacción del equipo de programación con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo de desarrollo.
✔ Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
✔ Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
✔ Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en
grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
✔ Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá
añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.
Cronograma Original del Proyecto
El proyecto original se había planteado en 8 iteraciones, ejecutando un total de 576 horas en 128 días.
T
AREAST
RANSVERSALES(A
DMINISTRACIÓN)
T
AREASV
ERTICALES(D
ESARROLLO)
Plan de infraestructura y Configuraciones
I
NTRODUCCIÓNEl presente documento tiene por objetivo describir la infraestructura (equipos informáticos, software y comunicaciones) requerida para el proceso de desarrollo e implementación de producto Switch Transaccional que será desarrollado dentro del marco de la Tesis de Licenciatura en informática de la Universidad de la Patagonia San Juan Bosco.
El presente documento establece el detalle de herramientas de desarrollo como todo el software necesario y requerido para la puesta en marcha del presente trabajo de tesis.
A
RQUITECTURALa Arquitectura del Switch Transaccional prevé como primer medida el ruteo y sincronización de servicios entre organizaciones y entidades, de esta forma el intercambio de servicios y mensajes queda concentrado y estandarizado en el Switch Transaccional.
Como se puede observar la arquitectura del portal está definida fundamentalmente por un conjunto de servicios back- end soportados en el concepto de arquitectura B2B (Business to Business) o A2A (Application to Application) basada en el concepto de colas para aplicaciones distribuidos, en este caso implementadas mediante la implementación de Web-Services y el uso de BPEL.
Por otra parte existe un módulo de configuración del portal que estará desarrollado en JAVA en una arquitectura en capas utilizando para ello J2EE y el patrón Model-View-Controller.
D
EFINICIÓN DEA
MBIENTESUn ambiente está definido por un conjunto de Soft de base (SO, Base de datos y servidor de aplicaciones) y por las herramientas con sus respectivas versiones y configuraciones utilizadas.
Es muy importante para la estabilidad de un ambiente conocer cada herramienta y las versiones utilizadas para determinar de esta forma una configuración dada para un ambiente y de esta forma mantenerlo controlado ante los cambios que deban sufrir (actualizaciones y nuevas versiones).
Así mismo los ambientes contienen un conjunto de configuraciones y de datos de la aplicación a desarrollar que también deberán ser controlados por cada ambiente para mantener la integridad de la aplicación, su desarrollo y las pruebas que se deban realizar sobre la misma.
D
ESARROLLOFormalmente se utilizará la denominación DESA para referirnos a este ambiente.
Es el ambiente donde se desarrolla todo el proceso implementación (Análisis, diseño y Construcción). Por proceso de implementación se entiende:
✔ Desarrollo de casos de usos: Requerimientos funcionales de la aplicación. ✔ Definición de los requerimientos no funcionales.
✔ Desarrollo de la Arquitectura y diseño. ✔ Construcción de la aplicación.
✔ Construcción de scripts para realizar las distintas pruebas de la aplicación y ajustes a las configuraciones
existentes.
✔ Construcción de componentes de ingeniería de sistemas y soporte.
T
ESTINGFormalmente se utilizará la denominación TEST para referirnos a este ambiente
Es el ambiente donde se realizan las pruebas de conformidad de los casos de uso implementados (durante el proceso de implementación), y donde además se realizan pruebas de carga. Especialmente en el desarrollo de la presente aplicación donde su característica de backend se basa fundamentalmente en la actividad transaccional de servicios Este ambiente también se utiliza en los procesos de capacitación.
El ambiente TEST puede ser clonado de los ambientes DESA o PROD con la finalidad de equiparar cualquiera de los ambientes y realizar las pruebas respectivas. Este mismo proceso de clonado servirá también para el testeo de los paquetes de Deploy, garantizando que la aplicación de los mismos mantendrá la integridad en el ambiente PROD. En la sección Control de Configuraciones se detallan los procedimientos asociados al clonado de ambientes.
P
RODUCCIÓNFormalmente se utilizará la denominación PROD para referirnos a este ambiente
Es el ambiente de producción que se utilizará para uso de la Solución durante y luego de la finalización del proceso de implementación.
El contenido de datos y funcionalidad de este ambiente va aumentando a medida que se avanza en el proceso de implementación y en el refinamiento de casos de uso. Los usuarios del cliente trabajan sobre este ambiente utilizando todas aquellas funcionalidades que hayan sido puestas en marcha. Cada nuevo caso de uso cuya implementación haya sido aprobada por el cliente en el ambiente de TEST, es implementado (siguiendo el plan de estrategia de control de configuraciones) en este ambiente para su utilización por parte de los usuarios.
A
MBIENTE DED
ESARROLLODada la génesis del proyecto donde la utilización y la producción de software de código abierto (Open Source) es un factor impulsor de la Sociedad de la Información. El ambiente de desarrollo del producto “Switch Transaccional” debe cumplir con las características mencionadas.
Se debe mencionar que por las características del producto a construir se ha decidido la utilización de Java como lenguaje debido a la gran integración que posee el mismo con las tecnologías de aplicaciones distribuidas. De hecho Java fue pensado como un lenguaje orientado a las aplicaciones en redes y sistemas distribuidos
Para ello se han recorrido distintos ambientes IDE (Integrated development environment) que permitieran lograr los objetivos Open Source y la utilización de Java como lenguaje.
Dicho ambiente debía soportar además la utilización de PlugIns (componentes enchufables o lo que se conoce como tecnología de cartuchos). Dichos PlugIns debían permitir la incorporación de diversas herramientas para la realización del proyecto, no solo desde el punto de vista de desarrollo sino también para la Ingeniería de Requerimientos, Arquitectura, Diseño, Construcción, Testing y Documentación.
En el proceso se investigaron y probaron varias herramientas de las cuales solo dos cumplían con los requisitos buscados:
✔ Eclipse de “Eclipse Foundation”
–ver http://www.eclipse.org/org/
–ver http://www.netbeans.org/index_es.html o http://www.netbeans.org/about/index.html
Finalmente se decidió realizar el proyecto utilizando NetBeans debido a que la mayoría de los plugins requeridos eran desarrollados por la misma organización NetBeans. Lo que garantiza una mejor integración de dichos plugins con el IDE.
Por otra parte algunos de los Plugin requeridos para el proyecto dentro del ambiente Eclipse no eran Open Source como por ejemplo la herramienta UML.
También dentro de la selección de la herramienta pesó superlativamente las opciones y soportes que daba el ambiente para el desarrollo de aplicaciones SOA, donde NetBeans posee herramientas y tutoriales sumamente avanzados, incluyendo una herramienta de diseño BPEL muy importante para la realización del proyecto.
En todos los casos si las condiciones del proyecto lo habilitan se realizarán las actualizaciones (o aplicación de parches) de los productos mencionados en el presente documento. Cuando esto sucede se notificaran los cambios realizados a las plataformas.
Para el detalle técnico de cada producto se provee el link respectivo al web site del producto con la información técnica del mismo.
S
OFTWARE DEB
ASESistema Operativo
– GNU/Linux Fedora Core 6 de 64 bits. http://www.redhat.es/fedora/http://fedoraproject.org/
➢ Linux version 2.6.20-1.2952.fc6 ([email protected]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:18:22 EDT 2007
Ver Anexo C: Detalle del Sistema Operativo
Base de datos
– MySQL 5.0.27 http://www.mysql-hispano.org/http://www.mysql.org/ Ver Anexo D: Detalle Servidor de Base de Datos
Servidor de aplicaciones
– Apache Tomcat 5.0.28 http://tomcat.apache.org – GlassFish V2 https://glassfish.dev.java.net/
Ver Anexo E: Detalle del Servidor de Aplicaciones
H
ERRAMIENTAS DEG
ESTIÓN– XPlanner Version 0.7b7 --> Herramienta de planificación, control y seguimiento de proyectos utilizando metodologías Agile (eXtreme Programming: XP) http://www.xplanner.org/
– OpenOffice.org 2.0.4 --> Herramienta de oficina que permiten gestionar documentos, planillas de cálculo y pesentaciones. http://es.openoffice.org/
H
ERRAMIENTA DED
ESARROLLO– NetBeans IDE 6 (Release Beta1) http://www.netbeans.org/community/releases/60/index.html ➢ Visual Web Pack http://www.netbeans.org/products/visualweb/
➢ Enterprise Pack http://www.netbeans.org/products/enterprise/ ➢ UML® Modeling http://www.netbeans.org/products/uml/index.htm l
H
ARDWAREU
TILIZADO– Motherboard: ECS RS485M-M
– Controlador IDE: ATI 4379 Serial ATA Controller
– Disco Rígido: Western Digital de 160 GB de 7500 RPM (WDC WD1600JS-22N) – Memoria: 1 Gb de memoria RAM SDDR 766 Mhz.
– Audio: IXP SB400 AC'97 Audio Controller – DVD: HL-DT-STDVD-RAM GSA-H20N – RED: RTL-8139/8139C/8139C+
A
MBIENTES DET
ESTINGPara el ambiente de Testing se utilizará el mismo hardware, Soft de base y herramientas que para el ambiente de desarrollo pero se utilizarán un esquema de base de datos diferencial al igual que un deploy diferente en el servidor de aplicaciones.
A
MBIENTE DE PRODUCCIÓNPara el ambiente de producción también se utilizará el mismo hardware, Soft de base y herramientas que para el ambiente de desarrollo. También aquí con el esquema de ambiente diferenciado para la Base de datos y servidor de aplicaciones.
Pero dada la génesis de integración de aplicaciones y simulando las posibles aplicaciones clientes de las organizaciones que demanden y provean servicios, se agrega una nueva plataforma con el objetivo de realizar dichas pruebas y garantizar que el Switch Transaccional funciona integrando distintas plataformas de ejecución
S
ISTEMAO
PERATIVO– GNU/Linux Fedora Core 6 de 64 bits. http://www.redhat.es/fedora/http://fedoraproject.org/
➢ Linux version 2.6.20-1.2952.fc6 ([email protected]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:18:22 EDT 2007
Ver Anexo A: Detalle del Sistema Operativo
B
ASE DE DATOS– MySQL 5.0.27 http://www.mysql-hispano.org/http://www.mysql.org/ Ver Anexo B: Detalle Servidor de Base de Datos
S
ERVIDOR DE APLICACIONES– GlassFish V2 https://glassfish.dev.java.net/
Ver Anexo C: Detalle del Servidor de Aplicaciones
H
ARDWAREU
TILIZADO– Motherboard: MICRO-STAR INTERNATIONAL CO., LTD (6A6LVM4D) Bios: Phoenix-Award BIOS v6.00PG – Procesador: AMD Athlon TH (Thoroughbred) / AMD Duron(tm) processor / 1399 Mhz
– Controlador: ATA Controller
– Disco Rígido: Western Digital de 80 GB de 7500 RPM (WDC WD800LB-55DNA0) – Memoria: 512 MB SDRAM de 60 ns + 256 MB SDRAM de 60 ns.
C
ONTROL DE CONFIGURACIONESM
ETODOLOGÍA DELC
ONTROL DEC
ONFIGURACIONES.
Resumen
El control de configuraciones estará orientado a las iteraciones del proyecto, donde se preve liberar versiones del producto integrales. El paquete de instalación (PI) de cada versión integral deberá permitir actualizar la versión anterior, incrementando al misma un release.
Así mismo se preve la generación de mini actualizaciones o parches que permitirán corregir problemas o defectos intermedios sin necesidad de esperar a la finalización de la iteración.
Igualmente se deberá garantizar que todos los parches estén incluidos en el PI (paquete de Instalación) del release siguiente y el PI siguiente no deberá afectar ninguna instalación intermedia.
Definiciones
PI --> Paquete de Instalación. El mismo contiene las siguientes secciones: DB:
Actualización e instalación de tablas, vistas, triggers y procedimientos de la Base de datos. El script deberá prever e ir solicitando información así corresponda. Usuario de conexión y esquema a instalar. Será responsabilidad del instalador conocer el ambiente donde instalar y garantizar que se está instalando el script en dicho ambiente.
También este proceso debe garantizar la actualización de datos cuando corresponda, salvo que se requiera intervención de los usuario en cuyo caso deberá quedar aclarado en la documentación general del PI XML --> Conjunto de XML, XSLT, DTS o XSD de la aplicación. A tal fin se definirá un único directorio del servidor de aplicaciones que contendrá todos los archivos de este tipo para cada ambiente. Estos archivos pueden ser tanto de configuración de uso de la aplicación, como de definiciones de usuario como puede ser un proceso BPEL y una parser o transformación requerida.
JAR --> Conjunto de paquetes Java con la aplicación en si. A tal fin se definirá un único directorio del servidor de aplicaciones que contendrá todos los archivos de este tipo para cada ambiente.
VGUI --> Conjunto de archivos vinculados a la parte visual de la aplicación. A tal fin se definirá un único directorio del servidor de aplicaciones que contendrá todos los archivos de este tipo para cada ambiente. Estos archivos pueden ser tanto Java Server faces (JSF) como Java Server Pages (JSP).
DOC --> Conjunto de archivos vinculados con la documentación de la aplicación. A tal fin se definirá un único directorio del servidor de aplicaciones que contendrá todos los archivos de este tipo para cada ambiente. Estos archivos pueden contener tanto documentos de texto, como hojas de cálculo, presentaciones y además todo el material UML desarrollado y mantenido en el análisis y diseño de la aplicación. Esto permitirá garantizar una trazabilidad entre los objetos de la aplicación y su documentación.
AI -->
Actualización Intermedia. Este paquete puede contener las mismas secciones anteriores salvo la sección DB. De esta forma se garantizará que los AI no contienen cambios estructurales a la aplicación. Ya que el resto de las secciones son inocuas ante nuevos Deploy, pero la base de datos no, ya que allí se registrará el comportamiento de la aplicación mediante una arquitectura de meta información de la misma.
Deberá quedar claro por lo tanto que no se podrá incluir ningún nuevo objeto de la aplicación que requiera de dichos cambios de Base de datos. Quedando las actualizaciones limitadas a solucionar problemas existentes en la aplicación que impiden realizar, por ejemplo, el plan de pruebas trazado.
H
ERRAMIENTAS PARA LAA
DMINISTRACIÓN DELC
ONTROL DE CONFIGURACIONES.
Como herramienta de administración y control de configuraciones se diseñará una pequeña base de datos que permita registrar las actualizaciones y la registración de parches instalados en cada ambiente, permitiendo de esta forma controlar los componentes y las revisiones de instalación de cada ambiente.
Será muy importante la clara documentación de los PI y de los AI que permitirá realizar la trazabilidad de los componentes que contiene cada ambiente y su respectiva versión.
P
LAN DEC
ONTINGENCIADebido a la génesis del proyecto no implica un mayor riesgo la administración de un plan de contingencia ya que el proyecto afecta a la tesis de licenciatura donde se involucra a una sola persona y donde no existen riesgos económicos afectados a la misma.
Por lo tanto no se describirán posibles escenarios de amenaza ni impactos consecuentes de dichas amenazas. Sí se establecerá un esquema de resguardo del proyecto y una indicación de restauración del mismo y los tiempos incurridos para la restauración del mismo.
E
SQUEMA DE RESGUARDO Y RECUPERACIÓN DE AMBIENTES.
Toda la gestión y desarrollo del proyecto se administra desde un sólo equipo, por lo tanto el procedimiento que a continuación se describe afecta a dicho equipo utilizado en el ambiente DESA y TEST. No se preve respaldo del ambiente de producción ya que el mismo es reinstalable y recuperable desde los parches de actualización e instalación en producción.
H
ERRAMIENTAU
TILIZADA PARA LA GESTIÓN DEB
ACKUPSe ha decidido utilizar la herramienta Open Source Yakup (yet another backup script) que simplifica mediante el uso del comando tar la realización y gestión de copias de seguridad.
Entre las principales características se puede mencionar: – Backup completo (full), incrementales y diferenciales.
– Resguardo y recuperación desde disco rígido y medios removibles como CD o DVD. – Administración avanzada de medios.
– Configuración de copias de seguridad mediante el uso de archivos de configuración. – Uso de tar. tar compatible.
– Compresión de datos mediante uso de gzip o bzip2.