Desarrollo de un sistema basado en aplicaciones Web para la automatización del control de pedidos asociado al proceso de ventas de una Empresa Cafetalera

...

El Sistema de aplicaciones será dividido en tres partes, una que se utilizará en el departamento de facturación de la empresa para el control de los pedidos realizados, otra orientada al uso de los vendedores para realizar los pedidos de café y la última utilizada por administradores del sistema para el control de seguridad y acceso a usuarios y administración de las bases de datos, estas partes a su vez conectadas a la base de datos en común que registra las actividades realizadas.

Este será el inicio del proceso de automatización en Dinaca 2000, por tanto se espera que los resultados obtenidos mejoren y sobrepasen las expectativas, logrando así el alcance de las metas propuestas y la mayor productividad en la Empresa.

MATERIALES Y MÉTODOS

Para lograr el desarrollo del sistema antes mencionado se utilizó la metodología de Proceso Unificado de Desarrollo de Software con algunas variantes utilizadas en el desarrollo de aplicaciones Web, con el cual se realizó el estudio de los procesos a automatizar para su posterior implementación en el sistema, estableciendo así el plan de ataque contra el problema a resolver. Se emplearon diversas herramientas de desarrollo Web para la construcción de las aplicaciones que componen el sistema y un manejador de base de datos que alimenta las bases de datos diseñadas y suministra la información requerida por las aplicaciones en el funcionamiento del sistema. (Jacobson, Booch, Rumbaugh. 2000).

El desarrollo del sistema se llevó a cabo haciendo uso de las cuatro fases del proceso unificado de desarrollo de software, a través de estas fases son representados cinco flujos de trabajo, utilizando el Lenguaje Unificado de Modelado (UML). Una vez analizados los requerimientos básicos (para el desarrollo del sistema) y los opcionales (para complementar labores de ventas) del área de venta, se fueron modelando y desarrollando los modelos y componentes para la realización del sistema. Los diagramas utilizados para documentar el desarrollo del sistema a través de la herramienta UML fueron diagramas de casos de uso, diagramas de análisis, diagramas de clases, diagramas de colaboración y diagramas de secuencia. (Stevens, Pooley. 2002).

El Proceso Unificado se basa en componentes, lo que significa que el sistema en construcción está hecho de componentes de software interconectados por medio de interfaces bien definidas; Los aspectos distintivos del Proceso Unificado están capturados en tres conceptos clave: dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. Esto es lo que hace único al Proceso Unificado.

Se utilizaron las siguientes fases del Proceso Unificado de Desarrollo de Software,

Fase de inicio: durante la fase de inicio, se desarrolla una descripción del producto final a partir de una buena idea y se presenta el análisis de negocio para el producto. Esencialmente, esta fase responde a las siguientes preguntas:

• ¿Cuáles son las principales funciones del sistema para sus usuarios más importantes?

• ¿Cómo podría ser la arquitectura del sistema?

• ¿Cuál es el plan de proyecto y cuánto costará desarrollar el producto?

Fase de elaboración: en esta fase se identifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. La relación entre la máquina del sistema y el propio sistema es primordial.

Fase de construcción: En esta fase se crea el producto. Aquí la línea base de arquitectura crece hasta convertirse en el sistema completo. La descripción evoluciona hasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios. El grueso de los recursos requeridos se emplea durante esta fase del desarrollo. Sin embargo la arquitectura del sistema es estable, aunque los desarrolladores pueden descubrir formas mejores de estructurar el sistema, ya que los arquitectos recibirán sugerencias de cambios arquitectónicos de menor importancia. Al final de esta fase, el producto contiene todos los casos de uso que la dirección y el cliente han acordado para el desarrollo de esta versión. Sin embargo, puede que no esté completamente libre de defectos. Muchos de estos defectos se descubrirán y solucionarán durante la fase de transición. La pregunta decisiva es: ¿cubre el producto las necesidades de algunos usuarios de manera suficiente como para hacer una primera entrega?

Fase de transición: La fase de transición cubre el periodo durante el cual el producto se convierte en versión beta. En la versión beta un número reducido de usuarios con experiencia prueba el producto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan algunas de las mejoras sugeridas en una versión general dirigida a la totalidad de la comunidad de usuarios. La fase de transición conlleva actividades como la fabricación, formación del cliente, el proporcionar una línea de ayuda y asistencia, y la corrección de los defectos que se encuentren tras la entrega. El equipo de mantenimiento suele dividir esos defectos en dos categorías: los que tienen suficiente impacto en la operación para justificar una versión incrementada y los que pueden corregirse en la siguiente versión normal. (Jacobson, Booch, Rumbaugh. 2000).

[pic 1]

Figura 1. Arquitectura Web de tres niveles. Vegas (2002)

La arquitectura de la aplicación presenta un esquema de tres niveles (véase la Figura 1). El primer nivel consiste en la capa de presentación que incluye no sólo el navegador, sino también el servidor Web que es el responsable de dar a los datos un formato adecuado. El segundo nivel está referido habitualmente a algún tipo de programa o script. Finalmente, el tercer nivel proporciona al segundo los datos necesarios para su ejecución. Vegas (2002)

RESULTADOS

- Fase de Inicio: en esta fase se definió y acordó el alcance del proyecto con las personas involucradas y responsables del sistema propuesto, se identificaros los requisitos, se desarrolló el modelo de dominio y el modelo de casos de uso para los principales procesos, así como también se identificaron los riesgos asociados al proyecto. A partir del modelo de casos de uso y la lista de riesgos, se determinó qué casos de uso deben implementarse primero para atacar los riesgos críticos y se estableció la primera visión de la arquitectura candidata. Con base en la información previa se realizó el proceso de