Benemérita Universidad Autónoma de Puebla

Facultad de Ciencias de la Computación

Implementación de un Sistema de Información basado en software, para Pequeñas y Medianas Empresas (PyMES) de ventas y distribución

(Manuales de Procedimientos, Diagramas de Flujo de actividades)

Tesis Profesional que para obtener el título de Licenciado en Ciencias de la Computación

Presenta

Ismael Morales Hernández

Asesor Lic. José Luis Meza León

Puebla Pue. Mayo de 2012

2

Agradecimientos:

"Gracias infinitas a dios por brindarme el ser y el libre albedrío" "A mis Padres pues al transmitirme sus cuidados, cultura e ideales, aunados al permanente apoyo en cada etapa de mi desarrollo, he logrado encontrarme hoy ante ésta realización" "A mis Hermanas y Hermanos por compartir conmigo tantas experiencias y por el impulso que en muy variadas formas han dado a mi carrera" "Esperando no ser excluyente, un gran agradecimiento a todo mi entorno, Amigos, Profesores, Compañeros de estudio y de trabajo, que han sido de gran provecho y han colaborado, todos y cada uno, en la construcción de mi proyecto de vida"

“Mi agradecimiento especial al Profesor José Luis Meza León, tutor, asesor y amigo”

3

ÍNDICE INTRODUCCIÓN ............................................................................................................................... 5 I.I Manuales de Procedimientos y Diagramas de Flujo de Actividades .................................... 5 I.II Metodologías para el Desarrollo de Software y Patrones de Diseño Arquitectónico. ...... 6 I.III Objetivo ......................................................................................................................................... 8 I.IV Objetivos Específicos ................................................................................................................. 8 I.V Estructura de los Capítulos ........................................................................................................ 9 Capítulo I ........................................................................................................................................... 10 Marco teórico .................................................................................................................................... 10 1.1 Introducción ............................................................................................................................... 10 1.1.1 Los Conceptos. ...................................................................................................................... 11 1.2 ¿Qué es un diagrama de flujo de actividades? .................................................................... 12 1.2.1 Uso y Aprovechamiento ....................................................................................................... 12 1.2.2 Clasificación de los Diagramas de Flujo ............................................................................ 13 1.2.3 Símbolos y Técnicas usados en los Diagramas de Flujo ............................................... 15 1.3 ¿Qué es un Manual de Procedimientos? .............................................................................. 15 1.3.1 Justificación ............................................................................................................................ 15 1.3.2 Objetivos ................................................................................................................................. 16 1.3.3 Lineamientos. ......................................................................................................................... 16 1.3.4 Reingeniería de Procesos (Mejoras en General). ............................................................ 18 1.4 Metodologías para el Desarrollo de Software ...................................................................... 19 1.4.1 Fases Clásicas En la producción de Software ................................................................. 22 1.4.2 Metodologías Orientadas a Objetos ................................................................................... 26 1.4.3 UML, RUP y XP ..................................................................................................................... 27 1.4.4 La necesidad de Herramientas de Desarrollo ................................................................... 29 1.4.5 Diagramas UML ..................................................................................................................... 30 1.5 Model-View-Controller .............................................................................................................. 32 1.5.1 Struts ....................................................................................................................................... 35 Capítulo II .......................................................................................................................................... 37 Adaptación de las técnicas ............................................................................................................ 37 2.1 Manuales de Procedimientos (Integración). ......................................................................... 37 2.2 Metodología para preparar un diagrama de flujo de actividades ...................................... 43 2.3 RIPPLE ....................................................................................................................................... 47 2.4 Servidor Web MVC ................................................................................................................... 51 Capítulo III ......................................................................................................................................... 60 Resultados y Entregables .............................................................................................................. 60 3.1 Actividades, Funciones Y Responsabilidades Área De Sistemas .................................... 60 3.1.1 Organigrama ........................................................................................................................... 61 3.2 Manual de Procedimientos (Documento Resultado)........................................................... 62 3.3 Entregables RIPPLE ................................................................................................................. 75 3.3.1 Requerimientos de negocio ................................................................................................. 75 3.3.2 Requerimientos de Sistema ................................................................................................. 79 3.3.3 Análisis .................................................................................................................................... 85 3.3.4 Diseño del Sistema ............................................................................................................... 90 3.3.5 Diseño de Subsistemas ...................................................................................................... 101 3.3.6 Especificación de Clases ................................................................................................... 109 3.3.7 Esquema de Plan de Pruebas ........................................................................................... 113

4

3.3.7 Glosario ................................................................................................................................. 118 3.4 Aplicación WEB y patrones ................................................................................................... 119 Capítulo IV ...................................................................................................................................... 126 Conclusiones .................................................................................................................................. 126 4.1 Trabajos Futuros ..................................................................................................................... 128 Bibliografía ...................................................................................................................................... 130 Anexo A – Pantallas del SICBA ...................................................................................................... 133 Anexo B – Herramientas del Servidor Tomcat ................................................................................ 137 Anexo C – Entorno de desarrollo Eclipse ........................................................................................ 139 Anexo D – Herramientas del Servidor de Base de Datos................................................................. 141

5

INTRODUCCIÓN

En el momento de abordar un proyecto para desarrollo de software informático administrativo, en especial si está dirigido a una empresa de reciente surgimiento y en expansión, es común encontrarse con una serie de problemas, muchos de ellos de tipo operativo, de tal suerte que al iniciar el proceso del desarrollo, según lo establecido por la metodología o patrón elegido, a partir de la amplia gama propuesta y estudiada en la ingeniería del software, resulta muy difícil avanzar más allá de las etapas iniciales de la recopilación y análisis de requerimientos, tanto que ésta fase puede prolongarse por un tiempo indefinido.

Con este escenario es correcto inferir que dicha limitación encuentra su origen en el modo mediante el cual está organizada la empresa cliente, así también y en mayor grado, en la forma en que sus colaboradores se dirigen al realizar cada una de las actividades de valor para la misma, pues la ausencia de puntos de control específicos, formatos precisos, métodos de seguimiento, entre otros, se traduce en pérdidas importantes para la empresa; reflejándose éstas siempre en pérdidas económicas, los principales factores que propician esto son los tiempos de proceso y de re procesado; permitiendo la apertura a la posibilidad de fraudes internos por parte de malos elementos de la empresa, ambigüedad en la información que se tiene para la toma de decisiones, por mencionar algunos.

Nuestro tema de interés como programadores de software, es como tal, la obtención de información resultante y de valor. Por ése motivo debemos garantizar que los datos sean consistentes desde su origen al punto de entrada, conserven su integridad durante el almacenamiento y se enriquezcan durante su procesamiento, para que a la salida de la información, sus elementos conformen un recurso útil para la toma de decisiones. Esto se puede tornar en una imposibilidad, si el sistema o modo de operación en el plano del mundo real, tolera los problemas antes mencionados.

Es así como nos proponemos el estudio, elaboración y utilización plena de los manuales de procedimientos y diagramas de flujo de actividades, por el momento no como material fundamental para el desarrollo de software, pero sí como una herramienta que da un valor agregado al analista y programador de sistemas, de tal forma que coadyuve a la resolución de problemas propuestos por el cliente; además de su papel informático. Se promoverá como un guía importante en la re estructuración de la empresa, con avances sustantivos que conserven y lleven el proyecto a buen término.

I.I Manuales de Procedimientos y Diagramas de Flujo de Actividades

En una empresa es importante tanto en la matriz como en sus sucursales y en todas sus áreas, contar con una guía técnica que les sirva de apoyo, para la formulación de sus Manuales de Procedimientos. Por tratarse de documentos de carácter estratégico administrativo, se deberá incluir para un establecimiento formal y la operación de los mismos, los lineamientos normativos referentes a su autorización, impresión, publicación, distribución y control.

6

Se pretende así que los manuales resultantes, mantengan la uniformidad necesaria para facilitar que quede sistematizado de manera global, y que la información le permitan, tanto al analista de sistemas como a los usuarios, un conocimiento más profundo de la organización y funcionamiento de la Administración Corporativa.

El poder contar con manuales de procedimientos, es necesario, porque existen procesos que presentan cierto grado de complejidad y se requieren descripciones claras y precisas de los mismos, de tal manera que sea fácil consultarlos para aclarar dudas, asegurando así la uniformidad en el desarrollo de las operaciones y sus procedimientos, orientándonos a nuestra recopilación y análisis de requerimientos.

Es prudente durante la elaboración de dichos manuales, aprovechar la información resultante del análisis de los procesos para realizar la simplificación y automatización de los métodos y sistemas de trabajo empleados. En este caso, se justificará la aplicación de la re ingeniería de procesos, útil para identificar las oportunidades de mejora respecto a una actividad, servicio o área de trabajo por lo que se deben presentar de manera general los formatos que pueden utilizarse en este caso.

De igual manera se requiere incluir, los puntos más relevantes que deben contener los procedimientos que forman parte de un sistema de calidad, a fin de que los mismos cumplan con las necesidades propias del área en la que se llevan a cabo las actividades que describen, ajustándose a ciertos estándares.

Como un auxiliar que sin discusión debe acompañar a todo manual de procedimientos, nos debemos concentrar también, en definiciones y lineamientos para el diseño y elaboración de diagramas de flujo de actividades, ya que estos proporcionan una visión sistemática del conjunto de actividades que integran el proceso, permiten proporcionar explicaciones más claras sobre la secuencia de actividades del proceso, entre otras ventajas, pues al representar gráficamente hechos, situaciones, movimientos o relaciones de todo tipo, brindan a toda organización los elementos de juicio idóneos para la representación de procedimientos y procesos, así como las pautas para su manejo en sus diferentes versiones.

Lo más importante para el que desarrolla, es que estos van además a proporcionar una visión más clara de lo que son los flujos de datos e información.

I.II Metodologías para el Desarrollo de Software y Patrones de Diseño Arquitectónico.

Entrando en materia informática debemos elegir una metodología que nos permita

dirigir el proyecto de desarrollo en un modo controlado, con puntos de revisión y evaluación desde la fase de recopilación y análisis de requerimientos hasta llegar a su integración. Así también contar con un patrón de diseño que permita administrar y dividir

7

los distintos tipos de trabajo a realizar en cada una de las etapas del desarrollo; así como las instancias, a los que cada uno de dichos trabajos, serán delegados.

La metodología propuesta para estudio y bajo la cual se dirigirá el proyecto es denominada RIPPLE. No obstante para el correcto seguimiento de las tareas que ésta propone será necesario hacer una revisión de las fases clásicas del proceso de desarrollo de software y su propósito elemental, las ventajas que proporciona el apego a una metodología, puesto que describe un modo sistemático de llevar a cabo las labores inmersas en dicho proceso.

Después del análisis de algunas metodologías orientadas a objetos, es fácil identificar que RIPPLE explota los mejores aspectos de las propuestas metodológicas siguiendo un tipo espiral, iterativa y con incrementos. Así también está orientada a la comprensión y aprovechamiento de todos los resultados involucrados en todo proyecto de desarrollo de software, modelado con objetos como pueden ser los diagramas de caso de uso, de clase, de objetos, de actividades o de despliegue, por mencionar algunos. De espectro amplio o reducido, ésta metodología es aplicable en forma transparente al mundo real, pues marca la pauta desde las primeras fases como la concepción del proyecto, la asignación de responsabilidades, en la producción del plan del proyecto, hasta las etapas tardías como su implementación y el mantenimiento.

No se puede pasar por alto la necesidad de contar con herramientas de desarrollo las cuales hacen eficiente cualquier metodología y sirven de apoyo en tareas como son: el seguimiento a históricos de cambios, el control de acceso por muchos usuarios, la operación en red para la fase de pruebas, de los objetos producidos entre otras.

Para la arquitectura de software se elige Model-View-Controller como patrón de diseño, pues demuestra un concepto basado en separar el modelo de datos de la aplicación, de lo que se presenta o envía al usuario y de la interacción que se da entre éste y la aplicación; planteando la división de la aplicación en tres elementos fundamentales:

• El modelo: en el que recae o se localiza toda la lógica de negocio de nuestra aplicación.

• La vista: considera todo lo necesario para que el usuario tenga la información en interfaz.

• El controlador: recibe cada acción del usuario, la interpreta y actúa tanto sobre el modelo, como sobre la vista para generar los cambios de estado necesarios en la representación interna de los datos, así también en su presentación.

Se sabe que ésta arquitectura MVC ha mostrado ser bastante apropiada para las aplicaciones WEB, especialmente por aplicarse de manera fácil y transparente usando las tecnologías proporcionadas por la API de java como lo es J2EE y otros frameworks relacionados.

8

I.III Objetivo El objetivo del presente trabajo, es el de recopilar y poner en práctica los

conocimientos de organización y administración básicos, para estructurar o en su caso re-estructurar áreas de una empresa cliente, mediante la elaboración de diagramas de flujo de actividades y el establecimiento formal de manuales de procedimientos, con el fin de que el apego a la metodología y patrón de diseño que se elijan, se logre de manera transparente, alcanzando como resultante, un sistema de información robusto, confiable y que cumpla con los requerimientos y expectativas de los usuarios finales en un lapso programado de 6 meses, definiendo para el alcance del proyecto, el control de inventarios.

I.IV Objetivos Específicos

Describiendo puntualmente y en la secuencia en que se irán desarrollando las tareas, Se pretende:

• Conformar una guía práctica para la elaboración de manuales de procedimientos y diagramas de flujo de actividades, así como coordinar la capacitación para su aprovechamiento, durante los primeros 30 días.

• Diseñar durante el período del segundo mes, los diagramas de flujo de actividades comenzando por las áreas que requieran atención inmediata, para detectar y corregir inconsistencias, así hasta terminar con las áreas de menor impacto, cuidando siempre el alcance del proyecto.

• Formalizar manuales de procedimientos en el modo y tiempo descritos anteriormente.

• A partir del tercer mes, adquirir el dominio del conocimiento de la metodología RIPPLE incluyéndola en la práctica para dirigir el proyecto de desarrollo de software y comprobar los beneficios que esto nos representa.

• Diseñar cada uno de los módulos del sistema de información utilizando la arquitectura Modelo-Vista-Controlador (del inglés Model-View-Controller) para mantener un patrón en el cual se facilite la división o clasificación de la carga de trabajo por roles específicos.

• Realizar la entrega del sistema de control de inventarios como un producto de software funcional en la primera quincena del sexto mes, cumpliendo al 100% con los requerimientos recopilados al inicio del proceso de desarrollo.

• Llevar a cabo la integración y capacitación utilizando los mismos manuales de procedimientos antes elaborados, durante la última quincena del sexto mes.

Como objetivo último, pero más a manera de tarea futura, queda comprobar que el mantenimiento del sistema como producto final, resulta sencillo y controlable, como una consecuencia del seguimiento correcto y del cumplimiento con los objetivos anteriores.

9

I.V Estructura de los Capítulos El capítulo 1 reúne los conceptos generales y en su caso a detalle de las

definiciones de nuestro tema de estudio, de tal modo que pueden identificarse cuatro elementos teóricos auxiliares como fundamento del presente proyecto.

El capítulo 2 describen de cierta manera las técnicas mediante las cuales se lleva a cabo el desarrollo del trabajo, incluyendo a su vez detalles, de las tareas requeridas al momento de poner en práctica los conocimientos adquiridos en la primera etapa del mismo.

En el capítulo 3 se esquematizan los diagramas, manuales y diseños resultantes de la aplicación de las técnicas vistas en el capítulo anterior, proporcionando en su caso una descripción de cada resultado obtenido.

En el capítulo 4 a manera de conclusiones se resumen los puntos clave sobre los que se identifican las ventajas y la manera en que todo el proceso llevado a cabo facilita el desarrollo y entrega de la aplicación en su versión funcional, así como de la documentación generada.

10

Capítulo I

Marco teórico

1.1 Introducción El término "Organizar" se puede definir como la acción de tomar una entidad,

establecerle un orden o reformarle el ya existente, tomando en cuenta ciertas reglas, el número de partes o elementos que la conforman, así como su armonía e interdependencia.

Las empresas son organizaciones complejas por lo que requieren de una estructura, donde se especifique la función que cada uno de sus integrantes debe ejecutar. Por ello se deduce que la marcha correcta de una empresa, recae en la buena estructuración de su organigrama, en el cual se indica la línea de autoridad y responsabilidad, los canales de comunicación y de supervisión con los que se logra la integración de las diversas partes que componen tal organización.

Por lo anterior, es importante comenzar con el estudio y realización de dicha estructura en su representación gráfica.

Un organigrama como instrumento metodológico de las ciencias administrativas, permite observar la estructura interna de una organización, pero muchas de las veces dicha estructura se ajusta a lo que puede ser escrito y no a lo que es en realidad.

El organigrama es resultado del diseño de estructura de una organización, la cual hubo que representar de alguna forma y muestra los niveles jerárquicos existentes en una empresa u organización.

Figura 1. Organigrama Vertical.

Gerente

Organigrama

Admin 1 Admin 2

SubordinadoSubordinado Subordinado

11

En cuanto a los distintos tipos de organigramas, se encuentra que los verticales son los que se utilizan en mayor frecuencia.

La ventaja que más resalta de un organigrama, es que muestra las líneas de dependencia entre los actores y tiene la particularidad de indicar a los administradores y al personal de nuevo ingreso, la forma como se integra la organización.

Así como existen múltiples factores positivos, también deben de tomarse en cuenta sus desventajas, considerándose muy desfavorable el aspecto que, en ciertas condiciones, exponen la estructura de la organización como era antes y no como actualmente es, ya que algunos administradores olvidan actualizarlos, descuidando el dinamismo de la organización, lo cual hace que dicha versión del organigrama se torne obsoleta.

La jerarquía dispuesta en un organigrama constituye un principio básico de la organización y también lo es de la dirección, no obstante es sólo el punto de partida para nuestro caso de estudio, en el cual necesitamos, sobrepasar el límite de la generalización hacía un nivel de detalle; de tal manera que únicamente puede ser descrito de forma conveniente, al diseñarse para el análisis a los llamados diagramas de flujo de actividades.

1.1.1 Los Conceptos. El comprender la metodología para la elaboración de Manuales de Procedimientos

y Diagramas de Flujo de Actividades, requiere determinar algunos conceptos básicos que nos lleven a decidir de manera lógica las causas principales y justificables que motivan su realización; por lo anterior, es necesario conocer lo que son un proceso y un procedimiento e identificar sus diferencias.

Un Proceso es la transformación de un conjunto de insumos, como pueden ser personas, materiales, energía, equipo, procedimientos; que son utilizados para la obtención resultados sales como un producto, un servicio o el cumplir una tarea.

El analizar un proceso consiste en:

• Observar y registrar cada uno de los pasos importantes y necesarios para el logro de ciertos resultados.

• Colocar estos pasos en su secuencia apropiada. • Identificar cada tipo de paso, así como su aportación al resultado. • Registrar adicionalmente toda la información que se considere importante al

proceso.

Un Procedimiento es una sucesión cronológica y detallada de las operaciones, tomando en cuenta su orden lógico y su método de ejecución. En ocasiones es común determinar que un proceso es lo mismo que un procedimiento; para efectos del presente trabajo, existirá diferencia entre proceso y procedimiento; la cual radica en que el primero contiene los pasos importantes para llevar a cabo la implantación de un sistema, mientras que un procedimiento contiene el detalle de actividades a realizar en cada uno de los pasos determinados en el proceso.

12

1.2 ¿Qué es un diagrama de flujo de actividades? Es una representación gráfica o pictórica de los pasos en un proceso,

extremadamente útil para determinar cómo funciona realmente dicho proceso en la obtención de un resultado. Este último puede ser un producto, un servicio, información o una combinación de los tres. Al examinar el modo en que los diferentes pasos en un proceso se relacionan entre sí, se pueden descubrir con gran facilidad las fuentes que originan problemas potenciales. Los diagramas de flujo en general se pueden aplicar sobre cualquier aspecto del proceso, desde el flujo de materiales hasta los pasos para realizar una venta u ofrecer un producto. Los diagramas de flujo enriquecidos con descripciones muestran la mayoría de los pasos en un proceso, pero con frecuencia este nivel de detalle no es necesario, en todo caso de ser requerido, un equipo del consejo de gerencia o coordinador, normalmente desarrolla una versión general, para que posteriormente grupos de trabajo más pequeños o responsables de área, puedan agregar niveles de detalle, según sea necesario durante el proyecto.

1.2.1 Uso y Aprovechamiento

Los diagramas de flujo de actividades son muy útiles cuando un equipo de analistas o un usuario, necesita ver cómo funciona realmente un proceso completo. Durante su diseño con frecuencia se revelan problemas potenciales tales como cuellos de botella en el sistema, pasos innecesarios y duplicidad de trabajo. Algunas de sus aplicaciones comunes son:

• En definición de proyectos, para identificar oportunidades de cambios en el proceso, desarrollar estimados de costos originados por mala calidad, identificar áreas que deban estar representadas en el equipo y su interacción. Así también, desarrollar una base común de conocimiento para los nuevos miembros del equipo e involucrar a los trabajadores en las labores de solución a problemas para reducir la posibilidad de resistencia al cambio.

• En identificación de causas. Comenzando con el desarrollo de planes para recolección de datos sobre algún tipo de problema, que sirvan de base para la formulación de teorías sobre las causas principales. Es muy útil emplear diagramas para discutir las formas de estratificar dichos datos de modo que faciliten el análisis y estimado del tiempo requerido para las distintas vías del proceso

• Diseño de soluciones. Para describir los cambios potenciales en el proceso y sus efectos, así como identificar las áreas que serán afectadas por dichos cambios propuestos.

• Aplicación de soluciones. Pues son auxiliares al explicar a otros el proceso actual y la solución propuesta, superando la resistencia al cambio mediante la demostración de que dicha solución y los pasos que ésta comprende, simplificarán el proceso.

13

• Para el control al facilitar la revisión y establecimiento de puntos de monitoreo del proceso, además de auditorías periódicas para asegurar que se están siguiendo los nuevos procedimientos y así también entrenar a nuevos empleados.

1.2.2 Clasificación de los Diagramas de Flujo

A) Propósito:

• Formularios.- Se ocupan fundamentalmente del flujo de documentos desde el inicio del proceso hasta que el documento es archivado tomando en cuenta cada una de sus copias y las personas o departamentos destinatarios.

• Labores.- Son un tanto abreviados y sólo Indican el flujo o secuencia de las

operaciones, así como quién y en donde se realizan.

• Método.- Muestran principalmente la manera de hacer cada una de las

actividades del procedimiento, la secuencia de operaciones y la persona responsable de realizarlas.

• Analíticos.- Además de describir el procedimiento, la persona o área responsable de su ejecución y cómo se hace cada operación, se ocupan en mostrar el sentido de la actividad y comprender para que sirve.

• Espacio.- Indican principalmente los lugares por los que se desplaza un formulario o una persona, señalando su itinerario y puede incluir registro de distancia y tiempo empleado en su recorrido.

• Combinados.- Integran características tomadas de dos o más tipos de

diagramas dependiendo del caso que se desee representar para lograr un diagrama ampliamente expresivo.

B) Formato:

• Vertical.- Esquematiza la lista de operaciones de un proceso de manera ordenada cuyo flujo se dispone de arriba hacia abajo y de izquierda a derecha.

• Horizontal.- En éste la secuencia de las operaciones se dibuja de izquierda a derecha y con seguimiento en forma descendente, resaltando la distribución de las tareas.

• Tabular.- Se presenta el proceso completo en una sola carta, en ésta se

corresponde para cada columna un puesto o área, con el propósito de mostrar

14

todas las actividades en una sola vista para agilizar su comprensión.

• Arquitectónico.- Muestran el desplazamiento de personas, formularios y materiales, a través del espacio o plano arquitectónico donde se realizan, además de la secuencia de las operaciones.

Figura 2. Diagrama de Formato Tabular.

C) Presentación:

• Bloque.- Representan entidades de manera general solo para destacar determinados aspectos de dependencias o secciones a manera de introducción a los procesos.

• Detalle.- Muestran cada una de las actividades con el mayor nivel de detalle posible, por tanto pueden ser aprovechados para la capacitación de personal.

Servicios Generales

Procedimiento de Adquisición de Materiales

Departamento Solicitante Almacén Departamento de Compras Proveedor

Elaboró: Autorizó Fecha: Versión:

Inicio

Pide material mediantesolicitud de material

¿Existenciasuficiente?

Solicita materialmediante requisición

de compraPide material mediante

orden de compra

Comunica deficienciaal almacén

Surte material

Surte material

Surte material

Utiliza material

Comunica deficienciaal proveedor

Fin

A

B

A

B

¿Materialrequerido?

¿Materialrequerido?

¿Origen delmaterial?

Si

No

No

Prov

Si

Alm

acén

Si

No

15

1.2.3 Símbolos y Técnicas usados en los Diagramas de Flujo Existe una gran variedad de simbologías cuya utilización facilita el diseño, permite

la correcta identificación de actividades, simplifica su comprensión, y permite el acercamiento y coordinación con los usuarios, además, Disminuye la complejidad e incrementa la accesibilidad a los mismos, sin olvidar que cada diagrama se elabora con rapidez y no requiere de recursos sofisticados. Las siguientes son algunas de las simbologías más populares por mencionar algunas:

• American Society of Mechanical Enginners (ASME)

• American National Standard Institute (ANSI)

• International Organization for Standarization (ISO)

• Deutches Institut fur Normung e.V (DIN)

La elección de una o varias de ellas, dependerá de la orientación o propósito de cada diagrama o etapa del proyecto en cuestión y más adelante se especificará dicha elección.

1.3 ¿Qué es un Manual de Procedimientos? Es un instrumento informativo, en el cual se describen en forma secuencial y

cronológica, las operaciones que deben seguirse para la realización de las funciones de una persona, un área, o varias de ellas en una organización.

Los procedimientos administrativos en cuanto al manejo de información, están conformados por una secuencia de operaciones ordenadas cronológicamente en un mismo conjunto, que determinan la forma sistemática de realizar un trabajo de rutina en particular.

1.3.1 Justificación

Se requerirá de la creación de un Manual de Procedimientos siempre que se tenga un entorno bajo las siguientes condiciones:

a) Si se detecta que existen procesos complejos y que deben describirse de manera precisa y que sean de fácil consulta.

b) Cuando el desarrollo de las actividades no se está realizando de manera uniforme y se generan ambigüedades en el proceder.

c) Es apremiante una simplificación de los procesos. d) Se pretende iniciar con algún proyecto de capacitación al personal. e) Se pretende automatizar los métodos de trabajo, así como los sistemas.

16

La presente metodología nos lleva a analizar cada paso en un proceso, no solo a buscar quien realiza las actividades inmersas en este o cómo se realizan, sino que pone especial atención a lo que en esencia se está realizando, por lo tanto, la prioridad es conocer las actividades que en conjunto logran la rapidez y factibilidad económica de un proceso, tomando como base los siguientes puntos:

• Utilizar la información generada por la persona o puesto responsable, y con ella mejorar, corregir o implantar actividades.

• Buscar la simplificación de pasos. • Diseñar opciones o alternativas con las que se puede manejar una actividad para

satisfacer a usuarios o clientes. • Mejorar la comunicación y coordinación entre los participantes.

1.3.2 Objetivos

Un Manual de Procedimientos es una herramienta que facilita la consecución de diversos objetivos, entre los que se identifican:

• La reglamentación y uniformidad de los procedimientos.

• Instrumentar las políticas de la organización al establecer un método obligatorio para realizar las actividades futuras.

• El mejoramiento de los métodos y técnicas de trabajo.

1.3.3 Lineamientos. Elaboración. La elaboración de los Manuales de Procedimientos, inicia una vez que el

departamento o área en la empresa cuenta con su diagrama de Organización, el cual sirve como marco de referencia para definir el área responsable de la realización del proceso.

Deben ser elaborados por los jefes de área encargados del desarrollo administrativo en los departamentos o por los responsables de la gente que realiza las actividades o procesos, con la asesoría técnica y apoyo del analista de procesos y sistemas, que en este caso es el responsable del proyecto de desarrollo de sistemas, y es quien toma la información para la elaboración del diseño de los manuales de procedimientos y son la base fundamental para elaborar la ingeniería del software.

Autorización. Los proyectos de Manuales de procedimientos se someten a la aprobación y

autorización de las áreas correspondientes, apegándose a un esquema como el siguiente: Para cada área o departamento, el titular en jefe de la misma será el responsable

de aprobar el manual, para pasar posteriormente a la unidad administrativa central, donde

17

el Director General o el Consejo de Administración o ambos, corroboran mediante su autorización. Para el caso de las sucursales o áreas descentralizadas, en las que por condiciones de la zona realicen sus propias versiones de los manuales, el titular responsable emite una preautorización la cual encuentra su formalización con el visto bueno de la dirección general, previo acuerdo con el Consejo de Administración.

Publicación. La impresión y publicación de los Manuales de Procedimientos es considerada

como publicación oficial, debiendo observarse las especificaciones establecidas en su contenido, una vez que el equipo encargado del proyecto de desarrollo de dichos manuales, como responsable de su complementación, recopilación de firmas pertinentes e impresión, así lo anuncie en común acuerdo con la administración general.

Difusión y Distribución. La distribución de los ejemplares se lleva a cabo por el personal de las áreas

responsables de su elaboración, debiéndose efectuar reuniones o pláticas de difusión y de instrucción sobre su uso con el personal encargado de realizar las funciones, actividades y las operaciones señaladas en el mismo.

El personal de los departamentos que recibe la instrucción sobre el uso de los manuales, debe firmar de enterado y conformidad con la operación de los procesos, en listados de asistencias o bien, en la entrega de los manuales, turnando copia a la administración general.

Control. Para llevar un control y actualización de los manuales, la administración general, en

coordinación con el equipo encargado del proyecto de desarrollo, efectúan una selección y registro de responsables y departamentos que deben contar con ejemplares de los mismos, con el objeto de proporcionarles en forma permanente la información necesaria para mantener actualizados la totalidad de los ejemplares distribuidos y los conservados en el archivo y áreas destinadas para su consulta.

Cuando un área en la empresa requiera hacer cambios, adiciones o revisiones al manual, presentará los proyectos de modificaciones correspondientes a la administración general para que verifique que los mismos se realicen de acuerdo con las políticas generales de la empresa o área y prever los posibles efectos en otras áreas, así como mantener la uniformidad de estilo y presentación.

La administración general, someterá las actualizaciones de los manuales a los mismos trámites de autorización y distribución requeridos para la elaboración del documento original.

18

1.3.4 Reingeniería de Procesos (Mejoras en General). Es necesario señalar, que la importancia de la implantación de un Manual de

Procedimientos, no radica en documentar las actividades, referencias y responsables de un proceso; lo esencial es mejorarlo continuamente a fin de lograr la agilización, simplificación y en un momento dado la desregulación, por así decirlo, de pasos que se realizan para proporcionar un servicio u obtener un producto. Aunado a esto, es imprescindible mantener los procesos sencillos para una mejor comprensión de los mismos.

El principal propósito en la elaboración de un Manual de Procedimientos es la necesidad de lograr uniformidad de las actividades rutinarias y proveer de referencias adecuadas, así como controlar las normas de operación. Por lo anterior, se define como Reingeniería de Procesos al rediseño radical de un proceso que tiene como meta realizar mejoras importantes. Para lograr la mejora de los procesos (Reingeniería) es indispensable realizar un análisis de lo siguiente:

• Definición de los límites del proceso. Definición del inicio y el final del mismo, incluyendo la identificación de los insumos y producto o servicio resultante del proceso. Además, se debe analizar si en realidad el proceso elegido para mejora es eficaz y confiable. Asimismo, el nivel de familiaridad y la atribución que se tiene en el proceso es importante para alcanzar los resultados deseados en la implantación de la reingeniería de procesos. Una vez establecidos los límites, participarán en su mejora las áreas involucradas.

• Observación del flujo. este paso es determinante en la mejora, ya que en ocasiones se pretende realizar una diagramación del flujo que lleva un proceso sin siquiera observarlo, lo que repercute en que algunas actividades podrían no estarse contemplando; ésta observación debe ser física y registrarla en un formato específico, tomando en cuenta que la misma deberá realizarse más de una vez para corroborar la situación.

• Recolección de datos. Es conveniente que los datos sean recabados después de haber realizado varias observaciones al proceso sujeto a la mejora para obtener cifras precisas. En este punto se recaban formatos, normas de las áreas y responsables, entre otros.

• Análisis de datos. Este paso, ayuda a determinar o realizar algunos cálculos sobre la eficiencia del trabajo y el tiempo de ciclo del proceso, para lograr un resumen de lo recabado.

• Establecimiento de áreas de oportunidad. Aquí es donde se deberá determinar, según los pasos anteriores, la identificación del trabajo repetido, de las demoras o del desperdicio a través de su eliminación o reducción al mínimo. Por ejemplo, si a un proceso, previo análisis, se le eliminan ciertas actividades que no aportan avance en su seguimiento y el resultado deseado sigue siendo el mismo, quiere decir que existe la posibilidad de realizar una reingeniería de procesos.

• Desarrollo de mejoras. Este punto, determina el diseño y desarrollo de las mejoras identificadas en el proceso, calculando beneficios potenciales, haciendo un

19

comparativo respecto a la situación actual contra la propuesta a implantar. Implantación y seguimiento de mejoras: La implantación se puede llevar a cabo bajo la aplicación de pruebas piloto, en el caso de procesos muy complicados; de cambio completo, mediante una modificación total en la manera de hacer las cosas; de cambio gradual, como una transición paulatina. Aunado a esto, debemos conocer otros conceptos que se deben tomar en cuenta y

aplicarse concretamente para el estudio de la mejora de los procesos, estos son Trabajo y Desperdicio, a fin de identificarlos y sacarles la mayor ventaja al primero y evitar en lo posible del segundo. Para identificar el trabajo sólo basta con decir que el mismo es el que proporciona valor y hace avanzar el proceso. Una forma de detectar el desperdicio, es por ejemplo, recabar dos veces la misma información, que en ocasiones se puede convertir en repetición de trabajo, que a su vez se traduce en demora, la cual repercute en los costos de producción o de elaboración del proceso: Mayor demora, mayor costo del proceso.

1.4 Metodologías para el Desarrollo de Software Todo software y en particular, sistemas grandes desarrollados por grupos de varias

personas, debería producirse usando algún tipo de metodología; no obstante, también los módulos pequeños de software, que una persona sola es capaz de mantener, pueden ser mejorados apegándose a alguna metodología.

Una metodología son modos de realizar cualquier trabajo, son procesos por lo regular repetibles, tal que podemos seguir desde las primeras etapas del desarrollo; en nuestro caso de software, la concepción de una idea o una nueva oportunidad comercial, hasta la etapa de mantenimiento de un sistema ya instalado. Así como en un proceso, una metodología debe especificar lo que se espera producir según el apego dicho proceso y la forma que deben tomar los productos finales. Una metodología también incluye técnicas y recomendaciones para la administración de recursos, proyección, planificación y otras tareas de tipo administrativas.

Las mejores metodologías que están ampliamente disponibles en el mundo informático, se presumen esenciales para una organización madura, dedicada a la industria del software, optar por alternativas emergentes o contrarias al uso de una metodología, por lo general conlleva ha resultados poco satisfactorios. En el peor de los casos conduce categóricamente a un total caos, en el que los miembros del equipo de desarrollo entran en un cierto estado de pánico, con el problema de no saber dar continuidad al desarrollo del sistema que recién les han encomendado. Algunas veces se logra salvar ligeramente ésta situación cuando un grupo de novatos en metodologías dentro del equipo de desarrollo, improvisan el diseño de un proceso de desarrollo ad-hoc; tal metodología incipiente, por así decirlo, al ser adaptaciones exprofeso, deberá ser estudiada y aprendida por todo integrante nuevo que se incorpore al equipo, representándole este conocimiento un bien endeble al momento de dejar el grupo y tratar de integrarse a otra organización desarrolladora de software, que sí tenga entre sus prácticas el uso de una buena metodología.

Aunque la mayoría de las metodologías están diseñadas para enfrentar los problemas de los equipos de desarrolladores que trabajan con grandes cantidades de

20

software, comprender los fundamentos de éstas, es esencial también para aquellos en el otro extremo, como son los desarrolladores particulares que trabajan sobre problemas pequeños y así mismo en cualquier escala intermedia hablando a nivel de producción de software. Esto a razón de que:

• Una metodología puede ayudar a imponer disciplina sobre las labores de codificación.

• Al experimentar aun en los pasos básicos o iniciales de una metodología, hará que aumente nuestra comprensión del problema, mejorando la calidad de nuestra solución.

• Escribir líneas de código, es sólo una de las muchas actividades comprendidas dentro del desarrollo de software, pero el realizar algunas de las otras actividades incluidas, nos ayuda a percatarnos de errores conceptuales y prácticos antes de que los convirtamos en código fuente.

• En cada etapa, una metodología especifica lo que deberemos hacer para la siguiente. Evitando el que daremos en un lapso sin directiva.

• La metodología nos ayuda a producir código que será extensible, reutilizable y mucho más fácil de depurar, esto garantiza la factibilidad en las modificaciones y ser aplicable a otros problemas pues la documentación estará más completa.

En los grandes proyectos de desarrollo también se obtienen beneficios tales como:

• La documentación. Todas las metodologías promueven la documentación minuciosa de cada fase en el trabajo de desarrollo, a fin de que el sistema resultante no sea monolítico e impenetrable.

• Tiempos de entrega aceptables. La distribución del trabajo, donde las actividades, funciones e interdependencias son mejor comprendidas, hay menos oportunidad para el dispendio de los recursos, entre ellos los humanos, permanezcan ociosos en tiempos muertos, a la espera de algo que hacer, propiciando pérdidas económicas.

• Grandes probabilidades de entregar a tiempo y sin sobrepasar el presupuesto.

• Mejor comunicación entre usuarios, agentes de ventas, gerentes y desarrolladores. Una buena metodología se basa en la lógica y el sentido común, por lo tanto, será fácil para todos los participantes comprender sus fundamentos; aplicando la empatía, así, tenemos un ciclo de desarrollo mucho más metódico, con un margen mínimo para ambigüedades y trabajo infructuoso.

• Factibilidad de ser reproducible. Debido a que contamos con actividades bien definidas, proyectos similares deberán ser liberados a escalas de menor tiempo y costo. Si hemos estado produciendo sistemas semejantes en repetidas ocasiones para clientes diferentes (v. g. puntos de venta para comercio electrónico), entonces podemos hacer rentable al máximo la metodología, con el fin de concentrarnos únicamente en los aspectos exclusivos para trabajos de desarrollo tanto nuevos y en proceso. Eventualmente podríamos automatizar

21

partes del desarrollo y más aún, vender dichas automatizaciones a terceros (v. g., pensando en un producto empaquetado y etiquetado como “punto de venta”).

• Estimación de costos más precisa. ésta estará en función de La paga al personal participante, los gastos por depreciación de equipos y herramientas, costos de energía, papelería y otros consumibles. Así cuando nos pregunten ¿Cuánto costará? Nos veremos menos tentados a contestar con otra pregunta típica como ¿Cuánto ofrece?

Una buena metodología se ocupará por lo menos de las siguientes cuestiones:

• La planeación. Decidir qué necesidades se deben satisfacer.

• La planificación de Tiempos. Establecer para cuándo estarán hechas las cosas mediante una calendarización.

• Los Recursos. Hacer una estimación y adquirir los recursos humanos, de software, de hardware y otros recursos necesarios.

• La Distribución del Trabajo. Las partes inmersas dentro de un amplio proyecto de desarrollo, por ejemplo, diseñar la arquitectura del sistema, modelar el problema como un todo y planear las actividades de desarrollo, entre otros.

• Las actividades. Las tareas particulares dentro de un flujo de actividades, tales como probar un componente, trazar un diagrama de clases o detallar un caso de uso, estas actividades pueden ser tan sencillas o tan elaboradas que a su vez sean consideradas para conformar un flujo de actividades en si mismas.

• Los roles. Las funciones que desempeñan cada uno de los empleados al poner en práctica la metodología y su interrelación (v. g. el desarrollador, el de control de calidad o el de diseño gráfico).

• Los entregables. Los productos del proyecto de desarrollo, como piezas de software, documentos de diseño, planes de capacitación y manuales.

• Capacitación. Decidir cómo preparar al personal en caso de ser necesario, para desempeñarse en sus respectivos roles. Así también, determinar cómo aprenderán los usuarios finales (empleados, clientes, vendedores) a utilizar el nuevo sistema.

Para los propósitos del presente trabajo, no se entrará en detalles que

corresponden a una metodología tipo industrial. En cambio, usaremos una metodología de propósito específico, conocida en el ambiente de ingeniería del software como RIPPLE, la cuál es derivada de la metodología RUP (Rational Unified Process o Proceso Unificado Rational de IBM) pero con la ventaja de que es mucho más simple. Antes de examinar RIPPLE, necesitamos tener una idea de los procesos, actividades y entregables del desarrollo de software en general.

22

1.4.1 Fases Clásicas En la producción de Software Empecemos con La pregunta, ¿qué involucra el desarrollar software?, para

contestarla nos damos cuenta de que, existe un número de fases comunes en cada desarrollo, independientemente de la metodología, comenzando con la recopilación de requerimientos para finalizar en el mantenimiento. Con los enfoques tradicionales, se espera avanzar elegantemente de una fase a la siguiente. Con las prepuestas modernas por otro lado, se tiene la libertad de llevar a cabo cada fase más de una vez y en cualquier orden.

La siguiente lista describe las fases más comunes en el desarrollo de software, se podrán haber visto nombres diferentes para algunas de éstas, pero en esencia son lo mismo. Para ventaja nuestra, pondremos especial interés en el propósito de las fases, más que en detallar el cómo realmente se podría llevar a cabo su ejecución. Se advierte, sin embargo, que algunos productores de metodologías tienden en sus propuestas a combinar fases como la de requerimientos con análisis, mientras que otros combinan análisis y diseño, por ejemplo.

Requerimientos La recopilación de los requerimientos trata de descubrir lo que queremos alcanzar

con nuestra nueva pieza de software y cubre dos aspectos. El modelado del negocio que implica entender el contexto en el cual nuestro software funcionará; si no logramos entenderlo, entonces tenemos pocas probabilidades de producir algo que agregue valor a dicho contexto. El tipo de pregunta que debemos hacernos durante la fase de modelado del negocio es, por ejemplo, ¿De qué manera un cliente de una mueblería realiza la compra de una televisión?

El modelado de requerimientos del sistema (o especificación funcional) resulta ser un medio para decidir qué capacidades tendrá el nuevo software y establecer por escrito dichas capacidades. Necesitamos dejar en claro lo que nuestro software hará y, así como también las restricciones de lo que no hará, a fin de que el desarrollo no se desvíe hacia áreas irrelevantes e identifiquemos fácilmente, tanto el momento en que hayamos terminado, como el nivel de éxito obtenido. El tipo de pregunta que nos haremos durante la fase de modelado de requerimientos del sistema es ¿Cómo es que se verá el sistema de inventarios, cuando una televisión ha sido comprada?

Análisis El análisis implica comprender esencialmente a que nos estamos enfrentando.

Antes de que podamos diseñar una solución, necesitamos tener bien claras las entidades relevantes, sus propiedades y sus interrelaciones. También necesitamos ser capaces de verificar dicho nivel de comprensión. Ya que puede involucrar a clientes y usuarios finales, y que muy probablemente serán los expertos en la materia. El tipo de cuestionamientos que nos haremos durante la fase de análisis son, ¿Qué productos vendemos en ésta mueblería? ¿De dónde vienen? ¿Cuánto cuestan?

23

Diseño En la fase del diseño, determinamos cómo solucionar el problema. En otras

palabras, tomamos decisiones basadas en la experiencia, estimación e intuición, acerca de qué software escribiremos y cómo lo implementaremos. Diseñar sistemas comienza con la descomposición del sistema general en subsistemas lógicos (los procesos) y físicos (computadoras y redes), para después decidir cómo se comunicarán las máquinas, elegir las tecnologías adecuadas para el trabajo, etcétera. El tipo de decisión que tomamos durante la fase del diseño de un sistema es "vamos a usar una intranet y Java Messaging Service (JMS) para comunicar los movimientos de ventas a la oficina central", Al diseñar subsistemas decidimos cómo separar cada subsistema lógico para convertirlo en código efectivo, eficiente y factible. El tipo de decisión que tomamos durante la fase de diseño de subsistemas son "las unidades en un inventario que serán implementadas mediante un objeto de tipo 'HashTable', referenciadas por un Identificador Único"

Especificación Esta fase, la que a menudo es ignorada, o por lo menos descuidada. Diremos que

el término especificación es usado con diferentes significados, por diferentes desarrolladores. Por ejemplo, lo que se entrega como salida de la fase de requerimientos es una especificación de lo que el sistema debe ser capaz de hacer; a la salida de análisis nos encontramos con una especificación de lo que estamos afrontando etcétera. En este trabajo, el término será usado para que se entienda como "describir el comportamiento que se espera de nuestros componentes de programación". Debido a que las técnicas de especificación descritas son esquematizadas en clases de objetos, cualquier confusión puede ser evitada usando el término especificación de clase. Una especificación de clase es una descripción clara, inequívoca de la forma en que los componentes de nuestro software deberían ser usados y cómo se comportarán si son usados correctamente. El tipo de afirmación que hacemos durante la fase de especificación es " Si el objeto 'asistente de venta' se ha conectado, puede solicitar al objeto 'tienda', la oferta especial del día; en respuesta, recibe una lista de productos, ordenados alfabéticamente".

Este trabajo presta especial atención a la fase de especificación, debido al principio básico de una metodología denominada "Design by Contract" algo parecido a "diseño por contrato". La idea crucial tras un contrato es: siempre que un objeto de software solicite los servicios de otro, tanto el "consumidor" como el "productor" contraen obligaciones por cumplir. El tener presente este esquema de contratos de software es útil durante todas las etapas del desarrollo.

El proceso de especificación puede ser usado en las siguientes formas:

• Como una base, para diseñar software orientado a pruebas que corrobore la eficacia del sistema.

• Para demostrar que nuestro software es correcto, (deseable para aplicaciones de alta disponibilidad).

• Para documentar nuestros componentes de software a tal grado que podrían ser implementados por terceros.

24

• Para describir cómo nuestro código puede ser reutilizado con toda seguridad por otras aplicaciones.

Implementación Aquí es donde hacemos el trabajo más pesado, escribir los bloques de código que

trabajan conjuntamente para formar subsistemas, que a su vez colaboran para formar el sistema completo. El tipo de tarea que llevamos a cabo durante la fase de implementación es "Escribir el cuerpo de los métodos para la clase Inventario, de tal manera que resulten conforme a su especificación previa". Aunque esperaríamos que la mayoría de las decisiones difíciles debieran estar libradas, en cuanto a codificación antes de llegar a ésta fase (es decir, durante el diseño), hay todavía bastante oportunidad para la creatividad: Aunque las interfaces públicas de nuestros componentes de software hayan sido bien diseñadas, especificadas y documentadas, los programadores aun tienen rienda suelta para explorar y decidir sobre el funcionamiento interno. Mientras el resultado final sea efectivo y correcto, todos quedarán satisfechos.

Pruebas Cuando nuestro software está completo, debe ser probado contra los

requerimientos del sistema para ver si cumple con los objetivos o metas originales. El tipo de pregunta que nos haremos durante la fase de pruebas es ¿puede un responsable de una mueblería usar la actual interfase para vender un tostador, disminuyendo la cantidad en el inventario de productos, como un efecto secundario? Así como ésta clase de test de conformidad, es una buena idea ver si nuestro software puede ser bloqueado o degradado en su servicio mediante sus interfaces externas, esto ayuda a protegernos contra el abuso accidental o malicioso del sistema cuando haya sido liberado.

Es una buena idea para los programadores, realizar pequeñas pruebas conforme avanzan, para mejorar la calidad del código que entregan. Generalmente hablando, sin embargo, las pruebas principales no deberían ser diseñadas, implementadas o llevadas a cabo por los mismos desarrolladores que escribieron tal software.

Para entender por qué, considere que compra una casa nueva y gasta cantidades inmensas de tiempo y dinero remodelándola de arriba abajo. Es poco probable que quiera golpear las estructuras e instalaciones fijas con un martillo pesado para ver si son resistentes, en su lugar, preguntará a cualquier desconocido que pase, si considera que tiene usted buen gusto, o pedirá que simule ser un ladrón e intente burlar la seguridad de su casa. Éste es exactamente el tipo de cosas que necesitamos realizar durante las pruebas de software. (Es muy útil si los miembros del equipo que hace las pruebas tienen una tendencia a la crueldad y tratan sin piedad alguna de hacer fallar a nuestro sistema).

Liberación En la fase de liberación, nos ocupamos de tener el hardware y software listo para

los usuarios finales, junto con los manuales y el material para la capacitación. Éste puede ser un proceso complicado, que implica una transición gradual y planeada, del modo en que anteriormente se trabajaba, hacia la nueva forma de hacer las cosas. El tipo de tarea

25

que llevamos a cabo durante la fase de liberación es "ejecutar el programa setup.exe en cada máquina servidor y seguir las instrucciones que aparecen".

Mantenimiento Cuando nuestro sistema es liberado, es como un "recién nacido". Una larga vida se

extiende ante el, durante la cual tiene que permanecer siempre listo para el uso diario, aquí es donde la prueba real tiene lugar. El tipo de problema que descubrimos durante la fase de mantenimiento es "Cuando la ventana de entrada al sistema se muestra, aun contiene la última contraseña introducida".

Como desarrolladores de software, estamos normalmente interesados en el mantenimiento, debido a los defectos (a veces denominados pulgas o bugs del inglés) hallados en nuestro software. Debemos encontrar tales defectos y eliminarlos tan pronto como sea posible, entregando versiones corregidas del software para mantener satisfechos a los usuarios. Así como los defectos, nuestros usuarios pueden descubrir deficiencias (cosas que el sistema debería hacer pero no las hace) y requisitos adicionales (mejoras al sistema). Desde el punto de vista de negocio, esperaríamos reparar y mejorar nuestro software a través del tiempo para así mantener ventajas competitivas.

Preguntas Clave Estas preguntas clave ayudan a recordar el propósito de cada una de las fases del

desarrollo de software:

• Fase de Requerimientos: o ¿Cuál es nuestro contexto? o ¿Qué estamos tratando de lograr?

• Fase de análisis: o ¿Con qué entidades estamos tratando? o ¿Cómo podemos estar seguros de que son las correctas?

• Fase de diseño del sistema: o ¿Cómo vamos a resolver el problema? o ¿Qué hardware y software necesitaremos para el sistema final?

• Fase de diseño de subsistemas: o ¿Cómo vamos a implementar la solución? o ¿Cuál será la apariencia del código fuente y los archivos que lo

respaldan?

• Fase de especificación: o ¿Qué normas regulan las interfaces entre los componentes de sistema? o ¿Podemos eliminar la ambigüedad y asegurar la exactitud?

26

• Fase de Implementación: o ¿Cómo podemos codificar los componentes para apegarnos a la

especificación? o ¿Cómo escribimos código elegante?

• Fase de pruebas: o ¿El sistema terminado satisface los requerimientos? o ¿Podemos bloquear total o parcialmente al sistema?

• Fase de liberación: o ¿Qué tienen que hacer los administradores del sistema? o ¿Cómo podemos instruir a los usuarios finales?

• Fase de mantenimiento: o ¿Podemos encontrar y arreglar los defectos? o ¿Podemos mejorar el sistema?

1.4.2 Metodologías Orientadas a Objetos Todos los expertos en el ramo del desarrollo orientado a objetos, están de acuerdo

en que una buena metodología es esencial para el desarrollo de software, especialmente al trabajar en equipo. Así, un buen número de metodologías han sido creadas en la última década. Ampliamente podemos decir que, todas las metodologías orientadas a objetos son parecidas, tienen fases similares y entregables similares, pero con una variedad de pequeñas diferencias. Las metodologías orientadas a objetos tienden a no ser demasiado prescriptivas. A los desarrolladores se les ha dado la opción de que usen algún tipo de diagrama particular por ejemplo. Por consiguiente, el equipo de desarrollo debe seleccionar una metodología y acordar cuales entregables deben ser producidos, antes de elaborar cualquier planeación o planificación detallada.

En general, cada metodología aborda:

• La filosofía detrás de cada una de las fases.

• Los flujos de actividades y las actividades individuales mismas dentro de cada fase.

• Los entregables que deben ser producidos (diagramas, código y descripciones textuales).

• Las dependencias o simples interrelaciones entre los entregables.

• Las notaciones para los diferentes tipos de entregable.

27

• La necesidad de modelar estructuras estáticas y comportamiento dinámico. El modelado estático implica decidir lo que serán las partes lógicas o físicas del

sistema y cómo estarán conectadas entre sí. El modelado dinámico corresponde a decidir cómo deberán colaborar las partes estáticas. Hablando en términos generales, el modelado estático describe cómo construimos e inicializamos el sistema, mientras el modelado dinámico describe cómo deberá comportarse el sistema, cuando esté en ejecución. Típicamente, producimos al menos un modelo estático y un modelo dinámico durante cada fase del desarrollo.

Algunas metodologías, especialmente las de gran amplitud, tienen rutas alternativas

para el desarrollo, orientadas a distintos tipos y tamaños de proyectos. La metodología usada en este trabajo, RIPPLE, tiene el propósito de ayudar a entender lo que involucra cualquier trabajo de desarrollo de software, ya sea de amplio o reducido espectro, pero es fácilmente aplicable al mundo real.

1.4.3 UML, RUP y XP A mediados de los 90's, las metodologías mejor conocidas eran las que fueron

desarrolladas por Ivar Jacobson [Jacobson Et Al. 92], James Rumbaugh [Rumbaugh Et Al. 91] y Grady Booch [Booch 93] . Cada uno de ellos tenía su propia compañía de consultoría, así también, usaban su propia metodología y su propia notación. Durante 1996, Jacobson y Rumbaugh se unieron a la Rational Corporation (fundada por Booch), y desarrollaron un conjunto de notaciones que se dieron a conocer como el Unified Modeling Language (UML) OMG 03a. Los "tres amigos", como se hacían llamar, donaron el lenguaje UML al Object Management Group (OMG) para su custodia y perfeccionamiento. OMG (www.omg.org) es un consorcio de la industria no lucrativa, fundado en 1989 para promover estándares abiertos para la tecnología de objetos de nivel empresarial; Su otro trabajo reconocido es CORBA OMG 04.

Algunos desarrolladores, consideran a UML simplemente como una notación que se

usa en sesiones de lluvia de ideas y para la documentación de alto nivel. Otros consideran a UML como un lenguaje de programación gráfico, y generan código a partir de él o lo sintetizan de código ya existente.

28

Cliente Servidor de Base de Datos

Cliente Cliente

DB Server

Base de Datos

GUI

Diagrama de Paquetes UML - Encapsulacion

Proxy de BD

Logica deDominio

GUI

Figura 3. Diagrama de Paquetes UML

Una vez que UML estuvo en manos seguras, los tres amigos emprendieron el

diseño de una metodología que aprovechara los mejores aspectos de su trabajo individual. A la distancia de un par de años, resultaron con la propuesta de su propio método tipo espiral, iterativo e incremental que fue llamado Rational Unified Process (RUP) [Jacobson et al. 99 ]. Como se podría esperar, RUP no es la única metodología disponible, ni la única que usa UML como notación.

Otra metodología también popular es llamada extreme programming (XP) Beck 99. XP es referida como una metodología ágil porque es sensible a cambios. XP se distingue por dos ideas radicales: El programar en parejas y el desarrollo dirigido por pruebas. Con la programación en parejas, cualquier desarrollo es efectuado por dos personas sentadas frente a la pantalla, en vez de una sola, la idea es que, en vez de mejorar la velocidad a la que es producido el software, la programación en parejas mejora la calidad de dicho software (también ayuda a los desarrolladores a acelerar su crecimiento propio, mediante el uso compartido de ideas). De acuerdo con los seguidores del desarrollo dirigido por pruebas, la ejecución continua de pruebas es tan importante que no sólo deberían realizarse por los mismos desarrolladores, si no que deberían ser escritas o diseñadas antes que el mismo código.

29

1.4.4 La necesidad de Herramientas de Desarrollo Para ser efectiva, cualquier metodología espiral, iterativa e incremental requiere una

herramienta de desarrollo que sea completa. La necesidad de corregir iterativamente los entregables de un proyecto es una poderosa justificación para el uso de una herramienta de desarrollo de software. Tal herramienta debería permitir a los miembros del equipo destinado al proyecto, producir los entregables para luego almacenarlos, mejor dicho, debería soportar:

• La posibilidad de rastreo. Registrar las conexiones entre un entregable y los derivados de este, por ejemplo, registrar el subsistema particular que dio origen a un grupo de clases implementadas. La mayor parte de la información de rastreo será capturada por los desarrolladores antes que inferida por la herramienta.

• Llevar el Histórico de cambios. Registrar los cambios hechos a los entregables, quien hizo los cambios y cuando. Donde sea factible (esto es, con entregables tipo texto) la herramienta debería poder proveer un resumen de las diferencias entre una edición del entregable y otra.

• Control de acceso multiusuario. Asegurarse de que el acceso simultáneo a los entregables no cause problemas. Hay tres mecanismos pertinentes aquí: La autorización, controlar quien puede leer los entregables y quien los puede editar; Lectura multiusuario – edición mono usuario, sólo permitir que un desarrollador a la vez edite un entregable o grupo de entregables, pero permitir que todos los usuarios autorizados puedan ver la versión no editada; Versionado, permitir a cualquier número de desarrolladores editar un entregable, cada uno produciendo una versión distinta del mismo en cualquier momento, pero sólo una versión será la oficial.

• Redundancia reducida. Asegurar que nunca se tenga que actualizar nada en más de un lugar. Típicamente, la misma información aparecerá en varios entregables de inmediato. Si tenemos una herramienta, ésta puede considerar a los entregables como proyecciones alternativas en un mismo modelo.

• Verificación de consistencia. Asegurar que un entregable es consistente con sus entregables relacionados. No siempre es posible hacer cumplir la consistencia. Por ejemplo, en un mundo ideal, una herramienta podría comprobar que el código escrito para un método está sujeto a su especificación, pero aún las computadoras modernas simplemente no pueden hacerlo (es demasiado difícil, hasta imposible), Aún en los casos donde la herramienta pueda forzar la consistencia (o rastreo en todo caso), el desarrollador debe tener la posibilidad de desactivar tal verificación. Por ejemplo, un desarrollador podría querer llevar clases de la fase de análisis a la fase de diseño, mientras otro podría preferir iniciar el diseño con un conjunto completamente nuevo de clases: Cualquier herramienta que requiera que toda clase resultante en análisis aparezca en el modelo de diseño sería de gran ayuda para el primer tipo de desarrollador y un obstáculo para el segundo.

• Operación en red. Proveer acceso a todos los entregables de cualquier máquina en la red destinada al proyecto. Actualmente, la mejor plataforma para operaciones en red es TCP/IP, la base de todos los protocolos que operan por Internet e Intranets particulares.

30

• Probar los entregables que producimos conforme vamos avanzando. El caso más obvio se da cuando el código de implementación es probado para medir su efectividad y exactitud, pero el principio puede ser aplicado también a otros entregables (como en el caso de registrar los resultados obtenidos de una revisión de diseño).

La Rational Corporation desarrolló una herramienta llamada Rose, basada en RUP

y UML. Rose se convirtió probablemente en la herramienta de desarrollo orientada a objetos mejor conocida. En 2003, Rational fue comprado por IBM y la herramienta ha sido remodelada como un conjunto modular de productos y se llama ahora Rational Application Developer. Por supuesto, Existen muchas herramientas de desarrollo disponibles, los productos de Rational son mencionados aquí solo por su perspectiva histórica.

1.4.5 Diagramas UML Como UML, la notación estándar de facto, es usada a lo largo de este trabajo, se

puede tener la certeza de que los diagramas que se generen, describirán patrones de comportamiento similares a los encontrados en el mundo real. En RIPPLE, la notación UML es utilizada siempre que así es posible. UML tiene 13 tipos de diagrama. La especificación UML no dice dónde deberían ser usados estos diagramas para una metodología en particular, por lo tanto tendremos la libertad de usar cualquiera que consideremos apropiado sobre cualquier etapa. Ente ellos:

• Los Diagramas de Caso de Uso que catalogan las distintas formas en que es usado un sistema.

• Los Diagramas de Clase muestran clases y cómo pueden ser ensambladas en conjunto (también pueden mostrar objetos).

• Los Diagramas de Objetos solo muestran objetos y cómo pueden ser integrados.

• Los Diagramas de Actividades exhiben acciones de humanos u objetos en modo similar a un diagrama de flujo.

• Los Diagramas de Estado de Máquina exponen los diversos estados de cualquier objeto con un ciclo de vida que causa interés o que es un tanto complicado.

• Los Diagramas de Comunicación muestran los mensajes enviados y recibidos entre objetos dispuestos en algún escenario.

• Los Diagramas de Secuencia exponen información de forma similar a los diagramas de comunicación, pero enfatizando secuencias en vez de conexiones.

• Los Diagramas de Paquetes exhiben como es que las clases relacionadas son agrupadas juntas, para beneficio de los desarrolladores.

31

• Los Diagramas de Despliegue muestran máquinas, procesos y entregables implementados para un sistema terminado.

• Los Diagramas de Componentes muestran componentes reutilizables (objetos o subsistemas) y sus interfaces.

• Los Diagramas de Visión General de Interacción resaltan pasos individuales de una actividad usando diagramas de secuencia.

• Los Diagramas de Tiempos exponen restricciones precisas de tiempo para mensajes y estados de objetos.

• Los Diagramas de Estructura Compuesta muestran cómo los objetos se integran conjuntamente en una agregación o composición, resaltando las interfaces y objetos que colaboran.

<<actor>>System

Tarea

Tarea

Tarea

Tarea

Tarea

Tarea

<<Usa>>

<<Usa>>

<<Extiende>>

<<Extiende>>

Actor

Figura 4. Diagrama de Caso de Uso.

32

Como se verá posteriormente, algunos de los entregables de RIPPLE se basan en UML y algunos no. Esto es simplemente porque UML no cubre todo. En gran medida, solo nos permite dibujar imágenes de nuestro código. Para los entregables que no son cubiertos con UML, se usa una notación alternativa. A pesar de que ésta notación es no convencional, su contenido se basa en teorías y prácticas ampliamente aceptadas.

Se ha visto cómo las fases clásicas encajan perfectamente dentro de una metodología orientada a objetos ideal, que aprovecha los mejores aspectos de las propuestas espiral, iterativa e incremental.

En la siguiente sección se discutirá sobre patrones de diseño, pues nos permiten tomar ideas de implementación a partir de las propuestas más comerciales.

1.5 Model-View-Controller Los patrones han sido desarrollados para la plena organización de aplicaciones,

algunas veces llamados patrones arquitectónicos. En ésta sección, se analizará un patrón arquitectónico que se precia de ser de gran utilidad para organizar proyectos en diferentes formas, simplifica su codificación y su mantenimiento.

Los patrones de diseño son en esencia algo así como recetas para solucionar

problemas genéricos de codificación. No son algoritmos, sino más bien principios organizacionales para el software. La idea de usar “patrones de diseño” para solucionar problemas comunes de la ingeniería del software tomo importancia por primera vez dentro de la publicación del libro Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional, 1995), de Erich Gamma, Richard Helm, Ralph Johnson, y John Vlissides. Los autores acreditan una publicación Previa, A Pattern Language for Building and Construction (Oxford University Press, 1977) del Arquitecto Christopher Alexander, como inspirador de la idea de los patrones de diseño de software

Model-View-Controller (MVC) surgió como patrón arquitectónico para el desarrollo

de interfaces gráficas de usuario en entornos Smalltalk. Muestra una buena forma de describir la separación entre la parte de un programa que interactúa con el usuario y la parte que se encarga de la carga pesada, el procesamiento de datos numéricos, u otra operación de negocio de la aplicación. MVC se aplica típicamente a gran escala, cubriendo capas completas de una aplicación incluso extendiéndose a otras capas. A continuación, se presentará este patrón.

33

Vista Controlador

Modelo

Figura 5. La Arquitectura Modelo/Vista/Controlador.

El patrón MVC identifica tres roles los cuales un componente en el sistema puede

cumplir. El Modelo (Model) es la representación sobre el dominio del problema que se pretende solventar con la aplicación, el tópico contra el que se va a trabajar. Un procesador de textos modelaría un documento; Una aplicación de mapas modelaría puntos como en un plano cartesiano, curvas de nivel, etcétera, dicho de otro modo, el modelo contiene la lógica de negocio de la aplicación. La vista (View) es la parte del programa que presenta cosas al usuario, formularios de entrada, imágenes, texto, o los llamados widgets (símbolos gráficos que habilitan la interacción entre el usuario y la computadora). La Vista o presentación no forzosamente debe ser gráfica. En un programa de reconocimiento de comandos de voz, por ejemplo, los comandos o solicitudes habladas son la vista, en resumen, muestra al usuario la información que éste necesita durante el uso de la aplicación.

La regla de oro para MVC es que la Vista y el Modelo no deben interactuar. Tomado

literalmente esto, sería como hablar de un programa bastante disfuncional, pero aquí es donde el Controlador (Controller) entra en acción. Cuando el usuario presiona un botón o llena un formulario, la Vista llama al Controlador. El Controlador entonces recibe e interpreta la interacción del usuario, maneja el Modelo, para que en caso de ser necesario, provocar cambios de estado en la representación interna de los datos y después decidir si dichos cambios en el Modelo precisan una actualización de la vista. Si es así, le Indica a la Vista cómo transformarse.

34

Controlador

Vista

Modelo

1. Interacción

2. Modifica3. Notifica Cambios

4. Actualiza Vista

Figura 6. Componentes Principales de MVC.

La ventaja de esto es que el Modelo y la Vista permanecen desvinculados, es decir,

el uno tiene mínimo conocimiento sobre el otro. Obviamente necesitan saber lo suficiente como para lograr su cometido, pero la Vista sabe del Modelo sólo en términos muy generales.

Consideremos un programa para la administración de inventarios. El Controlador podría proveer a la Vista de la funcionalidad que devuelva una lista de todas las líneas de productos correspondientes a un Id (Identificador) de categoría dado, pero dicha Vista ignora completamente el modo en que fue generada esa lista. Puede ser que la versión 1.0 del mencionado programa, mantuvo los datos usados para generar tal lista, almacenados en un simple arreglo de memoria o en un archivo de texto plano. Cuando se prueba la segunda versión del programa, se cumple con el requerimiento de manejar conjuntos de datos mucho más grandes, por lo tanto, un servidor de bases de datos con soporte relacional debió ser integrado a la arquitectura. Las implicaciones de este cambio en el Modelo serían significativas, y una gran cantidad de código necesitaría ser reescrito. Mientras el Controlador continúe entregando una lista de líneas de productos correspondientes a una categoría, el impacto en el código de la Vista sería nulo.

De la misma manera, los ingenieros que trabajen sobre la Vista estarán en plena

libertad para mejorar la utilidad de la aplicación sin preocuparse por romper con asunciones ocultas dentro del Modelo, siempre y cuando se apeguen a las convenciones básicas sobre las interfaces que les provee el Controlador. Dividiendo el sistema en subsistemas, MVC provee una "póliza de seguros" contra cambios menores que pretendan difundirse directamente a través del código base y habilita al equipo detrás de cada subsistema para responder rápidamente sin que alguno se vea afectado por la presión del otro.

35

1.5.1 Struts Struts implementa mediante java el patrón de arquitectura MVC. Es un framework

que extiende dicho lenguaje mediante varias jerarquías de clases implementando o enriqueciendo la funcionalidad y gracias a que es un código abierto, tales clases y su funcionalidad pueden ser extendidas.

Ventajas y Utilidad Siendo el propósito de todo framework, agiliza y hace más simple la implementación

de la arquitectura siguiendo el patrón MVC. Esté patrón, separa claramente lo que es la gestión del workflow (flujo de trabajo) de la aplicación, del modelo de objetos de negocio y así también de la generación de la interfaz.

Struts ya cuenta con el controlador implementado, llamémosle un servlet

especializado, aunque de ser necesario, se puede heredar y extender o hasta modificar. El workflow de la aplicación se programa en un archivo XML y las acciones que se

ejecutarán sobre el modelo, deberán ser implementadas con base en clases que están ya predefinidas por el mismo framework y siguen el patrón Facade (fachada).

Para poder generar la interfaz de usuario, se utiliza un conjunto de Tags (etiquetas)

que están también predefinidas por Struts y su finalidad es no caer en el uso de los llamados Scriptlets (segmentos de código Java dispuestos entre "<%" y "%>") embebidos en una JSP, todo esto genera ventajas en el mantenimiento y un alto desempeño.

En términos de logística y administración de recursos, separa de forma clara el

desarrollo de cada una de las partes de ésta arquitectura, como es interfaz, workflow y lógica de negocio, permitiendo el desarrollo de éstas por personal especializado en cada área y además en paralelo.

También es evidente que potenciará la reutilización, soporte de múltiples interfaces

de usuario (HTML, SHTML, WML, Aplicaciones de Escritorio, etc.) y de múltiples idiomas, localismos, etc.

36

JSP + Tags Struts(Vista)

ActionForm Subclase paraValidación de Formularios

(Controlador)

Action Subclase paraLógica de Negocio

(Controlador)

Struts-Config.xml ParaControl de Flujo y

Configuracion

POJOs para Acceso aDatos/ Persistencia

(Modelo)

Figura 7. Correspondencia Struts con MVC.

Licencia Lo mejor de este framework es que la licencia Struts se encuentra publicada entre

otras licencias, como "free-to-use-license" por la Apache Software Foundation(ver http://www.apache.org/licenses/), siempre que se respeten los acuerdos enunciados en sus documentos.

El patrón MVC es comúnmente aplicado a frameworks clásicos de aplicaciones

WEB en un modo particular, para que éstas puedan servir secuencias de páginas estáticas que componen su interfaz. En los siguientes capítulos, se proporcionará la información necesaria para comprender cómo es que los frameworks WEB tales como Struts, y/o Spring pueden propiciar una aplicación mucho más escalable y robusta.

37

Capítulo II

Adaptación de las técnicas

2.1 Manuales de Procedimientos (Integración). En este capítulo, como primera parte se describe el contenido de un Manual de

Procedimientos (C.P. y C.I.A. Vera Smith, Fernando. IPN. 2003), ya sea específico para una sola área o bien que contenga descripciones de procedimientos que implican la intervención de dos o más áreas de la empresa. Se recomienda que en su formulación se contemplen los apartados siguientes:

1 Identificación. Dentro de este apartado se incluyen los siguientes datos: Nombre del área, Nombre

completo del o los procedimientos a que se refiere el manual, Nombre del departamento coordinador cuya función básica corresponda a los procedimientos señalados. Por ejemplo, para el Manual de Procedimientos de compras: La Dirección o Departamento de Compras, Número de identificación de los procedimientos, en su caso, Lugar y fecha de elaboración, Número de revisión, Responsables de su elaboración; Cantidad de ejemplares impresos.

2 Índice o Contenido. Es una relación de las partes o capítulos que constituyen la estructura del

documento, señalando la numeración progresiva que facilite su localización. 3 Presentación. Contiene una explicación para el lector o usuario, sobre lo que es el documento, los

propósitos que se pretenden cumplir a través de él. Además, se incluye información sobre el área de su aplicación, a quién va dirigido, cómo se usará, cómo y cuándo se realizarán las revisiones y actualizaciones.

4 Objetivo de los Procedimientos. Debe contener una explicación del propósito que se pretende cumplir, con los

procedimientos presentados en el documento. 5 Áreas de Aplicación. Este apartado contiene una relación de las áreas que intervienen en los

procedimientos, así como la delimitación precisa de sus respectivas responsabilidades. La presentación de dichas áreas deberá seguir el orden en que intervienen dentro del procedimiento.

38

6 Políticas o Normas de Operación. A fin de facilitar el cumplimiento de las responsabilidades, de las distintas áreas que

participan en el desarrollo de los procedimientos, es necesario determinar en forma explícita las políticas, criterios o lineamientos generales que les permitan realizar sus actividades, sin tener que consultar constantemente a los niveles jerárquicos superiores. Este apartado puede presentarse por áreas o responsabilidades.

7 Descripción de las Operaciones. Se deben presentar por escrito, en forma descriptiva y secuencial, cada una de las

operaciones a realizar dentro de un procedimiento, explicando en qué consisten, cuándo, cómo, con qué, quién, dónde, en cuánto tiempo se hacen, señalando los responsables de su ejecución. Se recomienda utilizar el formato CBMP-02 procurando que la descripción, dé respuesta a las preguntas señaladas anteriormente. Cuando la descripción del procedimiento sea general, y por lo mismo comprenda varias áreas, debe indicarse el área encargada de la ejecución de cada actividad. Si se trata de una descripción detallada dentro de una sola área, debe indicarse el puesto del responsable de la ejecución de cada operación. Es necesario codificar las distintas operaciones de manera que se facilite su comprensión e identificación aún en los casos de varias alternativas para una misma operación.

Casa Brasil SA de CVCalle Analco No. 2 C.P.7419 San Pedro Yancuitlatpan

San Nicolas de los Ranchos, Pue.

Procedimiento Para :

Área Descripción de la actividad1. Área y/oDepartamento

1. Actividad Realizada Por el Área

Figura 8. Formato para la elaboración del proceso descriptivo

Por lo antes expuesto, es recomendable seguir los siguientes pasos para la

descripción de las actividades:

39

a) Enunciarlas siguiendo un orden cronológico. b) Precisar las actividades contestando las preguntas señaladas con anterioridad. c) Disponer la lectura resaltando encabezados. d) Claridad y seriedad en la redacción, buscando que la misma sea positiva. e) Utilización de apoyos como anexos.

8 Diagramas de Flujo Los diagramas de flujo representan en forma gráfica, la secuencia en que se

realizan los pasos de un determinado procedimiento, o el recorrido de personas, formatos o materiales. Muestran las áreas responsables y los puestos que intervienen para cada operación descrita en él y hasta podrían indicar el equipo que se debe utilizar en cada caso. Como se menciona anteriormente, se emplean principalmente en el análisis de los procedimientos los cuales son presentados en forma sencilla y accesible dentro del manual, proporcionan una síntesis descriptiva de conjunto para facilitar su comprensión.

Las distintas operaciones de que se compone un procedimiento pueden estar

representadas en los flujogramas, mediante símbolos convencionales o dibujos simples. La selección de dichos símbolos, están en función del procedimiento que va a presentarse en las gráficas y el propósito de aplicación a las mismas, para lo cual existen, como se ha comentado, diversas técnicas de diagramación.

La simbología ASME (American Society of Mechanical Engineers) es una técnica

tradicional y de las más utilizadas para el análisis detallado de procesos o bien para aplicar una Reingeniería de Procesos.

40

SÍMBOLO SIGNIFICADOOperaciónIndica las principales fases por las cuales pasa un proceso, método oprocedimiento.Por lo Común, el insumo se modifica durante el avance de la operación.

InspecciónIndica que se verifica la calidad, la cantidad o bien los procesos de operación;este punto es importante analizarlo antes de su implementación ya que si seabusa de el podría generar retrabajos o desperdicio por una inspección noaprobada, es decir, se debe analizar detalladamente el momento idóneo paraaplicar la inspección en el proceso y no abusar de ella

TransporteIndica el Movimiento de los trabajadores, materiales y equipo de un lugar a otro

Depósito provisional o EsperaIndica demora en el desarrollo de los hechos: por ejemplo, trabajos ensuspenso entre dos operaciones sucesivas, o abandono momentáneo noregistrado de cualquier objeto hasta que se requiera. Este paso puede serparte del proceso o no estar programado.

Almacenamiento permanenteIndica depósito de un objeto bajo vigilancia de un almacén donde se le recibe oentrega mediante alguna forma de autorización o donde se guarda con fines dereferencia.

Actividades CombinadasPara indicar que varias actividades son ejecutadas al mismo tiempo o por elmismo operario en un mismo lugar de trabajo, se combinan los símbolos detales actividades. Por ejemplo, un circulo dentro de un cuadrado representa laactividad combinada de operación e inspección.

Retrabajo o producto no conformeConsiste en repetir un paso de operación, ya sea por errores humanos,materiales o partes defectuosas o procesos mal diseñados.R

Figura 9. SIMBOLOGÍA ASME (Se utiliza como base para el análisis de procesos).

Esta simbología es aplicable sobre una hoja de trabajo de análisis de procesos, la

cual ayuda a describir cada paso, mostrando el símbolo correcto, colocándolos en la secuencia lógica, para registrar las medidas apropiadas

41

# ACTIVIDAD SÍMBOLO DEFLUJO MIN

123456789

101112131415

R

Figura 10. Hoja de trabajo para el análisis de procesos

PASOS ANTES DESPUÉS

PASOS MINUTOS PASOS MINUTOSOperación

Transporte

Demora o Espera

Inspección

Almacenamiento

Retrabajo

TOTAL

R

Figura 11. Resumen del proceso

Se recomienda manejarla en la descripción de los procesos prioritarios, que para nuestro caso corresponden a los que se refieren al punto de venta con el cliente final de la empresa y el manejo de inventarios de producto; integrados en los Manuales de Trámites de venta y cobranza y los de movimientos internos.

La simbología ANSI (American National Standar Institute) es empleada en las técnicas de procesamiento electrónico de datos, utilizada ampliamente por los fabricantes y técnicos de las computadoras. Por lo tanto, ésta técnica es la más sencilla de aplicar sobre los procedimientos que involucran el quehacer administrativo.

42

SÍMBOLO REPRESENTA

PROCESAMIENTO: Función del proceso.

Se debe describir de manera breve la actividad dentro delsímbolo.

DECISIÓN: Punto del flujo en donde es posible seguir caminosalternativos.

Se indica la pregunta en el interior del símbolo y en los extremoslas respuestas planteadas que reflejarán el flujo a seguir. lasrespuestas pueden ser SI, NO o bien A, B, C, Según la gama deopciones.

ALMACENAMIENTO: Almacenar la información.

Se señala directamente al símbolo, la línea de flujo que provienedel documento o forma a archivar

CONECTOR DE PÁGINA: Usado en vez del signo conector paraindicar entrada o salida desde o a una página.

En la parte superior se indica con numero arábigo, la hoja de lacual continúa o proviene el flujo. la parte inferior refleja el numerode conector de página que se esta utilizando.

DOCUMENTO: Forma o Reporte Impreso.Se debe indicar el nombre oficial del documento original, y en elmargen inferior, el numero de copias y cuando la actividad dedistribución se realice, se enunciaran las áreas a las que sedistribuyen.

INICIO O TÉRMINO: Indica en dónde se Inicia o dónde se terminaun flujo.Se deberá anotar la palabra Inicio o Término en el interior delsímbolo.

CONECTOR DE FLUJO: Conectar una parte de un diagrama deflujo con otra.

Se señala con un numero arábigo progresivo, según secomporten el procedimiento y las relaciones entre las áreas.

FLECHAS: Conectan los símbolos señalando el orden en que sedeben realizar las distintas operaciones.

Deberá reflejarse como una línea continua terminada en puntade flecha, que va unida a símbolos para continuación del flujo.

Figura 12. SIMBOLOGÍA ANSI (Esta simbología se utiliza principalmente para el procesamiento electrónico de datos, por lo que en la descripción de procedimientos no todos se usan en la elaboración de los diagramas de flujo)

43

Algunas recomendaciones importantes (Franklin Fincowsky Enrique Benjamín, FCA-UNAM) a tomar en cuenta en la elaboración de los diagramas de flujo, son:

a. Determinación de áreas y puestos, en la descripción de la operación. b. Usar las figuras y líneas de la misma dimensión y grosor. c. Las líneas deberán indicar con las flechas el flujo de las actividades

secuenciales que se presentan en el procedimiento. d. Colocar tantas columnas como las áreas involucradas en el procedimiento. e. Hacer uso de los conectores de línea o de hoja, según sea el caso, a fin de

evitar el cruce de líneas de flujo. f. Señalar en el símbolo relativo al documento, el nombre oficial del formato

original y en su caso, en el margen inferior el número de copias que contiene.

9 Formatos o impresos. Las formas impresas que se utilizan dentro de un procedimiento también deben

formar parte del manual, ya sea intercalándolas de manera descriptiva en el procedimiento en que se originan, o incluyéndolas como anexos del mismo. En la descripción de las operaciones que impliquen el uso de formularios o impresos, deben hacerse referencias precisas a través de claves de identificación.

Específicamente en el apartado de la descripción de la actividad, las formas utilizadas, señalando su nombre oficial o clave, las copias que se manejan y la distribución de las mismas hacia las áreas que las conservan.

Los formatos deben contener las especificaciones y colores oficiales que determine la Coordinación encargada del proyecto de formalización de los manuales, así como manejar estrictamente las copias necesarias.

Los responsables de la elaboración de los Manuales de Procedimientos en las distintas áreas podrán apoyarse y solicitar información y/o asesoría técnica a la Coordinación antes mencionada.

2.2 Metodología para preparar un diagrama de flujo de actividades En el apartado anterior se presentaron algunas características esenciales para

documentar un diagrama de flujo de actividades, dentro del manual de procedimientos; en este segmento se propone un método sencillo a seguir (Franklin Fincowsky Enrique Benjamín, FCA-UNAM), para obtener un diagrama de flujo completo y que cumpla con el propósito al que está orientado de manera eficaz, este método indica los siguientes puntos:

Propósito. Analizar el sentido en que se va a utilizar el diagrama de flujo registrando cada particularidad en un escrito. Colocar este documento en un lugar

44

siempre a la vista, como una pared, para ser consultado en cualquier momento con el fin de verificar constantemente que el diagrama de flujo es apropiado y se mantiene congruente a sus aplicaciones.

Determinar el nivel de detalle requerido. Clasificando claramente procesos y subprocesos, de tal manera que sea fácil identificar los casos en que sea necesario. Dejar el diseño de un diagrama maestro en estatus completado, para continuar con el diseño de un diagrama de detalle y así de lo general a lo particular.

Figura 13. Análisis y Nivel de detalle en Procesos

Definir los límites. Identificando el momento en que las actividades por plasmar pertenecen a otro proceso y este puede ser considerado totalmente independiente. Después de establecer los límites del proceso, enumerar los resultados (outputs) y los clientes o consumidores del resultado en el espacio a la derecha del diagrama. Elegir símbolos apropiados al propósito del diagrama, como buena práctica comúnmente se comienza dibujando los resultados en el diagrama. Para cada entrada realizar las preguntas tales como:

¿Quién recibe o consume los insumos del proceso? ¿Qué se realiza con las entradas como primer paso?

MACROPROCESO

MICROPROCESO

PRO

CE

SO

45

Documentar cada paso, se puede comenzar ya sea con el primero o con el último paso, respetando su secuencia cronológica. Para cada paso, es requerido hacer preguntas como:

¿Qué resultados produce este paso? ¿Quién va a recibir este nuevo resultado generado? ¿Qué paso en el proceso es el que sigue? ¿Alguno de los otros pasos se alimenta de resultados producidos por el actual y que aun no se han representado?

Continuar y Terminar el diseño del diagrama de flujo de actividades, hasta que encontremos que se han conectado todos los resultados definidos al inicio y dispuestos a la derecha del diagrama con el resto de la estructura. Si se encuentra un segmento del proceso que es extraño para todos en el equipo de diseño de flujos, se toma nota en algún documento de trabajos pendientes y continuar la construcción del diagrama para no generar retrasos. Revisar y Preguntar:

¿Todos los insumos y resultados del proceso se corresponden a cada flujo de información? ¿Se capturaron de forma concisa las actividades como ocurren en la realidad? Pues sería un error mostrar las cosas como se piensa que deberían ocurrir o como originalmente fueron pensadas.

Determinar oportunidades, iterando ente los pasos anteriormente realizados y documentados, realizando los cambios pertinentes.

El diagrama de flujo resultante deberá fungir como un registro fiel de la manera en que el proceso actualmente opera, Indicado en su fecha de creación.

Consideraciones generales para su elaboración:

• Definir el proceso que se va a diagramar para su análisis, eligiendo la nomenclatura que sea adecuada al mismo.

• Definir quién es el propietario de ese proceso.

• Definir el resultado esperado para el cliente o beneficiario del proceso.

• Listar las actividades del proceso.

• Elaborar el diagrama de flujo empleando los símbolos establecidos.

46

Figura 14. Carta de proceso

En cuanto a dibujo, estas son unas de las recomendaciones para el buen uso de los

símbolos independientemente de los elegidos:

• Un símbolo no deberá tener varias líneas de entrada y salida por un mismo lado • Para la unión entre dos símbolos, usar solo una línea de entrada y salida. • Las líneas de unión son siempre representadas con líneas rectas • El símbolo que puede tener una línea de entrada y dos de salida, es el de decisión. • Es importante respetar la uniformidad en el tamaño de los símbolos.

Casa Brasil SA de CVNombre del Proceso:

Propietario del Proceso:

Carta de Proceso Fecha:

Factores aControlar Actividades Responsable Resultados

Esperados

Insumos,Datos,Contexto,Normas,Información,Previsionespara lasActividades.

PersonalEspecíficosegún cargo

Lo que queremosobservar alrealizar laactividad.

Inicio

Fin

Actividad

Decisión Actividad

Actividad

47

2.3 RIPPLE En ésta sección se presentan versiones orientadas a objetos para todas las fases

clásicas del desarrollo de software y se identificará la manera, en que éstas encajan perfectamente sobre una metodología orientada a objetos. Debido a que la orientación a objetos es muy accesible, los desarrolladores estarán involucrados en todas las fases. Los clientes pueden ser incluidos durante las primeras etapas, lo cual es de gran ayuda a los desarrolladores para cumplir con su trabajo; los gerentes tampoco quedan fuera del mundo de los desarrolladores, así la comunicación es mucho mayor.

A continuación se propone una visión general de RIPPLE (Mike O’Docherty, 2005) la metodología simplificada que se emplea en este trabajo. Este es un resumen de los entregables, que se deberían producir por cada fase. Para generar estos entregables, se procede como es mostrado en seguida, pero recordando dirigir las actividades en forma espiral, iterativa y liberar incrementalmente:

1. Concepción del Proyecto (Con el cliente)

a) Hacerse una idea de lo que el cliente busca o convencerlo de lo que necesita.

b) Obtener documentación de los requerimientos del cliente, como el enunciado que describe su misión o alguno otro documento más completo. Si ninguno de estos existe, entonces realizar un documento informal de requerimientos con el cliente.

2. Asignación de Responsabilidades

a) Decidir sobre los roles de desarrollo, por ejemplo en el planteamiento de la planeación, la administración de tiempos, el desarrollo, las pruebas y la administración del sistema.

b) Definir quién será responsable de cada rol. 3. Realizar un Cuaderno de Trabajo: Producir un escrito o un cuaderno electrónico, que contenga todos los entregables del proyecto. 4. Realizar un Glosario

a) Hacer un glosario en el que se registren las definiciones para la terminología usada en el proyecto.

b) Actualizar dicho glosario durante todo el proceso de desarrollo. 5. Elaborar un Plan de Proyecto

a) Llevar a cabo una planeación inicial que considere el flujo de actividades en modo espiral, sus fases e incrementos y producir una agenda.

b) Revisar y ajustar el plan de proyecto a intervalos regulares durante todo el proceso de desarrollo.

6. Elaborar un Plan de Pruebas: Diseñar un plan de pruebas que contemple evaluaciones continuas, las fases de donde se harán las mismas, revisiones o aprobaciones por parte del cliente; su extensión después de su liberación y mantenimiento por un periodo convenido.

48

7. Requerimientos de Negocio (Con el Cliente)

a) Elaborar una lista de actores dentro del negocio (con descripciones). b) Realizar una lista de casos de uso envueltos dentro del negocio (con

descripciones). c) Llevar a cabo sesiones de lluvia de ideas o ilustrar casos de uso de

negocio con diagramas de actividades. d) Llevar a cabo sesiones de lluvia de ideas o ilustrar casos de uso de

negocio en ésta ocasión usando diagramas de comunicación. (Opcional) e) Elaborar detalles de Casos de Uso de negocio.

8. Requerimientos de Sistema (Con el Cliente)

a) Llevar a cabo sesiones de lluvia de ideas sobre la interacción del sistema usando bosquejos de interfaces de usuario.

b) Producir una lista de actores involucrados dentro del sistema (con descripciones).

c) Elaborar una lista de casos de uso del sistema (con descripciones). d) Realizar un diagrama de casos de uso del sistema. e) Conformar un informe o desarrollo de casos de uso del sistema. f) Exponer detalles de casos de uso del sistema. g) Describir los requisitos suplementarios para el sistema. h) Definir prioridades entre casos de uso del sistema.

9. Análisis

a) Elaborar diagramas analíticos de clases. b) Conformar una lista de atributos (con descripciones). c) Usar máquinas de estados para modelar ciclos de vida complejos sobre

entidades, registrando los resultados en diagramas de máquinas de estados (Opcional)

d) Realizar un ejercicio de caso de uso, documentando los resultados en diagramas de comunicación.

e) Hacer una lista de operación (con descripciones). 10. Diseño del Sistema

a) Elegir tecnologías. b) Buscar oportunidades de reutilización (librerías, patrones y frameworks). c) Elaborar diagramas de capas. d) Escribir una política de interacción entre capas. e) Diseñar la estructura de paquetes y registrar ésta en diagramas de

paquetes.

49

f) Realizar un diagrama de despliegue. g) Escribir una política de seguridad. h) Escribir una política de concurrencia.

11. Diseño de Subsistemas

a) Definir servicios de negocio. b) Buscar más oportunidades de reutilización (librerías, patrones y

frameworks). c) Mapear las clases de nivel de análisis contra las clases de la capa de

negocio: Lista de Clases, diagrama de clases (con descripciones), lista de campos (con descripciones).

d) Elaborar un diagrama de base de datos. e) Diseñar clases para otras capas (v.g. servidor y protocolo, servlets,

control, persistencia). f) Realizar un ejercicio sobre los servicios de negocio, registrando los

resultados en un diagrama de secuencia. g) Producir una lista de mensajes (con descripciones). h) Finalizar el diseño de la interfaz de usuario.

12. Especificación de Clases

a) elaborar una especificación informal para cada clase. b) Registrar la especificación informal en diseño y en código fuente.

13. Implementación

a) Describir pruebas unitarias. b) Escribir el código de implementación.

14. Pruebas

a) Disponer a la gente capacitada y sin capacitación para probar el sistema. b) Corregir defectos.

15. Liberación

a) Elaborar guías y manuales (tutoriales). b) Instalar los entregables generados por el código sobre el sistema del

cliente. c) Capacitar o adiestrar al cliente.

16. Mantenimiento

a) Verificar la corrección de defectos detectados. b) Combinar retroalimentación por parte del cliente con ideas de mejora y

cambios en el mercado para las nuevas adiciones.

50

Entregables RIPPLE por FaseFase Entregables UML

Concepción del Proyecto Misión o Requerimientos InformalesRolesResponsabilidadesPlan de ProyectoLibro de TrabajoGlosario (se actualiza durante todo el proyecto)Plan de Pruebas

NoNoNoNoNoNoNo

Requerimientos Negocio Lista de Actores(con descripciones)Lista de Casos de Uso (con descripciones)Detalles de Casos de UsoDiagramas de Actividades (opcional)Diagramas de Comunicación (opcional)

NoNoNoSiSi

Sistema Lista de Actores(con descripciones)Lista de Casos de Uso (con descripciones)Detalles de Casos de UsoDiagramas de Casos de UsoDesarrollo de Casos de UsoBosquejos de interfaces de usuario

NoNoNoSiNoNo

Análisis Diagramas de ClasesDiagramas de Comunicación

SiSi

Diseño Sistema Diagrama de DespliegueDiagrama de Capas

SiNo

Subsistema Diagramas de ClasesDiagramas de SecuenciaEsquema de Base de Datos

SiSiNo

Especificación de clases Comentarios (Documentales) No

Implementación Código Fuente No

Pruebas Reportes de Pruebas No

Liberación Solución EmpaquetadaManualesMaterial de Capacitación

NoNoNo

Mantenimiento Reportes de FallasPlanes de Incremento

NoNo

Figura 15. Tabla de entregables RIPPLE por fase.

51

En las secciones subsecuentes, revisaremos cada una de las principales fases que se llevan a cabo antes de la liberación de código: recopilación de requerimientos, análisis, diseño de sistema, diseño de subsistemas, especificación y la fase de pruebas. La implementación será cubierta de forma parcial, pues nos enfocaremos sobre un caso de uso en particular.

La idea principal es encontrarse con que hemos recorrido a través de una espiral desde un incremento inicial (la versión 1.0, después de una espiral iterativa, en su caso). Aunque lo descrito pueda parecerse mucho a la metodología de cascada un tanto revestida de una manera más elegante, es debido a la naturaleza de todo texto impreso en el cual el contenido está siempre dispuesto de inicio a fin, sin dar muestras de repetición alguna. No está por demás dejar enfáticamente claro que, cuándo se comiencen a poner en práctica estas técnicas en sí mismas, debemos estar preparados para un trabajo en espiral, iterar actividades y liberar incrementalmente.

El empleo del caso de estudio de aquí en adelante, SICBA, no es desarrollado con el uso de un estilo cascada. Los entregables incluidos resultan de dos incrementos, cada uno comprendiendo un determinado número de espirales iterativas.

RIPPLE se describe y practica progresivamente conforme se avanza en el siguiente capítulo. Debido a que este trabajo hace énfasis sobre los entregables relacionados al software, nos enfocaremos a la recopilación de requerimientos, al análisis, del diseño así como de la especificación. También se mencionará en forma breve, sobre los glosarios, los planes de pruebas y las definiciones tales como misión. Otros aspectos, como la administración, la implementación, la liberación y el mantenimiento no serán cubiertos a gran detalle.

Aunque se verán ejemplos de diagramas de actividades y algún diagrama de máquina de estados, no serán mostrados ampliamente durante la sección dedicada al desarrollo de software. Así también, no todos los tipos de diagramas UML serán usados. Los diagramas de componentes, de visión general de interacción, de tiempos y los diagramas de estructura combinada resultan simplemente innecesarios para los propósitos de este trabajo. La mayoría de estos tipos de diagrama pueden ser expresados usando el resto de los diagramas, a diferencia de los diagramas de tiempos, los cuáles son más útiles para el diseño de hardware y software de tiempo real.

2.4 Servidor Web MVC Las aplicaciones Web no son ajenas a MVC, incluso las de la variedad clásica

basada en páginas. La misma naturaleza de una aplicación Web impone algún nivel de separación entre la Vista y el Modelo, debido a que comúnmente están distribuidas en máquinas diferentes. Entonces cabe la pregunta, ¿Una aplicación Web sigue intrínsecamente el patrón MVC?, O puesto de otra manera, ¿Es posible escribir una aplicación Web que reúna a la Vista y al Modelo en una misma masa confusa? Desafortunadamente, si, es muy fácil, y la mayoría de desarrolladores Web probablemente lo han hecho en algún momento, incluido el autor del presente trabajo.

La mayoría de los partidarios de MVC en la Web consideran a la página HTML generada, y el código que la genera, como la Vista, en vez de lo que el usuario realmente ve cuándo dicha página se presenta.

52

En el caso de una aplicación con servlets o, un servlet especializado coordinando actions, en el mejor concepto para este trabajo, con el fin de servir datos y poner en ejecución una JSP sirviéndola a un Web browser cliente, la Vista será el documento, siendo devuelto al cliente sobre la respuesta HTTP. Separar el documento generado de la lógica de negocio precisa entonces un poco de disciplina.

La arquitectura Model-View-Controller, se basa principalmente en la separación del modelo de datos de una aplicación, de la presentación que se entrega al usuario, así como de la interacción que tiene éste último con la aplicación, mediante la división de la aplicación en sus tres partes fundamentales. Ésta arquitectura es muy apropiada para las aplicaciones Web ya que se adopta fácilmente utilizando las tecnologías disponibles para la plataforma J2EE, de modo que:

El Modelo, al contener puramente la lógica de negocio, es implementado por un conjunto de clases Java, existiendo como alternativas básicas, los objetos java tradicionales denominados POJOs (Plain Old Java Objects) o utilizando los llamados EJBs (Enterprise JavaBeans) para sistemas con mayores requerimientos de concurrencia o de aplicaciones distribuidas.

Todos los Objetos de Negocio se encuentran dentro del ámbito del Modelo, en estos se implementa la lógica de negocio, así como deberán soportar plenamente los requisitos funcionales del sistema, evitando mezclar estas reglas de negocio con partes correspondientes al workflow, cuyo lugar se encuentra en el Controlador.

Action Bean

Los Action Beans por lo general están entendidos para realizar dentro de su alcance, lo siguiente:

• Obtener los valores que están dispuestos como su entrada desde un Action Form, un JavaBean, de request o de sesión, según sea el caso.

• Realizar los llamados necesarios a objetos de negocio del Modelo enviando los valores tomados.

• Recuperar los resultados y dependiendo de algún parámetro en estos, devolverá un Action Forward como resultado.

Business Logic Beans

En los objetos de negocio se implementa la, de igual forma llamada, lógica de negocio, las reglas de cómo se realizan las tareas y de cierta manera su persistencia. Estos objetos no tendrán ningún conocimiento de la Vista o el Controlador, de tal forma que sin mayor ajuste serán reutilizables en cualquier implementación como para dar soporte a distintas interfaces y hasta para incluirse en nuevas aplicaciones.

Acceso a Bases De Datos Con Struts se puede definir un origen de datos o dataSource para una

aplicación, configurándolo en el archivo struts-config.xml. Este dataSource nos permite obtener una conexión a base de datos desde un Action y desde allí utilizarla o

53

transferirla al Modelo, no obstante es buena práctica utilizar otros frameworks como iBATIS que incluye mapas configurables utilizando objetos relacionales y objetos de acceso a datos.

Vista 1

Vista 2

Action Servlet(Controlador)

Action 1

Action 2

Action 3

Action 4

Modelos

Figura 16. Implementación struts de MCV.

La vista entrega dinámicamente al usuario o cliente resultados en la forma de

páginas Web, siendo para él simples páginas HTML. Existen actualmente varios frameworks que ayudan a generar dichas páginas Web y en distintos formatos, encontrándose las páginas JSP (Java Server Pages) en mayor frecuencia de uso, pues mediante un conjunto de tags XML exponen una interfaz sencilla y adecuada a las clases Java, así como a los distintos objetos que se generan mediante el servidor de aplicaciones. Facilitando su desarrollo a personas con experiencia en el uso de HTML. Entre las etiquetas o tags utilizadas en una JSP, tienen especial importancia las que se encuentran disponibles en la librería estándar JSTL (Java Server Pages Standard Tag Library) pues proporcionan una gran versatilidad además de que agregan mayor funcionalidad.

La Vista comprende las JSP principalmente, pero también se pueden incluir algunos servlets que son auxiliares para la generación de la interfaz con el usuario o con otros Sistemas. Cabe señalar que Struts soporta también la construcción de aplicaciones cuya presentación puede mostrarse en distintos idiomas, así también, la interacción con

54

formularios en modo wizard (asistente), entre otras utilidades aprovechando la integración de Tags especiales (TagLibraries).

Forms

La interacción con formularios es una de las tareas que durante el desarrollo de una aplicación requiere de mucho trabajo, ya sea para editar o recopilar información, comprobaciones, el manejo de errores, o para presentarle el mismo Form al usuario con los valores que alimentó en pasos anteriores, entre otros. Todas estas utilidades son de fácil configuración en Struts con fines de agilizar el trabajo de desarrollo.

La idea principal es que todo el trabajo de validaciones y generación de mensajes de error debe implementar en los ActionForm, y por otro lado, todo el trabajo de generación de interfaz usuario deberá recaer en las JSP.

Básicamente, para implementar la vista se pueden seguir estos pasos:

• Desarrollar el ActionForm. • Desarrollar la página JSP (paginaForm.jsp) para el formulario aprovechando las

Tags disponibles en Struts. • Declarar o configurar el ActionForm en el archivo struts-config.xml para esto, se

agrega en la rama /struts-config/form-beans la etiqueta <form-bean name="nombreForm" type="paquete.clase"/> y en la declaración del Action agregar los atributos name="nombreForm", scope="request|session", e input="paginaForm.jsp".

Tags

Es necesario saber qué es una Tag de struts en JSP y cómo funciona, para lograr su dominio y aprovechamiento, por tanto podemos decir que consiste en una etiqueta con formato <prefijoTagLib:nombreTag atributo=valor ... >, cuando la JSP se compila, ésta etiqueta es sustituida por una llamada a la clase TagHandler que es encargada de resolver su funcionalidad.

El TagHandler extiende a BodyTagSupport si se trata de una etiqueta que contiene un cuerpo o TagSupport si es una etiqueta simple, dichas clases implementan en su funcionalidad los métodos doStartTag(), doEndTag(), doInitBody(), doAfterBody() según sea el caso, además incluyen métodos getters y setters correspondientes a los atributos particulares. Ésta clase TagHandler está definida en un archivo xml con extensión TLD(Tag Library Definition) donde se establece el nombre de la etiqueta, la clase TagHandler que la resuelve, la definición de sus atributos, si tiene body, etc. A su vez el archivo TLD se debe declarar en el archivo de configuración web.xml, dentro de <web-app> escribiendo la etiqueta <taglib> <taglib-uri> nombreTagLib </taglib-uri> <taglib-location>/directorios/nombreArchivo.tld </taglib-location> </taglib>, además se registra también en la JSP donde se utilizará (<%@ taglib uri="nobreTagLib" prefix="prefijoTagLib" %>). Finalmente, la Tag que se usa en la JSP consiste, como ya se mencionó, en <prefijoTagLib:nombreTag atributo=valor ... >

55

HiperLinks/Action Forwards

Formularios HTML/Action Forms

Acciones Habituales/Action Beans

Figura 17. Componentes Principales de Struts.

Los objetos llamados servlets integran la implementación del controlador, y su

trabajo es proporcionar el medio de comunicación entre la vista y el modelo, al estar escritos como clases Java normales, evitan mezclar código visual (HTML, XML...) con código Java, como suele ocurrir con las JSPs. Nuevamente encontramos que Struts es el framework que facilita la implementación de tales servlets, pues una amplia comunidad de desarrolladores ha adoptado fácilmente su concepto de Actions y lo ha establecido como un estándar en su producción de software.

Toda la funcionalidad involucrada desde que un usuario genera un evento (click en

un link, envío de un formulario, etc.), hasta que se genera la interfaz de respuesta, está soportada por el Controlador. En el lapso intermedio, llamará a los objetos de negocio integrados al Modelo, para que resuelvan la funcionalidad inherente a la lógica de negocio y dependiendo del resultado de ésta funcionalidad, se ejecutará la JSP correspondiente para generar la página con la respuesta al usuario.

El framework de Struts incluye un servlet especializado que a partir de lo que se

configure en el archivo struts-config.xml, recibe las peticiones del usuario o su navegador, realiza un llamado al ActionBean correspondiente para finalmente ejecutar una JSP en respuesta a la petición original. Para lograr esto, las tareas que se deben realizar son:

• Desarrollar una clase que extiende de org.apache.action.Action.

• Configurar dicha clase en el archivo struts-config.xml tomando en cuenta su action mapping y sus forwards de salida.

o En un ejemplo sencillo de esto sería, cuando la petición es "/solicitud" el Controlador llamará a la clase SolicitudAction y si ésta retorna un ActionForward, con valor exitoso (success) entonces ejecutará la jsp “/vista.jsp”. Si la respuesta del action está asociada a un formulario entonces se debe definir un FormBean, un ActionMapping con el FormBean asociado y los forwards necesarios, aunque también se puede definir un global-forward que, como su nombre lo indica, tiene la particularidad de ser un forward aplicable a todos los action-mappings (a excepción de que se redefina algo distinto para un forward en particular).

• En las JSPs habrá que ubicar los enlaces utilizando la etiqueta <html:link> o los formularios utilizando la etiqueta <html:form>, para completar el ciclo.

56

ActionForm Beans

Los ActionForm Beans son clases que extienden a ActionForm y deben implementar métodos get y set para cada una de los inputs de un form de una página, adicionalmente pueden también incluir los métodos validate y reset.

Java Server Page JSP tags Objeto ActionFormatealos Datosa Desplegar

Recopilalos Datos

Figura 18. Struts regresando datos a la vista.

Cuando un usuario completa un formulario y lo envía, el Controlador busca

en el scope configurado en el struts-config.xml, su ActionForm Bean correspondiente, en caso de no encontrarlo lo crea. Luego utiliza los métodos set de cada input o campo del form para llenar sus datos para finalmente llamar al método validate. Si éste último regresara como respuesta uno o más errores, el Controlador llamaría a la JSP del formulario para que ésta vuelva a generarse en pantalla, con los valores que el usuario ingresó anteriormente, incluyendo adicionalmente los mensajes de error correspondientes. Cuando todos los datos son correctos, llama al método perform de la clase Action, enviando como parámetro el ActionForm Bean para que sea utilizado en la obtención de los resultados de procesamiento.

Aunque un ActionForm parece contener características que corresponden al

Modelo, los ActionForm pertenecen a la Vista. Uno de sus puntos comunes es la validación de datos, por ello, para evitar la duplicidad de funcionalidad, si desde un ActionForm se deben realizar controles de validación, que deberían implementarse en un objeto de negocio, entonces se puede utilizar una instancia de éste para ejecutar tal tarea.

Cuando se desarrolla un ActionForm es preciso tomar en cuenta los siguientes puntos:

• No debe contener métodos o funciones que correspondan a la lógica de negocio.

• Los únicos métodos a implementar son getters, setters y en su caso incluyendo los de reset y validate.

• Debe representar un modo de barrera entre el usuario y el Action, deteniendo todo tipo de errores por inconsistencia de datos en campos obligatorios.

• Si el formulario completo tiene que desarrollarse en paginas separadas (v.g., en las interfaces de tipo "Wizard"/Asistentes) el ActionForm y el Action deberán estar integrados como uno mismo, permitiendo así, que los campos de entrada puedan reorganizar se en distintas páginas sin tener que cambiar los ActionForm ni los Action.

57

Una vez comprendido lo anterior, se puede resumir que el funcionamiento de una aplicación web diseñada con apego al patrón arquitectural MVC, puede ser desglosado en los siguientes pasos:

1. El usuario ejecuta una acción en su navegador, la cual alcanza al servidor mediante una petición HTTP y es recibida por nuestro Servlet especializado (el Controlador). Este se encarga de analizar la solicitud, seguir lo programado en su archivo de configuración XML realizando un al Action correspondiente y pasándole los parámetros enviados. El Action instanciará y/o utilizará los objetos de negocio para tratar de concretar la tarea, lo cual se puede referir como la ejecución de código java, delegando al modelo la ejecución de una acción.

2. El modelo recibe las peticiones y parámetros del controlador, a través de una interfaz o fachada que encapsula y oculta la complejidad del modelo al controlador. Después de realizar la tarea de negocio, el resultado de dicha petición retornado al controlador.

3. El controlador recibe el resultado y tomando en cuenta algún parámetro del mismo, elije la vista para ser mostrada al usuario, proporcionándole los datos recibidos además de otros datos requeridos para su transformación a HTML. Con esto realizado, es cuando el control pasa a los objetos que conforman la vista para la ejecución de tal transformación.

4. En la vista se realiza cierta transformación con los datos recibidos del controlador, generando una respuesta HTML correspondiente y tal que el usuario visualiza los resultados.

Solicita Página

Acciones del Usuario Actions de Struts

Llena elFormulario y lo

Envía

Visualiza lasiguiente Página

Reemplaza conTags de Strus y

Envía

EjecutaValidaciones

Simples

Ejecuta Lógica deNegocio

Arroja la siguientePágina

Si

No

Errores?

Figura 19. Ciclo de vida de procesamiento de una página típica Struts.

58

Puesta en marcha En Struts Como en muchos tipos de framework, se cuenta con una librería de

clases y una serie de configuraciones; por lo que su instalación es muy similar en cualquiera de los servidores de aplicaciones, que provean o que tengan la factibilidad de agregarse de soporte para:

• Java Development Kit (version 1.2 o posterior). • Servlet Container (version 2.2 o posterior). • JavaServer Pages (JSP) (version 1.1 o posterior). • XML Parser compatible con Java API for XML Parsing (JAXP) specification, 1.1 o

posterior. • JDBC 2.0 Optional Package Classes.

La instalación consiste en:

1. Obtener y descomprimir una distribución binaria del framework struts, la cual puede ser descargada de http://struts.apache.org/index.html.

2. Copiar las siguientes librerías en el directorio WEB-INF/lib de la aplicación: a. lib/commons-*.jar (clases comunes de Jakarta), b. lib/struts.jar (JAR de las clases Struts) y c. lib/struts-*.tld (Tag Library Descriptors de los Tags de Struts),.

3. Modificar el archivo de configuración WEB-INF/web.xml de la aplicación para incluir un elemento "<servlet>", que definirá al Servlet del Controlador y un "<servlet-mapping>" que establezca las diferentes formas de peticiones que serán atendidas por éste.

4. Ubicar un archivo ".properties" que contendrá los mensajes de la aplicación en la estructura: com.empresa.aplicacion.ApplicationResources

5. Modificar el archivo de configuración WEB-INF/web.xml de la aplicación para incluir la definición de las TagLibraries

6. Agregar la definición de las TagLibraries en las JSPs donde se utilicen. 7. Crear un archivo de configuración struts-config.xml donde se configura el

Controlador según se vio en secciones anteriores.

59

ServletAction

JSPJSP

Form

Action

Página Inicial(JSP/HTML)

struts-config.xml

Submit

Response Response

Figura 20. Panorama General de Struts.

En este capítulo se han descrito los métodos o procesos, a través de los cuales se

entiende debemos dirigir las actividades encaminadas, a la consecución de los objetivos "materiales" por así decirlo, del presente trabajo. En adelante se pretende mostrar, con formato de reporte, un conjunto de entregables los cuales son generados durante el ciclo de vida del proyecto de desarrollo planteado en un principio, buscando, siempre que sea posible, el apego al orden en que se fueron creando bajo las pautas de la metodología correspondiente.

60

Capítulo III

Resultados y Entregables

3.1 Actividades, Funciones Y Responsabilidades Área De Sistemas El área de sistemas es en principio una entidad de reciente Incorporación a la

empresa, por lo cual no están bien delimitadas sus funciones. Pero dentro de las que se han ido identificando sobre la marcha, junto con algunas que son planteadas como proyecto, pueden ser resumidas en:

• Soporte técnico a usuarios.- Resolver las dudas que se presentan en cuanto al uso de algún programa o archivo (Excel, Word, PowerPoint, etc.).

• Soporte técnico de Hardware.- Resolver problemas de mal funcionamiento en equipos.

• Mantenimiento de Hardware.- Es muy importante cuidar que las computadoras estén en el estado óptimo para su funcionamiento; este tipo de mantenimiento previene o corrige daños físicos en los equipos.

• Mantenimiento de Software.- Los programas de computadora, aunque actúan como una parte intangible par los usuarios, requiere de ser mantenidos mediante algunas técnicas, que van desde la realización de ajustes, o reinstalación y que suele llegar hasta su reemplazo.

• Configuración de red.- Ésta requiere mantener una estructura de tal modo que los recursos como son Archivos, Carpetas, Impresoras, etc.; y que sean compartidos, estén al alcance del usuario en un modo más transparente.

• Configuración de impresoras.- Esto como parte de la configuración de red o como parte de mantenimiento de software, puede considerarse una actividad independiente pues aquí convergen los dos problemas más comunes de configuración debidos a los tipos de usuarios, en cuanto a controladores se refiere. Como consecuencia del cambio de ubicación de las impresoras, por ejemplo.

• Configuración y administración de la conexión a Internet.- El requerimiento de mantener una conexión estable y configurar el acceso al exterior es muy importante, para garantizar la comunicación y proteger la información interna. Un modo de conexión segura puede fallar debido a problemas externos o internos, estas actividades de configuración pueden formar parte de la administración de la red y tiene muchos aspectos que se deben vigilar, como los accesos a sitios no seguros, los cuales derivan en intrusiones por virus como los denominados “troyanos”.

• Apoyo a las diferentes áreas, en cuanto al mejoramiento y agilización del proceso de la información. Esto implica un análisis de lo que se hace, cómo se hace y en que situaciones un programa de computadora puede mejorar dicho proceso, en este caso se ha estado usando Excel como programa de soporte, no obstante el

61

enfoque que se da a las hojas de cálculo elaboradas, es con miras a la implantación o implementación sobre un programa hecho a medida.

• El análisis del flujo de la información entre los diferentes módulos o departamentos que conforman a la empresa. Necesario para la estandarización de entradas y salidas de información y así diseñar un buen diagrama de flujo de actividades y la información que como producto en estas actividades se genera.

• Diseño de diagramas de flujo de información.- El desarrollo de sistemas, está muy íntimamente ligado a la estructura real en el flujo de la información de la empresa, de hecho depende de que este tenga un modelo físico en el mundo real bien especificado, por eso se requiere del diseño de diagramas de flujo de actividades, que a su vez marcan la pauta para el flujo de la información.

• Desarrollo del sistema de información.- Buscando la automatización del antes mencionado flujo de información, la tarea de desarrollo debería ser realizada una vez que el diagrama de flujo de la información estuviera bien definido, no obstante debido a las necesidades de la empresa este desarrollo también puede llevarse a cabo mediante una implantación de prototipos consistentes, mientras se van realizando tareas de refinamiento de diagramas de flujo de actividades y siguiendo la metodología adoptada.

• Proposición de soluciones alternativas. para mejorar el flujo de la información es bueno tener en mente que durante el desarrollo de sistemas, siempre se van a identificar cuellos de botella o destinos ambiguos en el flujo de la información, hasta la misma información puede presentarse en forma ambigua. De tal suerte que llega un momento en el cual se torna difícil generar informes confiables a la gerencia, se duplican actividades y se pierde tiempo en recuperar información. Por lo tanto se deben buscar soluciones o modos de proceder alternativos para solventar dichos problemas.

A grandes rasgos, estas son algunas de las necesidades que se tienen que

satisfacer día a día durante el trabajo que se nos ha planteado. En cuanto al análisis del flujo de la información, en la siguiente sección veremos algunos de los documentos generados al formular los manuales de procedimientos, incluidos los diagramas de flujo, para posteriormente mostrar también los entregables considerados importantes obtenidos del proceso de desarrollo del software.

3.1.1 Organigrama Como se describió brevemente en el primer capítulo, el siguiente organigrama,

correspondiente a la fecha que indica su elaboración, nos sirvió como punto de partida y de inmersión, por así decirlo, para conocer el entorno de nuestro cliente.

62

GerenteGeneral

nómina

Pagos

Ventas

Cobranza

Proveedores

Viajes

Responsable

Ayudante

Tesorería Compras yServicios

AlmacénGeneral

Logística ySistemas transportes Taller

Chofer

Ayudante

Carpintería x(2)

Supervisión

Línea Blanca x(2)

Contabilidad

Mueblería x(10)

Camioneta X(4)

Ruta x (12)

Responsable

Vendedor x (2)

Ayudante x (2)

Vendedor

Ayudante

TalleresForáneos

Responsable

Cobranza x (2)

Almacen x (2)

Casa Brasil SA de CVCalle Analco No. 2 C.P.7419 San Pedro Yancuitlatpan

San Nicolas de los Ranchos, Pue.

Organigrama: Estructura General 01/12/08

Figura 21. Organigrama en Casa Brasil.

3.2 Manual de Procedimientos (Documento Resultado) Siendo un producto extraído del análisis de procesos y procedimientos, así como

del diseño de diagramas de flujo de actividades, se presentan fragmentos del documento formal, con lo cual se trata de ejemplificar el seguimiento de las técnicas aprendidas en la primera mitad del capítulo II.

63

Casa Brasil SAManejo y Control del Almacén

Manual de Procedimientos CBMP-ALM01

Manual de Procedimientospara el Manejo y Control del Almacén

Equipo Coordinador: Administración y Logística de Almacén

Responsable: Alberto Popoca Salazar

ID del Documento: CBMP-ALM01

Elaboración: San Pedro Yancuitlalpan, San Nicolás de los Ranchos

Puebla. 24 de enero de 2009.

Revisión: 3

Ejemplares: 5

64

Casa Brasil SAManejo y Control del Almacén

Índice CBMP-ALM01

Presentación ....................................................................................................................... IProcedimientosEntrada de productos por compra ...................................................................................... 2Entrada de productos por inventario .................................................................................. 13Traslado de producto a mueblería .................................................................................... 25Traslado de producto a camioneta .................................................................................... 33Salida de producto por venta ............................................................................................. 42Salida de producto por inventario ...................................................................................... 51

…

Firmas de autorización ....................................................................................................... II

65

Casa Brasil SAManejo y Control del Almacén

Presentación CBMP-ALM01

La coordinación de administración general de Casa Brasil SA establece como unode sus principales directivas, lograr la concreción de una empresa moderna que ofrezcamejores productos y servicios.

Para lograr los niveles de productividad, eficiencia, eficacia y calidad que todocliente espera, es necesario que los departamentos y/o sucursales cuenten con unmarco administrativo que detalle las actividades que de manera sistemática realizan lasáreas y personas que las integran.

Con tales propósitos de claridad de orden, el equipo encargado del análisis ymejora de procesos elaboró el manual de procedimientos para el manejo y control delalmacén, como guía de quién y como se realizan las actividades, a través de las cualesse da cumplimiento a las responsabilidades atribuidas a cada cual según reglamentosinternos.

El presente documento es el resultado del trabajo conjunto del equipo de análisisy de las personas que dirigen las actividades de operación real y para cada procesocomprende los siguientes apartados:

Descripción de procedimientos. Señala el nombre, objetivo, normas y descripciónnarrativa y gráfica (diagramas de flujo de actividades) de las rutinas de trabajodesarrolladas por el personal involucrado en sus diferentes áreas.

Descripción narrativa. Expresa el orden, de manera lógica, detallada y secuencialen que se desarrollan las actividades de un procedimiento y señala quienes son losresponsables de su ejecución.

Diagramas de Flujo de Actividades. Es la representación gráfica de unprocedimiento.

Finalmente se encontrará adjunta la sección de firmas de autorización a travésde las cuales se precisa la responsabilidad de cada departamento en la elaboraciónrevisión y autorización del documento.

I

66

Casa Brasil SAManejo y Control del Almacén

Procedimiento CBMP-ALM01

Nombre: Traslado de producto a muebleríaObjetivo: Asegurar que las personas y departamentos involucrados realicen el movimientode productos que representan una salida para el almacén general y una entrada a mueblería,con estricto apego a las políticas y normas establecidas en Casa Brasil SA, llenando losformatos correspondientes y reportando oportunamente tanto los movimientos como laseventualidades que puedan surgir, para contribuir a que el control de dispersión de productosalcance el nivel deseado.

Áreas de aplicación:Almacén general

TransporteMueblería

Logística y sistemas

Políticas o normas de operación

Los productos en el conjunto a traspasar a la salida del almacén deberán estardebidamente etiquetados sin excepción alguna. En caso de que al conformar este grupo deproductos, se encuentre que existe alguno sin etiqueta se deberá levantar un reporteinmediatamente con su jefe directo para tomar las medidas correspondientes.

Los formatos que respaldan el Traslado deberán estar completos y debidamente llenadosy firmados. Estos documentos quedarán bajo el resguardo de los interesados y girando la copiacorrespondiente al departamento de logística y sistemas para su registro.

Los productos en el conjunto a traspasar a la entrada de la mueblería deberán estardebidamente etiquetados sin excepción alguna. En caso de que al revisar este grupo de productosse encuentre que existe alguno sin etiqueta se deberá levantar un reporte inmediatamente con sujefe directo para tomar las medidas correspondientes.

Se deberá realizar una doble revisión, de ser posible por distintas personas, al conjuntode productos a traspasar tanto en el almacén general como en la mueblería.

Elaboración Ene/2009 Elaboró Revisó AutorizóAutorización Ene/2009 Logística de Almacén Logística y Sistemas Director General 25

67

Casa Brasil SAManejo y Control del Almacén

Traslado de producto a mueblería CBMP-ALM01Área Actividad Descripción

1

2

2.a

2.a.1

3

4

5

5.a

5.a.1

5.b

5.c

5.c.1

Genera solicitud, vía telefónica, de un producto o conjunto de productos pararesurtido por traslado, al departamento de logística y sistemas.

Consulta en el sistema de control de almacén (SICBA), las existencias.

En caso de no completar el paquete solicitado, se inicia el procedimiento derastreo y/o resurtido de producto ya sea recurriendo al tipo de traslado queaplique ó, a una compra.

Si el paquete solicitado aun sigue incompleto, el responsable de logísticacomunica al responsable de la mueblería una entrega parcial.

Acepta la entrega parcial dándose por enterado que inicia los procedimientosnecesarios para un resurtido en estatus pendiente*.

Imprime listado del conjunto de productos a traspasar y lo entrega al responsablede almacén general.

Recibe listado y gira instrucciones para conformar el conjunto de productos atraspasar.

El personal de almacén localiza y reubica los productos a traspasar hacia la zonadesignada(área de embarque), procurando mantener la etiqueta identificador decada producto, de tal modo que se facilite a la vista.

Si el conjunto de productos está incompleto, se procede como en el paso anteriorhasta completarlo.

El responsable de almacén general llena el formato de traslado, registrando eneste cada una de las claves o códigos de identificación correspondientes a losproductos a traspasar.

El responsable de almacén general realiza una primera revisión al paquete atraspasar, corroborando los datos y productos que su formato respalda.

Si existen incongruencias, se procede a llenar un nuevo formato como en el paso5.b.

26

Mueblería

Logística ySistemas

Mueblería

Logística ySistemas

AlmacénGeneral

68

Casa Brasil SAManejo y Control del Almacén

Traslado de producto a mueblería CBMP-ALM01Área Actividad Descripción

5.d

6

6.a

6.b

6.b.1

6.c

6.d

6.e

6.d

6.d.1

6.d

7

7.a

7.b

El responsable de almacén se pone en contacto con el personal de transporte,entregando el conjunto de productos y el formato que lo respalda, tododebidamente firmado.

Recibe el formato y realiza una segunda revisión del conjunto de productos atraspasar.

Si existen incongruencias, se lo comunica al responsable de almacén, el cualprocede como en el paso 5.b.

El responsable del transporte firma el formato de traslado y entrega la copiaamarilla al responsable de almacén general.

El responsable de almacén recibe y resguarda el documento.

El personal de transporte carga su unidad con el conjunto de productos atraspasar.

El transporte se traslada a la mueblería destino.

El personal de transporte descarga el conjunto de productos a traspasar.

El responsable del transporte realiza una primera revisión de los productos queentregará a la mueblería.

Si existen incongruencias se lo comunica a logística y sistemas, iniciando elprocedimiento de rastreo de productos* y/o deslindando responsabilidades.

El responsable del transporte entrega el formato de traslado al responsable demueblería.

El responsable de mueblería realiza la segunda revisión de los productos que vaa recibir.

Si existen incongruencias se lo comunica a logística y sistemas, iniciando elprocedimiento de rastreo de productos* y/o deslindando responsabilidades.

El responsable de mueblería firma el formato de traslado, conserva la copiaverde y entrega el restante al responsable del transporte.

27

Mueblería

AlmacénGeneral

Transporte

Transporte

69

Casa Brasil SAManejo y Control del Almacén

Traslado de producto a mueblería CBMP-ALM01Área Actividad Descripción

8

9

9.a

9.b

9.c

El responsable de mueblería gira instrucciones para ubicar su producto segúnsus procedimientos de mostrador o almacenamiento en bodega*.

El responsable de transporte se traslada a las oficinas centrales, presenta ladocumentación del traslado al responsable de logística y sistemas.

El responsable de logística y sistemas pone el sello de "entregado" a la copiacorrespondiente y la entrega al responsable de transporte.

El responsable de transporte recibe y resguarda su copia.

Fin

El responsable de logística y sistemas gira instrucciones para iniciar elprocedimiento de captura o registro del movimiento, así como del resguardo deldocumento que lo ampara.

Fin del procedimiento

28

Transporte

Transporte

Logística ySistemas

Logística ySistemas

70

Casa Brasil SAManejo y Control del Almacén

Diagrama de Flujo de Actividades CBMP-ALM01Mueblería Logística y Sistemas Almacén General

29

Genera Solicitud

Consulta SICBA

Completo?

Acepta entrega parcial Propone entrega parcial

Imprime y Entregalistado de Productos

Proceso Resurtido

Recibe listado

Mueve Productos azona de embarque

Completo?

LLena Formato deTraslado

Primera revisión deproductos

Congruente?

Entrega Formato Firmadode Traslado y Productos

1

Inicio del Procedimiento

4

4

3

Si

Si

Si

No

No

NoResurtidoo Parcial?

71

Casa Brasil SAManejo y Control del Almacén

Diagrama de Flujo de Actividades CBMP-ALM01L & S Almacén General Transporte

30

Recibe Formato Firmadode Traslado y Productos

Segunda revisión deproductos

Congruente? Reporta Incongruencias

1Firma y entrega copiarecive y resguarda

documento

Carga Productos enUnidad

Se traslada a Destino

Descarga productos

Primera revisión deproductos

Congruente?Rastreo de productos(Responsabilidades)

2

Reporta Incongruencias

2

Entrega Formato Firmadode Traslado y Productos

4

41

3

3

4

Si

Si

No

No

72

Casa Brasil SAManejo y Control del Almacén

Diagrama de Flujo de Actividades CBMP-ALM01Mueblería Transporte Logística y Sistemas

31

Recibe Formato Firmadode Traslado y Productos

Segunda revisión deproductos

Congruente? Reporta Incongruencias

2

Firma, resguarda yentrega respectivamente

Recibe FormatoFirmado de Traslado

Ubicar Productos enMueblería

Se traslada a OficinasCentrales

Entrega Documentacionde Traslado

Recibe Documentacionde Traslado

Sella de Entregado enFormato

Entreaga Copia deTraslado Sellada

Recibe Copia deTraslado Sellada

Fin

Captura y Registro deMovimiento (Resguardo)

Fin del Procedimiento

3

3

2

2 2

2

1

4

1

Si

No

73

74

Casa Brasil SAManejo y Control del Almacén

Firmas de Autorización CBMP-ALM01

Elaboró

_____________________________________José Alberto Popoca Salazar

Responsable de Compras y Servicios(con funciones de Administración y Logística de Almacén)

Revisión y Colaboración

_____________________________________Anabel Popoca Cerezo

Responsable de Logística y Sistemas

_____________________________________Demetrio Ramírez TequitlalpanResponsable de Almacén General

_____________________________________Hector Popoca Huilotl

Responsable de Transporte

_____________________________________Oscar Popoca Huilotl

Coordinación de Mueblerías

Autorización

_____________________________________Adelaido Popoca Huilotl

Director General

II

75

3.3 Entregables RIPPLE En las siguientes secciones, se mostrarán fragmentos de documentación que

intentan evidenciar el seguimiento del desarrollo de software apoyándonos en la metodología RIPPLE; así también, se verán ejemplos de algunos diagramas UML que son aprovechados por RIPPLE y empleados en el desarrollo de SICBA. Sin embargo, se deberá tener en mente que la notación UML, como muchos de los estándares integrales, es muy amplia. Por consiguiente, bajo razones prácticas, solo serán mostrados los fundamentos de tal notación, dejando fuera de este contexto algunos de los detalles más finos. Siempre que se revise un diagrama durante este trabajo, se mantendrá en mente que UML nos permite suprimir la información que no sea relevante en determinado caso y evitar discusión. Por ejemplo, si en un diagrama solo se ven cajas etiquetadas cuando una clase está siendo discutida, no se asumirá que tal clase no tiene atributos o métodos. Una vez establecido lo anterior, entramos en materia:

3.3.1 Requerimientos de negocio En seguida se documentará parte del modelado de los requerimientos de negocio

recopilados durante la fase correspondiente del desarrollo del SICBA, en términos de la misión del proyecto y el modelo de casos de uso del negocio.

Misión La siguiente descripción, es tomada a manera de misión para los usuarios del área

administrativa en Casa Brasil SA, redactada y entregada al iniciar el desarrollo del proyecto SICBA.

"Una vez que hemos comprobado las ventajas de un sistema de información para la cobranza, hecho a medida, disponible en red y explotando el uso de bases de datos. Encontramos que, de cierta manera, al controlar rutas y el flujo de ingresos que de estas se obtiene, se ha logrado impulsar y agilizar la captación de dinero, reflejándose esto directamente a la recuperación de inversión, la solvencia para costos de manejo y la obtención de beneficios o ganancias un tanto razonables.

La gerencia se propone abordar el tema para dar solución a uno de los grandes problemas que impiden completar el ciclo de control de la información y recursos, es decir, la fuga tanto de productos, como de deudores. Por tanto se planea que, mediante un nuevo sistema de inventarios, éste sea capaz de monitorear la dispersión de productos entre las posibles ubicaciones así como sus responsables, una bitácora de flujos y movimientos de productos inclusive las modificaciones permitidas para estos, con la finalidad de que se logre el seguimiento de un producto, desde su ingreso a los activos de la empresa, dígase una compra, hasta el momento de la entrega con el cliente y, más aún, el tener la capacidad de ser relacionado directamente con la cobranza; controlar también la antigüedad de saldos, identificando los clientes buenos, regulares o morosos. Así mismo tener un panorama general de la recuperación de inversión y el comportamiento de las ventas de productos.”

76

Lista de Actores

• Usuario Administrador. La persona que supervisa lo relacionado al manejo de la información del almacén y cuenta con privilegios de acceso a la misma.

• Usuario. La persona que captura información y genera reportes o informes de forma periódica y bajo demandas específicas.

• Cliente. Solicita información del producto, en su caso genera la orden de compra y es el destinatario final de un producto.

• Responsable. En su momento es quién resguarda el producto y rinde cuentas sobre su estado.

• Transportista o Medio. Mueve el producto de un origen a un destino.

• Vendedor. Promueve la venta con base a la información existente sobre los productos.

• Cobrador. La persona que realiza la captación de pagos por abonos periódicos de los clientes.

• SI-COB. Sistema de información sobre los respectivos contratos de compra venta y de cobranza general; ya existente del cual se obtiene información de la captura de los pagos realizados por parte de los clientes.

• Supervisor. Se encarga de la cobranza vencida y de negociar con los clientes morosos.

Listado de Casos de Uso.

• CU1. El cliente compra un producto. Después de solicitar información de disponibilidad y precio sobre un producto mediante un vendedor, firma un contrato y lo recibe en su casa.

• CU2. El cliente devuelve un producto. El producto es devuelto al inventario alterando el estatus del mismo de forma correspondiente, indicándose el motivo de la devolución.

• CU3. Producto reportado como perdido. Después de deslindar responsabilidades y tomar medidas al respecto, se genera una salida del inventario.

• CU4. Compra de productos. Durante la descarga del medio de transporte se etiquetan debidamente los productos y se registran en el inventario.

77

• CU5. El gerente requiere informes del inventario. Después de que el usuario llena la forma configurando el filtro de datos, recibe el resumen o listado correspondiente que incluye la ubicación o estados de dispersión de los productos.

• CU6. Mueblería solicita surtido de producto. Se valida la ubicación y existencia, se determina la logística del traspaso y se ejecuta, registrando en el sistema dicho movimiento.

• CU7. El gerente requiere información de ventas. El usuario llena la forma con el filtro de datos correspondiente, recibe en respuesta el informe solicitado.

• CU8. El jefe de almacén solicita rastreo de producto. El usuario configura una consulta en el formulario de movimientos y en respuesta obtiene un listado con las ubicaciones y responsables que han resguardado un producto desde su ingreso al inventario hasta su baja.

Estos son sólo unos de los casos de uso que se han documentado en el proyecto.

Por razones de espacio, en adelante nos vamos a enfocar en un caso de uso particular y a veces distinto en cada fase, con la intención de ejemplificar cada paso o proceso en el presente trabajo.

Diagramas de Comunicación en un Caso de Uso Este tipo de diagramas no se usaron ampliamente en el modelado de

requerimientos de negocio (aunque se aprovecharon en gran medida durante la recopilación de requerimientos de sistema). No obstante, elaboramos el siguiente ejemplo para mostrar a los actores internos y externos involucrados en CU5. El gerente requiere informes del inventario.

InterfazSICBA

ProductosActivos

1:solicita Inventario 2:configura filtroProductos

4:entrega Reporte 3:muestra RepProductos

Gerente Usuario

Figura 22. Diagrama de Comunicación para el CU5. El gerente requiere informes del inventario.

78

Diagramas de Actividades de Caso de Uso Los diagramas de actividades se usaron y se encuentran mejor documentados en

los manuales de procedimientos, esto a nivel administrativo, para mostrar la utilidad y aplicación transparente en lo que es el desarrollo de sistemas, a continuación se reutiliza un diagrama para ilustrar los puntos más finos del caso de uso CU5. El gerente requiere informes del inventario.

(Gerente)Solicita inventario

(Usuario)Llena formulario y

envía a SICBA

(SICBA)Ejecuta consulta yregresa Listado

(Usuario)Imprime Reporte yEntrega a Gerente

Figura 23. Diagrama de Actividades para el CU5. El gerente requiere informes del inventario. Detalles de Caso de Uso CU1.El cliente compra un producto.

1. El cliente pregunta al vendedor interesado en un producto.

2. El vendedor consulta en el SICBA para existencias y precios de referencia en su local o mueblería.

79

3. Sí el producto está disponible el vendedor procede a firmar la venta y entregar el producto o sugiere su entrega a domicilio.

4. Sí el producto no existe localmente y el cliente confirma su compra, el vendedor investiga con logística y sistemas para conseguir el producto desde cualquier otra ubicación.

5. Sí el traspaso del producto tomara más tiempo del que el cliente puede esperar, el vendedor sugiere la entrega a domicilio.

6. El producto llega al local o mueblería bajo los trámites correspondientes a la logística de traspasos.

7. Se genera la salida hacia la casa del cliente.

8. Se registra la venta.

3.3.2 Requerimientos de Sistema Esta sección documenta los resultados del modelado de sistema, obtenidos durante

la fase de requerimientos en el desarrollo del SICBA, en términos de bosquejos de interfaces de usuario y un modelo de caso de uso de sistema.

Bosquejos de Interfaz de Usuario. Estos fueron ideados y producidos con la ayuda del cliente o usuario final, se

muestra y detalla un flujo a continuación:

Configurar ConsultaMenú

TodosProducto:

Buscar

MenúInventario MenúLogo

Estatus: Todos

Ubicación Grupo UbicaciónTodas Todos

80

Reporte de InventarioMenú Menú Menú

Logo

Cantidad Total: xxxxx

Producto Nombre Ubicaciónclave x Producto x Mueblería xclave x Producto x Mueblería xclave x Producto x Mueblería xclave x Producto x Mueblería xclave x Producto x Mueblería xclave x Producto x Mueblería xclave x Producto x Mueblería xclave x Producto x Mueblería xclave x Producto x Mueblería xclave x Producto x Mueblería x

Inventario

Figura 24. Bosquejos de interfaz de usuario (Consulta de Inventarios). Lista de Actores

• Usuario Administrador. Persona que dirige y es responsable de las operaciones realizadas en el SICBA, tiene privilegios de acceso a información y módulos especiales del sistema.

• Usuario Capturista. Encargado especialmente del registro de cada uno de los movimientos operativos realizados en el almacén.

• Vendedor. Mediante un WEB browser (navegador WEB) tiene acceso a los formularios para consultar inventarios locales y generales.

• Usuario de Consulta Administrativa. Cualquier otra persona, particularmente de la plantilla administrativa, que requiere consultar inventarios u otros datos como los informes para análisis de ventas.

Lista de Casos de Uso

• U1. Entradas. Se capturan las compras o ingresos de productos.

• U2. Salidas. Se capturan las ventas o egresos de productos.

• U3. Traspasos. Se capturan los movimientos de cambio de ubicación o responsable en custodia de un producto.

81

• U4. Modificación a Productos. Se capturan los cambios sufridos por un producto durante su permanencia en el inventario (extiende a U9).

• U5. Mantenimiento a Catálogos. Se realizan altas, bajas y modificaciones a responsables, ubicaciones, proveedores, etc. (extiende a U9).

• U6. Cuentas por Cobrar. Se configuran consultas sobre el comportamiento de las rutas de cobranza y su labor, los clientes y antigüedad de saldos (incluye a U9).

• U7. Inventarios. Se filtran los datos para consultar disponibilidad, ubicación, existencias y dispersión de productos entre otros (especializa a U14 e incluye a U9).

• U8. Movimientos. Se tiene la posibilidad de rastreo de productos en cuanto a los lugares o responsables que los han resguardado, movimientos realizados desde alguna ubicación, etc. (especializa a U14 e incluye a U9).

• U9. Ver reportes. se visualizan los informes generados por la aplicación (extendido por U10, U4, U5 e incluido por U6, U7, U8).

• U10. Relaciona con Facturación. Se complementan los datos que vinculan una salida de almacén con una factura y sus registros de cobranza (extiende a U9).

• U11. Identificación Clave de Acceso. Se ingresa usuario y contraseña para identificarse con usuario administrador (extendido por U12 y U13).

• U12. Cambio de Claves de Producto. Se cambia el código identificador único, a un producto que haya sido capturado de forma incorrecta (extiende a U11).

• U13. Eliminar Unidades de Producto. Se elimina de forma directa, un producto, el cual no debió ser capturado y se desea limpiar todo rastro (extiende a U11).

• U14. Búsqueda de Productos. Se navega por los módulos pertinentes de la aplicación en busca de un producto o un tipo de productos (abstracto, generalizado por U7 y U8).

82

Diagrama de Casos de Uso El Diagrama de Casos de Uso para el SICBA se muestra en la siguiente figura

<<incluye>>

U1. Entradas

U2. Salidas

U3. Traspasos

U8.Movimientos

U10. Relacionacon Facturación

U7. Inventarios

U9. Verreportes

U6. Cuentas porCobrar

U5.Mantenimiento a

Catálogos

U4. Modificacióna Productos

VendedorUsuarioCapturista

UsuarioAdministrador

DIAGRAMA DE CASOS DE USO: CONTROL DE ALMACÉN

U11.Identificación

Clave de Acceso

U12. Cambio deClaves deProducto

U13. EliminarUnidades de

Producto

U14. Búsquedade Productos

UsuaroConsulta

Administrativa

<<extiende>>

<<extiende>>

<<incluye>>

<<incluye>>

<<extiende>>

<<extiende>>

<<extiende>>

SICBA

Figura 25. Diagrama de Casos de Uso SICBA.

83

Inspección de los Casos de Uso La inspección de los Casos de Uso para el SICBA, describiendo como es que los

mismos encajan perfectamente, se describe a continuación: Todo usuario capturista, podrá realizar operaciones tales como

Entradas (U1), Salidas (U2) y Traspasos (U3) de productos, así también estará encargado de enlazar mediante sus identificadores y en coordinación con el sistema de cobranza las operaciones de salida de productos, las cuales se relacionan con facturación (U10), para conseguir esto se deberá dirigir a partir de la vista de reportes (U9) conseguida después de configurar una consulta de Movimientos (U8) de salida.

Un vendedor obtendrá los reportes de su cobranza solo al configurar una consulta de Cuentas por Cobrar (U6).

Los Usuarios de Consulta Administrativa, tendrán la opción de conseguir información y localizar uno o varios productos, mediante una búsqueda de productos (U14), ya sea en los Inventarios (U7) o realizando un rastreo a través de su historia de movimientos (U8). Donde es posible ver un reporte después de configurar una consulta en los módulos mencionados anteriormente.

El Usuario Administrador será el único que contará con los privilegios sobre aspectos importantes de la información, tales como el mantenimiento a catálogos (U5); el cual está regido por un esquema en el que se parte de la vista, reporte o listado de entidades para así ejecutar Altas, Bajas y Cambios. De la misma forma, es el encargado de realizar cualquier tipo de cambio o Modificación a Productos (U4) siempre que estos estén debidamente autorizados. Los casos en los que se ve claramente el nivel de privilegios de un Usuario

Administrador, son cuando se requiere un cambio de claves de productos (U12) o la eliminación de Unidades de Producto (U13), pues para alcanzar estas opciones, es requerido que se identifique con su calve de acceso (U11).

Detalles de Caso de Uso U12. Cambio de Claves de Producto. (extiende a U11)

Precondiciones: El usuario debe ser administrador con privilegios. 1. El usuario elige herramientas misceláneas. 2. El usuario ubica el área para el cambio de claves de producto. 3. El usuario llena el campo de clave actual de producto. 4. El usuario llena el campo de clave nueva para el producto. 5. El usuario inicia el cambio. 6. El SICBA realiza y dispersa el cambio hacia cualquier registro relacionado,

existente en la base de datos.

84

Post-condiciones: El producto de ahora en adelante será identificado mediante su nuevo código dentro de todo el sistema. Rutas Anormales: a1. Si lo ingresado como código actual no existe el usuario será informado de un error, a2. Si lo ingresado como código nuevo ya está en uso por otro producto el usuario será informado de un error, a3. Si lo ingresado como código actual está incompleto el usuario será informado de un error. Requerimientos Suplementarios s1. La instalación y configuración de las máquinas cliente, debe ser mínima y transparente. s2. El SICBA debe ser capaz de almacenar, procesar y devolver grandes cantidades de datos, en el orden de los 300000 registros s3. La cantidad de usuarios simultáneos debe ser escalable sin degradar significativamente el desempeño, inicialmente se contemplan 8 usuarios locales. Prioridades en los Casos de Uso Esta es la lista de prioridades en los Casos de Uso para el SICBA, en un modo que

muestra los grados de urgencia en que fueron dispuestos para el primer incremento.

• Verde: o U5.mantenimiento a catálogos. o U1.entradas. o U2.salidas. o U3.traspasos. o U4.modificación a productos.

• Amarillo: o U7.inventarios. o U8.movimientos. o U9.ver reportes. o U6.cuentas por cobrar.

• Rojo: o U10.relaciona con facturación. o U11.identificación clave de acceso. o U12.cambio de claves de producto. o U13.eliminar unidades de producto.

Durante el primer incremento se logró completar hasta el Caso de Uso U7, el resto, en la segunda iteración.

85

3.3.3 Análisis Esta sección documenta los resultados obtenidos de la fase de análisis del

desarrollo del SICBA, en términos del modelo analítico de clases, una máquina de estados para un producto y la ejecución de Casos de Uso (diagramas de comunicación).

Diagrama de Clases El diagrama de clases de análisis para el SICBA se muestra en la siguiente figura,

la mayoría de estas clases también se documentan en el modelo de clases de diseño. Por lo que su descripción tiene lugar en tal apartado.

ProductoInventariado

1

Proveedor

ResponsableUbicacion

Puesto

VentaReportada

ManInfoUniProducto

InfoRelacionaFacturaMov

InfoMovUniProducto

InfoMiscelaneo

InfoEntradaUniProducto

GpoUbicacion

GpoProducto

FiltroVentas

FiltroProductos

FiltroMovtos

1 1 1..*1

1

1..*

*

*

* * *

*agrupa

localizadoen agrupa

resguarda

desempeña

1..*

1..*

1..* 1..*

1..*

1..*

1..*

1..** *

*

*** *

ingresa

modifica

mueve

altera

seleccionado por

vendido en

identifica

**seleccionado

por

*

1..*

seleccionadopor

seleccionadopor

genera 0..**

Figura 26. Diagrama de Clases de Análisis. Atributos Algunos de los atributos de clase para el SICBA se muestran en el siguiente

ejemplo, estos también aparecerán en el modelo de clases de diseño descritos como campos, en donde se proporcionarán tipos y descripciones.

86

ManInfoUniProducto

idUniversalfechafolioidResponsableidStsProdidGpoProdnombredescripcionprecioCompraprecioVentaidProveedorcodProvmodelocomentario

Figura 27. Ejemplo de atributos en la fase de análisis. Lista de Operación

• ManInfoUniProducto: - getCodProv()– Devuelve el código proporcionado por el proveedor.

- setCodProv(String codProv)– Asigna un valor al código proporcionado por el proveedor.

- getDescripcion()– Devuelve la descripción textual del producto.

- setDescripcion(String descripcion)– Asigna un valor a la descripción textual de un producto.

- getFecha()– Devuelve la fecha de modificación del producto.

- setFecha(String fecha)– Asigna un valor a la fecha de modificación de un producto.

- getFolio()– Devuelve el folio del documento que ampara la modificación del producto.

- setFolio(String folio)– Asigna un valor al folio del documento que ampara la modificación de un producto.

- getIdGpoProd()– Devuelve el identificador del grupo al que pertenece el producto.

87

- setIdGpoProd(Integer idGpoProd)– Asigna un valor al identificador del grupo al que pertenece un producto, creando una relación.

- getIdProveedor()– Devuelve el identificador del proveedor del producto.

- setIdProveedor(Integer idProveedor)– Asigna un valor al identificador del proveedor de un producto, creando una relación.

- getIdResponsable()– Devuelve el identificador del responsable que resguarda el producto.

- setIdResponsable(Integer idResponsable)– Asigna un valor al identificador del responsable que resguarda un producto, creando una relación.

- getIdStsProd()– Devuelve el identificador del estatus que describe la situación del producto.

- setIdStsProd(Integer idStsProd)– Asigna un valor al identificador del estatus de un producto, creando una relación.

- getModelo()– Devuelve el modelo descriptivo del producto.

- setModelo(String modelo)– Asigna un valor al modelo descriptivo de un producto.

- getNombre()– Devuelve el nombre genérico asignado al producto.

- setNombre(String nombre)– Asigna un valor al nombre genérico de un producto.

- getPrecioCompra()– Devuelve el precio de compra del producto.

- setPrecioCompra(double precioCompra)– Asigna un valor al precio de compra de un producto.

- getPrecioVenta()– Devuelve el precio de venta del producto.

- setPrecioVenta(double precioVenta)– Asigna un valor al precio de venta de un producto.

- getIdUniversal()– Devuelve el identificador único del producto.

- setIdUniversal(String idUniversal)– Asigna un valor al identificador único de un producto.

- getComentario()– Devuelve algún comentario adicional relacionado al producto.

- setComentario(String comentario)– Asigna algún valor al comentario adicional para un producto.

88

Máquina de Estados para un Producto

La siguiente figura muestra el diagrama de máquina de estados para un producto, elaborado para modelar su complejo ciclo de vida. El desarrollo de la máquina de estados que lo acompaña se describe mas abajo:

Evaluable

VendíbleReparable

Desechable

Baja

Recolectable

Entregable

normal rezagadodefectos

a corregir

defectosimposiblesde corregir

usuariocapturasalida

registray envía a

taller

recoge detaller y registra

rezagado

iniciatraspaso

transportistatoma

traspaso

terminatraspaso

venta entienda

usuario capturaventa en tienda

transportistatoma ventadomicilio

usuario capturaventa domicilio

Figura 28. Diagrama de Máquina de Estados para un Producto.

Cuando un Usuario captura una entrada de Producto, éste adquiere un primer estado de Evaluable, si está en perfecto estado es declarado con estatus normal y pasa a Vendible como producto activo. Si se encuentra con defectos menores y en condiciones aceptables es declarado con estatus rezagado y pasa a Vendible como producto activo, si tiene defectos que se pueden corregir se convierte en Reparable, si el Producto tiene defectos irreparables entonces es Desechable y catalogado como rezagado en los productos activos.

Cuando un Producto es Desechable, el usuario deberá capturar su salida inmediatamente para que este adquiera su estado de Baja en los productos

89

inactivos. Esto garantiza el registro de su historia y traza en los activos de la empresa.

Cuando un Producto es Reparable el usuario lo registra como artículo en reparación dentro de los productos activos y lo envía al taller correspondiente convirtiéndose en Recolectable. Tiempo después cuando el Producto es recogido pasa a Vendible como rezagado.

Estando el Producto como Vendible puede ser solicitado por un Vendedor ya sea en camioneta o en mueblería, esto origina un movimiento de traspaso el cual lo pasa a un estado de Recolectable, el Transportista lo recoge y lo pone en Entregable, cuando un Responsable lo recibe lo devuelve a Vendible.

Cuando un Producto Vendible es solicitado por un Cliente se inicia el procedimiento de venta y se convierte en Recolectable, según los términos acordados en la venta, si el Cliente lo requiere para entrega en tienda este lo recoge, terminando el proceso de venta cuando el Usuario captura la salida del Producto para que este adquiera su estado de Baja en los productos inactivos. Si el Cliente requiere que el Producto le sea entregado en su domicilio, entonces nuestro Transportista lo recoge, lo pone como Entregable y cuando el Cliente lo recibe se termina el proceso de venta, después de que el Usuario captura la salida del Producto para que este adquiera su estado de Baja en los productos inactivos.

El Sistema mantendrá informados a los Usuarios en lo que se refiere al estatus de los productos actuales, a fin de que puedan tener datos para tomar las decisiones apropiadas.

Ejecución de Caso de Uso

El siguiente es un Diagrama de Comunicación del SICBA, el cual verifica el modelo de clases de análisis para un Caso de Uso. En algunos casos se requirió el uso de condiciones arbitrarias entre paréntesis para indicar mensajes condicionales y el símbolo * para especificar iteración, con el fin de evitar la complejidad en los diagramas.

90

ActionMiscelaneos

ProductosActivos

1:ejecutaMiscelaneo(infoMiscelaneo)

1.1.2:[tipoMisc=1]:miscService.cambiaCodigo(infoMiscelaneo)

FormaMiscelaneos

1.1:ejecutaMiscelaneo(infoMiscelaneo)

ServiceMiscelaneo

DAOMiscelaneo

1.1.2.1:dao.cambiaCodigo(infoMiscelaneo)

1.1.2.1.1:getSqlMapClient().insert("UniProducto.cambiaCodigo", infoMiscelaneo)

infoMiscelaneo

idUniversalidUnivNuevouserNamepwdtipoMisc

Usuario Administrador

Figura 29. Diagrama de Comunicación para U12 cambio de claves de producto.

3.3.4 Diseño del Sistema

Esta sección documenta los resultados obtenidos del diseño de sistema, durante la fase de diseño del desarrollo del SICBA, en términos de la Elección de las Tecnologías, Diagramas de Capas, Paquetes y Despliegue, y Políticas de Seguridad y Concurrencia.

Elección de Tecnologías

En el lado del cliente, la elección de tecnologías está dirigida en pro de la conveniencia de él mismo, no queremos que los clientes tengan que instalar ningún software para tener acceso a nuestros servicios. También, queremos que puedan usar cualquier máquina de escritorio o Laptop, independientemente del sistema operativo que tengan instalado. La elección obvia para el ambiente del cliente, por consiguiente, es un navegador WEB. Debido a que la interfaz de usuario debe ser interactiva, para hacer una venta por ejemplo, tenemos que hacer una elección entre las tecnologías tales como HTML, Applets Java, controles ActiveX y Flash. Atendiendo a la necesidad de portabilidad

91

y la seguridad del cliente, podemos comenzar por descartar a los controles ActiveX. También, preferimos que nuestros clientes tengan acceso casi instantáneo a la interfaz de usuario y naveguen por nuestro sitio. Esto efectivamente elimina a los Applets y a Flash, ambos típicamente implican un retraso mientras la interfaz es descargada, además de lo anticuado que ahora resulta el uso de Applets. Por consiguiente, la interfaz de usuario inicial será HTML utilizando formularios, JavaScript y hojas de estilo.

Ahora, por el lado del servidor, el Servlet especializado de Struts y los Action Beans son una buena elección para procesar múltiples demandas porque son portables, son eficientes y tienen acceso a todas las facilidades de la plataforma J2EE implementándose sobre frameworks tales como Spring, Struts, iBATIS, etc.; que junto al desarrollo y configuración de las capas de negocio, servicio y acceso a datos, proveen todo lo que los Action Beans podrían necesitar (como la administración de transacciones con la base de datos). Los Scripts tradicionales muestran problemas con la portabilidad, el poder expresivo y el rendimiento; las tecnologías .Net tienen también problemas con la portabilidad.

Una vez que los Action Beans han sido configurados y están siendo usados como el punto de entrada hacia nuestros servidores, la elección obvia para producir páginas WEB dinámicas es el mecanismo de las JSP's. Todo lo anterior será configurado y empaquetado como una aplicación WEB.

Inicialmente, usaremos una implementación open-source(libre) de un servidor de aplicaciones como lo es Tomcat y de J2EE para el desarrollo y la liberación, teniendo cuidado de evitar cualquier dependencia al usar métodos propietarios a cualquier plataforma. La implementación debe soportar el reenvío de solicitudes múltiples a los Action Beans y JSPs corriendo en procesos separados, para que puedan ser accedidos directamente por las interfaces de usuario de los clientes. Si las implementaciones open-source resultan ser inadecuadas, simplemente podemos comprar un producto comercial y re liberar nuestro código sobre este.

Debido a su portabilidad, podemos liberar nuestros Action Beans en cualquier combinación de hardware y sistema operativo, para después cambiar y re liberar si es necesario. Inicialmente, se librará el software del sistema en una máquina servidor con Windows XP pues es lo que está dentro del presupuesto, proporcionando la confiabilidad y el rendimiento deseado, evitando el gasto que representa comprar un servidor con hardware de alto rendimiento y disponibilidad.

Para los datos de negocio, usaremos una base de datos MS-SQL 2000 dado que ya se cuenta con este recurso. Debido al estado del arte en la tecnología y porque nuestra aplicación está orientada a un negocio, se usa una base de datos relacional, manejando una gran cantidad de datos pero con muy poca complejidad en la lógica. La base de datos también se libera sobre el mismo servidor antes mencionado.

92

Se ha elegido el framework de iBATIS para hacer más fácil el acceso a bases de datos relacionales. Las bases de datos son complicados monstruos que pueden requerir de mucho trabajo para utilizarlas correctamente. La base de datos es responsable de manipular y modificar los datos. La razón de usar una base de datos en lugar de simples archivos planos es que una base de datos puede ofrecer muchos más beneficios, principalmente en cuestiones de integridad, desempeño y seguridad.

Integridad

La integridad es probablemente el beneficio más importante, tanto que sin ella el sistema es endeble y de poca valía. Si nuestros datos no son consistentes, confiables y correctos, entonces tienen menor valor para nosotros (hasta pueden considerarse inútiles). Las bases de datos logran la integridad mediante el uso de tipos de datos bien definidos, implementación de restricciones (Constraints) y trabajando dentro de transacciones.

Por ejemplo, en nuestras tablas podremos definir una columna como VARCHAR (25) NOT NULL. Este tipo de dato garantiza que el valor será una cadena de caracteres y que su longitud no será mayor a 25. La parte NOT NULL de la definición significa que los datos son requeridos y por tanto se debe proporcionar forzosamente un valor para ésta columna. Un ejemplo de restricción puede ser UNIQUE, la cual garantiza que para una columna dada en una tabla, un valor en particular podrá ser usado sólo una vez. Otra clase de restricción utilizada es FOREIGN KEY, que se asegura que el valor que esté en alguna columna de una tabla estará en una columna similar de otra tabla. Las restricciones FOREIGN KEY se usan para describir relaciones entre tablas y por tanto son imprescindibles para el diseño de bases de datos relacionales y para la integridad de los datos.

Una de las formas más importantes en la que nuestra base de datos mantendrá la integridad, será mediante el uso de transacciones. La mayoría de las funciones de negocio requieren una gran cantidad de datos de distintos tipos. Generalmente estos datos están relacionados de algún modo y por eso deben ser actualizados consistentemente. Usando transacciones, un sistema manejador de base de datos puede garantizar que todos los datos relacionados son actualizados de un modo coherente. Además, las transacciones permiten la actualización de datos a múltiples usuarios del sistema, concurrentemente y sin colisionar.

Desempeño

Las bases de datos relacionales nos ayudan a lograr un nivel mayor de desempeño el cual no es posible tan fácilmente utilizando archivos planos. El desempeño de la base

93

de datos puede analizarse en tres factores clave: Diseño, Configuración de Software y Configuración de Hardware.

La consideración número uno para el desempeño de una base de datos es el diseño. Un mal diseño de base de datos relacional puede conducir a ineficiencias tan grandes que no pueden ser corregidas con ningún ajuste adicional de Software o de Hardware. Los malos diseños pueden conducir a deadlocks, cálculos relacionales exponenciales, o simplemente al escaneo innecesario de millones de registros en tablas.

Una buena configuración de software es el segundo aspecto más importante en el desempeño de las grandes bases de datos. Aunque algunas características de los sistemas RDBMS (Relational Data Base Management System o Sistemas Gestores de Bases de Datos Relacionales) son muy parecidas entre productos diferentes, generalmente cada producto tiene complejidades y diferencias engañosas que requieren a un especialista para cada software en particular. El configurar el desempeño puede generar grandes beneficios. La correcta configuración de un simple índice, en base de datos puede hacer que una consulta compleja se ejecute en pocos segundos lo que antes eran minutos. Existen muchas otras variables configurables adicionales al RDBMS, como caches, manejadores de archivos, algoritmos de índices, y hasta consideraciones de sistema operativo. El mismo software RDBMS se comportará de forma diferente si cambia el sistema operativo y por eso debe estar configurado de otra manera.

Los grandes sistemas de base de datos relacionales usualmente exigen mucho del hardware de la computadora. Por esta razón, no es raro que la mayor parte de los poderosos servidores en una compañía sean los servidores de bases de datos. En muchas compañías la base de datos es el centro de su universo, por lo que tiene sentido el que se realicen grandes inversiones en hardware para bases de datos. Arreglos de discos muy veloces, controladores I/O, caches de hardware e interfaces de red son todos críticos para el desempeño de sistemas de administración de grandes bases de datos. Dado lo anterior, se deberá evitar tomar al hardware elegido como excusa para un mal diseño de base de datos o como un reemplazo a la configuración del RDBMS. El hardware no debe usarse para solucionar problemas de desempeño, deberá usarse para cumplir requerimientos de desempeño.

Diagrama de Capas Las capas del SICBA se ilustran en la siguiente figura, casi cualquier pieza bien

escrita de software utiliza un diseño por capas. Un diseño por capas separa las responsabilidades técnicas de una aplicación en partes consistentes que aíslan los detalles de la implementación de una interfaz o tecnología en particular.

Las flechas en la figura se pueden leer como “depende dé” o “usa”. Ésta propuesta de diseño por capas respeta lo especificado en las políticas de interacción entre capas que se exponen más adelante y evita el bien conocido código espagueti, el cual es común en aplicaciones diseñadas sin el uso de capas. Ésta separación es importante para asegurar

94

que la estrategia de persistencia no sea mezclada con el código de lógica de negocio, o viceversa. El beneficio es que el código puede ser más fácil de mantener y de tal modo se permitirá evolucionar al modelo de objetos independientemente del diseño de base de datos.

Persistencia

La capa de persistencia es donde se ubica iBATIS para el almacenamiento y la recuperación de objetos, o más específicamente los datos almacenados en dichos objetos. La capa de persistencia interactúa con el sistema de base de datos relacional para almacenar datos. Debido a la naturaleza dispar de las estrategias de persistencia en aplicaciones empresariales, una cuestión secundaria de la capa de persistencia es la abstracción. La capa de persistencia deberá ocultar todos los detalles de cómo están siendo almacenados y recuperados los datos. Tales detalles nunca deberán estar expuestos hacia las otras capas de la aplicación.

Para una mejor comprensión de estas cuestiones y cómo son manejadas, es muy útil separar la capa de persistencia en tres partes básicas: La Capa de Abstracción, el Framework de Persistencia, y el Controlador o Interfaz (Driver), como se muestra en la parte inferior de la figura.

Observemos más detenidamente cada una de estas tres partes: La Capa de Abstracción El papel de la capa de abstracción es proveer una interfaz coherente y significativa

a la capa de persistencia. Es un conjunto de clases y métodos que actúan como una fachada de los detalles de implementación de la persistencia. Los métodos en la capa de abstracción nunca requerirán parámetros específicos de implementación, ni devolverán valores o lanzarán excepciones exclusivas de implementación de la persistencia. Con una capa de abstracción apropiada en uso, toda la propuesta (incluyendo tanto la API de persistencia como la infraestructura de almacenamiento de persistencia) será capaz de evolucionar sin requerir modificaciones a la capa de abstracción o a alguna de las otras capas que dependen de ésta. El patrón utilizado para la implementación correcta de la capa de abstracción es el patrón de Objetos de Acceso a Datos (Data Access Objects-DAO).

El Framework de Persistencia El Framework de Persistencia es responsable de interactuar con el controlador o

interfaz. El Framework de Persistencia proveerá métodos para almacenar, recuperar, actualizar, buscar, y manejar datos. A diferencia de la capa de abstracción, el Framework de Persistencia es específico para nuestra infraestructura de almacenamiento. JDBC es el Framework estándar para aplicaciones Java para tener acceso a bases de datos, iBATIS es un framework de persistencia que trabaja exclusivamente con bases de datos de relaciones de todo tipo y soporta tanto Java como .NET usando una propuesta consistente.

El Controlador o Interfaz Se utiliza un controlador de software para comunicarse con la infraestructura de

almacenamiento a bajo nivel. Algunos controladores, como Drivers nativos del sistema de

95

archivos, son muy genéricos en su funcionalidad pero específicos para una plataforma. Los controladores de bases de datos tienden a ser complejos y difieren en su implementación, tamaño, así como del comportamiento. Es el trabajo del Framework de Persistencia, el comunicarse con el Driver a fin de que estas diferencias sean minimizadas y simplificadas.

BD

Persistencia

Abstraccion/DAOs

Framework

Controlador

Logica de Negocio Modelo de Objetosde Negocio

DTOsServices

WorkFlow

Action Form

Action Servlet

Actions

Presentacion

HTML

JavaScript

JSPs

Figura 30. Diagrama de Capas para el SICBA.

96

El Modelo de Objetos de Negocio

Los objetos de negocio sirven de plataforma para el resto de la aplicación. Es la representación orientada a objetos del dominio del problema, junto con diversos objetos de soporte y por consiguiente las clases que conforman el modelo de objetos de negocio son algunas veces denominadas clases de dominio. Todas las otras capas usan los objetos del modelo de negocio para representar datos y realizar ciertas funciones de lógica de negocio.

Usualmente comenzamos con el diseño del modelo de objetos de negocio antes de cualquier otra cosa. Aun a muy alto nivel, estas clases son identificadas derivándolas de los objetos entidad del diagrama de clases de análisis en el sistema. Conforme la aplicación va desarrollándose y creciendo, estas clases representan conceptos más abstractos.

Las clases del modelo de objetos de negocio pueden contener un poco de lógica también, pero nunca deberán contener código de acceso a cualquier otra capa, especialmente la de presentación y la de persistencia. Además, el modelo de objetos de negocio nunca deberá depender de cualquier otra capa. Otras capas usan el modelo de objetos de negocio, nunca a la inversa.

La capa de persistencia iBATIS usará el modelo de objetos de negocio para representar datos que se almacenan en la base de datos. Las clases de dominio del modelo de objetos de negocio se convertirán en los parámetros y los valores de regreso de los métodos de persistencia. Es por esta razón que estas clases son algunas veces llamadas objetos de transferencia de datos (Data Transfer Objects, DTOs). Aunque la transferencia de datos no es su único propósito, es su nombre visto justo desde la perspectiva de un framework de persistencia.

La Capa de Lógica de Negocio

La capa de lógica de negocio de la aplicación, describe el grueso de los servicios que la aplicación proporciona. Por esta razón algunas veces son llamadas clases de servicio. A un nivel alto, cualquiera podrá observar las clases y los métodos en la capa de lógica de negocio y entender fácilmente lo que hace el sistema. Estas clases tienen funciones que no deben ser colocadas en una clase de dominio, pues el código inmediatamente se vería inconsistente, muy mezclado y generalmente inmanejable. Lo mejor es separar las funciones de negocio, de los objetos del modelo de negocio con los que están relacionados.

Los adeptos fieles a la orientación a objetos podrían afirmar que este diseño está menos orientado a objetos que el tener tales métodos directamente en la clase de dominio relacionada. Independientemente de que esté más o menos orientado a objetos, es una mejor elección de diseño separar esas cuestiones. La razón principal es que las funciones de negocio son comúnmente muy complejas, usualmente involucran más de una clase y se ocupan de un cierto número de componentes de infraestructura, incluyendo las clases de abstracción en la capa de persistencia. Además, existen frecuentemente un cierto número de clases de dominio involucradas en una sola función de negocio, lo cual haría difícil decidir a cuál clase debería pertenecer tal método. Es por estas razones que las funciones de negocio son implementadas como métodos separados en clases que forman parte de la capa de lógica de negocio. En nuestra arquitectura por capas, la capa de lógica

97

de negocio es el consumidor de los servicios de la capa de persistencia. Hace llamadas a la capa de persistencia para cargar y cambiar datos.

La Capa de Control y Flujo de la Aplicación

Esta capa aunque a su vez estará dividida en sub-capas la consideramos como una sola en ésta etapa del diseño, contiene toda la configuración del Workflow del sistema en sus correspondientes archivos XML. De tal manera que integra, entre otras cosas, el Servlet controlador de Struts, las clases que corresponden a los Action Forms y nuestras clases principales de operación como son los Action Beans, estos últimos son los que utilizan métodos y funciones provistos por la capa de negocio. Aquí es donde se ejemplifica con mayor claridad el patrón MVC, nuevamente encontramos una serie de objetos a manera de Modelo (Action Forms), el mismo Controlador (Servlet Genérico) y las peticiones recibidas desde la capa de Presentación (Vista), las cuales están ligadas a sus respectivos Actions y a su vez los resultados de estos son direccionados nuevamente a la capa de presentación, siempre cuidando evitar cualquier violación a la Política De Interacción entre Capas.

La Capa de Presentación

La capa de presentación es responsable de mostrar controles de aplicación y datos al usuario final así como de la interacción con éste. Es responsable también de la distribución y formateo de toda información. La propuesta de presentación elegida se menciona en el apartado anterior y se resume en interfaces de usuario (Front Ends) en JSPs que podrán usar HTML y JavaScript, para proveer una apariencia y comportamiento (Look and Feel) al usuario, a través de un navegador WEB.

Las aplicaciones WEB tienen la ventaja de ser compatibles entre plataformas, facilidad de implementación y escalabilidad.

En este esquema la interfaz de usuario no contendrá ninguna lógica de negocio, en su lugar, la funcionalidad de negocio disponible es configurada mediante una aplicación WEB, que implementa una interfaz entre el cliente y el servidor (Workflow de Struts). En respuesta a cada comando o consulta, el Servlet controlador realizará la acción que sea necesaria y luego devolverá la siguiente página HTML al cliente. Así, el diseño de la página y el código fuente están separados, cada página de respuesta está construida por una JSP, que produce contenido dinámicamente basándose en la interacción con el cliente. Las JSPs toman sus datos dinámicos como objetos de modelo que les proveen los Actions. La comunicación en red para la capa HTML, está provista por la capa HTTP estándar.

Aunque la capa de presentación no se comunicara directamente con el Framework de persistencia, debemos contemplar que ciertas decisiones acerca de la interfaz de usuario afectarán los requerimientos en cascada que había en todas nuestras capas, posiblemente hasta alcanzar la capa de persistencia.

Política de Interacción entre Capas En el servidor y con fines de simplicidad, toda comunicación entre capas fluirá hacia

abajo. Es decir, los mensajes sólo serán enviados de una capa hacia la capa inferior. Se usaran algunos eventos del lado del cliente en beneficio de la capa de interactividad, los

98

que son soportados mediante códigos JavaScript, a fin de que el conocimiento específico de la aplicación, pueda ser pulsada desde los componentes de la interfaz de usuario, hasta la capa de Control. La vista HTML necesita manejar eventos en forma mínima, porque con este esquema toda la información desplegada al usuario da muestra de haber sido calculada por los Action Beans y pasada directamente a las JSPs para la presentación.

Las capas serán de estructura encapsulada, para simplificar la implementación y el mantenimiento. Cada objeto podrá tener acceso a los objetos en la capa inmediatamente inferior, pero no más allá.

Paquetes El diagrama de paquetes para el SICBA se muestra en la siguiente figura, aunque

para este no se requieren mayores comentarios.

mx.com.casabrasil

model

persistence servlet

action form

service

Figura 31. Diagrama de Paquetes para el SICBA.

99

Diagrama de Despliegue

El diagrama de despliegue para el SICBA se muestra en la figura de abajo.

La capa de datos del SICBA comprende el servidor de base de datos, al cual hemos llamado DBServer. Teniendo comprobado su rendimiento y confiabilidad mediante el SI-COB. el DBServer contiene un proceso Manejador de base de datos para administrar el acceso a los datos.

El entregable sql_sicba_casabrasil.sql contiene comandos para la creación de tablas en base de datos, en un formato específico para la base de datos que se está utilizando. Esto se libera en la consola analizadora de consultas del DBMS, usando herramientas específicas de la base de datos (para este caso no se mostrarán detalles). El archivo sql_sicba_casabrasil.sql contiene el esquema para el sistema SICBA completo, incluyendo los servicios o procedimientos almacenados, que dan soporte a gran parte de las operaciones relacionadas con los datos del SICBA y algunas mejoras al SI-COB; tomando en cuenta que hay puntos en los que comparten información.

La capa intermedia, que se comunica con la capa de datos, consta de las interfaces que usa el servidor de aplicaciones Tomcat, instalado en la máquina servidor, este último se apoya en la configuración de un pool de conexiones y el driver correspondiente para soporte JNDI, el servidor Tomcat tiene la plena capacidad para manejar peticiones de negocio y para manipular el contenido estático HTML.

Dentro del servidor de aplicaciones, la carpeta del SICBA se llamará “casabrasil”, esto es porque nuestro archivo casabrasil.war es liberado en la carpeta de trabajo de Tomcat, este automáticamente desempaqueta y crea la estructura funcional del SICBA. El archivo casabrasil.war contiene el descriptor de la aplicación web.xml, archivos de configuración de Spring, Struts e iBATIS, así como los jars, que comprenden sus frameworks y paquetes de utilerías adicionales, JSPs, clases de Modelo, Acceso a Datos, Negocio y Actions, además de algunos elementos estáticos como imágenes, JavaScripts y hojas de estilo (eventualmente).

100

:Cliente :Servidor de Aplicaciones / Win XP :DB Server / Win XP

<<HTTP>>

:Tomcat

InternetExplorer

HTML

JDBC

Diagrama de DespliegueUML / SICBA

:MS SQL 2000

sql_sicba_casabrasil.sql

mx.com.casabrasil

IMG

CSS

JS

JRE SPRING

STRUTS iBATIS

Figura 32. Diagrama de Despliegue para el SICBA.

La aplicación puede ser accedida simultáneamente por cualquier número de clientes. Cada cliente utiliza o es un navegador WEB, el cual accede al servidor utilizando HTTP. Ninguno de los entregables necesita ser liberado en las máquinas cliente, en todo caso únicamente se creará un acceso directo en el escritorio o se agregará un enlace a la carpeta de favoritos.

Políticas de Seguridad Buscar y Navegar entre los servicios estará disponible para todos los usuarios

clientes, sin tener que estar previamente registrados. En contraste, para los servicios reservados a usuarios con privilegios, tienen primero que obtener una contraseña personal con el administrador del sistema, luego usarla para ingresar a las áreas u opciones que así lo requieran. Los números y contraseñas con privilegios usadas para ingresar serán manejadas en una tabla central, por facilidad de mantenimiento y debido a que se reserva para un próximo incremento, usando mecanismos estándar de consola en base de datos.

Política de Concurrencia Como los clientes son HTML, cada JSP tendrá acceso exclusivo a sus objetos de

servicio, así tal acceso es naturalmente de un solo Thread. Para datos de negocio, el servidor de aplicaciones administra automáticamente el control de la concurrencia de bajo nivel. Cada uso de un servicio de negocio está envuelto en una transacción; al inicio de cada petición de negocio será instanciado un objeto de acceso a datos el cual mediante iBATIS manejará una transacción Java, ésta transacción será asociada con cada acceso a base de datos realizado dentro de dicha petición, pasando directamente al DBMS. Al final de cada petición, la transacción Java será completada, habilitando así las actualizaciones a otras peticiones.

101

Para simplificar el control de la concurrencia a nivel de base de datos, se seguirán dos estrategias: en primer lugar, en la capa de persistencia se configurarán esquemas de caché nulos para los datos que se sabe cambian constantemente; en segundo término, en la capa de datos se promoverá el uso de transacciones atómicas a cada batch de operaciones que se concluirán en commit, siempre que no existan problemas de lógica de negocio. Esto minimizará la necesidad de reportar errores del tipo "Intenta mover un producto que no se encuentra en la ubicación origen proporcionada" a los usuarios. Esto ocurrirá ocasionalmente, debido a que la pantalla del cliente no se actualizará explícitamente cuando los datos cambien en el servidor vía rutas concurrentes; Mostrar todos los cambios relevantes a los clientes, aunque técnicamente sea factible; ya que sería demasiado ineficiente, más aún, los procedimientos seguidos en el departamento de logística y sistemas, minimizan de forma natural estos riesgos.

3.3.5 Diseño de Subsistemas Esta sección documenta los resultados del diseño de subsistema, llevados a cabo

durante la fase de diseño del desarrollo del SICBA, en términos de los Servicios de Negocio, Modelos de Clase de Diseño, Esquema de Base de Datos, Diseño de la Interfaz de Usuario y ejecución de Servicios de Negocio (Diagramas de Secuencia). En general, ésta documentación describe los entregables del subsistema requeridos para dar soporte a la ejecución de los servicios de negocio.

Servicios de Negocio

1. Ingresa un producto.

2. Actualiza un producto.

3. Mueve un producto.

4. Cambia código a un producto.

5. Elimina definitivamente un producto.

6. Obtiene listado de bitácora de movimientos.

7. Obtiene detalle de un movimiento de bitácora.

8. Obtiene esquema de relación movimiento – facturación.

9. Actualiza movimiento relacionado con facturación.

10. Obtiene listado de productos inventariados.

11. Obtiene listado con datos de Ventas.

12. Obtiene listado de cuentas por cobrar.

102

Diagrama de Clases de la capa de Actions El diagrama de clases de la capa de Actions se muestra en la siguiente figura:

mx.com.casabrasil.action

EntradaUniProductoAction

ManInfoUniProductoAction

MiscelaneoAction

MovUniProductoAction

ReporteMovtosAction

ReporteCtasCobrarAction

ReporteVentasAction

ReporteProductosAction

Figura 33. Diagrama de clases de la capa de Actions.

Lista de Campos de la capa de Action Beans Todos los Action Beans no conservan información de su estado y por consiguiente

no tienen campos esenciales. Cualquier información acerca del estado de la interacción de un cliente es registrada en las mismas páginas resultantes y en un objeto de estado almacenado en la sesión HTTP del navegador. Los objetos en la capa de Actions son localizados usando sus URLs configuradas en el archivo struts-config.xml. Sin embargo se ejemplifican a continuación algunos parámetros que también son configurados como campos de acceso a negocio y de registro a la bitácora de la aplicación (log).

ReporteMovtosAction

• logger:Log Objeto para registro de actividad en logs de sistema.

• repService:ReporteMovtosService Objeto de servicio para operaciones de negocio y uso de objetos para acceso a datos.

Lista de Mensajes de la capa de Actions Usando el mecanismo estándar de Java, cada petición del cliente es pasada al

Servlet controlador seleccionado por un mensaje designado doGet (:HttpServletRequest:HttpServletResponse). Las peticiones y comandos del cliente son

103

transmitidas como parte del HttpServletRequest. Abajo hay un ejemplo de las peticiones y comandos que pueden ser emitidos por el cliente, directa o indirectamente.

ReporteMovtosAction

• ReporteMovtosAction(ReporteMovtosService repService) Es el constructor del Action que inicializa entre otras cosas, su objeto de servicio.

• setUpParaConsulta(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response):ActionForward Configura todo lo necesario para iniciar el filtrado de una consulta de movimientos de productos, redireccionando a la pantalla correspondiente.

• consultaMovtos(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response):ActionForward Ejecuta la consulta utilizando los parámetros elegidos en el filtro de datos, redireccionando a la pantalla correspondiente.

• setUpParaUpdateMovtos(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response):ActionForward Configura todo lo necesario para iniciar la relación de un movimiento de un producto con su factura, redireccionando a la pantalla correspondiente.

• updateMovtos(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response):ActionForward Ejecuta la actualización de un movimiento, para establecer la relación con su factura, redireccionando a la pantalla correspondiente.

• prepConsulta(HttpServletRequest request):void Prepara cada uno de los campos del filtro de consulta, que requieren de datos catalogados.

• prepActualiza(HttpServletRequest request):void Prepara cada uno de los campos del formulario de actualización y que requieren de datos catalogados.

• validationSuccessful(HttpServletRequest request, FiltroMovtosForm form):Boolean Método para validación de campos requeridos u obligatorios para la consulta.

• updateValidationSuccessful(HttpServletRequest request, InfoRelacionaFacturaMovForm form):Boolean Método para validación de campos requeridos u obligatorios para la actualización.

104

Diagrama de Clases de la Capa de Negocio El Diagrama de Clases para la Capa de Negocio se muestra en la siguiente figura.

mx.com.casabrasil.service

EntradaUniProductoService

ManInfoUniProductoService

MiscelaneoService

MovUniProductoService

ReporteMovtosService

ReporteCtasCobrarService

ReporteVentasService

ReporteProductosService

Figura 34. Diagrama de clases de la capa de Negocio.

Lista de Campos de la Capa de Negocio Los objetos del servidor mantienen información de los objetos de acceso a datos,

los cuales son instanciados cada vez que son requeridos y destruidos cuando cumplen su función, por lo general se ha definido sólo un campo o parámetro, el cual es inicializado tal como se específica en su configuración de Struts y a continuación se ejemplifica su definición. (Todas las clases de la capa de negocio son accedidas vía los Actions).

MiscelaneoDaoService

• dao:MiscelaneoDao Objeto para acceso a datos que esquematiza y dirige las operaciones abstractas a realizar sobre éstos.

Lista de Mensajes de la Capa de Negocio Para los objetos del servidor, los mensajes siguientes corresponden a un ejemplo

de los servicios de negocio. MiscelaneoDaoService

• MiscelaneoDaoService(MiscelaneoDao dao) Es el constructor del Servicio que inicializa su objeto de acceso a datos.

• cambiaCodigo(InfoMiscelaneo infoMisc):Integer Genera el llamado a la actualización del código de un producto.

• eliminaProducto(InfoMiscelaneo infoMisc):Integer Genera el llamado a la eliminación definitiva de un producto.

105

Diagrama de Clases de la Capa de Acceso a Datos El diagrama de clases para la capa de acceso a datos se muestra en la figura

adjunta.

mx.com.casabrasil.persistence

EntradaUniProductoDao

ManInfoUniProductoDao

MiscelaneoDao

MovUniProductoDao

ReporteMovtosDao

ReporteCtasCobrarDao

ReporteVentasDao

ReporteProductosDao

Figura 35. Diagrama de clases de la capa de Negocio.

Lista de Campos de la Capa de Acceso a Datos Los objetos de la capa de acceso a datos, no conservan información de su estado y

por estrategia no se ha considerado ubicar en ésta capa alguna funcionalidad sobre los datos. Por consiguiente no tienen campos.

Lista de Mensajes de la Capa de Acceso a Datos La mayor parte de los mensajes públicos en las clases de la capa de acceso a

datos, son simplemente un mapa de los mensajes de la capa de negocio, en este caso ejemplificaremos los mensajes disponibles en la clase que hace un mapeo del servicio antes mostrado. La diferencia radica en los llamados que hacen estos a los servicios de base de datos configurados en el mapa de iBATIS:

MiscelaneoIbatisDao

• cambiaCodigo(InfoMiscelaneo infoMisc):Integer Ejecuta la actualización del código de un producto.

• eliminaProducto(InfoMiscelaneo infoMisc):Integer Ejecuta la eliminación definitiva de un producto.

Diagrama de Clases de los Objetos de Modelo El diagrama de clase para objetos de modelo, usados para entablar la relación entre

la capa de servidor y la de base de datos, es decir, en donde se define el modelado de la persistencia, es mostrado en la figura siguiente.

106

mx.com.casabrasil.model

InfoEntradaUniProducto

ManInfoUniProducto

InfoMiscelaneo

InfoMovUniProducto

InfoRelacionaFacturaMov

FiltroCtasCobrar

VentaReportada

ProductoInventariado

FiltroVentas

FiltroProductos

FiltroMovtos

Figura 35. Diagrama de clases de la capa de Negocio.

Lista de Campos de los Objetos de Modelo La siguiente lista muestra campos para los atributos almacenados un una clase

ejemplo. El significado de estos campos equivale a los de la capa de base de datos en el servicio correspondiente, el cual se ve configurado en su mapa de iBATIS.

InfoRelacionaFacturaMov

• idMovimiento:Integer Es el identificador del movimiento que será modificado para establecer su relación con facturación.

• folio:String Es el folio de contrato o factura que servirá para como referencia al documento impreso.

• listaIdUniversal:String Es la lista con los códigos de los productos que son incluidos en el movimiento.

• listaPreciosIdUn:String Son los precios correspondientes a cada producto incluido en el movimiento.

• idFactura:Integer Es el identificador en base de datos del contrato con el cual se relaciona el movimiento.

Lista de Mensajes de los Objetos de Modelo Todos los mensajes públicos en las clases de la capa de modelo son simplemente

de acceso a atributos, por tanto no se da detalle de éstos. Bastará con mostrar mediante un ejemplo que son setters y getters para cada atributo.

InfoRelacionaFacturaMov

107

• getIdMovimiento():Integer Devuelve el identificador del movimiento.

• setIdMovimiento(Integer idMovimiento):void Asigna un valor al identificador del movimiento.

• getFolio():String Devuelve el folio de contrato o factura relacionado a un movimiento.

• setFolio(String folio):void Asigna un valor al folio de contrato o factura relacionado a un movimiento.

• getListaIdUniversal():String Devuelve una lista con los códigos de los productos incluidos en el movimiento.

• setListaIdUniversal(String listaIdUniversal):void Asigna un valor a la lista con los códigos de los productos incluidos en el movimiento.

• getListaPreciosIdUn():String Devuelve los precios correspondientes a cada producto incluido en el movimiento.

• setListaPreciosIdUn(String listaPreciosIdUn):void Asigna un valor a la lista de precios correspondientes a cada producto incluido en el movimiento.

• getIdFactura():Integer Devuelve el identificador del contrato con el cual se relaciona el movimiento.

• setIdFactura(Integer idFactura):void Asigna un valor al identificador del contrato con el cual se relaciona el movimiento.

Esquema de Base de Datos El esquema de base de datos es mostrado en el siguiente listado. En el cual, los

nombres de columnas llave primaria se muestran en negrita y los nombres de columnas llave foránea se muestran en cursivas. El significado de las columnas atributo se corresponden con los campos en las clases de la capa de modelo.

TIPOCLIENTE (TIPO:int, NOMBRE_TIPOCLIENTE:nvarchar(50), DESCRIPCION:nvarchar (60))

PRODUCTOS_ACTIVOS (ID_UNIVERSAL:Varchar(11), NOMBRE:Varchar(70), DESCRIPCION:Varchar(150), ID_GRUPO:Integer, PRECIO_COMPRA:Decimal(9,2), PRECIO_VENTA:Decimal(9,2), ID_PROVEE:Integer, CODIGO_PROVEEDOR:Varchar(20), ID_UBICACION:Integer, ID_RESPONSABLE:Integer, ID_STS_PROD:Smallint, MODELO:Varchar(30))

GRUPOS_PRODUCTO (ID_GRUPO:Integer, NOMBRE_GRUPO:Varchar(60), MODELO:Varchar(30), ID_STS_OPERATIVO:Smallint)

UBICACIONES (ID_UBICACION:Integer, NOMBRE:Varchar(70), ID_RESPONSABLE:Integer, ID_GPOUBI:Integer, ID_STS_OPERATIVO:Smallint)

CATPROVEE (ID_PROVEE:Integer, NOMBRE:Varchar(70), DIRECCION:Varchar(150), TELEFONO:Varchar(100), ID_PROVCATORIGEN:Integer)

STS_PROD (ID_STS_PROD:Smallint, DESCRIPCION:Varchar(30), COMENTARIOS:Varchar(150))

RESPONSABLES (ID_RESPONSABLE:Integer, NOMBRE:Varchar(70), ID_PUESTO:Smallint, ID_STS_OPERATIVO:Smallint)

PUESTOS (ID_PUESTO:Smallint, DESCRIPCION:Varchar(50), ID_STS_OPERATIVO:Smallint)

108

STS_OPERATIVO (ID_STS_OPERATIVO:Smallint, DESCRIPCION:Varchar(20))

TIPOMOV (ID_TIPOMOV:Smallint, DESCRIPCION:Varchar(40), ID_CLASEMOV:Smallint, ID_STS_OPERATIVO:Smallint)

CLASEMOV (ID_CLASEMOV:Smallint, DESCRIPCION:Varchar(20))

DETBITAMOVPROD (ID_UNIVERSAL:VarChar(11), ID_MOVIMIENTO:Integer)

PRODUCTOS_INACTIVOS] (ID_UNIVERSAL:Varchar(11), NOMBRE:Varchar(70), DESCRIPCION:Varchar(150), ID_GRUPO:Integer, PRECIO_COMPRA:Decimal(9,2), PRECIO_VENTA:Decimal(9,2), ID_PROVEE:Integer, CODIGO_PROVEEDOR:Varchar(20), ID_UBICACION:Integer, ID_RESPONSABLE:Integer, ID_STS_PROD:Smallint, MODELO:Varchar(30))

BITAMOVPROD (ID_MOVIMIENTO:Integer, ID_TIPOMOV:Smallint, FECHA:Datetime, ID_UBIORIGEN:Integer, ID_RESPORIGEN:Integer, ID_UBIDESTINO:Integer, ID_RESPDESTINO:Integer, ID_TRANSPORTISTA:Integer, FOLIO:Varchar(25), COMENTARIOS:Varchar(150), FECHACAPTURA:Datetime)

BITACAMBIOSTSPROD (ID_CAMBIOSTSPROD:Integer, ID_UNIVERSAL:Varchar(11), FECHA:Datetime, FOLIODOC:Varchar(25), ID_RESPONSABLE:Integer, ID_GPOANT:Integer, ID_GPONUEVO:Integer, NOMBREANT:Varchar(70), NOMBRENUEVO:Varchar(70), DESCRIPCIONANT:Varchar(150), DESCRIPCIONNUEVO:Varchar(150), PRECIO_COMPRAANT:Decimal(9,2), PRECIO_COMPRANUEVO:Decimal(9,2), PRECIO_VENTAANT:Decimal(9,2), PRECIO_VENTANUEVO:Decimal(9,2), ID_PROVEEANT:Integer, ID_PROVEENUEVO:Integer, CODIGO_PROVEEDORANT:Varchar(20), CODIGO_PROVEEDORNUEVO:Varchar(20), ID_STSPRODANT:Smallint, ID_STSPRODNUEVO:Smallint, MODELOANT:Varchar(30), MODELONUEVO:Varchar(30), COMENTARIO:Varchar(150), FECHACAPTURA:Datetime)

GPO_UBICACIONES (ID_GRUPOUBI:Integer, NOMBRE:Varchar(40))

Diseño de Interfaz de Usuario El diseño de interfaz de usuario no se muestra aquí debido a que es similar a los

bocetos de interfaz de usuario mostrados en la Sección 3.3.2. Ejecución de Servicios de Negocio La figura siguiente muestra un diagrama de secuencia, documentando la ejecución

de un servicio de negocio, para un caso de uso de sistema. En algunos diagramas se usan corchetes para mostrar ciclos, el operador del ciclo es a menudo una marca en pseudocódigo que controla el número de iteraciones. También se explota el uso de recuadros para incluir abreviaciones que se refieren a casos de uso que están incluidos en otros, usando un operador ref, el nombre del caso de uso incluido aparecería en el centro del recuadro, junto con una lista de parámetros que le son transmitidos.

Para fines de simplicidad, cada interacción entre el navegador de un cliente y un Action, ha sido mostrada como un mensaje enviado desde el actor directamente hacia el Action. En realidad, esto está implementado mediante la emisión de una orden y sus parámetros dentro del el mensaje doGet del Servlet Controlador.

109

MiscelaneoAction

MiscelaneoDaoService

MiscelaneoIbatisDao

ejecutaMiscelaneo(InfoMiscelaneoForm) ret = cambiaCodigo

(infoMiscelaneo)

UsuarioAdministrador

Producto

ret = cambiaCodigo(infoMisc)

update("cambiaCodigo",infoMisc)

RequestServlet

Controlador

/ejecutaMiscelaneo

páginamisceláneos

infoMiscelaneoFormsubmit()

páginamisceláneosejecutado[OK/NO]

setAttribute("ejecutado", ret)

Figura 36. Diagrama de secuencia para U12: Cambio de Claves de Producto.

3.3.6 Especificación de Clases Esta sección documenta los resultados de la fase de especificación del desarrollo

del SICBA. Debido a que hay muchas clases en el SICBA, las únicas especificaciones que serán incluidas son para una clase de la capa de Actions y una clase de la capa de Negocio, como ejemplos. Cada especificación está dada en forma de comentarios dentro del código fuente.

Especificación de una clase Action. ResponsableAction Campos: /* Los valores almacenados en estos campos, son objetos que a su vez pueden tener campos y * métodos los cuales tienen funcionalidades propias ya sea de negocio o de soporte a mensajes de * depuración o logs. */ logger respService ptoService Métodos: /*Constructor de la clase ResponsableAction *Precondiciones: * respService != null * ptoService != null * *Postcondiciones: * Una nueva instancia de ResponsableAction ha sido creada */ public ResponsableAction(ResponsableService respService, PuestoService ptoService); /*Método que devuelve la lista de todos los responsables configurados en el sistema.

110

*Precondiciones: * mapping es ActionMapping * form != null * *Postcondiciones: * request ha sido poblado con datos de responsables mediante el uso de respService * mapping ha sido configurado a un forward de SUCCESS * *Excepciones: * Exception – Se lanza cuando ocurre alguna excepción ya sea de base de datos o de servidor. */ public ActionForward getResponsables(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception; /*Método que prepara lo necesario para la pantalla de actualización o inserción de un responsable. *Precondiciones: * mapping es ActionMapping * *Postcondiciones: * responsableForm contiene la información del responsable en caso de ser actualización * responsableForm tiene sus campos vacíos en caso de ser inserción * request ha sido poblado con el catálogo de puestos mediante ptoService * mapping ha sido configurado a un forward de SUCCESS * *Excepciones: * Exception – Se lanza cuando ocurre alguna excepción ya sea de base de datos o de servidor. */ public ActionForward setUpParaInsertOUpdate(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception; /*Método que elimina un responsable del catálogo de responsables. *Precondiciones: * mapping es ActionMapping * form != null * *Postcondiciones: * Un responsable ha sido eliminado mediante respService.deleteResponsable(form.id) * request ha sido poblado con datos de responsables mediante el uso de respService * mapping ha sido configurado a un forward de SUCCESS * *Excepciones: * Exception – Se lanza cuando ocurre alguna excepción ya sea de base de datos o de servidor. */ public ActionForward delete(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception; /*Método que ejecuta la actualización o inserción de un responsable en el catálogo de responsables *Precondiciones: * mapping es ActionMapping * form != null * form.getNombre() != null * *Postcondiciones: * Un responsable ha sido actualizado en caso de aprobar validaciones y de ser actualización * Un responsable ha sido insertado en caso de aprobar validaciones y de ser inserción * request ha sido poblado con datos de responsables mediante el uso de respService * en caso aprobar validaciones * mapping ha sido configurado a un forward de SUCCESS en caso aprobar validaciones * request ha sido poblado con el catálogo de puestos mediante ptoService en caso * de NO aprobar validaciones * mapping ha sido configurado a un forward de FAILURE en caso de NO aprobar validaciones * *Excepciones: * Exception – Se lanza cuando ocurre alguna excepción ya sea de base de datos o de servidor.

111

*/ public ActionForward insertOrUpdate(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception; /*Método que coloca en request una lista de datos con los responsables *Precondiciones: * respService != null * *Postcondiciones: * request ha sido poblado con datos de responsables mediante el uso de respService */ private void populateResponsables(HttpServletRequest request); /*Método que coloca en request un catálogo con los puestos disponibles *Precondiciones: * ptoService != null * *Postcondiciones: * request ha sido poblado con el catálogo de puestos mediante ptoService */ private void prep(HttpServletRequest request); /*Método que verifica si el tipo de operación a utilizar es una inserción o una actualización *Precondiciones: * respForm != null * *Postcondiciones: * Regresa updateFlag = true si es una actualización (id ¡= null) o de lo contrario updateFlag = false */ private boolean isUpdate(HttpServletRequest request, ResponsableForm respForm); /*Método que realiza las validaciones pertinentes sobre los datos. *Precondiciones: * form != null * *Postcondiciones: * Resgresa isOk = true si la prueba es superada o de lo contrario isOk = false * En caso de errores request ha sido poblado con errors mediante saveErrors */ private boolean validationSuccessful(HttpServletRequest request, ResponsableForm form);

Especificación de una Clase de Lógica de Negocio. ResponsableDaoService Campos: /* El valor almacenado en este campo, es un objeto que a su ves pueden tener campos y * métodos los cuales tienen funcionalidades propias de acceso a datos */ dao Métodos: /*Constructor de la clase ResponsableDaoService *Precondiciones: * dao != null * *Postcondiciones: * Una nueva instancia de ResponsableDaoService ha sido creada */ public ResponsableDaoService(ResponsableDao dao); /*Método que devuelve la lista de todos los responsables configurados en el sistema con sus datos. *Precondiciones: * dao != null

112

* *Postcondiciones: * Ninguna */ public List getListResponsables(); /*Método que devuelve un catálogo con todos los responsables configurados en el sistema. *Precondiciones: * dao != null * *Postcondiciones: * Ninguna */ public List getAllResponsables(); /*Método que actualiza un responsable en el catálogo de responsables. *Precondiciones: * dao != null * resp != null * *Postcondiciones: * Responsable actualizado en Base de Datos */ public void updateResponsable(Responsable resp); /*Método que elimina un responsable del catálogo de responsables. *Precondiciones: * dao != null * id != null * *Postcondiciones: * Responsable eliminado de Base de Datos */ public void deleteResponsable(Integer id); /*Método que devuelve los datos de un responsable del catálogo de responsables. *Precondiciones: * dao != null * id != null * *Postcondiciones: * Ninguna */ public Responsable getResponsable(Integer id); /*Método que inserta un responsable en el catálogo de responsables. *Precondiciones: * dao != null * resp != null * *Postcondiciones: * Responsable insertado en Base de Datos */ public void insertResponsable(Responsable resp);

113

3.3.7 Esquema de Plan de Pruebas Introducción Las actividades de prueba del SICBA serán continuas, involucrando al desarrollador

responsable, algún colega desarrollador independiente, los clientes y el equipo designado para las pruebas.

• El desarrollador probará sus entregables conforme los produzca.

• Los clientes estarán involucrados en la verificación de los entregables de alto nivel, las pruebas de aceptación y las pruebas de las versiones Beta.

• Algún Colega revisará los entregables producidos por el desarrollador.

• El desarrollador será responsable, también de las pruebas de construcción después del primer incremento.

• El equipo de pruebas será responsable de coordinar el proceso de pruebas, incluyendo la producción y el mantenimiento de este plan y la fase de pruebas misma. Este plan de pruebas da una visión general de las pruebas, que serán efectuadas y

es complementado por los detalles de las tareas de pruebas para cada fase del desarrollo. No hace alusión a la implementación de un prototipo para el SICBA. El desarrollo de un prototipo estará a cargo del responsable del proyecto y se conducirá usando métodos rápidos e informales.

El Impacto de las Espirales e Incrementos Dentro de cada espiral del desarrollo, las pruebas serán efectuadas por el

desarrollador. Cada entregable estará sujeto a revisión por parte de algún colega, con la condición de que dichas revisiones no se harán necesariamente desde la primera espiral. Para cada espiral después de la segunda, las revisiones por parte del colega, se concentrarán sobre los cambios que se vayan haciendo a los entregables, para evitar duplicidad en el trabajo y consumir el tiempo mínimo posible de nuestro colega. De modo semejante, las revisiones por parte del cliente deberían concentrarse en los cambios hechos desde la última revisión ejecutada aunque tomándose el tiempo necesario para esto.

Después de cada grupo de espirales ya complementada, el equipo de pruebas asumirá el control, para manejar la fase de pruebas antes de la liberación del siguiente incremento.

Después del primer incremento, las pruebas de regresión asegurarán que el SICBA es por lo menos tan funcional como era cuando fue liberado el incremento previo.

Prueba de Entregables que no son Código Los casos de uso y los diagramas UML, serán producidos por el responsable del

desarrollo con la participación de los clientes. En las primeras espirales, el desarrollador revisará el trabajo realizado y los cambios serán llevados a cabo inmediatamente.

Durante la última espiral antes de la liberación de un incremento, las revisiones formales por parte del colega se llevarán a cabo, considerando que éste cuenta con la experiencia necesaria pero que no está directamente involucrado con el proyecto. Estas

114

revisiones se usarán para certificar que los entregables se corresponden, desde que son esquematizados en los casos de uso hasta el punto en que se hace la especificación basada en clases.

El desarrollador y el equipo dedicado al proyecto, serán responsables de asegurar que los entregables permanecen consistentes al transcurrir del tiempo de desarrollo.

Revisiones de Código Después de la fase final de codificación dentro de cada incremento, las revisiones

formales de código se llevaran a cabo con nuestro colega de confianza. Durante estas revisiones, se usarán pruebas manuales de caja blanca y herramientas métricas para identificar cualquier corrección de fuentes que sea necesaria.

Desarrollo Orientado a Pruebas Durante la implementación del diseño, el programador realizará pruebas continuas

de su trabajo. Estas pruebas desarrolladas por programador comprenderán pruebas unitarias a nivel de clase y de integración para todas las clases que el desarrollador posee. Se corregirán defectos de código antes de publicarlo.

Al final de cada espiral, se realizarán pruebas de integración y pruebas de subsistema a un nivel medio informal, siendo la meta eliminar tantos defectos como sea posible antes de la fase formal de pruebas. El responsable del desarrollo arreglará cualquier defecto que descubra hasta este punto, antes de la siguiente espiral o la fase de pruebas, según el caso.

Depuración y Validación Como se detallada posteriormente en este plan de pruebas, se espera que el

programador agregue comentarios documentales o instrucciones de salida a depuración (mensajes a debug) y al código en la fase de desarrollo. Durante la fase de pruebas, estos mensajes inicialmente facilitan la identificación de errores. Una vez que todas las pruebas son exitosas, se vuelven a ejecutar pero ahora con los mensajes deshabilitados, para comprobar que ninguno de estos cause efectos secundarios. También permitirá comparar el desempeño con y sin depuración. Para la liberación, los mensajes serán deshabilitados pero se mantendrán en el código a fin de que puedan ser reactivados para ayudar a diagnosticar fallas. Para que el sistema en funcionamiento real no se vea comprometido por la inhabilitación de los comentarios, se toman medidas adicionales para proteger al SICBA.

Para reducir la cantidad de información incorrecta que llega a la capa de servidor, un tipo firewall se dispondrá tras las interfaces de usuario, comprobando datos de entrada usando JavaScript, por ejemplo. Este firewall del cliente se basa principalmente en las validaciones de la capa de Actions.

Además del uso de técnicas GUI estándar, como deshabilitar botones que no deban ser usados y reemplazar entradas de texto por listas desplegables y botones de selección.

Fase de Pruebas Una vez que las espirales para cada incremento hayan finalizado completamente, el

sistema será entregado al equipo de pruebas. El equipo de pruebas usará las especificaciones de clase y de subsistema para ayudarles a producir casos de prueba de

115

subsistema, junto con procedimientos de pruebas. Los casos de prueba de sistema se basarán en los casos de uso del sistema. Cada caso de prueba comprenderá un número de pruebas individuales, cada una con nombre de prueba, descripción, procedimiento y resultados esperados.

El equipo de pruebas se ocupará de los siguientes requerimientos:

• La carga inicial de prueba, con cargas promedio y máximas.

• Pruebas a profundidad, para comprobar que no existirá corrupción o gasto indebido de recursos con el paso del tiempo.

• Pruebas de estrés, para confirmar que el SICBA, en un supuesto caso detendrá su operación en una forma no abrupta.

• Pruebas de seguridad. Se usaron automatizaciones de pruebas, donde fue posible, para reducir el costo de

la fase de pruebas. En paralelo, el equipo de pruebas organizó las pruebas de aceptación, con la ayuda

de voluntarios locales y empleados de Casa Brasil cuidadosamente seleccionados. Las pruebas de instalación fueron realizadas usando un banco de pruebas que

comprende un equipo, con características muy semejantes a las plataformas destino. Finalmente antes de la liberación, las pruebas de versión Beta serán realizadas en el lugar seleccionado por el cliente. Donde sea factible, todos los defectos conocidos serán corregidos por el desarrollador antes de liberar.

Se recopilaron métricas de desempeño, por ejemplo, el tiempo promedio en procesar un reporte; y métricas de diseño, por ejemplo, el tamaño de métodos y servicios. Cualquier desempeño inaceptable debe ser corregido antes de hacerse la liberación. Los problemas de diseño se dieron y registraron como entrada para el siguiente incremento.

Pruebas de Documentación Después de la primera espiral, el equipo responsable del proyecto comenzará a

producir manuales y material para la capacitación. Estos estarán sujetos a revisiones por nuestro colega. Después de varias espirales, durante la fase explícita de pruebas que tiene lugar antes de la liberación de cada incremento, la documentación será probada nuevamente. Ésta prueba comprenderá revisión por parte del colega, pruebas de aceptación y pruebas de versión Beta.

Pruebas de Construcción El programador usará una herramienta de administración de código fuente incluida

en el IDE de eclipse, para asegurar que todo código se mantiene como un repositorio central. Tendrá la posibilidad y será responsable de manejar versiones de cada pieza de código, bajo unas condiciones controladas en un historial (History).

Después de que el primer incremento haya sido liberado, todo desarrollo posterior estará sujeto a pruebas de construcción, ejecutadas por el programador. Esto implicará constituir el sistema entero y realizar un subconjunto significativo de pruebas de sistema.

116

Documentación de pruebas y las bitácoras Todos los casos de pruebas son documentados y conservados en un repositorio

bajo el control del equipo de pruebas. Conforme fueron efectuadas éstas, sus resultados fueron registrados y agregados al repositorio.

Para promover las pruebas de código antes de la fase de pruebas misma, no se registran en el repositorio las fallas detectadas.

Por otro lado, durante la fase de pruebas, las evidencias de fallas o errores también se fueron agregando al repositorio. El equipo de pruebas colabora con el responsable del proyecto, para asegurar que los defectos sean asignados a un esquema o calendario de atención y corregidos siguiendo esa misma línea.

Con propósitos de mantener reportes periódicos, el desarrollador debe confirmar el término de las pruebas de integración que se llevan a cabo al final de cada espiral, añadiendo una entrada correspondiente al repositorio de pruebas.

Actividades de Pruebas por Fase A continuación se muestran las actividades de pruebas que tendrán lugar dentro de

cada fase del desarrollo. La necesidad de que se hagan revisiones formales por parte de algún colega será mínima para la primera espiral. Nuestro colega observador será seleccionado con base en su perfil profesional.

• Fase de Requerimientos: Los casos de uso de negocio, bocetos de interfaz de usuario, el diagrama de casos de uso, casos de uso de sistema, caso de uso por prioridades, los requerimientos suplementarios y los diagramas de actividades (en los casos en que se usaron), se revisaron por el desarrollador, el colega y los clientes.

• Fase de Análisis: El diagrama de clases de análisis, los diagramas de máquinas de estado (donde se hayan usado) y los diagramas de comunicación serán revisados por el desarrollador, el colega y los clientes.

• Fase de Diseño de Sistema: El diagrama de despliegue, las elecciones de tecnología, diagrama de capas, política de interacción entre capas, las políticas de concurrencia y las políticas de seguridad serán revisados por el desarrollador y el colega.

• Fase de Diseño de Subsistema: Los diagramas de clase de diseño; El esquema de base de datos; El diseño de interfaz de usuario y los diagramas de secuencia serán revisados por el desarrollador y el colega.

• Fase de Especificación: Para cada clase, las precondiciones, las postcondiciones y las constantes de clase serán especificadas. sus comentarios o mensajes de depuración serán revisados por el desarrollador y el colega. Las especificaciones de subsistema pueden ser usadas sólo donde sea apropiado pues serán probadas de modo similar a las especificaciones de clase.

• Fase de Implementación: Las pruebas durante ésta fase constan de dos partes.

Añadir mensajes de depuración o comentarios (según la especificación de clase) a los métodos, otros tipos de logueos, como la verificación de término

117

de ciclos y la evasión de condiciones imposibles, son opcionales, pero recomendados.

Ejecutar revisiones de código, por el desarrollador y el colega.

• Fase de Pruebas: La fase de pruebas será responsabilidad del equipo de pruebas, el desarrollo de casos de prueba y procedimientos de pruebas por parte del equipo de pruebas será revisado por el colega. Las pruebas comprenderán. Pruebas de Subsistema, basándose en cualquier interfaz de subsistema

especificada durante las fases de diseño y especificación. Pruebas de sistema, basándose en los casos de uso, prueba funcional y

cargas de prueba a niveles promedio y niveles máximos. Pruebas de Estrés, para confirmar que una posible degradación del servicio

no se alcanza de forma abrupta, como fue definido durante las fases de diseño y especificación.

Pruebas de Seguridad con intentos agresivos para forzar acciones restringidas en el SICBA sin autorización.

Pruebas de Aceptación, basándose principalmente en métricas de productividad.

Métricas, basándose en el desempeño del sistema y el estilo de codificación. Pruebas de Documentación, con la ayuda de usuarios finales y

administrativos. Pruebas de Instalación, usando un equipo con características muy parecidas

al ambiente destino. pruebas Beta, en un sitio seleccionado por el cliente.

• Fase de Mantenimiento: El equipo de pruebas será responsable de manejar el reporte de defectos encontrados después de la liberación, con la ayuda de administrativos, así también dará seguimiento a las correcciones por parte del desarrollador. Entre cada incremento, pueden ser implementadas las correcciones, aplicándoles pruebas de regresión; y liberadas considerando el buen juicio del equipo de pruebas y de los responsables del proyecto. Las pruebas de regresión comprenderán: Pruebas de Subsistema. Pruebas de Sistema. Pruebas de Instalación.

La retroalimentación por parte de los clientes acerca de mejoras posibles para el SICBA será transmitida a los responsables del proyecto, con miras a su incorporación en el siguiente incremento.

118

3.3.7 Glosario A continuación mostramos algunos de los términos catalogados dentro del glosario

obtenido durante el proceso de desarrollo:

SI-COB. Sistema de Información de Cobranza SICBA Sistema de Información Casa Brasil Almacenes

CodProv Código que es asignado a un producto y funciona dentro del ámbito del proveedor.

DBMS Proceso que incluye un sistema manejador de base de datos relacional

Desechable Que está próximo a ser desechado y que formara parte de los Productos Inactivos.

Entregable Que tiene o está en posibilidad de ser Entregado. Evaluable Que tiene o está en posibilidad de ser evaluado

Getter Método que tiene como funcionalidad principal devolver el contenido de un campo

IdGpoProd Identificador de una clase de productos agrupadora.

IdStsProd Identificador de los estatus en que se puede reportar un producto

IdUniversal Identificador único en el universo de productos.

InfoMovUniProducto Bean que modela las entidades de datos necesarios en el proceso de movimiento de un producto

J2EE Edición Empresarial de la plataforma Java 2

JDBC Librería Estándar de Java que proporciona acceso a cualquier base de datos relacional en un modo uniforme

JSP

Java Server Page, una página Web dinámica que contiene código Java para ser ejecutado en el servidor y mezclado con algo de HTML

Producto Activo Que forma parte de los inventarios de la Empresa y que puede aparecer en alguna de las ubicaciones registradas

Producto Inactivo Que ha dejado de ser parte de los inventarios de la empresa aunque guarda registro para su consulta histórica.

Recolectable Que tiene o está en posibilidad de ser Recogido. Reparable Que tiene o está en posibilidad de ser Reparado.

ResponsableAction Maneja las peticiones correspondientes al control de catálogos de responsables

Rezagado Que fue devuelto, recogido o que no está en condiciones equiparables a nuevo.

Setter Método que tiene como funcionalidad principal asignar un valor a un campo

Tomcat Servidor de Aplicaciones WEB, incluye un Contenedor de Servlets y uno de JSPs

Vendible Que tiene o está en posibilidad de ser vendido. WEB Browser Navegador WEB

119

3.4 Aplicación WEB y patrones Para ilustrar nuestro tema de discusión, se desarrolló un Servlet a manera de contra

ejemplo en el cual se muestra una solución rápida y poco elegante, planteando solventar el requisito particular que se describe a continuación:

Primero, se presenta la aplicación. Tenemos una lista de productos que la mueblería tiene en distintos puntos de

venta, la cual se guarda en una base de datos, se requiere consultar ésta base de datos y presentar la lista de artículos al usuario, mostrando su identificador o clave, un título, su ubicación, y un precio, donde el mismo modelo de artículo puede estar disponible entre distintas ubicaciones, se requiere también proveer un contenedor final para mostrar estos. La figura de abajo muestra los componentes principales de este sistema, esencialmente la base de datos, una estructura de datos representando un producto, y un documento HTML para ser transmitido a nuestro cliente, listando todos los productos correspondientes a una consulta. Se asume que el usuario ha entrado al módulo de inventarios y se le ha ofrecido elegir una sucursal en particular. Cada producto es asignado a una de estas sucursales por la columna id_ubicacion de la tabla llamada productos_activos de la base de datos.

Entidad

Atributo (Primary Key)Atributo (Foreign

Key)

Entidad

Atributo (Primary Key)Atributo (Foreign

Key)

Entidad

Atributo (Primary Key)Atributo (Foreign Key)

ORM

1 Tablas de Base de Datos 2 Modelo de Objetos 3 Navegador WEB

Motor de Aplicación

JDBC HTTP

Figura 37. Componentes principales del sistema básico propuesto.

Un fragmento simple de lenguaje SQL para recuperar todos los artículos pertinentes para una búsqueda bajo el parámetro "Mueblería Balcones del sur" o mejor dicho su ID correspondiente podría ser:

SELECT * FROM productos_activos WHERE id_ubicacion = 12

Necesitamos ir a traer los resultados de ésta consulta y luego enviarlos al navegador como HTML. Veamos cómo podemos hacer eso, generando datos para el cliente

package mx.com.casabrasil.servlet; import java.io.IOException; import java.io.PrintWriter; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest;

120

import javax.servlet.http.HttpServletResponse; public class SrvConsProdContraEjemplo extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter pw = response.getWriter(); String connectionURL =

"jdbc:microsoft:sqlserver://192.168.0.1:1433;DatabaseName=CASABRASIL"; Connection connection=null; try{ Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver"); connection = DriverManager.getConnection(connectionURL, "sa", "juri"); Statement st = connection.createStatement(); ResultSet rs = st.executeQuery("SELECT A.ID_UNIVERSAL AS PRODUCTO, "+ "B.NOMBRE_GRUPO AS GRUPO, "+ "C.NOMBRE AS UBICACION, "+ "D.DESCRIPCION AS STS, "+ "A.PRECIO_COMPRA, "+ "A.PRECIO_VENTA, "+ "A.MODELO, "+ "E.NOMBRE AS PROVEEDOR, "+ "A.CODIGO_PROVEEDOR, "+ "A.NOMBRE, "+ "A.DESCRIPCION "+ "FROM CasaBrasil.dbo.PRODUCTOS_ACTIVOS A (NOLOCK) "+ "INNER JOIN CasaBrasil.dbo.GRUPOS_PRODUCTO B (NOLOCK) "+ "ON B.ID_GRUPO = A.ID_GRUPO "+ "INNER JOIN CasaBrasil.dbo.UBICACIONES C (NOLOCK) "+ "ON C.ID_UBICACION = A.ID_UBICACION "+ "INNER JOIN CasaBrasil.dbo.STS_PROD D (NOLOCK) "+ "ON D.ID_STS_PROD = A.ID_STS_PROD "+ "INNER JOIN CasaBrasil.dbo.CATPROVEE E (NOLOCK) "+ "ON E.ID_PROVEE = A.ID_PROVEE "+ "ORDER BY B.NOMBRE_GRUPO, C.NOMBRE "); pw.println("<table border=\"1\" bordercolor=\"#F2E328\">"); pw.println("<tr>"+ "<td>Producto</td>" + "<td>Nombre de Grupo</td>"+ "<td>Ubicación</td>"+ "<td>Estado del Producto</td>"+ "<td>Precio Compra</td>"+ "<td>Precio Venta</td>"+ "<td>Modelo</td>"+ "<td>Proveedor</td>"+ "<td>Código Proveedor</td>"+ "<td>Nombre del Producto</td>"+ "<td>Descripción</td>"+ "</tr>"); while(rs.next()){ pw.println("<tr>"+ "<td>"+rs.getString(1)+"&nbsp;</td> " + "<td>"+rs.getString(2)+"&nbsp;</td> " + "<td>"+rs.getString(3)+"&nbsp;</td> " + "<td>"+rs.getString(4)+"&nbsp;</td> " + "<td>"+rs.getString(5)+"&nbsp;</td> " + "<td>"+rs.getString(6)+"&nbsp;</td> " + "<td>"+rs.getString(7)+"&nbsp;</td> " + "<td>"+rs.getString(8)+"&nbsp;</td> " + "<td>"+rs.getString(9)+"&nbsp;</td> " + "<td>"+rs.getString(10)+"&nbsp;</td> " +

121

"<td>"+rs.getString(11)+"&nbsp;</td> " + "</tr>"); } pw.println("</table>"); } catch (Exception e){ pw.println(e); } } }

En este ejemplo podemos ver a java, conectándose y consultando datos de una base de datos MS-SQL e imprimiendo cadenas con formato HTML al stream de salida, pero lo importante a notar es la estructura general. Una página ASP o PHP podría construirse de modo semejante.

Es así como se comenzó codificando desde la forma más simple posible y gradualmente reestructuramos con dirección al patrón MVC encontrando cómo es que beneficia a nuestra aplicación en términos de su capacidad de respuesta al cambio.

En los siguientes listados se intenta mostrar, mediante las líneas sombreadas, el camino que sigue la operación requerida para conseguir la misma consulta anterior pero con un mejor diseño tanto en la estructura, como en la apariencia.

Cabe señalar que los siguientes fragmentos de código listados van acompañados de otras funcionalidades adicionales a la consulta ejemplificada y que complementan el proceso de negocio, esto puede confundir y dar la impresión de que el código se ha vuelto más complicado y ha crecido desmesuradamente, no obstante debemos tomar en cuenta, que ahora nuestra solución cuenta con una mayor funcionalidad, por ejemplo en la flexibilidad para las consultas con pase de parámetros, formularios con listas desplegables y reportes con un mejor formato estilizado, sin olvidar que también todos nuestros componentes están segmentados y separados para un mantenimiento mucho más fácil de controlar. En el Anexo A en las figuras 39 y 40 se puede observar la diferencia, por lo menos en apariencia, entre las dos soluciones.

Spring.xml …

<bean name="/procesaUniProducto" class="mx.com.casabrasil.action.ManInfoUniProductoAction">

<constructor-arg index="0" ref="uniProductoService"/> </bean>

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean" singleton="true"> <property name="jndiName"> <value>java:comp/env/PoolCB</value> </property> </bean> <bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean"> <property name="configLocation"> <value>classpath:mx/com/casabrasil/persistence/SqlMapConfig.xml</value> </property>

122

<property name="useTransactionAwareDataSource"> <value>true</value> </property> <property name="dataSource"> <ref bean="dataSource"/> </property> </bean> … <bean id="uniProductoDao" class="mx.com.casabrasil.persistence.ManInfoUniProductoIbatisDao"> <property name="sqlMapClient"> <ref bean="sqlMapClient"/> </property> </bean> <bean id="uniProductoService" class="mx.com.casabrasil.service.ManInfoUniProductoDaoService"> <constructor-arg index="0" ref="uniProductoDao"/> </bean>… struts-config.xml … <form-beans>

… <form-bean name="manInfoUniProductoForm"

type="mx.com.casabrasil.form.ManInfoUniProductoForm"/> …

</form-beans> … <action path="/procesaUniProducto" name="manInfoUniProductoForm" type="org.springframework.web.struts.DelegatingActionProxy" scope="request" parameter="dispatch"> <forward name="failure" path="/uniproductoform.jsp"/> <forward name="success" path="/uniproductos.jsp"/> </action> … <message-resources parameter="MessageResources" null="false"/> <plug-in className="org.springframework.web.struts.ContextLoaderPlugIn"> <set-property property="contextConfigLocation" value="/WEB-INF/classes/spring.xml"/> </plug-in> … ManInfoUniProductoAction.java … public ActionForward getUniProductos(ActionMapping mapping, ActionForm form,

HttpServletRequest request, HttpServletResponse response) throws Exception {

logger.debug("getUniProductos"); populateUniProductos(request); return mapping.findForward(Constants.SUCCESS); } … private void populateUniProductos(HttpServletRequest request) { List uniProductos = uniProductoService.getAllUniProductos(); request.setAttribute(Constants.UNIPRODUCTOS, uniProductos); } …

123

ManInfoUniProductoDaoService.java … public List getAllUniProductos(){ return dao.getAllUniProductos(); } … ManInfoUniProductoIbatisDao.java … public List getAllUniProductos() { return queryForList("UniProducto.obtenListado", null); } … UniProducto.xml … <procedure id="obtenListado" resultClass="java.util.HashMap" cacheModel="uniProductosCache"> EXEC CasaBrasil.dbo.CB_spr_IDUProducto </procedure> … Script de Base de Datos CREATE PROCEDURE dbo.CB_spr_IDUProducto @idUniver varchar(11)='-1' AS BEGIN SET NOCOUNT ON IF @idUniver = '-1' BEGIN SELECT A.ID_UNIVERSAL AS PRODUCTO, A.ID_GRUPO, B.NOMBRE_GRUPO AS GRUPO, A.ID_UBICACION, C.NOMBRE AS UBICACION, A.ID_STS_PROD, D.DESCRIPCION AS STS, A.PRECIO_COMPRA, A.PRECIO_VENTA, A.MODELO, A.ID_PROVEE, E.NOMBRE AS PROVEEDOR, A.CODIGO_PROVEEDOR, A.NOMBRE, A.DESCRIPCION FROM CasaBrasil.dbo.PRODUCTOS_ACTIVOS A (NOLOCK) INNER JOIN CasaBrasil.dbo.GRUPOS_PRODUCTO B (NOLOCK) ON B.ID_GRUPO = A.ID_GRUPO INNER JOIN CasaBrasil.dbo.UBICACIONES C (NOLOCK) ON C.ID_UBICACION = A.ID_UBICACION INNER JOIN CasaBrasil.dbo.STS_PROD D (NOLOCK) ON D.ID_STS_PROD = A.ID_STS_PROD INNER JOIN CasaBrasil.dbo.CATPROVEE E (NOLOCK) ON E.ID_PROVEE = A.ID_PROVEE ORDER BY B.NOMBRE_GRUPO, C.NOMBRE END ELSE BEGIN

124

SELECT A.ID_UNIVERSAL AS PRODUCTO, A.ID_GRUPO, B.NOMBRE_GRUPO AS GRUPO, A.ID_UBICACION, C.NOMBRE AS UBICACION, A.ID_STS_PROD, D.DESCRIPCION AS STS, A.PRECIO_COMPRA, A.PRECIO_VENTA, A.MODELO, A.ID_PROVEE, E.NOMBRE AS PROVEEDOR, A.CODIGO_PROVEEDOR, A.NOMBRE, A.DESCRIPCION FROM CasaBrasil.dbo.PRODUCTOS_ACTIVOS A (NOLOCK) INNER JOIN CasaBrasil.dbo.GRUPOS_PRODUCTO B (NOLOCK) ON B.ID_GRUPO = A.ID_GRUPO INNER JOIN CasaBrasil.dbo.UBICACIONES C (NOLOCK) ON C.ID_UBICACION = A.ID_UBICACION INNER JOIN CasaBrasil.dbo.STS_PROD D (NOLOCK) ON D.ID_STS_PROD = A.ID_STS_PROD INNER JOIN CasaBrasil.dbo.CATPROVEE E (NOLOCK) ON E.ID_PROVEE = A.ID_PROVEE WHERE A.ID_UNIVERSAL = @idUniver END SET NOCOUNT OFF END reporteproductos.jsp <%@ page contentType="text/html;charset=UTF-8" language="java" %> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %> <html> <head> <title><fmt:message key="label.productos"/></title> <jsp:include flush="true" page="header.jsp" /> </head> <body onresize=colocar(oper,rpts,mnmto)> <jsp:include flush="true" page="presmenu.jsp" /> <div align="center" style="height: 86%; overflow: auto"> <div class="titleDiv"><fmt:message key="module.title.uniproductos"/></div> <h1 class="main"><fmt:message key="label.productos"/></h1> <br/><br/> <div class="mainborder" style="overflow: auto; width: 95%; height: 75%"> <table width="99%"> <thead > <tr style="position:relative; top: expression(offsetParent.scrollTop); background: #FFFFFF"> <th class="main" style="white-space:nowrap"><fmt:message key="label.producto"/></th> <th class="main" style="white-space:nowrap">

<fmt:message key="label.nombregrupo"/></th> <th class="main" style="white-space:nowrap"><fmt:message key="label.ubicacion"/></th> <th class="main" style="white-space:nowrap">

<fmt:message key="label.estado.producto"/></th> <th class="main" style="white-space:nowrap">

<fmt:message key="label.precio.compra"/></th> <th class="main" style="white-space:nowrap"><fmt:message key="label.precio.venta"/></th> <th class="main" style="white-space:nowrap"><fmt:message key="label.modelo"/></th> <th class="main" style="white-space:nowrap"><fmt:message key="label.proveedor"/></th> <th class="main" style="white-space:nowrap">

<fmt:message key="label.codigo.proveedor"/></th> <th class="main" style="white-space:nowrap">

<fmt:message key="label.nombre.producto"/></th>

125

<th class="main" style="white-space:nowrap"><fmt:message key="label.descripcion"/></th> <th class="main">&nbsp;</th> </tr> </thead> <tbody style="overflow: auto; height: 74%; overflow-x: hidden"> <c:forEach var="uniProdMap" items="${uniProductos}" varStatus="status"> <tr class="${status.index%2==0?'even':'odd'}"> <td class="main" style="white-space:nowrap"> <c:url var="url" scope="page" value="/configuraUniProducto.do"> <c:param name="idUniversal" value="${uniProdMap.PRODUCTO}"/> <c:param name="dispatch" value="setUpParaInsertManUniP"/> </c:url> <a class="main" href="${url}"><c:out value="${uniProdMap.PRODUCTO}"/></a> </td> <td class="main" style="white-space:nowrap"><c:out value="${uniProdMap.GRUPO}"/></td> <td class="main" style="white-space:nowrap">

<c:out value="${uniProdMap.UBICACION}"/></td> <td class="main" style="white-space:nowrap"><c:out value="${uniProdMap.STS}"/></td> <td class="main" style="white-space:nowrap">

<c:out value="${uniProdMap.PRECIO_COMPRA}"/></td> <td class="main" style="white-space:nowrap">

<c:out value="${uniProdMap.PRECIO_VENTA}"/></td> <td class="main" style="white-space:nowrap"><c:out value="${uniProdMap.MODELO}"/></td> <td class="main" style="white-space:nowrap">

<c:out value="${uniProdMap.PROVEEDOR}"/></td> <td class="main" style="white-space:nowrap">

<c:out value="${uniProdMap.CODIGO_PROVEEDOR}"/></td> <td class="main" style="white-space:nowrap"><c:out value="${uniProdMap.NOMBRE}"/></td> <td class="main" style="white-space:nowrap">

<c:out value="${uniProdMap.DESCRIPCION}"/></td> </tr> </c:forEach> </tbody> </table> </div> </div> </body> </html>

126

Capítulo IV

Conclusiones

Como parte final del presente trabajo, se da como una reflexión del camino recorrido, el que por la parte escrita en los capítulos anteriores, podemos considerar lo conforma la teoría con una representación del 30% de todo el proyecto de tesis; en cuanto a la parte práctica se complementa con el 70% tanto de trabajo real como de aplicación de las técnicas estudiadas, se culmina con las siguientes partes que consisten de:

La documentación formal de los manuales de procedimientos, incluidos los diagramas de flujo de actividades, como producto final en lo que concierne al proceso administrativo.

Con respecto al desarrollo de software, entre los entregables relacionados podemos mencionar los documentos generados a la salida de cada fase y los construidos dentro del proceso mismo, los cuales fueron enriquecidos en cada iteración.

No obstante, todo el trabajo realizado encuentra como su mejor representante el SICBA mismo, al comprobar cómo es que su desempeño va cumpliendo uno a uno los requerimientos planteados, así también cumpliendo las expectativas del usuario y en sí de nuestro cliente.

Es importante resaltar que en el transcurso del presente proyecto, hemos logrado explotar sus propósitos cualitativos, pues el hacernos de una metodología, la que no implica la mecanización de actividades, por lo contrario, nos encontramos con un modo nuevo de pensar y de hacer las cosas, el cual está siempre orientado a la mejora y a la calidad, de una manera tal, que la búsqueda de ésta mejora continua, deja de ser tomada como una obligación para convertirse en una necesidad personal.

Por lo anteriormente expuesto y siendo congruentes con la premisa de que este es un primer trabajo usando estas técnicas y metodologías, dejamos pendiente la recopilación, el estudio y el análisis de los resultados cuantitativos para el trabajo que se nos presente, en las oportunidades futuras y en los proyectos de desarrollo dentro del ámbito laboral que ahora se abre a nuestro paso, puesto que sólo de ese modo podríamos tener puntos de comparación y valores de referencia como para hacer estadísticas y llegar a conclusiones cuantitativas con respecto a la aplicación de las metodologías y sus variantes. Es entonces que podemos concluir los siguientes pasos:

1. El Análisis de Procesos comienza por definir una secuencia de actividades que se llevan a cabo para obtener un resultado determinado, a través de la transformación de insumos y del uso de los recursos disponibles, un estudio minucioso de cada paso dentro de un proceso que permite responder en esencia los siguientes cuestionamientos:

1. ¿Cómo debemos realizar nuestras actividades para garantizar que los productos o servicios que entregamos son de buena calidad?

2. ¿Cómo los estamos realizando actualmente? 3. ¿Qué cambios deberíamos hacer?

127

Durante la búsqueda de respuestas para las preguntas anteriores, al seguir una

metodología correcta y al registrar los resultados en un documento formal, como lo es un manual de procedimientos bien elaborado. Se logra depurar y mejorar el proceso en cuestión de tal manera que se consigue:

• Hacer explícitos los estándares de calidad.

• Corregir los sistemas, de modo que desaparezcan las causas de los problemas de calidad o que originan duplicidad (no sólo los síntomas).

• Prevenir errores y defectos

• Identificar los aspectos que deben ser controlados 2. El presente método de análisis de procesos y formalización de manuales de

procedimientos, al ser implementado a través de los distintos niveles de análisis, es decir, de lo general a lo particular, nos pudo dar la pauta para documentar un MACROPROCESO, prestar la atención debida a lo que podría decirse un PROCESO, hasta conseguir la especificación necesaria para un MICROPROCESO, desde luego, sin sobrepasar los límites naturales y lógicos del proceso mismo, ni caer en la redundancia excesiva.

3. El complementar y respaldar la documentación anteriormente mencionada, mediante un buen Diagramas de Flujo de actividades:

• Proporciona una visión sistemática del conjunto de actividades que integran el proceso.

• Permite proporcionar explicaciones más claras sobre la secuencia de actividades del proceso.

• Facilita el establecimiento de límites

• Hace más claro el modo de asignar funciones

• Actúa como una herramienta para mejorar la calidad Con esto aseguramos que las actividades inherentes al proceso y por consecuencia

los datos que en cada punto de control se originan, son consistentes y libres de cualquier posibilidad de ambigüedad. Lo cual nos garantiza que la información que podrá entregar cada módulo del sistema deberá ser fidedigna considerando como un hecho la confianza en los datos alimentados. En consecuencia, a partir de los mismos documentos, se pudo iniciar de manera más fácil y transparente, el proceso de desarrollo del software, además se pudo descubrir su gran versatilidad como para acoplarse naturalmente al trabajo en espiral, iterativo e incremental.

4. Gracias a la utilización de UML como una notación auxiliar durante sesiones de lluvia de ideas para el caso de estudio que se desarrolla en el presente trabajo. Al finalizar, se logró que los diagramas principales se correspondieran exactamente con el código final, así, el resultado muy seguramente da el mismo aspecto que daría si se hubiera utilizado UML como lenguaje de programación gráfico. Esto, desde luego, siempre y cuando se siga una metodología y se exploten correctamente sus ventajas particulares,

128

dependiendo del tipo de proyecto, los recursos disponibles y el ambiente de trabajo en el que se desenvuelva el desarrollador o equipo de desarrollo.

5. Del uso de MVC podemos concluir que ésta arquitectura de aplicaciones otorga varias ventajas que son claves al desarrollo de aplicaciones WEB, destacando:

1. Al separar de manera clara la lógica de negocio (modelo), de la vista; se permite la reutilización del modelo, de modo que la misma implementación de la lógica de negocio que maneja una aplicación, pueda ser usada en otras aplicaciones, sean éstas WEB o no.

2. Permite una división sencilla de roles, dejando que sean diseñadores gráficos y sin conocimientos de programación o desarrollo de aplicaciones, los que se encarguen de la realización de la capa de vista, sin necesidad de mezclar código Java entre el código visual elaborado, tan sólo utilizando algunas etiquetas o tags, no muy diferentes de los usados en el código HTML.

Para nuestro caso, en el que una sola persona se encuentra desarrollando la aplicación, proporciona una manera de dividir el trabajo y agendar las labores de tal modo que, sea acorde a la metodología de desarrollo adoptada, y se vayan desarrollando cada una de las capas de forma iterativa e incremental y se puedan retomar aleatoriamente, según lo exijan los cambios por requerimientos encontrados mientras se avanza a través del proceso de desarrollo mismo. Todo esto con la seguridad de que tales cambios o modificaciones serán intuitivamente controlables.

4.1 Trabajos Futuros Dentro de los proyectos planteados a futuro, siguiendo la misma línea del SICBA,

podemos enunciar el hecho de que la tecnología usada está pensada en la posibilidad inequívoca de ser dispuesta e implementada en un ambiente abierto como lo es Internet, los puntos que debemos tomar muy en cuenta para lograr esto, están relacionados principalmente al tema de la seguridad, como son el acceso y la autenticación de usuarios mediante el uso de certificados, clave pública y privada, o sistemas desarrollados por terceros y de uso libre, que pueden ser integrados al SICBA y administrados independientemente.

Por otro lado la seguridad en el tráfico de la información; del lado del servidor y de modo que la información viaje por un canal seguro y siempre bajo un esquema criptográfico. El establecimiento y configuración de la máquina servidor, implica un trabajo de investigación, que aunque en la mayoría de los casos tiene efectos de modificación de configuración en consola, es esencial documentarse antes de tomar una decisión. Por ejemplo, para configurar la protección contra los bien conocidos ataques de espías o piratas informáticos que amenazan, tanto la confidencialidad de la información, como la disponibilidad del servicio de nuestra aplicación.

Como un modo de reforzar la seguridad y el rendimiento del SICBA, se propone trabajar en un cambio a la arquitectura, de tal suerte que se implementen por un lado, la parte estática del sistema en un servidor puramente WEB como lo es “Apache HTTP Server” y por otro lado, mantener la parte dinámica en el contenedor de servlets, JSPs y aplicaciones del servidor “Apache tomcat”, dejando como transparencia al usuario (front

129

end) y administrador de todas las peticiones al “Apache HTTP Server”, con las ventajas que esto representa.

En el sentido administrativo y con los conocimientos adquiridos, es muy factible pensar en las ventajas competitivas y de negocio que representara trabajar en el análisis y proyección de una micro-empresa consultora, dedicada a la reestructuración de empresas u organizaciones, considerando ofrecer como un producto, el análisis de estructura actual de la entidad cliente, la depuración de sus procesos, el establecimiento de puntos de control en donde no los haya, la virtualización de los mismos y un sistema de información que cierre el ciclo de la mejora o beneficio inherente a los servicios por los que pagaría el cliente.

Siguiendo está línea, se propone el estudio de los procesos que implican el formar un nuevo tipo de empresa, como la planeación estratégica, la posible asociación o reclutamiento de personas que tengan dominio específico en áreas del conocimiento y adaptabilidad a cambios, siendo como un administrador, contador, diseñador gráfico, ingeniero, etc. Esto con el fin de disminuir la curva de aprendizaje o comprensión de las necesidades de la empresa cliente. Investigando y en su caso llevando a cabo hasta los menesteres formales y legales como lo es un acta constitutiva, registros ante notario y hacienda, etc.

Esto último podría parecer un tanto divagante, no obstante sabemos ahora que es posible, gracias al conocimiento teórico y práctico adquirido durante el desarrollo del presente trabajo, el cual ha sentado bases firmes para la consecución de las metas futuras.

130

Bibliografía C.P. y C.I.A. Vera Smith, Fernando. “Guía para la elaboración e integración de

manuales de Procedimientos”. Instituto Politécnico Nacional. Abril de 2003. Indicadores. Características, metodología y utilización. Academia Mexicana de Auditoría Integral y al Desempeño, A.C. Dofiscal Editores.

“Manual para el Rediseño de Procesos Institucionales”. Secretaría de Relaciones Exteriores

Franklin Fincowsky Enrique Benjamín. “Organización De Empresas, Análisis Diseño Y Estructura”, FCA – UNAM

Franklin Fincowsky Enrique Benjamìn. "Manuales Administrativos: Guìa Para Su Elaboración", FCA – UNAM

Martínez, Elvira C.M. “Definición de los productos de los SADC”. Servicios de Administración y Documentación Clínica. Pap Med 1998;7(2): 4

Estévez Lucas J. “Gestión por procesos: una herramienta eficaz para la mejora continua”. Todo Hosp 1999;153:43-6

Varo, J. “Gestión estratégica de la calidad: Un modelo de gestión hospitalaria”. 1993, Valencia. Monografías Sanitarias. Serie A

Pinto Madroñero C, Uris Selles J, Mena Esquivias L “Papeles Médicos” 2003;12(3):119-124

Vivas Consuelo, D. “Mejora continua de la calidad de los servicios de salud: los gráficos de control estadísticos del proceso”. Papeles de Gestión Sanitaria. Monografías de Economía y Gestión de la Salud. Vol. 1. número 3. MCQ Ediciones. Valencia; 1994.

Juran, J. M.1996. “Juran y la Calidad por el Diseño”. Ed.Díaz de Santos. 819 p.

Kolarik, William J. 1995. “Creating Quality. Concepts, Systems, Strategies, and Tools”. McGraw-Hill. p.201-290.

Laudon, Kenneth C. y Laudon, Jane P. 1996. “Administración de los Sistemas de Información”. Prentice Hall. 885 p.

Martin, James y Odell, James J. 1992. “Análisis y diseño orientado a objetos”. Prentice Hall. 456 p.

Senn, James A. 1992. “Análisis y diseño de sistemas de información”. McGraw-Hill. 942 p.

Corzo A. M. “Introducción A La Ingeniería De Proyectos” Ed. LIMUSA

Gómez Cejas, Guillermo. “Sistemas Administrativos”, Análisis y Diseños. Editorial Mc Graw Gil. Año 1.997. Pág. 96 a la 103, 107 a la 117.

131

Chiavenato, Idalberto. “Iniciación A La Organización Y Control”. Editorial Mc Graw Gil. Año 1.993. Pág. 66 hasta 72.

Gómez Rondón, Francisco. “Sistemas Y Procedimientos Administrativos”. Editorial Mc Graw Gil. Año 1.995. Pág. 104 hasta 114

Rod Johnson, Juergen Hoeller, Alef Arendsen, Colin Sampaleanu, Rob Harrop, Thomas Risberg, Darren Davison, Dmitriy Kopylenko, Mark Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Rick Evans. “The Spring Framework” – Reference Documentation Spring java/j2ee Application Framework 2.0.2 Copyright © 2004-2007

Thomas Risberg. “Developing a Spring Framework MVC application”,step-by-step July, 2003 (Revised April, 2005) spring-framework-2.0.2 Documentation

Philip McCarthy. ”Ajax for Java developers: Exploring the Google Web Toolkit” Develop Ajax applications from a single Java codebase Level: Advanced. (philmccarthy@gmail.com, Software development consultant, Independent) 27 Jun 2006

Dave Crane, Eric Pascarello, With Darren James. “Ajax in Action” MANNING, Manning Publications Co. ©2006 ISBN 1-932394-61-3, Printed in the United States of America 1 2 3 4 5 6 7 8 9 10 – VHG – 09 08 07 06 05

Arnold Doray. “Beginning Apache Struts: From Novice to Professional” Copyright © 2006 ISBN-13 (pbk): 978-1-59059-604-3, ISBN-10 (pbk): 1-59059-604-8. Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1

Ted Husted, Cedric Dumoulin, George Franciscus, David Winterfeldt. “Struts in Action”, Building web applications with the leading Java framework. MANNING. Manning Publications Co. ©2003 ISBN 1-930110-50-2, Fourth, corrected, printing. April 2003. Printed in the United States of America 1 2 3 4 5 6 7 8 9 10 – VHG – 05 04 03

Mike O’Docherty. “Object-Oriented Analysis and Design”. Understanding System Development with UML 2.0. John Wiley & Sons Ltd, Copyright 2005 ISBN-13 978-0-470-09240-8. ISBN-10 0-470-09240-8 (pbk. : alk. paper) Printed and bound in Great Britain by Biddles Ltd, King’s Lynn

Alexander, C., Ishikawa, S., and Silverstein, M. “A Pattern Language”: Towns, Buildings, Construction, Oxford University Press, (1977) ISBN: 0-195-01919-9

Alur, D., Crupi, J., and Malks D. “Core J2EE Patterns: Best Practices and Design Strategies”, Prentice Hall, (2003) ISBN: 0-131-42246-4

Ambler, S. “Agile Database Techniques”, John Wiley & Sons, (2003)ISBN: 0-471-20283-5

Martin, J., and Odell, J. “Object-oriented Methods: A Foundation – UML Edition”, Prentice Hall, (1998) ISBN: 0-139-05597-5

132

Constantine, L., and Lockwood, L. “Software For Use: A Practical Guide to the Models and Methods of Usage-Centered Design”, Addison-Wesley, (1999) ISBN: 0-201-92478-1

Clinton Begin, Brandon Goodin. Larry Meadors ,“iBATIS in Action”, MANNING, Manning Publications ©2007 ISBN 1-932394-82-6. Printed in the United States of America 1 2 3 4 5 6 7 8 9 10 – MAL – 11 10 09 08 07

James Goodwill. “Mastering Jakarta Struts”. Wiley Publishing, Inc. Copyright © 2002. ISBN: 0-471-21302-0. Printed in the United States of America 10 9 8 7 6 5 4 3 2 1

Vivek Chopra, Amit Bakore, Jon Eaves, Ben Galbraith, Sing Li, Chanoch Wiggers. “Professional Apache Tomcat 5”. Wiley Publishing, Inc. Copyright © 2004. 2004103742. ISBN: 0-7645-5902-8. Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1. 1B/RR/QV/QU/IN

133

Anexo A – Pantallas del SICBA

Figura 38.Pantalla Principal con menú desplegado.

Figura 39. Resultado de la consulta mediante un Servlet sin usar el patrón MVC.

134

Figura 40. Resultado de la consulta mediante un Action usando el patrón MVC.

Figura 41. Formulario para consulta de Inventarios.

135

Figura 42. Reporte detallado de Inventarios.

Figura 43. Formulario para realizar un traspaso de productos.

136

Figura 44. Formulario para relacionar movimientos de ventas contra facturación.

Figura 45. Formulario para relacionar un cambio de clave a un producto.

137

Anexo B – Herramientas del Servidor Tomcat

Figura 46. Propiedades y Controles.

Figura 47. Monitoreo de logs en modo consola.

138

Figura 48. Administrador de aplicaciones WEB.

139

Anexo C – Entorno de desarrollo Eclipse

Figura 49. Estructura de paquetes y código fuente java.

Figura 50. Estructura del contenido WEB y configuraciones XML.

140

Figura 51. Ejemplificación de esquema History en el repositorio.

141

Anexo D – Herramientas del Servidor de Base de Datos

Figura 52. Analizador de Consultas y Compilador de Sotred Procedures.

Figura 53. Administrador Corporativo (Servidores, Bases de Datos y Tablas).