guÍa metodologÍca para el diseÑo sistemÁtico de

138
GUÍA METODOLOGÍCA PARA EL DISEÑO SISTEMÁTICO DE APLICACIONES WEB EN COMERCIO ELECTRÓNICO DANIEL RODRÍGUEZ BERNAL UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS COMPUTACIÓN BOGOTA DC 2002

Upload: others

Post on 12-Jan-2022

3 views

Category:

Documents


0 download

TRANSCRIPT

GUÍA METODOLOGÍCA PARA EL DISEÑO SISTEMÁTICO DE

APLICACIONES WEB EN COMERCIO ELECTRÓNICO

DANIEL RODRÍGUEZ BERNAL

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE SISTEMAS COMPUTACIÓN BOGOTA DC

2002

ISC-2002-2-41

2

GUÍA METODOLOGÍCA PARA EL DISEÑO SISTEMÁTICO DE APLICACIONES WEB EN COMERCIO ELECTRÓNICO

DANIEL RODRÍGUEZ BERNAL

Trabajo de grado para optar por el titulo de Ingeniero de Sistemas y Computación

Asesorado por: ÁNGELA CRISTINA CARRILLO

Ingeniero de Sistemas y Computación

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE SISTEMAS COMPUTACIÓN BOGOTA DC

2002

ISC-2002-2-41

3

DEDICATORIA

Dedico esta tesis A mis padres, por todo su apoyo y compresión a lo largo de mi carrera profesional. A la ingeniera Ángela Carrillo Ramos, por su colaboración y ayuda en el desarrollo de este trabajo. A mi novia, por su motivación y hermosa compañía. A mis amigos, que siempre confiaron en mis capacidades para la terminación de esta etapa de mi vida.

ISC-2002-2-41

4

CONTENIDO OBJETIVOS .....................................................................................................................6

Objetivo General. ..........................................................................................................6 Objetivos Específicos....................................................................................................6

INTRODUCCIÓN ............................................................................................................7 CAPÍTULO 1 ....................................................................................................................9 1. Consideraciones sobre modelos de negocios en Internet ..............................................9

1.1 Business to Business .............................................................................................10 1.2 Business to Customer............................................................................................12 1.3 Customer to Customer...........................................................................................13 1.4 Business to Government .......................................................................................13 1.5 Claves del éxito en Internet...................................................................................13

1.5.1 Consideraciones en el inicio de un proyecto de e-commerce ........................15 2. El contenido del sitio Web de comercio electrónico...................................................17

2.1 Valor agregado generado por e-commerce ...........................................................17 2.2 Comercio tradicional vs Comercio electrónico....................................................18 2.3 Panorama colombiano...........................................................................................19 2.4 Sistemas de pago en Internet.................................................................................23

2.4.1. Protocolos de pago en Internet......................................................................23 2.4.2 Medios de pago en Internet ............................................................................26 2.4.3 Panorama Colombiano en aspectos de seguridad y medios de pago .............28

2.4.3.1 El sistema de transición para pagos vía Internet en Colombia................29 2.5 Cultura de compra en Internet...............................................................................31

3. Plataformas de comercio electrónico ..........................................................................33 4. Arquitectura Web ........................................................................................................34

4.1 Arquitectura Cliente / Servidor .............................................................................35 4.2 Aplicaciones Multinivel ........................................................................................38

5. Modelo de Negocio a Considerar en el Desarrollo del diseño de la Aplicación Web de Comercio Electrónico......................................................................................................41

5.1 Consideraciones Especiales ..................................................................................41 5.2 Modelo de negocio B2B.......................................................................................41

CAPITULO 2 ..................................................................................................................43 1. MODELO CONCEPTUAL ........................................................................................43

1.1 Diagrama de Despliegue y Componentes ............................................................43 1.2 Casos de Uso .........................................................................................................44 1.3 Modelo del Negocio.............................................................................................48 1.4 Productos y Herramientas de Integración de Aplicaciones...................................51 1.5 E-bussines y el conocimiento del cliente ..............................................................54 1.6 Requerimientos Funcionales .................................................................................56

1.6.1 Requerimientos para la compañía ( productor de materia prima ).................57 1.6.2 Requerimientos para la compañía ( proveedor ) ............................................58 1.6.3 Requerimientos para la compañía ( convertidor ) ..........................................60 1.6.4 Requerimientos para la compañía (distribuidor)............................................61 1.6.5 Requerimientos para la compañía (minorista ) ..............................................63 1.6.6 Requerimientos del usuario (cliente final) .....................................................64

ISC-2002-2-41

5

1.7 Diagramas de Casos de Uso para la Cadena de Suministro de Muebles. .............65 1.8 Modelo Conceptual ...............................................................................................67 1.9 Modelo Conceptual para la Cadena de Suministro (Modelo de Negocio B2B) ...70

1.9.1 Modelo de la compañía del Productor de Materia Prima...............................70 1.9.2 Modelo de la compañía del Proveedor...........................................................73 1.9.3 Modelo de la compañía del Convertidor.......................................................75 1.9.4 Modelo de la compañía del Distribuidor........................................................77 1.9.5 Modelo de la compañía del Minorista............................................................78

2. MODELO DE NAVEGACIÓN..................................................................................79 2.1 Modelo De Espacio De Navegación .....................................................................80

2.1.1 Método ...........................................................................................................81 2.1.2 Ejemplos del método de espacio de navegación ............................................82

2.1.2.1 Modelo de espacio de navegación para el distribuidor ...........................83 2.1.2.2 Modelo de espacio de navegación para el minorista...............................86

2.2 Modelo De Estructura De Navegación .................................................................89 2.2.1 Definición de índices, consultas y guías ........................................................89

2.2.1.1 Método para enriquecer el modelo espacial con índices, consultas y guías. ...................................................................................................................92

2.2.2 Definición de menús. .....................................................................................93 2.2.2.1 Método para enriquecer el modelo espacial con menú ..........................95

2.3 Ejemplo del método de estructura de navegación.................................................95 3. MODELO DE PRESENTACIÓN ESTÁTICA........................................................101

3.1 Elementos de modelaje. ......................................................................................102 3.2 Modelo de presentación basado en un menú.......................................................105 3.3 Método de presentación basado en mapa............................................................113

4. MODELO DE PRESENTACIÓN DINÁMICO.......................................................117 4.1 Elemento de modelaje .........................................................................................117 4.2 Método ................................................................................................................118

CAPITULO 3 ................................................................................................................120 1. APLICACIÓN DE LA GUIA A CASOS REALES.................................................120 CONCLUSIONES GENERALES................................................................................133 REFERENCIAS............................................................................................................137

ISC-2002-2-41

6

OBJETIVOS

Objetivo General. Especificar los aspectos más importantes y fundamentales para la construcción de

aplicaciones Web, relacionadas con el manejo de transacciones comerciales basadas en

Internet. Estos aspectos tienen que ver con la infraestructura, es decir, la tecnología de

la arquitectura Web; para este fin se presentará un acercamiento a dichas tecnologías de

uso común en el desarrollo de aplicaciones Web. En esta parte, el objetivo general es

profundizar sobre las tecnologías utilizadas para soportar los modelos de comercio

electrónico.

Objetivos Específicos.

• Investigar y aportar recomendaciones sobre una adecuada implantación de

infraestructura lógica para el desarrollo de aplicaciones Web.

• Vincular los modelos de negocios con las tecnologías de arquitectura Web, para

reconocer sus requerimientos.

• Realizar una breve aproximación acerca de los conceptos claves en un proyecto

de comercio electrónico.

• Desarrollar una guía formal acerca del diseño de aplicaciones web, mediante la

construcción de modelos como el conceptual, de estructura de navegación y de

presentación.

• Realizar mediante un ejemplo de comercio electrónico, el desarrollo de la guía

metodológica para el diseño de aplicaciones Web, especialmente en el caso

B2B.

ISC-2002-2-41

7

INTRODUCCIÓN

Dado que las preguntas que causan mayor preocupación en el inicio de un proyecto de

comercio electrónico son ¿Qué infraestructura funcionará correctamente según las

necesidades del negocio?, ¿Qué clases de aplicaciones de Internet son usadas por otras

empresas?, ¿Pueden ser éstas transferidas y adaptadas exitosamente en la empresa?, en

esta primera parte se realizan consideraciones pertinentes sobre estos cuestionamientos.

Para lograr este objetivo, se analizará la infraestructura tecnológica y la arquitectura

utilizadas en los modelos de negocio. Dentro de este análisis se harán comparaciones

acerca de las tecnologías en uso y aquellas que se perfilan como posibles reemplazos en

el desarrollo de aplicaciones Web.

El comercio electrónico1, no es un concepto nuevo. Existe desde los años setenta, con

tecnología soportada por las empresas que hacían grandes inversiones en la

automatización de los procesos comerciales. Lo realmente nuevo es la infraestructura de

Internet, que permite ubicar al comercio electrónico al alcance de muchas más

empresas. La implementación del comercio electrónico ha permitido identificar algunas

tendencias o modelos de negocios:

• Negocio a Cliente ( Business to Customer)

• Negocio a Negocio ( Business to Business)

• Negocio a Gobierno (Business to Government)

1 Mauricio Ruiz Valdivieso, Internet en las organizaciones modernas.

ISC-2002-2-41

8

• Cliente a Cliente ( Customer to Customer)

Determinados los modelos de negocio anteriores, en el primer capítulo se define cada

uno de ellos y se dará una breve explicación de las tecnologías asociadas a dichos

modelos.

En el capítulo segundo, se utiliza un ejemplo del modelo de negocios B2B, cuyo tema

es la industria de muebles. Con éste ejemplo, se pretende ilustrar la metodología para el

diseño de aplicaciones Web, no obstante, cabe aclarar que cualquier modelo de negocio

es factible de ser modelado por esta metodología.

ISC-2002-2-41

9

CAPÍTULO 1

1. Consideraciones sobre modelos de negocios en Internet

Como ya se habló brevemente en la introducción, el comercio electrónico, no es

únicamente la compra y venta electrónica de bienes, información y servicios, sino que

también incluye el uso de la red para actividades como publicidad, búsqueda de

información sobre proveedores, negociaciones, trámites administrativos o colaboración

entre empresas. Internet provee un conjunto de tecnologías públicas y universales que

permiten los anteriores propósitos.

Así, se crean nuevos canales de ventas y formas de realizar el mercadeo.

Implementando transacciones electrónicamente se reducen los costos de éstas y el

tiempo de entrega para algunos bienes, especialmente, los que son de carácter digital tal

como software, texto, imágenes o videos.

Compañías grandes y chicas están utilizando Internet para otorgar la información del

producto, obtener pedidos y soportar las necesidades de los clientes. Estas iniciativas de

comercio electrónico representan la automatización de los tradicionales procesos

basados en papel. Los modelos de negocio basados en Internet, pueden ser parte interna

de un negocio existente, remplazar un proceso en un negocio existente o representar la

totalidad de una nueva clase de negocios. De esta manera, nuevos modelos de negocio

se generan, como por ejemplo las comunidades On-line (por ejemplo Tripod.com),

donde grupos de interés participan y se informan acerca de temas de tecnología o

ISC-2002-2-41

10

cultura, y los patrocinadores obtienen información acerca de los gustos de los clientes y

de potenciales compradores.

Los modelos de negocio en comercio electrónico se diferencian principalmente por los

actores (directos o intermediarios) que participan en las transacciones.

1.1 Business to Business El comercio electrónico entre empresas ha sido el origen de los negocios on-line. Este

tipo de comercio realiza ofertas concretas, especializadas, que permitan ofrecer un

servicio o producto con mayores ventajas para el consumidor, mediante la utilización de

tecnologías que integran aplicaciones, como el caso de XML2. Así mismo, el modelo de

negocio Business to Business, busca confiabilidad, robustez e integridad por medio del

intercambio electrónico de información de negocios (EDI) entre organizaciones por

medio de un formato estructurado, generalmente bajo el estándar X.12 ANSI.

EDI es una tecnología basada en traductores, se preparan los documentos en una

traducción de salida, luego realiza la transmisión por medio de Mailboxes, y se obtiene

la información deseada, por medio del traductor de entrada. Este mecanismo evita re-

entrada de datos (preserva la integridad), evita costos por uso de correos u otros canales

de comunicación, y en general disminuye los costos de las transacciones. No obstante,

EDI presenta algunas debilidades, como la rigidez de sus formatos, la utilización de

VAN (Value Added Network) como red de transporte (normalmente costosas de

mantener), y los costos altos de implementación y operación. Debido a estos

inconvenientes, se busca cambiar el esquema para lograr por medio de una aplicación

2 www.xmlglobal.com

ISC-2002-2-41

11

XML separar datos, formato y presentación, al igual que utilizar SSL como mecanismo

de seguridad y utilizar TCP/IP como protocolo de transporte.

El desarrollo e introducción de (XML) Extensible Markup Language, en el mundo del

comercio electrónico ha sido de gran ayuda, en cuanto a la integración de aplicaciones

se refiere. De esta manera, las restricciones de plataformas quedan atrás, debido a que

XML funciona como un metalenguaje, es decir, un lenguaje para describir otros

lenguajes, el cual permite diseñar un propio lenguaje de marcas para describir diferentes

tipos de documentos. Un ejemplo de su utilización es, Cisco Systems, que han

implementado GoXML™ el cual funciona como un Web Service Integration, para

transformar una gran cantidad de datos EDI en XML, los cuales son posteriormente

convertidos en HTML para ser soportados por redes Cisco AWID y permitir el acceso

IP telefónico. Con esto se generaron menores costos y mejor integración en su canal de

suministros.

Por otro lado, Microsoft ha desarrollado su propio conjunto de tecnologías de software

“Microsoft.Net”, para conectar su mundo de información, sistemas y dispositivos,

además de permitir un nivel alto de integración de software a través de Servicios Web

XML, con características adecuadas, y bloques de aplicaciones que se conectan con

cada uno vía Internet. La plataforma Microsoft .NET incluye una extensa familia de

productos-clientes que utilizan dispositivos inteligentes, servicios, servidores, y

herramientas diseñadas para utilizar XML e incorporar estándares de la industria del

Internet, tales como: Microsoft Server, Microdosft.Net, Microsoft Visual Studio.

ISC-2002-2-41

12

1.2 Business to Customer Esta modalidad es la aplicación al mercado virtual de las estrategias comunes de venta

del mercado tradicional. El tipo de potencial consumidor es distinto y se cataloga como

un “ciberconsumidor” alguien que sabe bien lo que quiere y exige al vendedor on-line

niveles de calidad y precio. Un hecho importante generado por la capacidad de

comunicación que brinda Internet entre cliente y la compañía, es la posibilidad de

reducir intermediarios entre estos para realizar una transacción. No obstante, la figura de

intermediario persiste pero con un mayor grado de especialización, para generar utilidad

en la cadena de valor del producto o servicio.

La Web provee un medio a través del cual los clientes pueden interactuar con la

compañía, a su conveniencia y encontrar información que lo enriquezca como

consumidor. Algunas compañías están invirtiendo muchos esfuerzos en lograr generar

aplicaciones que brinden la capacidad de autoservicio al cliente. American, Northwest y

otras aerolíneas han creado Websites donde los usuarios puedan revisar tiempo de

llegada de los vuelos, tiquetes disponibles, logística de los aeropuertos y mucha

información de su interés.

Es esencial en el desarrollo de una estrategia B2C tener en cuenta cuáles son las

necesidades del cliente virtual y de qué modo la empresa puede cubrirlas con el mejor

servicio. Las tecnologías usadas en la integración de las aplicaciones web, son las

mismas que se utilizan en el caso B2B, lógicamente, en la parte cliente, las aplicaciones

que corren son las comunes, como por ejemplo, los scripts, applets, etc.

ISC-2002-2-41

13

1.3 Customer to Customer Este modelo se emplea con gran éxito en Webs dedicadas a subastas entre particulares.

Es un proceso de compraventa que pretende poner en contacto a quienes ofrecen y

quienes demandan por un determinado producto, sin que exista la necesidad de un

intermediario.

El funcionamiento de este modelo se basa en subastas, como por ejemplo el modelo de

Yahoo! (Es.auctions.yahoo.com), donde la subasta en sí no es la base del negocio, sino

un servicio más de la compañía que gestiona el portal. Por otro lado, Aucland

(Aucland.es), Mercado Libre (Mercadolibre.com), pretenden intermediar en los

procesos de compra, dado que en el caso de un acuerdo es posible que cobren un

porcentaje sobre el importe del precio final.

1.4 Business to Government Este modelo no está muy desarrollado actualmente, pero su objetivo es que las empresas

actúen como proveedoras del gobierno.

1.5 Claves del éxito en Internet3 Después de realizar una breve introducción acerca de los modelos de comercio

electrónico más frecuentes, es preciso hacer mención de sugerencias que aportan ideas o

buenas bases para el diseño y construcción de la aplicación Web.

3 Maria Luisa Solé Moro, Comercio Electrónico: Un mercado en expansión.

ISC-2002-2-41

14

En la puesta en marcha de un negocio soportado en Internet, la alta gerencia o

administración debe considerar los cambios que influirán en los procesos normales de la

compañía, como la forma de ventas, la interacción con el cliente, el aprendizaje

continúo de nuevas tecnologías Web, la viabilidad económica a largo plazo, etc.

Cuando ya está decidida la incorporación de dichas tecnologías es preciso considerar el

procedimiento adecuado para comercializar sus productos, es decir, iniciar un proyecto

de e-commerce, con la colaboración de los departamentos involucrados (ventas,

contabilidad, producción, etc.). Los clientes serán pieza clave en el modelo del negocio

y las decisiones que sean tomadas deben estar enfocadas en la satisfacción total del

mismo.

En muchos casos estos proyectos deben ser asesorados por personal con experiencia en

temas de comercio electrónico, que a partir de las características ya definidas del

negocio, resuelvan por medio del diseño formal y la tecnología Web las necesidades

del cliente y de la compañía.

Las anteriores consideraciones son sólo la base del inicio o la migración de un negocio

en Internet, por tanto y según el caso específico, la compañía debe realizar estudios

exhaustivos para no llegar a fracasos debido a motivos como:

• Crear algo que no sea atractivo. • Ignorar lo que ya existe. • No prever la logística. • No incluir un mecanismo de respuesta. • Cobrar más que los puntos de venta tradicionales. • No relacionar los inventarios. • No acusar recibo de un pedido. • Utilizar diseños exagerados.

ISC-2002-2-41

15

• Construir un sitio lento. • Omitir la opción de búsqueda. • Confundir a los usuarios.

Muchos de los anteriores motivos, se encuentran ligados desde el principio a

consideraciones ignoradas en los objetivos del negocio y a fallas en el diseño de la

aplicación Web.

1.5.1 Consideraciones en el inicio de un proyecto de e-commerce Dado que una compañía puede determinar el traslado total de las operaciones del

negocio al mundo virtual, es conveniente hacer un replanteamiento o rediseño del

modelo de negocios para continuar siendo rentable y sobrevivir en la era informática.

Además, si una entidad de la cadena de valor se empieza a hacer electrónicamente, se

corre el riesgo de desviarse de la necesidad que pretende resolver, por eso la tecnología

debe estar a la mano con la estrategia del negocio.

El éxito de las compañías actualmente radica en la capacidad de transformación

continua, por eso, en su diseño se debe pensar en estructurar el control de flujo de la

información para hacer mas fácil los cambios. Con las nuevas tecnologías antes

mencionadas, es posible lograr alianzas flexibles con otras compañías o por medio de

outsourcing, para disminuir costos y mantener a los clientes. Igualmente estas alianzas

son fáciles de implementar cuando ambas partes usan software de aplicaciones similares

o utilizan las tecnologías de integración de aplicaciones cuando son diferentes.

• Desafiar las definiciones tradicionales de valor: con esto se pretende innovar o

generar nuevas proposiciones de valor que rompan paradigmas y otorguen al usuario

nuevas formas de percibir la empresa.

ISC-2002-2-41

16

• Definir el valor en términos de la experiencia del cliente: es decir reconocer la

importancia de realizar servicios y productos con un alto grado de personalización, para

lograr variables de diferenciación.

• Hacer ingeniería en toda la cadena: Con esto se pretende renovar o reinventar

procesos que afecten el correcto desempeño de la funcionalidad del negocio.

• Crear una nueva base de tecno-empresa centrada en el cliente: Involucrar

tecnologías de información que permitan orientar el negocio hacia el cliente y a la

prestación del servicio.

• Crear una nueva generación de líderes que comprendan cómo crear un futuro

digital con diseño y no por accidente: de aquí surge otro punto clave acerca de la

necesidad de metodologías capaces de evitar errores debidos a diseños sin orientación y

estructuras.

Sobre las definiciones de valor son interesantes aspectos como la velocidad, la

conveniencia, la personalización, el precio, y en general cualquier proposición de valor

para el cliente, que sea capaz de generarse con las nuevas tecnologías. El e-commerce

esta permitiendo a las compañías escuchar a sus clientes y lograr proporcionar menores

precios y a reinventar procesos de servicios.

En la primera fase del e-commerce, es importante no dejarse llevar por las

presentaciones interactivas generadas en la Web, ignorando el hecho de que debe ser un

negocio integrado de principio a fin, es decir, la orden, el envío, el servicio, etc.

ISC-2002-2-41

17

2. El contenido del sitio Web de comercio electrónico

2.1 Valor agregado generado por e-commerce4 El principal enfoque del contenido debe ser proveer valor agregado, por consiguiente,

cuando la empresa ingresa al mundo del comercio electrónico, se pueden describir las

etapas más comunes que ayudan a concretar dicho enfoque, de la siguiente manera:

• Etapa inicial: Se entiende como la creación de una presencia corporativa en la

red. En esta etapa el contenido del Website está dirigida a la información general de la

empresa, su objetivo social, sus productos, políticas y ubicación geográfica. Otra

posible variación de esta etapa puede ser el desarrollo de catálogos electrónicos, los

cuales permiten la actualización de la información de sus productos.

• Etapa transaccional: Aquí se pueden hacer pedidos, compras, ventas, reservas,

etc. En esta etapa las empresas requieren de infraestructuras seguras que permitan

utilizar Internet para realiza transacciones.

• Etapa relacional: En esta etapa se utiliza Internet para estrechar la relación

con el cliente. Internet se utiliza como un elemento “conversacional” para conservar una

relación con el cliente que ayude a la interacción, y de esta manera generar valor

agregado.

En empresas cuyas operaciones están basadas 100% en Internet, el desarrollo de las

etapas anteriores debe ser en paralelo, puesto que, sin alguna de ellas, la empresa no

podría operar, ni generar ingresos. Las cadenas de valor son específicas para cada

negocio, por tanto, es indispensable realizar un análisis profundo para que la alternativa

4 Mauricio Ruiz Valdivieso, Internet en las organizaciones modernas.

ISC-2002-2-41

18

de e-commerce genere valor. Así, se presentan dos enfoques necesarios para un sitio

Web:

• Servicio al cliente: El contenido está pensado para originar comportamientos de

compra, así, el contenido debe facilitar la compra, con información relevante y

fácil de obtener. Luego, la empresa puede ofrecer seguimiento de los pedidos y

entrega de los productos físicos, generando confianza en el cliente durante el

proceso. Por último, se ofrece un servicio postventa, para mantener las buenas

relaciones con el cliente.

• Conveniencia: La idea es que los sitios Web aprovechen las oportunidades de la

red, para ahorrarles tiempo y desplazamientos a los clientes. Para ello, en las

etapas iniciales del e-commerce, es necesario que cada actor de la cadena de

valor esté completamente conciente de los beneficios que agrega la alternativa e-

commerce.

2.2 Comercio tradicional vs Comercio electrónico5 El comercio tradicional es el resultado de la interacción entre elementos como la mano

de obra, tierras, capital y tecnología, así, la economía industrial tiene sus orígenes en la

economía de agricultura, y de la misma manera, la economía digital se abre camino

basada en la economía industrial. La economía digital hasta ahora comienza a ser

explorada. En esta economía, el cliente tiene mayor poder, elige con libertad y adquiere

mejor información acerca de los productos.

5 Douglas F. Aldrich, Mastering the Digital Marketplace.

ISC-2002-2-41

19

Internet maneja varios aspectos, y muchos tienen que ver con un cambio sustancial en la

forma tradicional de hacer intercambio comercial. Se trata, además de un nuevo

mercado, así, Internet es una nueva forma de comunicación multimedia de “muchos a

muchos”, en contraposición con los modelos tradicionales de “uno a muchos”. También

es una red, y por lo tanto sus conceptos económicos son los de la “Economía de Red”,

en muchos aspectos contrapuestos a los paradigmas del comercio tradicional en los que

la oferta sigue a la demanda. Aquí, muchas veces, la demanda sigue a la oferta.

El reto del comercio electrónico, se establece en pasar del estado embrional actual a una

verdadera alternativa de negocio como la que ya han conformado empresas como

DELL, Cisco Systems o Amazon. En el caso de las dos primeras su comercio

electrónico está rápidamente aproximándose al 35 % de su negocio total, mientras que

en el caso de Amazon, se trata del 100 %.

2.3 Panorama colombiano En Colombia mucha gente piensa en crear un negocio comercial minorista en Internet.

Muchas empresas colombianas medianas y grandes están considerando la posibilidad de

hacer negocios mayoristas por Internet. Muchos bancos colombianos adelantan

proyectos de servicios financieros operativos vía Internet, como valor agregado para sus

clientes.

Entre tanto, otros consumidores colombianos hacen compras (libros, discos, software,

ropa, tiquetes aéreos, paquetes turísticos, electrodomésticos, y hasta participan en

ISC-2002-2-41

20

remates) por Internet, la mayoría utilizando los servicios de negocios virtuales

norteamericanos o de multinacionales latinoamericanas.

Actualmente existen muchos proyectos colombianos sin despegar, y los consumidores

utilizan mucho más el comercio electrónico extranjero. Esta situación, es preocupante y

la realidad es que el comercio electrónico requiere, como toda industria, una

infraestructura nacional adecuada.

Algunas sugerencias planteadas pensando en estos problemas pueden ser:

• En el sector financiero, los banqueros colombianos, pensando en el mediano y

largo plazo, deberán unirse en un gran esfuerzo económico y profesional para

interconectar el sistema bancario y permitir el flujo de operaciones

interbancarias sin intermediarios que no aporten valor .

• El sector real tiene la tarea enorme de transformarse totalmente. En primer lugar,

tiene que aprender nuevas habilidades y modelos de negocios, y en segundo

lugar, aplicarlas.

• El Estado colombiano debe fortificar la infraestructura de telecomunicaciones y

acceso a Internet, y estimular el comercio electrónico concediéndole exención

del impuesto al valor agregado, a fin de ayudar a los empresarios a crear las

poderosas organizaciones financieras, tecnológicas y logísticas que esta

actividad requiere. El apoyo deberá extenderse a toda la cadena de valor

involucrada en este tipo de comercio, que típicamente requiere de alianzas entre

compañías.

• Situar niveles de acceso similares a los internacionales (tarifas telefónicas,

tarifas de Internet, computadoras).

ISC-2002-2-41

21

• Implementar plataformas que brinden a los usuarios mayor confiabilidad online

para pagos.

• Crear una infraestructura de entrega efectiva, que asegure la satisfacción de los

consumidores.

• Evitar la fragmentación del mercado en pequeños negocios. Crear

hipermercados, supermalls, de múltiples ventajas.

• Ofrecer opciones de selección, generando servicio y ofertas competitivas.

• Crear portales y sitios de contenido que entiendan las diferencias culturales entre

países.

En el cuadro 1, se muestra la situación de Colombia frente a los demás países

latinoamericanos con respecto a la utilización del comercio electrónico. Como aspecto a

destacar dentro del porcentaje de usuarios se encuentra que Colombia sólo participa con

un 4.2%, cifra que refleja un bajo nivel de penetración de tecnologías de información

dentro de la población del país.

ISC-2002-2-41

22

AMERICA DEL SUR

PoblaciónActual (2002)

Usuarios,año 2000

Usuarios Dato masreciente

% Zona

Crecimiento (2000-2002)

Penetración( %

Población)

ArgentinaArgentinaArgentinaArgentina 36,508,600 2,500,000 3,882,526 14.2% 55.3 % 10.6 %

BoliviaBoliviaBoliviaBolivia 8,476,200 120,000 120,000 0.4% 0.0 % 1.4 %

BrasilBrasilBrasilBrasil 176,274,400 5,000,000 13,980,649 50.6% 179.6 % 7.9 %

ChileChileChileChile 15,598,500 1,757,400 3,102,200 11.4% 76.5 % 19.9 %

ColombiaColombiaColombiaColombia 43,492,500 878,000 1,154,000 4.2% 31.4 % 2.7 %

EcuadorEcuadorEcuadorEcuador 13,285,700 180,000 327,700 1.2% 82.1 % 2.5 %

Guayana Guayana Guayana Guayana

FrancesaFrancesaFrancesaFrancesa 180,000 2,000 2,000 0.0% 0.0 % 1.1 %

GuyanaGuyanaGuyanaGuyana 861,200 3,000 95,000 0.3% 3066,7 % 11.0 %

Islas Islas Islas Islas

MalvinasMalvinasMalvinasMalvinas 2,300 - - 0.0% - n/d

ParaguayParaguayParaguayParaguay 5,827,100 20,000 60,000 0.2% 200.0 % 1.0 %

PerúPerúPerúPerú 26,657,300 2,500,000 3,000,000 11.0% 20.0 % 11.3 %

SurinamSurinamSurinamSurinam 453,600 11,700 14,500 0.1% 23.9 % 3.2 %

UruguayUruguayUruguayUruguay 3,410,800 370,000 400,000 1.5% 8.1 % 11.7 %

VenezuelaVenezuelaVenezuelaVenezuela 23,611,400 950,000 1,300,000 4.8% 36.8 % 5.5 %

Total Sur Total Sur Total Sur Total Sur

AméricaAméricaAméricaAmérica 354,639,600 14,292,100 27,438,575 100% 92.0 % 7.7 %

Cuadro 1. Usuarios Internet en América del Sur, tomado de www.exitoexportador.com

ISC-2002-2-41

23

2.4 Sistemas de pago en Internet Actualmente existe una amplia diversidad de mecanismos de pago electrónico, cada uno

con sus ventajas e inconvenientes. Por tanto, en ausencia de un único estándar, se hace

necesario que las empresas que se dediquen al comercio electrónico ofrezcan al cliente

la posibilidad de elegir el método de pago. Aunque, lógicamente, el coste de la

plataforma aumenta, cliente y proveedor se benefician de la diversidad de posibilidades.

2.4.1. Protocolos de pago en Internet

• Multipurpose Mail Enhancements (MIME)

MIME es un protocolo de intercambio de objetos a través de Internet. Cada objeto se

encapsula y se específica tanto su semántica, como el medio de codificación utilizado.

La caracterización semántica permite asociar los datos con su mecanismo de transporte

(codificación) y con su significado, de forma que el remitente y el destinatario utilicen

coordinadamente los datos intercambiados. MIME se desarrolló inicialmente para

intercambios de correo electrónico.

• Privacy Enhanced Mail (PEM) y MIME Object Security Objects (MOSS)

PEM es un sistema similar a MIME y desarrollado en paralelo con éste para crear

objetos de correo garantizados. Con el desarrollo de MIME, PEM es, de alguna forma,

repetitivo, por lo que se verá probablemente desplazado por MOSS, que no es más que

una extensión de MIME que aporta exclusivamente lo que le falta a éste para obtener las

garantías deseadas: claves, firmas, certificados, etc.

ISC-2002-2-41

24

• Secure Sockets Layer (SSL)

Secure Sockets Layer es una tecnología diseñada por Netscape Communications, que

proporciona un nivel seguro de transporte entre el servicio clásico de transporte en

Internet (TCP) y las aplicaciones que se comunican a través de él.

Las comunicaciones tienen lugar en dos fases. En una primera fase se negocia entre el

cliente y el servidor una clave simétrica sólo válida para esta sesión. En la segunda fase,

se transfieren datos cifrados con dicha clave. Este sistema es transparente para las

aplicaciones finales, que simplemente saben que el canal se encarga de proporcionarles

confidencialidad entre extremos.

La fase inicial se realiza muy cuidadosamente para evitar tanto la intromisión de

terceras partes como para evitar suplantaciones de personalidad de parte del centro

servidor. El cliente conoce de antemano las claves públicas de ciertos notarios

electrónicos. Con esta información se pone en contacto con el servidor, el cual le envía

su clave pública, autenticada por el notario. La identificación se completa enviando al

servidor un mensaje aleatorio que éste debe firmar. De esta forma el cliente sabe que al

otro lado está quien dice estar.

Verificada la identidad del servidor, el cliente genera una clave de sesión y la envía

cifrada con la clave pública del servidor. Conociendo ambos la clave de sesión, se

intercambian datos con seguridad. En ciertas circunstancias puede ser necesario ejecutar

una fase adicional para descubrir y legitimar la identidad del cliente.

ISC-2002-2-41

25

SSL se compone de dos capas:

SSL Record Protocol: Encapsula protocolos superiores (Aplicación).

SSL Handshake Protocol: Autenticación, negocia el protocolo de encripción e

intercambio de llaves.

SSL se utiliza fundamentalmente en los productos de la propia Netscape, concretamente

con el Netscape Commerce Server y en el Netscape Navigator. Aunque la

especificación permite diferentes algoritmos, el browser de Netscape sólo se exporta de

EE.UU. usando algoritmos RC4 de cifrado simétrico restringidos a 40 bits. Esto da un

nivel muy discutible de seguridad frente a ataques criptográficos.

• Internet Keyed Payment Protocols (iKP)

Los protocolos iKP han sido desarrollados en los Laboratorios de IBM en Zürich y

tratan de proporcionar formas seguras de pago multiparte. Aunque tienen voluntad de

no ligarse a instrumentos específicos de pago, están implementados para usarse sobre

tarjetas de crédito, confiando en las redes financieras preexistentes para realizar la

transferencia de dinero.

Están basados en criptografía de clave pública RSA para asegurar la privacidad de los

números de tarjeta de crédito y de los PIN, proporcionando características de no

repudiación. iKP tiene tres opciones. Dependiendo de los requerimientos, iKP implica

una clave pública (pagador, 1KP), dos claves (pagador y vendedor, 2KP) y tres

(pagador, vendedor y consumidor, 3KP).

ISC-2002-2-41

26

La criptografía nos proporciona funciones matemáticas para dotar a los datos de ciertas

propiedades interesantes. Su utilización sólo involucra a las partes que intercambian

información, si bien en ciertas situaciones de puede requerir la presencia de una tercera

parte confiable que avale la transacción.

Además de las funciones matemáticas, que encriptan la información, ésta hay que

transportarla. Para ello MIME proporciona un formato normalizado que se usa sobre

objetos individuales (MOSS), sobre sesiones cliente-servidor (SSL) o sobre

transferencias WWW (S-HTTP). No son técnicas incompatibles entre sí, sino más bien

diferentes opciones de integración en un entorno transaccional.

2.4.2 Medios de pago en Internet

• Dinero Electrónico (Anónimo e Identificado):

El concepto de dinero electrónico es amplio, y difícil de definir en un medio tan extenso

como el de los medios de pago electrónicos. El dinero electrónico se puede definir como

aquel dinero creado, cambiado y gastado de forma electrónica. Este dinero tiene un

equivalente directo en el mundo real: la moneda. El dinero electrónico puede

clasificarse en dos tipos:

Dinero on-line: Exige interactuar con el banco (vía módem o red) para llevar a cabo una

transacción con una tercera parte.

Dinero offline: Se dispone del dinero en el propio ordenador, y puede gastarse cuando

se desee, sin necesidad de contactar para ello con un banco. Estos sistemas de dinero

electrónico permiten al cliente depositar dinero en una cuenta y luego usar ese dinero

para comprar cosas en Internet.

ISC-2002-2-41

27

• Cheques Electrónicos:

Los métodos para transferir cheques electrónicos a través de Internet no están tan

desarrollados como otras formas de transferencia de fondos. Los cheques electrónicos

podrían consistir algo tan simple como enviar un e-mail a un vendedor autorizándole a

sacar dinero de la cuenta, con certificados y firmas digitales asociados. Un sistema de

cheques puede ser considerado como un compromiso entre un sistema de tarjetas de

crédito y uno de micropagos o dinero electrónico (anónimo).

En el caso del comercio B2B el pago con tarjeta es menos habitual. En las transacciones

entre empresas es más frecuente la utilización de cheques y pagos electrónicos. Un

ejemplo es el sistema eCheck, basado en un "talonario de cheques electrónicos" que

permite a las empresas realizar sus compras y ventas de forma fiable. Otro ejemplo es el

sistema NetCheque, desarrollado por la Universidad del Sur de California, que

básicamente reproduce en la Red el sistema usual de emisión de cheques y

compensación entre bancos.

• Tarjetas de Crédito:

Los sistemas de tarjetas de crédito en Internet funcionan de forma muy similar a como

lo hacen hoy en día. El cliente podrá usar si lo desea su tarjeta de crédito actual para

comprar productos en una tienda virtual. La principal novedad consiste en el desarrollo

del estándar de encriptación SET (Secure Electronic Transaction) por parte de las más

importantes compañías de tarjetas de crédito.

ISC-2002-2-41

28

El protocolo SET (Secure Electronic Transaction) regula la mayor parte de las

transacciones con tarjeta de crédito en Internet. Definido por MasterCard y Visa con la

colaboración de otras importantes compañías como IBM, Microsoft y Netscape, SET

permite un alto nivel de seguridad en las transacciones. Para ello utiliza procedimientos

de cifrado simétrico y asimétrico, firmas digitales y certificados de seguridad.

SET funciona desde 1997 y supone una garantía inestimable de seguridad y eficacia

para el cliente y el proveedor. Existen otros sistemas de pago electrónico basado en

tarjetas, como CyberCash y FirstVirtual.

2.4.3 Panorama Colombiano en aspectos de seguridad y medios de pago En Colombia el sector financiero es muy inmaduro con respecto al pago electrónico de

bienes o servicios, sólo algunos bancos como Bancolombia y Conavi, soportan

transacciones electrónicas eficientemente. La cultura bancaria y en general la de los

usuarios de los servicios bancarios, aún tienen el concepto de ganancia generada por

mantener “dineros flotantes” en los bancos, es decir, mantener el dinero en poder del

banco mientras se realiza una transacción demorada, generaría ganancia para el banco,

como por ejemplo el cambio de un cheque. Por eso, pensar en transacciones en tiempo

real, no convendría a personas que piensen de esta manera.

De los protocolos anteriores, SSL (Secure Sockets Layer) es el más común debido a

que por correr sobre TCP se vuelve transparente a las aplicaciones, pero en general el

esquema más utilizado es el siguiente:

ISC-2002-2-41

29

2.4.3.1 El sistema de transición para pagos vía Internet en Colombia.

• Primera fase: autorizaciones en diferido.

1. El comerciante pone su sitio en Internet y solicita a Credibanco Visa la

aprobación de un "convenio especial".

2. Si le es aprobada la solicitud, el comerciante se inscribe en la extranet de

Credibanco Visa para tramitar autorizaciones más ágilmente, pero no en línea ni

en tiempo real.

3. El cliente entra al sitio Web del comerciante y hace sus compras comunicándose

con encripción de acuerdo con el protocolo SSL, sin necesidad de poseer

certificado digital.

4. El comerciante extrae del sitio Web la información de las operaciones cada

cierto tiempo, y pide autorizaciones utilizando la extranet.

5. La extranet de Credibanco Visa responde estas autorizaciones en línea, pero ya

no en tiempo real respecto de la compra del cliente.

6. El comerciante se comunica por medios tradicionales o correo electrónico con el

cliente para informarle si ha sido autorizada la transacción o no.

7. El comerciante conserva la información de la operación, la cual incluye el

número de tarjeta de crédito del cliente y asume esa responsabilidad.

8. Si el cliente rechaza el cargo, al comerciante se le debita el importe. Si le

sustraen los números de las tarjetas de crédito y ocurren fraudes, el comerciante

responde.

• Segunda fase: autorizaciones en tiempo real.

1. El comerciante pone su sitio en Internet, y, si quiere habilitarlo para comercio

electrónico, pide a Credibanco Visa un certificado digital.

ISC-2002-2-41

30

2. El comerciante puede optar por contratar un servicio de "Gateway" para que

conecte su sitio Web con el sistema de Credibanco Visa, o instalar en su sitio

Web el software necesario para conectarse por cuenta propia.

3. El cliente entra al sitio Web del comerciante y hace sus compras comunicándose

en forma encriptada de acuerdo con el protocolo SSL, sin necesidad de poseer

certificado digital.

4. El sitio Web del comerciante transmite en línea y en tiempo real la información

al Gateway (o a Credibanco Visa) por protocolo de claves públicas y privadas,

junto con el certificado digital del comerciante. Si se utiliza Gateway, éste el

puente ante Credibanco Visa.

5. Credibanco Visa valida el certificado y responde en línea y tiempo real estas

autorizaciones. La información retorna al sitio Web del comerciante

directamente, o vía Gateway.

6. El comerciante conserva la información de la operación, la cual incluye el

número de tarjeta de crédito del cliente, y asume esa responsabilidad.

Figura 1. © Interfaz.Com Sistema de transición para pagos vía Internet en Colombia

ISC-2002-2-41

31

2.5 Cultura de compra en Internet.6

La cultura de compras del consumidor actual está cambiando, ahora el cliente es menos

paciente. En la economía industrial, el cliente tenía poco poder directo sobre los bienes

disponibles, luego, se prefería consumir o adquirir productos de marcas reconocidas y

confiables. Así, las empresas debían anticiparse a los gustos del cliente.

En la actualidad surgen nuevas características en los compradores, por ejemplo, la

necesidad de recibir mayor información sobre los productos y servicios deseados.

Además, el cliente espera poder personalizar los productos, contando adicionalmente,

con la pronta entrega y el pago de un precio razonable.

Esta personalización puede ser vista desde muchas perspectivas: mensajes de mercadeo

personalizados, productos personalizados, promociones personalizadas o publicidad

personalizada. La empresa Amazon.com dedicada principalmente a la comercialización

de libros, ha sido pionera en estos tipos de manejo personalizado al cliente, personaliza

hasta las ofertas y hace posible “empujar” los productos según las preferencias del

cliente.

En Colombia, la cultura de compra de los consumidores está aún muy poco

desarrollada, debido a factores intrínsecos de la cultura y de la economía. Los

compradores, prefieren sitios norteamericanos o latinoamericanos, pues estos generan

mayor confianza. Por tanto, el capital generado por el comercio electrónico, se escapa

6 Douglas F. Aldrich, Mastering the Digital Marketplace.

ISC-2002-2-41

32

del país. Para recuperarlo hay que cambiar la visión “contable” hacia una visión

estratégica del negocio, en la economía digital la tecnología es el único recurso que con

certeza costará menos en el tiempo al mismo tiempo que ofrece canales gratuitos de

distribución de la información. Además, comparando con otras inversiones, la que se

hace en tecnología tiene mejor retorno de la inversión debido a las mejoras en

productividad.

En resumen, el grado de personalización a través de e-commerce se genera al

personalizar el mercadeo, el servicio y los productos físicos. Así mismo, en una

aplicación de comercio electrónico, se debe permitir crear un ambiente comercial

comparado con el de una tienda, donde el propietario conoce las preferencias y

necesidades de cada cliente. Esta situación, podría ser inmanejable para empresas de

consumo masivo, con grandes catálogos de productos y millones de clientes.

ISC-2002-2-41

33

3. Plataformas de comercio electrónico

Durante el montaje de un proyecto de comercio electrónico es importante determinar la

plataforma que soportará la cantidad de funcionalidades, así como grandes volúmenes

de transacciones. En el mercado existen varias opciones, como por ejemplo IBM

WebSphere®7, que contiene características que permiten integrar las aplicaciones que

existan en la compañía y también las que sean construidas bajo estándar como Java™,

páginas JavaServer ™, Enterprise JavaBeans™ (EJB™) y XML. Además, captura y

analiza información acerca de sus clientes y de sus necesidades a través de una robusta

inteligencia de marketing.

TornadoStore™8, es una plataforma de comercio electrónico para Pymes. Promete una

rápida implementación y puesta en funcionamiento. Con una operatoria dinámica que le

permite mantener las ofertas, servicios y catálogos de artículos en línea siempre

actualizados. Esta plataforma por sus características, está al alcance de la mayoría de

compañías que quieran empezar a incursionar en el comercio electrónico.

Intershop 9, es un proveedor de software e-commerce para empresas, que se

caracteriza por automatizar procesos de marketing, servicios y ventas por medio de

tecnologías de Internet. La solución que brinda Intershop, se caracteriza por permitir a

las empresas realizar ventas y generar órdenes de compra en tiempo real. Entre las

compañías que han utilizado esta plataforma se encuentran HP, BMW, Ericsson, T-

Systems, Siemens y otras, gracias a que Intershop presta un servicio global para la

constante expansión de los negocios.

7 www-3.ibm.com/software/webservers/commerce/wcs_pro/ 8 www.tornadostore.com 9 www.intershop.com

ISC-2002-2-41

34

4. Arquitectura Web

La idea fundamental es que los navegadores (browsers), presentan documentos escritos

en HTML que han obtenido de un servidor Web. Estos documentos HTML

habitualmente presentan información de forma estática, sin más posibilidad de

interacción con ellos.

Figura 2. Esquema general de la Arquitectura Web La manera de crear los documentos HTML ha cambiado en cuanto las tecnologías Web

también lo hacen. Al principio, las primeras páginas escritas en HTML se almacenaban

en un directorio en el servidor Web; ahora estas se pueden generarse dinámicamente

como respuesta a una acción del cliente y cuyo contenido cambia según las peticiones.

Además, el modo de generar páginas dinámicas ha evolucionado, desde la utilización

del CGI (Common Gateway Interface), hasta los servlets pasando por tecnologías tipo

JavaServer Pages. Todas estas tecnologías se ejecutan en el servidor Web.

ISC-2002-2-41

35

Por otra parte, en el lado del cliente se permite la posibilidad de que las páginas lleven

incrustado código que se ejecuta en él mismo, como por ejemplo, JavaScript y

programas Java. El esquema general de la situación se puede ver en la Figura 2 donde

se muestran algunos tipos de tecnología asociada en la generación e interacción de

documentos Web.

4.1 Arquitectura Cliente / Servidor Durante una sesión normal, un cliente (navegador) solicita un documento de un servidor

Web y una vez obtenido lo muestra al usuario que hizo la solicitud. Si este documento

contiene un enlace a otro documento (en el mismo o en distinto servidor), y el usuario

activa el enlace, el cliente Web efectuará otra petición y mostrará el nuevo documento.

Además, el servidor debe soportar varios accesos o peticiones simultáneas, como se

muestra en la figura 3.

Las características principales de la arquitectura cliente / servidor son:

• Mantiene un modelo de sistemas distribuidos, que muestra cómo los datos son

distribuidos a través de una gama de componentes.

• Tiene una colección de servidores independientes que proveen servicios

específicos como imprimir, manejo de datos, mostrar texto, videos, imágenes, etc.

• Tiene una colección de clientes que utilizan estos servicios.

• Una red que permite que los clientes tengan acceso a los servidores.

Con la introducción de Internet y del Web en concreto, se han abierto infinidad de

posibilidades en cuanto al acceso a la información desde casi cualquier sitio. Esto

representa un desafío a los desarrolladores de aplicaciones, ya que los avances en

ISC-2002-2-41

36

tecnología demandan cada vez aplicaciones más rápidas, ligeras y robustas que permitan

utilizar el Web, para realizar transacciones de comercio electrónico. Las aplicaciones

cliente y servidor pueden ser variadas y funcionar sobre sistemas operativos diversos

(UNIX, Windows NT, MS-DOS, OS/2, etc.). No obstante, tanto el cliente como el

servidor utilizan el protocolo de comunicaciones TCP/IP.

Tecnologías como CGI han cumplido con el propósito de añadir interactividad a las

páginas Web pero sus deficiencias en el desarrollo de aplicaciones y en la escalabilidad

de las mismas ha conducido al desarrollo de APIs específicos de servidor como Active

Server Pages y PHP, que son más eficientes que su predecesor CGI.

Para aprovechar el potencial de estas tecnologías y ofertar una solución de servidor Web

más extensible y portable, Sun ha desarrollado la tecnología llamada servlet. Los

servlets Java son muy eficientes, debido al esquema de threads en el que se basan y al

uso de una arquitectura estándar como la JVM (Java Virtual Machine). Nuevas

tecnologías extienden la funcionalidad de los servidores Web, como por ejemplo, JSP

(JavaServer Pages). Los JSP permiten juntar HTML, aplicaciones Java, y componentes

como las JavaBeans creando una página Web especial que el servidor Web compila

dinámicamente en un servlet la primera vez que es llamada.

El navegador puede considerarse como una interfaz de usuario universal. Dentro de sus

funciones están la petición de las páginas Web, la representación adecuada de sus

contenidos y la gestión de los posibles errores que se puedan producir.

ISC-2002-2-41

37

De esta manera, los fabricantes de navegadores han dotado de posibilidades de

ejecución de programas de tipo script, con modelos de objetos que permiten manipular

los contenidos de los documentos. Estos lenguajes de programación son VBScript,

JScript (ambas de Microsoft) y JavaScript (de Netscape), y proporcionan las soluciones

llamadas del lado del cliente, permitiendo realizar validaciones de datos recogidos en

las páginas antes de enviarlos al servidor y proporcionar un alto grado de interacción

con el usuario dentro del documento.

Otras de las posibilidades de los navegadores, es la gestión del llamado HTML

dinámico (Dinamic HTML, DHTML). Éste está compuesto de HTML, hojas de estilo en

cascada, (Cascade Style Sheets, CSS), modelo de objetos y scripts de programación que

permiten formatear y posicionar correctamente los distintos elementos HTML de las

páginas Web, permitiendo un mayor control sobre la visualización de las páginas.

Los navegadores han ido un poco más allá y permiten la visualización de documentos

XML (eXtensible Markup Language) después de haber sido transformado

adecuadamente a HTML por las hojas de estilo extensibles (eXtensible Style Sheets,

XSL). De esta manera se puede elegir visualizar ciertos elementos y otros no,

dependiendo de las necesidades.

ISC-2002-2-41

38

Figura 3. Arquitectura Cliente / Servidor

Además, los navegadores permiten la ejecución de aplicaciones dentro de los

documentos mostrados. Las dos posibilidades más populares son la tecnología ActiveX

y los applets Java. Estos últimos, son pequeños programas que se descargan del servidor

Web y se ejecutan en la JVM del navegador.

El servidor Web es un programa que corre sobre el servidor que escucha las peticiones

HTTP que le llegan y las satisface. Dependiendo del tipo de la petición, el servidor Web

buscará una página Web o bien ejecutará un programa en el servidor. De cualquier

modo, siempre devolverá algún tipo de resultado HTML al cliente o navegador que

realizó la petición.

4.2 Aplicaciones Multinivel En la arquitectura cliente / servidor, la aplicación reside en el cliente mientras que la

base de datos se encuentra en el servidor. En este tipo de aplicaciones el peso del

cálculo recae en el cliente, mientras que el servidor hace la parte menos pesada, y eso

que los clientes suelen ser máquinas menos potentes que los servidores. Además, está el

problema de la actualización y el mantenimiento de las aplicaciones, ya que las

modificaciones a la misma han de ser trasladada a todos los clientes.

ISC-2002-2-41

39

Para solucionar estos problemas se ha desarrollado el concepto de arquitecturas de tres

niveles: interfaz de presentación, lógica de la aplicación y los datos.

La capa intermedia es el código que el usuario invoca para recuperar los datos deseados.

La capa de presentación recibe los datos y los formatea para mostrarlos adecuadamente.

Esta división entre la capa de presentación y la de la lógica permite una gran

flexibilidad a la hora de construir aplicaciones, ya que se pueden tener múltiples

interfaces sin cambiar la lógica de la aplicación.

La tercera capa consiste en los datos que gestiona la aplicación. Estos datos pueden ser

cualquier fuente de información como una base de datos o documentos XML.

Figura 4. Aplicaciones Multinivel La arquitectura de las aplicaciones Web suelen presentar un esquema de tres niveles,

como se observa en la figura 4. El primer nivel consiste en la capa de presentación que

ISC-2002-2-41

40

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.

Una aplicación Web típica recogerá datos del usuario (primer nivel), los enviará al

servidor, que ejecutará un programa (segundo y tercer nivel) y cuyo resultado será

formateado y presentado al usuario en el navegador (primer nivel otra vez).

Esta arquitectura retorna a los conceptos de computación central, buscando rendimiento,

escalabilidad y fácil mantenimiento de las aplicaciones B2B y B2C. Funcionalmente, el

mayor impacto se nota en el mejoramiento del uso de Internet, debido al carácter

centralizado y el bajo consumo de recursos de red, en cuanto que http, funciona sólo

con un “request” y una respuesta, así, el proceso de comunicación es simple. HTTP,

funciona entre el cliente y el servidor Web.

La flexibilidad y la escalabilidad, está determinada por el diseño de aplicaciones por

componentes, debido a que cuando surgen cambios, no es necesario cambiar gran parte

de la aplicación, solo lo necesario. Igualmente, el desarrollo de los componentes es más

rápido. Otra ventaja, es que no importa que tecnología sea usada en cada capa, debido a

que existen formas de comunicación estándar como XML, que proporcionan la

comunicación entre los componentes de la aplicación.

ISC-2002-2-41

41

5. Modelo de Negocio a Considerar en el Desarrollo del diseño de la Aplicación Web de Comercio Electrónico.

5.1 Consideraciones Especiales Como parte fundamental del diseño de aplicación Web para comercio electrónico, es

necesario escoger uno de los modelos de negocio citados con anterioridad, en el

documento. Esta necesidad radica en lograr enfocar la teoría de la guía metodologíca en

un escenario más puntual y determinado desde el principio.

Al realizar esta investigación, la información adquirida apunta a que según varios

estudios, el modelo con mayor futuro en el mundo del comercio electrónico, es Business

to Business (B2B), el cual es quien genera mayor cantidad de ingresos actualmente. De

acuerdo a las proyecciones que existen, se puede determinar que una gran porción de lo

que se transa en e-commerce es y estará representada por transacciones comerciales

entre empresas ( e-commerce B2B), más que por compras realizadas por consumidores

finales a empresas.

5.2 Modelo de negocio B2B El modelo de negocio B2B, que se usará para el diseño de la aplicación Web de

comercio electrónico, estará configurado de la siguiente manera:

• El negocio se enfoca en productos manejados por medio de una cadena de

suministros, por lo cual se elige el negocio de los muebles como ejemplo. Igualmente la

información referente al negocio es manejada a través de toda la cadena.

• Existirán Infomediarios, es decir, intermediarios pero basados en información.

ISC-2002-2-41

42

• Existirá distribución de los productos en forma directa y con Infomediarios.

• Dispondrá de mecanismo de pagos por Internet, por medio de tarjetas de crédito

o por otras formas de pago electrónico.

• Por medio del modelo B2B se ilustrará la guía metodológica, detallando cada

modelo y el método de construcción correspondiente. La idea es representar la cadena

de suministros en cargada del manejo de materias primas, la elaboración, y

comercialización de muebles.

• Del modelo del negocio, se obtendrá las funcionalidades básicas para la(s)

aplicación(es) Web necesarias para el correcto funcionamiento de la cadena de

suministros.

ISC-2002-2-41

43

CAPITULO 2

1. MODELO CONCEPTUAL

En el desarrollo de la “Guía Metodologíca para el Diseño Sistemático de Aplicaciones

Web en Comercio Electrónico”, se plantea un método y una notación. La notación es un

perfil de UML que define un conjunto de estereotipos apropiados para la Web, usando

un mecanismo de extensión de UML. El método, consiste en tres pasos, y el primero es

el diseño del Modelo Conceptual. Para realizar el diseño del modelo conceptual, se

propone seguir una metodología en la cual, los resultados de la aplicación de ésta son

modelos representados por diagramas “adaptados” de UML.

En el modelo conceptual realizamos explícitamente la descomposición interna del

sistema en términos de clases. No obstante, antes de esto, es importante realizar los

diagramas que representan la arquitectura general del sistema. Para esto, se utilizan los

diagramas de Despliegue y Componentes basados en notación UML.

1.1 Diagrama de Despliegue y Componentes 10 Estos diagramas resultan interesantes en cuanto a que permiten establecer y formalizar

la arquitectura del sistema. De la misma manera, si la arquitectura del sistema está

diseñada por capas (multinivel), las aplicaciones construidas por componentes podrán

ser soportadas, como por ejemplo, las desarrolladas en J2EE.

10 Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modeling Language User Guide. Addison-

Wesley (1999)

ISC-2002-2-41

44

Figura 5. Diagrama de Despliegue y Componentes. El diagrama de despliegue (Deployment Diagram), muestra el conjunto de nodos y sus

relaciones. Se usa para ilustrar el despliegue estático de una arquitectura y se relaciona

con el diagrama de componentes en cuanto a que un nodo encierra uno o más

componentes. El diagrama de componentes muestra el conjunto de componentes y sus

relaciones. De esta manera, se ilustra la implementación estática del sistema. El

diagrama de componentes se relaciona con el diagrama de clases en cuanto que un

componente describe una o más clases, interfaces, o colaboraciones.

En la figura 5, se observa un esquema de arquitectura multinivel, la cual consta de tres

nodos: Cliente, con su componente principal Browser, Servidor de aplicaciones y

Servidor de Base de datos. Este último interactúa con el servidor de aplicaciones por

medio de JDBC(java data base connectivity).

1.2 Casos de Uso Debido a que un caso de uso es utilizado para obtener información sobre cómo un

sistema o negocio trabaja, es una técnica para capturar requerimientos funcionales. Es

ISC-2002-2-41

45

importante tener en consideración que, utilizar los casos de uso para obtener los

requerimientos funcionales no significa que se obtengan buenos requerimientos.

Un caso de uso es un formato estructurado11, para expresar requerimientos, lo cual

ayuda pero no es suficiente. Identificar un completo conjunto de actores significa

obtener todos los puntos de vista de los usuarios, no obstante, este trabajo se dificulta en

casos donde un actor no entiende las necesidades del negocio o cuando el equipo de

desarrollo no comprende los casos de uso. Luego es importante entender el contexto,

sus correspondientes actividades e identificar los actores. Nunca se debe suponer que

los clientes conocen y pueden articular las necesidades reales de un negocio, por eso,

suele ocurrir que un usuario no utiliza el sistema entregado porque no satisface sus

necesidades. Por ejemplo, en un hospital, las enfermeras tienen un punto de vista, los

médicos otro, los administradores otro, etc.

Es muy difícil al principio del proyecto obtener casos de uso muy completos, porque la

comprensión del contexto o negocio madura durante el ciclo de vida del proyecto. Esto

significa que para obtener casos de uso útiles, es necesario que todas las fases del

proyecto estén involucradas en un ciclo de vida iterativo e incremental, claro iterando

sobre detalles del diseño. Como los casos de uso, permiten definir los límites del

sistema y las relaciones entre éste y su entorno, es primordial identificar el rol de cada

actor y tener una lista de los casos de uso correspondientes.

11 http://www.korson-mcgregor.com/publications/korson/usecase3/index.html

ISC-2002-2-41

46

En el desarrollo de aplicaciones Web de comercio electrónico, es necesario determinar

los procesos del negocio para definir los límites del posterior modelo conceptual. Con

procesos del negocio, se hace referencia al conjunto de actividades que permiten

conseguir los objetivos de la empresa. De esta manera, se representa cada proceso del

negocio mediante un caso de uso del mismo.

Para mayor claridad, se ilustra lo anterior con el ejemplo de una compañía que fabrica

productos bajo demanda. Como objetivos estratégicos de dicha compañía podrían

plantearse:

• La satisfacción del pedido de un cliente.

• Incrementar en un 10% las ventas.

• Disminuir el tiempo de producción en un 20%.

El objetivo de satisfacer el pedido de un cliente, se puede dividir en sub-objetivos como

registrar el pedido de un cliente, elaborar el producto, revisar inventario y realizar

pedidos a proveedores. Estos son los sub-objetivos que definen los procesos del

negocio.

Una vez encontrados los procesos del negocio, es necesario encontrar los agentes que

intervienen en su realización. Cada agente o actor del negocio realiza determinada

función (juega un rol), cuando colabora con otros para llevar a cabo las actividades que

conforman un caso de uso del negocio. Se pueden identificar agentes internos como por

ejemplo los de la propia empresa (trabajadores, departamentos, etc.) y agentes externos

ISC-2002-2-41

47

como clientes, proveedores u otros sistemas. Estos últimos serán los agentes tenidos en

cuenta para la continuación de la guía dado que con ellos la compañía interactúa para

llevar a cabo sus procesos de negocio, así mismo, se promueve la importancia del

modelo de negocio B2B. En el siguiente diagrama de casos de uso, intervienen

únicamente agentes externos al sistema.

Figura 6. Modelo del contexto del sistema

En la figura 6, se observa el modelo del contexto del sistema, donde se identifican los

actores externos que interactúan con él. En el caso de una transacción de compra de un

producto, los actores principales son: el cliente, el proveedor del servicio o producto

(compañía minorista en este caso) y los intermediarios como por ejemplo, los que

prestan servicios de validación de las tarjetas de crédito.

ISC-2002-2-41

48

1.3 Modelo del Negocio La importancia del comercio electrónico en la fabricación y en la distribución de

productos está relacionada con la gestión de la cadena de suministros. Dicha gestión

debe pensar en las características indispensables para la continuidad del negocio, por

ejemplo, rapidez en las transacciones, comunicaciones económicas, colaboración con

sus clientes y los proveedores. La cadena de suministros en el ámbito del comercio

electrónico pretende una la colaboración eficaz a través de una red de clientes y de

proveedores, lo cual genera un potencial enorme para mejorar la productividad, la

reducción de costos y el servicio de clientes. Por supuesto, las ventajas se basan en la

eficacia del empleo del comercio electrónico, que hace de la información una variable

de alta prioridad a lo largo de la cadena. Proporcionar la cantidad adecuada de

información relevante a los que necesiten saberla, cuando necesitan saberla, es la clave

de una gestión eficaz de la cadena de suministros desde el punto de vista de la

información.

La cadena de suministros son todos aquellos procesos y actividades que permiten la

realización de un producto o servicio. Por lo tanto, involucra la interacción entre

diferentes empresas en donde cada una genera valor agregado. Sin embargo, la cadena

de suministros ha evolucionado con la necesidad de integrar electrónicamente los

negocios. Un esquema tradicional de la cadena de suministros se muestra en la figura 7,

como se observa es un esquema lineal, donde la comunicación se realiza entre

componentes vecinos, por tanto, cuando aparece algún problema en un punto, el resto de

la cadena no se entera, lo cual conlleva a ineficiencias.

ISC-2002-2-41

Co

se

op

con

Es

con

(D

con

ben

12 S13 S

Proveedores de MP

Convertidores Distribuidores Mayoristas

Productores de materias

49

Figura 7. Cadena de suministros convencional.12

mo solución a dichas ineficiencias aparece la Digital Value Chain (figura 8), la cual

caracteriza por incrementar la eficiencia operacional, es decir, tiempos y costos en

eración y distribución. Igualmente, comparte la información a lo largo de la cadena,

lo cual se genera un mayor conocimiento del mercado para cada miembro.

te nuevo esquema de cadena de suministros sirve como plataforma para un “nuevo”

cepto de negocio, muy parecido al B2B, conocido como Digital Value Network

VN). Por definición la DVN, “es una comunidad de socios de negocios y

sumidores conectados utilizando tecnologías de información para maximizar los

eficios valor al consumidor” 13.

istemas extranets y comercio electrónico B2B, Juan Carlos Cárdenas, John Romero istemas extranets y comercio electrónico B2B, Juan Carlos Cárdenas, John Romero

Distribuidores Minoristas

Clientes

ISC-2002-2-41

50

Figura 8. Digital Value Chain.14 La interacción de los participantes en la DVN esta basada en el apoyo tecnológico del

comercio electrónico, para que de esta manera se implemente un modelo de negocio

B2B y este pueda ser relativamente fácil, cuando de por medio existe la colaboración de

cada uno de los participantes para llegar a una meta en común. En la figura 8, se

observan seis actores de la cadena de suministros los cuales cumplen con las funciones

necesarias para realizar un producto, desde la obtención de la materia prima, pasando

por los proveedores, los convertidores de la misma y de los comercializadores, hasta el

cliente final, en donde lo interesante radica en la posibilidad de compartir información

del negocio a lo largo de la cadena, claro está, con sus respectivas restricciones. Por lo

tanto, es posible implementar un negocio B2B con los parámetros requeridos y ya

especificados con anterioridad en este documento, debido en gran parte a la

incorporación de tecnologías que permiten conectar a todos los actores y por supuesto al

14 Sistemas extranets y comercio electrónico B2B, Juan Carlos Cárdenas, John Romero

Productor MP

Convertidor

Proveedor MP

Minorista

Distribuidor

Cliente

Bienes

Fondos

Información

ISC-2002-2-41

51

manejo de la información, para obtener beneficios y generar valor agregado a los

productos.

Otros componentes de la DVN, son los infomediarios y la Digital Function Plataform

(DFP). Los infomediarios son intermediarios de información, los cuales recolectan,

administran y distribuyen información, como por ejemplo, los motores de búsqueda, las

autoridades de certificación, las comunidades virtuales, etc. La Digital Function

Plataform es el servicio o tecnología que soporta los procesos de negocio a través de 2 o

más cadenas de valor, por supuesto, utilizando estándares como XML, Ansi EDI, etc.

1.4 Productos y Herramientas de Integración de Aplicaciones Actualmente existen compañías como Ariba15, Chemdex, Commerce One16 y Free

Markets que han creado productos para la integración de aplicaciones de comercio

electrónico Bussines-to-Bussines. Ariba, por ejemplo enfoca su software al manejo de

gastos, en un proceso cíclico conformado por tres áreas:

• Análisis de gastos (racionalizar gastos operacionales)

• Selección de proveedores (recomienda las mejores practicas de sourcing)

• E-procurement (adquisición de bienes y servicios)

Por supuesto, estas áreas están integradas por medio de software especializado, a lo

largo de la cadena de suministros. El software de Ariba se compone de Ariba Buyer

(evaluación de ofertas y de precios), Ariba Contracts ( manejo de proveedores ), Ariba

15 www.ariba.com

16 www.commerceone.com

ISC-2002-2-41

52

E-forms ( manejo de formatos ), Ariba Invoice (manejo de facturación, vencimientos),

Ariba Travel ( manejo de viajes, viáticos ) y Ariba WorkForce ( manejo de operaciones

y gastos de personal).

Otras empresas como WebMethods17 y Biztalk18, más que productos son consideradas

como herramientas de desarrollo para la integración de aplicaciones. WebMethods, está

diseñado para ser asimilado por personas no necesariamente técnicas, es decir, puede ser

utilizado por alguien encargado de administrar los procesos del negocio. Además, se

orienta a utilizar lenguajes orientados a objetos como java y arquitecturas abiertas. En

general, esta herramienta permite:

• Modelar procesos de negocios: configurar los procesos típicos de la empresa,

como por ejemplo, cotizaciones, órdenes de compra, facturación, pagos, etc.

Esto se realiza por medio de diagramas de flujos de procesos.

• Integrar y Administrar sistemas de información: maneja todo lo relacionado con

el control y estado de los procesos.

• Optimización: realiza métricas sobre los procesos para generar reportes del

desempeño de los mismos, y en general del negocio. De esta manera, se logra

obtener información para evaluar y rediseñar procesos ineficientes.

Biztalk es la herramienta propuesta por Microsoft , la cual funciona como un proceso

de flujo de información, dividida en cuatro componentes encargados de realizar la

integración. El primer componente es la función receptora, la cual recibe la

17 www.webmethods.com

18 www.microsoft.com/biztalk

ISC-2002-2-41

53

información de las colas de mensajes, de manera asincrónica, permitiendo la posibilidad

de enviar un mensaje sin que un proceso relacionado este corriendo. El segundo

componente son los canales, los cuales manejan editores y mapas para transformar la

información y enviarla al puerto de mensajería, o a un proceso de negocio, del cual se

encarga el cuarto componente, interactuando con las aplicaciones necesarias para

llevarlo a cabo. Esta herramienta, también permite guardar información de los logs, para

el posterior análisis del funcionamiento del negocio.

En el caso del modelo de negocio B2B, la utilización de XML está aumentando de

manera considerable. Con XML se puede estructurar los datos que forman parte de

nuestro flujo de negocio, permitiendo un mejor intercambio de éstos al realizar

transacciones. Para esto se crean aplicaciones Web, que conectan varios proveedores

para gestionar las compras o automatizar el proceso de aprovisionamiento de productos.

En el siguiente cuadro, se realiza una breve comparación entre las ventajas y

desventajas de cada uno de los productos y herramientas de integración de aplicaciones:

ISC-2002-2-41

54

VENTAJAS DESVENTAJAS ARIBA Se enfoca a los gastos.

Soporta un marketplace, donde reúne proveedores y compradores en torno a una industria. Habilita flujos de información de todos los participantes

Demasiado costoso para el medio colombiano, igualmente las best´s practice que implementa chocan con factores culturales de las organizaciones.

COMMERCE ONE Provee toda la plataforma de colaboración. Realiza su gestión en un ciclo, donde se retroalimenta de su propia gestión. Es capaz de reutilizar las aplicaciones legacy.

Aun es muy difícil emigrar hacia esta tecnología en Colombia, debido a que las aplicaciones en nuestro entorno son muy difíciles de llevar plataformas como estas.

VENTAJAS DESVENTAJAS WEBMETHODS Se logra embeber en

aplicaciones existentes sin necesidad de amplios conocimientos por parte de las personas. Ofrece la posibilidad de manejar Web Services

No es posible de embeber en aplicaciones propietarias, demasiado antiguas

BIZTALK Muy enfocado a B2B, pretende lograr la automatización de procesos de negocios.

No ha entrado con fuerza en el mercado Colombiano.

Cuadro 2. Ventajas y desventajas de los productos de integración de aplicaciones

1.5 E-bussines y el conocimiento del cliente19 Dado que las organizaciones están preocupadas por la fuerte competencia global, se han

orientado hacia los conceptos básicos de mercadeo referentes a conocer a los clientes y

entender en forma inteligente cuáles son sus necesidades para generar una oferta de

valor competitiva en el mercado. Conceptos como, Customer Relationship Management

(CRM), han renovado la forma de comprender a los clientes. CRM es una estrategia de

19 Las Megatendencias en e-bussines, Revista Dinero

ISC-2002-2-41

55

negocios enfocada a los clientes y diseñada para optimizar los ingresos, rentabilidad y la

lealtad del cliente. Al implementar la estrategia CRM, la empresa puede mejorar los

procesos de negocios y las soluciones de tecnología alrededor de las funciones de venta,

comercialización, mercadeo y servicio en todos los puntos de encuentro con el cliente,

por ejemplo, Web, correo electrónico, fax, etc.

CRM y el comercio electrónico están convergiendo hacia una solución centrada en

usuarios, la cual le permite a las organizaciones interactuar, vender, y darle servicio a

los clientes a través de todos los canales. De esta manera, los negocios se están

enfocando cada vez más en la interacción con el cliente y determinando las maneras de

mejorar la experiencia del cliente en cada punto de interacción o en el contacto que el

cliente tiene con ellos. Por otra parte, el comportamiento de los clientes potenciales se

dirige cada vez más a la Web, obligando a ésta a transformarse y modificar su

comportamiento. Cada día el cliente actual y el cliente potencial son más web-

dependientes, porque la Web ofrece cada vez mejores servicios.

En el siguiente cuadro, se muestra un esquema general del CRM en cuanto a sus

componentes básicos de funcionamiento, donde el cliente es el componente más

importante, en cuanto permanece como objetivo a lo largo de los diferentes

componentes que integran un CRM:

ISC-2002-2-41

56

Cuadro 3. Componentes de CRM 1.6 Requerimientos Funcionales El modelo conceptual es realizado teniendo en cuenta los requerimientos funcionales

capturados con los casos de uso. Muchas veces, estos requerimientos son desarrollados

de manera escasamente estructurada, provocando fallas en el establecimiento de las

relaciones entre estos y el modelo conceptual. Dichas fallas se encuentran en la

determinación de requerimientos ambiguos que pueden hacer inconsistente el modelo

conceptual, o en otros casos llegar a modelos conceptuales que no reflejan los

requerimientos planteados.

La fase de levantamiento de requerimientos tiene como finalidad, por un lado facilitar

la comprensión de las necesidades del usuario en el dominio del problema y

representarlo de una forma sencilla, completa y sin ambigüedades; por otro lado, toda la

información capturada en los requisitos debe tener su representación en el modelo

conceptual. El modelo conceptual representa los requisitos de los usuarios,

CRM

CLIENTE

Servicio al cliente

• Atención Telefónica

• Información por correo

• Servicio a domicilio

• Plataforma informática

Ventas

• Administración de contactos

• Relaciones con socios

• Cotizaciones

Mercadeo

• Análisis detendencias

• Administración de campañas

ISC-2002-2-41

57

especificando qué hará el sistema sin indicar cómo y suponiendo un ambiente de

implementación normal.

El diseño de la aplicación Web al igual que el del software en general, se realiza a partir

de la especificación de los requerimientos funcionales, capturados en los casos de uso,

esto siguiendo el proceso unificado (Booch, Rumbaugh & Jacobson, 1999). Se

determina quiénes son los usuarios (actores) de la aplicación, y cuáles son las posibles

funcionalidades que se otorgan a cada usuario. En el caso del comercio electrónico,

muchos requerimientos funcionales dependen del modelo de negocio y del propósito de

la relación comercial. De esta manera, el modelo del negocio es la base para la

especificación de los requisitos más importantes del sistema que dará soporte al

negocio, siendo por tanto el propio negocio quien determine los requisitos.

Por lo tanto, los requerimientos funcionales van de la mano con las características

propias de los negocios B2B, es decir, las aplicaciones deben ser capaces de responder a

necesidades básicas para realizar transacciones electrónicas, como por ejemplo:

1.6.1 Requerimientos para la compañía ( productor de materia prima )

• Permitir la validación del productor: este requerimiento hace referencia a la

posibilidad de acceder al sistema por medio de un login y password, el cual

realiza autenticación y autorización para permitir el ingreso a los servicios u

opciones.

ISC-2002-2-41

58

• Permitir el envío de un producto: El sistema debe permitir el envío de los

pedidos de los productos que el proveedor eligió o configuró, al igual que

verificar su estado en cualquier momento.

• Generar facturas a un proveedor : El sistema debe generar la factura para el

proveedor, cuando éste ordene un pedido. La factura será única y especificará

los detalles de la transacción.

• Generar reportes del estado de cuenta de un proveedor: El sistema de la

compañía podrá generar un reporte donde se encuentra la información de

transacciones del proveedor y su estado de cuenta. Este reporte podrá se

consolidado con información de las entidades financieras que intervengan.

• Realizar consultas sobre el estado de inventario: El sistema debe permitir

realizar consultas acerca de la cantidad de materia prima a disposición así, como

sus detalles para generar ordenes de producción.

• Permitir la visualización de los datos del proveedor: El sistema podrá generar

visualizaciones acerca de los datos característicos de la fabrica (proveedor), es

decir, fotos, participación en una cadena de negocios, descripción, etc.

• Restringir el acceso a usuarios no privilegiados. El sistema debe contar con

mecanismos de seguridad, para controlar las autorizaciones a proveedores no

privilegiados.

1.6.2 Requerimientos para la compañía ( proveedor )

• Permitir la validación del proveedor: este requisito hace referencia a la

posibilidad de acceder a el sistema por medio de un login y password, el cual

ISC-2002-2-41

59

realiza autenticación y autorización para permitir el ingreso a los servicios u

opciones.

• Generar orden de compra a productor MP: El sistema debe permitir realizar una

orden de compra de productos, según existencias en inventario.

• Permitir el envío de un producto: El sistema debe permitir enviar los pedidos de

los productos que el convertidor eligió o configuró, al igual que verificar su

estado en cualquier momento.

• Generar facturas a un convertidor : El sistema debe generar la factura a la

fabrica, cuando ésta ordene un pedido. La factura será única y especificará los

detalles de la transacción.

• Generar reportes del estado de cuenta de un convertidor: El sistema de la

compañía podrá generar un reporte donde se encuentra la información de

transacciones del convertidor y su estado de cuenta. Este reporte podrá se

consolidado con información de las entidades financieras que intervengan.

• Realizar consultas sobre el estado de inventario: El sistema debe permitir

realizar consultas acerca de la cantidad de inventario de productos a disposición

así, como sus detalles para solicitar productos al productor de materias primas.

• Permitir la visualización de los datos del convertidor: El sistema podrá generar

visualizaciones acerca de los datos característicos de la fabrica (convertidor), es

decir, fotos, participación en una cadena de negocios, descripción, etc.

• Permitir la visualización de los datos del productor MP: El sistema podrá

generar visualizaciones acerca de los datos característicos del productor MP, es

decir, fotos, participación en una cadena de negocios, descripción, etc.

ISC-2002-2-41

60

• Restringir el acceso a usuarios no privilegiados. El sistema debe contar con

mecanismos de seguridad, para controlar las autorizaciones a convertidores no

privilegiados.

• Realizar pago a productor MP: El sistema debe permitir la transacción de pago,

por el monto descrito en las facturas, este pago podrá ser elegido por el

proveedor.

1.6.3 Requerimientos para la compañía ( convertidor )

• Permitir la validación de un convertidor: este requisito hace referencia a la

posibilidad de acceder al sistema por medio de un login y password, el cual

realiza autenticación y autorización sobre estos para permitir el ingreso a los

servicios u opciones

• Generar orden de compra a proveedor: El sistema debe permitir realizar una

orden de compra de productos, según existencias en inventario.

• Permitir el envío de un producto: El sistema debe permitir enviar los pedidos de

los productos que el distribuidor eligió o configuró, al igual que verificar su

estado en cualquier momento.

• Generar facturas a un distribuidor : El sistema debe generar la factura de un

distribuidor, cuando éste ordene un pedido. La factura será única y especificará

los detalles de la transacción.

• Generar reportes del estado de cuenta de un distribuidor: El sistema de la

compañía podrá generar un reporte donde se encuentra la información de

ISC-2002-2-41

61

transacciones del distribuidor y sus estados de cuenta. Este reporte podrá se

consolidado con información de las entidades financieras que intervengan.

• Realizar consultas sobre el estado de inventario: El sistema debe permitir

realizar consultas acerca de la cantidad de inventario de productos a disposición

así, como sus detalles para solicitar productos al proveedor.

• Permitir la visualización de los datos del proveedor: El sistema podrá generar

visualizaciones acerca de los datos característicos del proveedor, es decir, fotos,

participación en una cadena de negocios, descripción, etc.

• Permitir la visualización de los datos del distribuidor: El sistema podrá generar

visualizaciones acerca de los datos característicos del distribuidor, es decir,

fotos, participación en una cadena de negocios, descripción, etc.

• Restringir el acceso a distribuidores no privilegiados. El sistema debe contar

con mecanismos de seguridad, para controlar las autorizaciones a distribuidores

no privilegiados.

• Realizar pago a proveedor: El sistema debe permitir la transacción de pago, por

el monto descrito en las facturas, este pago podrá ser elegido por el convertidor.

1.6.4 Requerimientos para la compañía (distribuidor)

• Permitir la validación de un distribuidor: este requisito hace referencia a la

posibilidad de acceder al sistema por medio de un login y password, el cual

realiza autenticación y autorización sobre estos para permitir el ingreso a los

servicios u opciones.

ISC-2002-2-41

62

• Generar orden de compra a convertidor: El sistema debe permitir realizar una

orden de compra de productos ya terminados al convertidor, según existencias

en inventario.

• Permitir el envío de un producto: El sistema debe permitir enviar los pedidos de

los productos que el minorista eligió o configuró, al igual que verificar su estado

en cualquier momento.

• Generar facturas a un cliente: El sistema debe generar la factura del minorista,

cuando éste ordene un pedido. La factura será única y especificará los detalles de

la transacción.

• Generar reportes del estado de cuenta de un minorista: El sistema de la

compañía podrá generar un reporte donde se encuentra la información de

transacciones del minorista y su estado de cuenta. Este reporte podrá se

consolidado con información de las entidades financieras que intervengan.

• Realizar consultas sobre el estado de inventario: El sistema debe permitir

realizar consultas acerca de la cantidad de inventario de productos a disposición

así, como sus detalles para solicitar productos al convertidor.

• Permitir la visualización de los datos del distribuidor: El sistema podrá generar

visualizaciones acerca de los datos característicos del distribuidor mayorista, es

decir, fotos, participación en una cadena de negocios, descripción, etc.

• Restringir el acceso a minoristas no privilegiados. El sistema debe contar con

mecanismos de seguridad, para controlar las autorizaciones a minoristas no

privilegiados.

• Realizar pago a proveedor: El sistema debe permitir la transacción de pago, por

el monto descrito en las facturas, este pago podrá ser elegido por el distribuidor.

ISC-2002-2-41

63

1.6.5 Requerimientos para la compañía (minorista )

• Permitir la validación del minorista: este requisito hace referencia a la

posibilidad de acceder al sistema por medio de un login y password, el cual

realiza autenticación y autorización sobre estos para permitir el ingreso a los

servicios u opciones

• Generar orden de compra a distribuidor: El sistema debe permitir realizar una

orden de compra de productos, según existencias en inventario.

• Permitir el envío de un producto: El sistema debe permitir enviar los pedidos de

los productos que el cliente eligió o configuró, al igual que verificar su estado en

cualquier momento.

• Generar facturas a un cliente : El sistema debe generar la factura de un cliente,

cuando éste ordene un pedido. La factura será única y especificará los detalles de

la transacción.

• Generar reportes del estado de cuenta de un cliente: El sistema de la compañía

podrá generar un reporte donde se encuentra la información de transacciones del

cliente y su estado de cuenta. Este reporte podrá se consolidado con información

de las entidades financieras que intervengan.

• Realizar consultas sobre el estado de inventario: El sistema debe permitir

realizar consultas acerca de la cantidad de inventario de productos a disposición

así, como sus detalles para solicitar productos al distribuidor.

• Permitir la visualización de los datos del distribuidor: El sistema podrá generar

visualizaciones acerca de los datos característicos del distribuidor mayorista, es

decir, fotos, participación en una cadena de negocios, descripción, etc.

ISC-2002-2-41

64

• Restringir el acceso a usuarios no privilegiados. El sistema debe contar con

mecanismos de seguridad, para controlar las autorizaciones a clientes no

privilegiados.

• Realizar pago a distribuidor: El sistema debe permitir la transacción de pago,

por el monto descrito en las facturas, este pago podrá ser elegido por la

compañía minorista.

1.6.6 Requerimientos del usuario (cliente final)

• Permitir la validación de un cliente: este requerimiento hace referencia a la

posibilidad de acceder a el sistema por medio de un login y password, el cual

realiza autenticación y autorización sobre estos para permitir el ingreso a los

servicios u opciones.

• Permitir la realización de un pedido o servicio: por medio de este requisito, el

cliente ya autorizado puede lanzar procesos o transacciones, acerca de los

productos o servicios disponibles. El sistema debe permitir realizar una orden de

compra configurada por el cliente.

• Permitir la elección de forma de pago para comprar un producto o pagar un

servicio: El sistema debe otorgar la posibilidad de elegir formas de pago de las

facturas generadas por las compras del cliente. El cliente tendrá libre elección

sobre la forma de pago.

• Permitir la utilización de foros para comentarios y sugerencias: Con el fin de

mantener canales de comunicación abiertos permanentemente, el sistema debe

ISC-2002-2-41

65

permitir al cliente, el acceso a foros de comentarios, el ingreso a dichos foros no

estará necesariamente controlado.

• Permitir la personalización de un producto o servicio: El sistema debe permitir

la configuración de un producto por parte del cliente, y enviar dicha

configuración al sistema de pedidos.

Los anteriores requerimientos aplican a una cadena de suministros que realiza sus

transacciones por medios electrónicos, esta cadena simula el modelo de negocios B2B,

que se quiere utilizar para el desarrollo de la “Guía Metodoló|gica para el Diseño

Sistemático de Aplicaciones Web en Comercio Electrónico”, por tanto y para efectos

ilustrativos, se asumirá el ejemplo de una cadena de suministros que trabaja en el sector

de los muebles.

Volviendo a lo visto en los casos de uso y con el ejemplo ha desarrollar ya determinado,

es conveniente realizar los diagramas de casos de uso aplicados a dicho ejemplo.

1.7 Diagramas de Casos de Uso para la Cadena de Suministro de Muebles. Para realizar los diagramas de casos de uso es necesario determinar cuales son los

actores que intervienen en el sistema de la cadena de suministros. De esta manera, se

identifican:

• Productor de materia prima

• Proveedor

• Convertidor

• Distribuidor mayorista

ISC-2002-2-41

66

• Minorista

• Cliente final

Diagrama de casos de uso para el productor de materia prima: Diagrama de casos de uso para el proveedor: Diagrama de casos de uso para el convertidor:

generar factura a proveedor

Permitir acceso Permitir envío de un producto a proveedor

Permitir envío de un producto al distribuidor

Permitir acceso G

generar factura a convertidor

Permitir acceso

generar reportes de estado de cuenta de un proveedor

enerar factura a distribuidor

generar reportes de estado de cuenta de un convertidor

Permitir envío de un producto a convertidor

Generar estado de cuenta dedistribuidor

ISC-2002-2-41

67

Diagrama de casos de uso para el Distribuidor Mayorista: Diagrama de casos de uso para el Minorista: Diagrama de casos de uso del cliente final: 1.8 Modelo Conceptual En el modelo conceptual se manejan dos elementos principales, las clases y las

asociaciones. Las clases son usadas en el diseño de navegación para derivar los nodos

de la estructura web. Las asociaciones son empleadas para derivar los vínculos (links).

Permitir envío de un producto al minorista

Permitir acceso Generar factura a minorista

Generar estado de cuenta del minorista

Permitir envío de un producto al cliente final

Permitir acceso Generar factura a cliente final

Generar estado de cuenta del cliente final

Permitir la realización de un pedido

Permitir acceso Consultar estado de orden de compra

Permitir la elección de forma de pago

Consultar productos en catalogo

ISC-2002-2-41

68

Con esto en mente, el modelo conceptual para representar el modelo del negocio B2B,

se puede obtener mediante los siguientes pasos:

• Encontrar las clases. Las clases son determinadas a partir de los objetos que

comparten un comportamiento similar, atributos, operaciones y relaciones. Así

en el diseño del modelo conceptual para una cadena de suministros del sector de

muebles, se identifican clases como clientefinal, minorista, distribuidor,

convertidor, proveedor, productormp (productor de materia prima), de la misma

manera y enfocándose en los requerimientos del negocio se identifican clases

como los catálogos de productos de cada participante: catalogominorista,

catalogodistribuidor, catalogoconvertidor, catalogoproveedor,

catalogoproductor , igualmente las órdenes de compra: ordencompracliente,

ordencompraminorista ordencompradistribuidor, ordencompraconvertidor,

ordencompraproveedor, ordencompraproductor, los productos:

productoproductor, productoproveedor, productoconvertidor,

productodistribuidor, productominorista y por último la forma de pago:

formapagoproveedor, formapagoconvertidor, formapagodistribuidor,

formapagominorista, formapagocliente.

• Especificar los atributos más relevantes y operaciones. Los atributos utilizados,

identifican claramente y modelan las propiedades de las clases correspondientes.

por ejemplo, la clase clientefinal, contiene atributos como nombreCliente,

idCliente, email, dirección, teléfono, edad. Para la clase ordencompracliente se

ISC-2002-2-41

69

determinan atributos como idOrden, valorTotal, formaPago, fechaOrden,

fechaEntrega, estadoActual, cantidadProductos.

• Determinar asociaciones entre clases: las asociaciones especifican que objetos

se conectan entre sí, de esta manera, el modelo conceptual resultante está

conectado de forma que el acceso sea lo más inmediato y directo posible, para

responder a los requerimientos funcionales. Estas asociaciones se verán

claramente en los diagramas del modelo conceptual de la cadena de suministros.

Por ejemplo, las clases clientefinal, minorista están asociadas por medio de una

relación de pertenencia, es decir el cliente final tiene uno o más minoristas, que

le proveen los productos y el minorista tiene uno o más clientes finales quienes

le compran.

• Definir jerarquías de herencia. En el modelo conceptual no se encuentran

jerarquías de herencia.

• Encontrar dependencias. En el desarrollo del modelo conceptual se pueden

encontrar situaciones donde una clase se conecta con otra únicamente como un

parámetro para realizar una operación. Por ejemplo, la existente entre la clase

ordendecompra con la clase que genera la orden (cliente final, convertidor,

proveedor, etc.).

• Encontrar Generalizaciones. En el proceso de pago, se permite elegir entre

pagar con tarjeta de crédito o por otro medio electrónico, de esta manera las

clases tarjetacreditocliente y dineroelectronico, se convierten en subclases de

formapagocliente.

ISC-2002-2-41

70

A continuación se presentan los diagramas del modelo conceptual para cada

participante en la cadena de suministro, que trabaja en la fabricación y comercialización

de muebles.

1.9 Modelo Conceptual para la Cadena de Suministro (Modelo de Negocio B2B) En esta sección se realizan los diagramas correspondientes a los modelos conceptuales

de cada actor que interviene en la cadena de suministro, como ya se estipularon los

pasos del método para realizar el modelo conceptual en la sección anterior, se procede a

utilizar las clases y asociaciones relevantes para conformar dicho modelo, además se

utilizan interfaces para representar la interacción de los actores correspondientes a cada

modelo conceptual.

1.9.1 Modelo de la compañía del Productor de Materia Prima Este modelo describe el inicio de la cadena de suministros, donde el productorMP es

quien vende la materia prima necesaria para realizar lo muebles, el genera la factura

para el proveedor quien actúa en el rol de cliente para el productorMP. Por medio del

modelo conceptual, se puede observar como los requerimientos funcionales son

fácilmente alcanzables gracias a las asociaciones que permiten la comunicación entre

las clases, de esta manera, es posible acceder a los catálogos de productos de

productorMP, a la vez que el cliente puede seleccionar la forma de pago. En la figura 9,

se puede observar los atributos y los métodos que componen cada clase del modelo

conceptual. Allí se encuentra además la cardinalidad de las asociaciones y el rol de cada

una.

ISC-2002-2-41

71

En el siguiente modelo conceptual representa funcionalidades básicas para el proveedor,

como por ejemplo adquirir materia prima por medio de ordenes de compra después de

revisar el catalogo del productor de materia prima, e igualmente puede seleccionar el

medio de pago. También es posible conocer mutuamente quienes son los productores de

materia prima y éste quienes son sus clientes proveedores.

ISC-2002-2-41

72

Figura 9. Modelo conceptual para la compañía del productor de materias primas

ISC-2002-2-41

73

1.9.2 Modelo de la compañía del Proveedor

Figura 10. Modelo conceptual para la compañía del proveedor

En el modelo conceptual del proveedor se observa las clases y asociaciones que se

involucran en una transacción de comercio electrónico entre el productor de materia

ISC-2002-2-41

74

prima, en este caso el talador de árboles, el proveedor y el convertidor o fabricante de

los muebles. La comunicación (integración) entre estos se realiza por medio de

interfaces. Este modelo conceptual soporta una transacción normal, en donde tanto el

convertidor, como productor de materias primas pueden acceder al catalogo del

proveedor para solicitar productos, a la vez que elige la forma de pago por los mismos.

ISC-2002-2-41

75

1.9.3 Modelo de la compañía del Convertidor

Figura 11. Modelo conceptual para la compañía del Convertidor

En el modelo conceptual del convertidor se observa igualmente las clases y asociaciones

que se involucran en una transacción de comercio electrónico entre el proveedor de

ISC-2002-2-41

76

materia prima, el convertidor y el distribuidor de los muebles. La comunicación

(integración) entre estos se modela igualmente por medio de interfaces. Este modelo

conceptual soporta una transacción normal, en donde tanto el proveedor, como

distribuidor pueden acceder al catalogo del convertidor para solicitar productos o

generar ordenes de producción en el caso del proveedor, a la vez que elige la forma de

pago por los mismos. El convertidor es el encargado de transformar la materia prima

(madera, insumos, etc) en productos o muebles que comercializará por medio del

distribuidor mayorista.

ISC-2002-2-41

77

1.9.4 Modelo de la compañía del Distribuidor

Figura 12. Modelo conceptual para la compañía del distribuidor

En el modelo conceptual del distribuidor se tienen las clases y asociaciones que se

asocian en una transacción de comercio electrónico entre el convertidor, el distribuidor

y el minorista. La comunicación (integración) entre estos se modela nuevamente por

ISC-2002-2-41

78

medio de interfaces. Este modelo conceptual soporta una transacción normal, en donde

tanto el convertidor, como minorista pueden acceder al catalogo del distribuidor para

solicitar productos, a la vez que elige la forma de pago por los mismos.

1.9.5 Modelo de la compañía del Minorista

Figura 13. Modelo conceptual para la compañía del minorista

ISC-2002-2-41

79

En el modelo conceptual para el minorista, se observa las clases y asociaciones que se

involucran en una transacción de comercio electrónico entre el distribuidor, el minorista

y el cliente final. En dicha transacción interviene el mayorista distribuidor como

proveedor de los bienes terminados (muebles) al minorista y el cliente final como

comprador de dicho bien. En la transacción el cliente entra al sitio del minorista y elige

los productos del catálogo, arma la orden de compra y paga por el medio seleccionado.

El distribuidor también tiene acceso al catalogo de productos para verificar que

existencias hay y decidir sobre su proceso interno de solicitud de bienes al convertidor.

2. MODELO DE NAVEGACIÓN

En este capítulo se presenta la guía para el desarrollo del modelo de navegación a partir

del modelo conceptual detallado con anterioridad. Para obtener mayor claridad acerca

de la elaboración de éste proceso es conveniente dividirlo en dos etapas:

• MODELO DE ESPACIO DE NAVEGACIÓN

• MODELO DE ESTRUCTURA DE NAVEGACIÓN

La etapa del modelo de espacio de navegación tiene como objetivo determinar qué

clases del modelo conceptual intervienen para la correcta funcionalidad de la aplicación,

para diseñar dicho espacio. Por otra parte, el modelo de estructura de navegación toma

ese espacio y muestra cómo puede ser accedido por medio de elementos como índices,

guías, consultas y menús.

ISC-2002-2-41

80

Para un mismo modelo conceptual, se pueden diseñar diferentes sistemas de

navegación, por lo tanto, un mismo modelo conceptual pueda generar varios modelos de

navegación. El hecho de separar los conceptos de navegación de los conceptos de

diseño conceptual permite la reutilización del diseño, puesto que, si cambian los

requisitos de navegación cambiará sólo el modelo navegacional, sin tener que

modificarse el modelo conceptual. Por otro lado, en el momento de realizar un modelo

navegacional, hay que tener en cuenta qué objetos del modelo conceptual van a ser

navegables, qué tipo de relaciones y estructuras de composición hay entre estos objetos

navegables y las conexiones entre los distintos objetos y las posibilidades de navegación

de un nodo a otro.

2.1 Modelo De Espacio De Navegación En este modelo se especifica qué objetos son visitados a través de la navegación en la

aplicación Web. En ésta etapa el desarrollador toma importantes decisiones, tales como

qué vistas del modelo conceptual son necesarias para la aplicación y qué rutas de

navegación son requeridas para asegurar su funcionalidad. Cuando el desarrollo

involucra un contexto comercial, es importante tener en cuenta que los usuarios

prefieren aplicaciones amigables, que les permita personalizar el producto o el servicio

de acuerdo a sus necesidades, información oportuna, confiable y respuestas inmediatas a

los requerimientos deseados.

En el momento de realizar un modelo navegacional, hay que tener en cuenta qué objetos

del modelo básico van a ser navegables, qué tipo de relaciones y estructuras de

ISC-2002-2-41

81

composición hay entre estos objetos navegables y las conexiones entre los distintos

objetos y las posibilidades de navegación de un nodo a otro.

En la construcción del modelo son utilizadas las clases de navegación y las asociaciones

de navegación, estas permiten expresar una navegación directa.

La clase de navegación permite modelar una clase cuyas instancias son visitadas por el

usuario durante la navegación; estas clases deben conservar el mismo nombre de las

clases del modelo conceptual. En los diagramas de modelo de navegación estas clases

llevan el estereotipo << clase de navegación>>.

Las asociaciones de navegación permiten representar la navegación directa desde la

clase de navegación fuente hasta la clase de navegación objetivo. La semántica de estas

asociaciones difiere de la usada en el modelo conceptual, se modelan con flechas que

indican su dirección (posiblemente existan algunas bidireccionales) y son etiquetadas

con un rol al final de cada flecha y una cardinalidad. Sí no existe un nombre de rol

explícito, se considera que sí la cardinalidad es menor o igual a uno, el rol toma el

nombre singular de la clase de navegación objetivo, pero si la cardinalidad es mayor que

uno, se usa el plural de la clase de navegación objetivo. En los diagramas del modelo de

navegación las asociaciones con excepción de las composiciones llevan implícitamente

el estereotipo << navegación directa>>.

2.1.1 Método Aunque no hay forma de automatizar el siguiente proceso, los siguientes pasos son

necesarios para construir el modelo espacial de navegación:

ISC-2002-2-41

82

• Se incluyen las clases del modelo conceptual relevantes como clases de

navegación.

• Las clases del modelo conceptual que no son visitadas según los casos de uso,

no son incluidas, por cuanto son irrelevantes para el proceso de navegación y su

espacio.

• La información no incluida de las clases del modelo conceptual omitidas, puede

ser incluida como atributos en otras clases de navegación.

• Los atributos no relevantes pueden ser también omitidos.

• Las asociaciones del modelo conceptual son incluidas en el modelo de

navegación, pero además es posible añadir asociaciones de navegación

necesarias para evitar caminos de longitud mayor que uno entre dos clases de

navegación. Además, los escenarios descritos por los casos de uso modelados,

son un buen escenario para encontrar opciones de navegación directa.

2.1.2 Ejemplos del método de espacio de navegación En los siguientes ejemplos se desarrollan los modelos conceptuales del distribuidor y

del minorista. Con estos ejemplos se muestra como la navegación entre clases es

realizada para mantener la funcionalidad inicial de la aplicación correspondiente a cada

una. En el modelo de espacio de navegación del distribuidor (figura 14) se observa la

interacción entre el convertidor, el distribuidor y el minorista, donde los requerimientos

funcionales son muy parecidos a los estipulados para el modelo conceptual del

productor de materia prima, el proveedor, y el convertidor, por eso sólo se presenta éste

modelo de navegación para efectos de ilustración de la guía.

ISC-2002-2-41

83

En el modelo de espacio de navegación del minorista (figura 15) se observa la

interacción del distribuidor, el minorista y el cliente final quienes participan en la parte

terminal de la cadena de suministros que fabrica y comercia con muebles. A

continuación se define el espacio de navegación de cada uno, de acuerdo con la guía

metodológica propuesta.

2.1.2.1 Modelo de espacio de navegación para el distribuidor

• Clases del modelo conceptual relevantes:

En el caso del modelo de negocio B2B que se está manejando como ejemplo, las clases

de los clientes que interactúan en cada modelo conceptual a lo largo de la cadena de

suministros, no son omitidas debido a la necesaria navegación por cada una de ellas,

para asegurar las funcionalidades propias del modelo de negocio. De esta manera, las

clases consideradas como relevantes son:

! convertidor ! minorista ! distribuidor ! catalogodistribuidor ! productodistribuidor ! ordendecompraminorista ! tarjetacreditominorista ! dineroelectronico

• Clases del modelo conceptual omitidas:

Del modelo conceptual referente al minorista sólo se omitieron las clases

correspondientes a las interfaces que permiten comunicar a dicho modelo con los demás

participantes en la cadena de suministros.

ISC-2002-2-41

84

! Interface Iconvertidor ! Interface Idistribuidor ! Interface Formapagominorista

• Manejo de la información omitida:

Debido a que sólo se omitió las interfaces, no se pierde información, ni atributos

importantes para la navegación.

• Navegación directa:

Se mantienen las asociaciones del modelo conceptual, pero además se adicionan las

correspondientes a:

! Asociación entre ordendecompraminorista y tarjetacreditominorista ! Asociación entre ordendecompraminorista y dineroelectronico ! Asociación entre distribuidor y productodistribuidor ! Asociación entre distribuidor y ordendecompraminorista

Modelo del espacio de navegación, correspondiente a la parte intermedia de la cadena

de suministros, donde se asocian el convertidor, el distribuidor mayorista, y el

minorista. Las asociaciones de navegación, indican en este diagrama la posibilidad de

realizar un acceso directo a la clase de navegación hacia donde apunta la flecha. Con

esto se pretende mantener la funcionalidad original de la aplicación y del diseño del

modelo conceptual correspondiente realizado en el capítulo anterior.

A continuación se muestra el modelo de espacio de navegación del distribuidor,

aplicando las consideraciones anteriores:

ISC-2002-2-41

85

Figura 14. Modelo de espacio de navegación para el modelo conceptual del distr

minoristas

1..* 1..*

distribuidores 1..*1..*

catalogodistribuidor

1..*

1productodistribuidor

1

1..*

catalogodistribuidores

1..*

1..*

productodistribuidores 1

1..*

productodistribuidores

1..*

1

tarjetacreditominorista dineroelectronico 1

1

1

1

catalogodistribuidores

1.*

1.*

1

1.*

ordendecompraclientes

ordendecompraclientes1.*

1

ibuidor

ISC-2002-2-41

86

2.1.2.2 Modelo de espacio de navegación para el minorista

• Clases del modelo conceptual relevantes:

En el caso del modelo de negocio B2B que se está manejando como ejemplo, las clases

de los clientes que interactúan en cada modelo conceptual a lo largo de la cadena de

suministros, no son omitidas debido a la necesaria navegación por cada una de ellas,

para asegurar las funcionalidades propias del modelo de negocio. De esta manera, las

clases consideradas como relevantes son:

! clientefinal ! minorista ! distribuidor ! catalogominorista ! productominorista ! ordendecompracliente ! tarjetacreditocliente ! dineroelectronico

• Clases del modelo conceptual omitidas:

Del modelo conceptual referente al minorista sólo se omitieron las clases

correspondientes a las interfaces que permiten comunicar a dicho modelo con los demás

participantes en la cadena de suministros.

! Interface Icliente ! Interface Idistribuidor ! Interface Formapagocliente

• Manejo de la información omitida:

Debido a que sólo se omitió las interfaces, no se pierde información, ni atributos

importantes para la navegación.

ISC-2002-2-41

87

• Navegación directa:

Se mantienen las asociaciones del modelo conceptual, pero además se adicionan las

correspondientes a:

! Asociación entre ordendecompracliente y tarjetacreditocliente ! Asociación entre ordendecompracliente y dineroelectronico ! Asociación entre minorista y productominorista ! Asociación entre minorista y ordendecompracliente

A continuación se muestra el modelo de espacio de navegación del minorista, aplicando

las consideraciones anteriores:

ISC-2002-2-41

88

Figura 15. Modelo de espacio de navegación para el modelo conceptual del minorista

clientesfinales

distribuidores

1..*

1..* 1..* 1..*

catalogominoristas

1..*

1

catalogominoristas

catalogominoristas

1..* 1.*1..*

1..*

productominoristas

1..* 1

productominoristas 1

1..*

ordendecompraclientes1..*

1

tarjetacreditocliente dineroelectronico

11

11

productominoristas

1..*

1

ordendecompraclientes1..*

1

ISC-2002-2-41

89

Modelo del espacio de navegación, correspondiente a la parte final de la cadena de

suministros, donde se asocian el distribuidor mayorista, el minorista y el cliente final.

Las asociaciones de navegación, indican en este diagrama la posibilidad de realizar un

acceso directo a la clase de navegación hacia donde apunta la flecha. Con esto se

pretende mantener la funcionalidad original de la aplicación y del diseño del modelo

conceptual realizado en el capítulo anterior.

2.2 Modelo De Estructura De Navegación Este modelo describe la manera en que la navegación puede ser realizada por medio de

elementos de acceso como índices, guías, consultas y menús. Los caminos de

navegación junto con los elementos de acceso son presentados en un modelo de

estructura de navegación, el cual puede ser sistemáticamente construido a partir del

modelo espacial de navegación en dos etapas:

• Enriquecer el modelo espacial de navegación con índices, guías y consultas.

• Derivar menús los cuales representan posibles elecciones de navegaciones.

2.2.1 Definición de índices, consultas y guías Índices, guías y consultas (también llamados accesos primitivos) son nodos de

navegación adicionales necesarios para acceder a instancias de la clases de navegación.

Para modelar dichos nodos de navegación, es necesario definir los siguientes elementos

para modelar:

ISC-2002-2-41

90

• Indice : Es modelado por un objeto compuesto, el cual contiene un número

arbitrario de objetos índice. Cada objeto índice es a la vez un objeto con

nombre y un link a una instancia de una clase de navegación. Cualquier índice

es un miembro de una cierta clase índice que esta estereotipada por <<índice>>

con un icono correspondiente. Una clase índice debe ser construida para

conformar la estructura de composición de clases como se muestra en la figura

16. En la práctica se pueden hacer simplificaciones de la notación como se

muestra en la figura 17. En la forma simplificada, la asociación entre MiIndice

y MiClaseNavegacion es derivada de la composición de índice y la asociación

entre MiObjetoIndice y MiClaseNavegacion.

Figura 16. Clase Indice

En la figura 17, se observa la clase MiIndice que tiene

contiene un objeto índice llamado MiObjetoIndice

navegación llamada MiClaseNavegacion.

Figura 17. Notación abreviada de la c

<<índice>> MiIndice

nombre: String

MiObjetoIndice

<<clasMiC

MiIndice

1

*

el estereotipo “índice”, la cual

con un link a una clase de

<<clase de navegación>> MiClaseNavegación

*

lase Índice.

e de navegación>> laseNavegacion

ISC-2002-2-41

En la figura 17, se observa el icono que representa la composición de índices con el

respectivo link a la clase de navegación.

• Guía: Es modelada por un objeto el cual otorga acceso secuencial a las

instancias de una clase de navegación. En aquellas clases que contienen guías

se usa el estereotipo <<guía>>, como se muestra en la figura 18. Cualquier

clase guía debe estar conectada a una clase de navegación por una asociación

directa, la cual tenga la propiedad {ordenado}.

Figura

En la figura 18, se observa la clase g

secuencial, con el estereotipo <<guía

navegación.

• Consulta: Es modelada por u

como atributo. Para las clases

como se muestra en la figura 1

asociaciones dirigidas relacion

puede modelar el hecho de q

deba primero conducir a un í

particular de una clase de naveg

*

<<clase de navegación>>

MiClaseNavegacion

MiTourGuiado

{ordenado}

91

18. Clase guía

uía representada como un elemento de acceso

>>. Está debe tener un link a una clase de

n objeto el cual tiene una palabra de consulta

consulta se usa el estereotipo <<consulta>>,

9. Cualquier clase consulta es la fuente de dos

adas por la condición {or}. De esta manera, se

ue una consulta con muchos objetos resultado

ndice que apoya la selección de una instancia

ación.

ISC-2002-2-41

92

Figura 19. Clase consulta.

En la figura 19, se observa la clase consulta, que representa un elemento

cual contiene asociaciones dirigidas relacionadas con un “or” como ya se e

una clase de navegación.

2.2.1.1 Método para enriquecer el modelo espacial con índices, consultas En el enriquecimiento de un modelo espacial de navegación con element

como índices, guías y consultas, se deben seguir pautas tales como:

• Considerar sólo aquellas asociaciones del modelo de espacio de

que tengan al final, multiplicidad mayor o igual a uno.

• Para cada asociación de esta clase, se escoge uno o más elementos

la navegación. En este paso, es importante saber reconocer cu

elementos de acceso apropiados. Por otro lado, es posible automati

tomando una decisión de diseño por defecto, la escogencia de

acuerdo a un atributo clave seleccionado de la clase de navegación

?

<<clase de navegacMiClaseNavegac

0..1

ión>> ion

*

{or}

MiConsulta

MiIndice

1

de acceso el

xplicó, hacia

y guías.

os de acceso

navegación

para realizar

ales son los

zar este paso

un índice de

objetivo.

ISC-2002-2-41

93

• Debe existir correspondencia entre el modelo espacial de navegación y la

estructura de navegación. Por tanto los nombres de rol de la navegación en el

modelo de espacio de navegación, deben ser asignados a los elementos de

acceso.

2.2.2 Definición de menús. Con los menús se hace referencia a los accesos primitivos de tipo menú, que se añaden

al modelo de estructura de navegación.

Un menú es modelado por un objeto compuesto, el cual contiene un número fijo de

objetos menú, donde cada objeto menú tiene un nombre fijo y un enlace a una

instancia de una clase de navegación o a un elemento de acceso. Cualquier menú es una

instancia de alguna clase menú que tenga el estereotipo <<menú>>, con su ícono

correspondiente. La clase menú debe ser construida de acuerdo a la composición de

estructura de clases, mostrada en la figura 20, y el estereotipo es restrictivo como se

estipula en la clasificación de estereotipos de Berner et al (1999).

Debido a que cada objeto menú de la clase menú tiene un nombre fijo, se rotulan los

atributos de nombre en una clase objeto menú, con la propiedad {frozen}. Sin embargo,

una misma clase objeto menú puede tener diferentes instancias, ya que pueden existir

varios objetos menú con el mismo nombre pero enlazados a diferentes objetos.

Para abreviar su representación también existe un modelo simplificado. Como se

muestra en la figura 21.

ISC-2002-2-41

94

Figura 20. Clase menú.

En la figura 20, se observa la composición de la clase menú, su estereotipo “menú” y las

asociaciones a elementos de acceso, de cada menú ítem (MiObjetoMenu#).

Figura 21. Notación abreviada de la clase menú.

<<menu>> MiMenu

1 nombre: objeto1{frozen}

MiObjetoMenu1

1

1

1

1

nombre: objeto2{frozen}

MiObjetoMenu2

nombre: objeto3{frozen}

MiObjetoMenu3

nombre: objeto4{frozen}

MiObjetoMenu4

nombre: objeto5{frozen}

MiObjetoMenu5

?

1

1

1

1

1

Objeto1

Objeto2

Objeto3

Objeto4

Objeto5 ?

MiMenu

ISC-2002-2-41

95

2.2.2.1 Método para enriquecer el modelo espacial con menú En el enriquecimiento de un modelo espacial de navegación con elementos de tipo

menú como elemento de acceso, se procede como sigue:

• Considere aquellas asociaciones que tienen como origen una clase de

navegación.

• Asocie a cada clase de navegación que tenga en el modelo anterior, por lo

menos una asociación saliente a una clase menú. Dicha asociación debe ser una

composición.

• Introducir cada rol que aparezca en el modelo anterior, en el extremo final de la

asociación directa, el correspondiente menú ítem. Por defecto, el nombre del rol

es usado como el nombre del menú ítem.

• Cualquier asociación que tiene como fuente una clase de navegación, se

convierte ahora en una asociación del correspondiente menú ítem introducido en

el paso anterior.

2.3 Ejemplo del método de estructura de navegación Continuando con los ejemplos correspondientes al espacio de navegación descrito en la

sección anterior, se plantean las posibles configuraciones del modelo de estructura de

navegación de acuerdo con la guía metodológica propuesta.

En el modelo de estructura de navegación de la figura 22 se utiliza el modelo conceptual

del distribuidor, el cual incluye las clases minorista y convertidor. En la estructura de

navegación se recurre a la utilización de índices, guías y menús como elementos de

ISC-2002-2-41

96

acceso más comunes debido a las características de los atributos de las clases y de la

cardinalidad de las asociaciones de navegación. Se utilizó también una consulta para

ejemplificar su utilidad en la implementación de búsquedas.

ISC-2002-2-41

97

Figura 22. Modelo de estructura de navegación para el distribuid

distribuidor

1

dineroelectronico

MENU DISTRIBUIDOR

Por Nombre del Distribuidor

1

1..*

1

Por Nombre del Minorista

Por número del Cata

1..*

1..*

1

Por Identificador del Producto

1..*

1

Por número de la Orden de Compra

1

1..*1

1

1..*

Por número del Catalogo MEN

Por ndel Ca

11..*

1

MENU ORDEN DE COMPRA MINORISTA

1

1..*

MENU CATALOGO DISTRIB

1

1..*

1

Por Identificador del Producto

1

1..* {or} 1

0..11..*

tarjetadecreditominorista

Buscar por IdTarjeta por orden de compraminorista

Por Identificador del producto

?

minorista

convertidor

catalogodistribuidor

productodistribuidor

ordendecompraminorista

productodistribuidor

tarjetacreditominorista

dineroelectronico

buscarIdTarjeta1

catalog

ordend

catalogodistribuidor

productodistribuidor

MENU CATALOGO CONVERTIDOR

minorista

convertidor

logo

productodistribuidor

1..*

ordendecompraminorista

catalogodistribuidor

or

Por Identificador de la Orden

U MINORISTA

1úmero talogo

UIDOR

1

odistribuidor

ecompraminorista

1

ISC-2002-2-41

98

En el anterior modelo de estructura de navegación (figura 22) se especifica por medio

de elementos de acceso, cómo será realizada la navegación dentro del modelo

conceptual del distribuidor, para que los requerimientos funcionales estipulados con

anterioridad.

La clase de navegación del distribuidor esta asociada por medio de una agregación a un

menú que lleva el mismo nombre y contiene una colección de objetos menú, donde cada

objeto menú tiene un nombre fijo y un enlace a una instancia de una clase de

navegación o a un elemento de acceso; en éste caso el menú se llama MENU

DISTRIBUIDOR, y los objetos menú se enlazan principalmente a elementos de acceso

de tipo guía o índices. Con estos elementos de acceso se permite hacer un link a una

clase de navegación por medio de un índice, como por ejemplo, el acceso a los

minoristas o al convertidor, o por medio de acceso secuencial como por ejemplo, el

acceso a producto del distribuidor (productodistribuidor), las ordenes de compra de los

minoristas (ordendecompraminoristas) o el catalogo del distribuidor

(catalogodistribuidor).

Estas clase de navegación también tienen agregados menús que funcionan igual a lo

explicado anteriormente, pero además, se encuentra en el modelo un ejemplo sobre

cómo se puede representar una consulta para obtener información del negocio. Dicha

consulta se construye de manera tal, que pueda ser realizada por medio de una búsqueda

secuencial mediante el empleo de un elemento guía, o pueda ser llevada a cabo de forma

directa sobre la clase de navegación correspondiente, en este caso,

tarjetadecreditominorista.

ISC-2002-2-41

99

Figura 23, Ejemplo del modelo de estructura de navegación

Por Identificador del dinero

MENU DISTRIBUIDORES

Por Idtarjeta por orden compra cliente

minorista

1

Por Identificador de la Orden

dineroelectronico

clientefinal distribuidor

productominorista

ordendecompracliente

catalogominoristas

MENU MINORISTA

Por Nombre del Distribuidor

1

1..*

1

Por Nombre del Cliente Final

Por número del Catalogo

1..*

1..*

1

Por Identificador del Producto

1..*

1

Por número de la Orden de Compra

1

1..*1

1

1..*

Por número del Catalogo MENU CLIENTEFINAL

1

1..*

Por número del Catalogo

11..*

1

MENU ORDEN DE COMPRA CLIENTE

1

1..*

MENU CATALOGO MINORISTA

1

1..*

1

Por Identificador del Producto

1

1..*

1

{or} 1

0..1 1..*

tarjetadecreditocliente

Buscar por IdTarjeta por orden de compracliente

Por Identificador del producto

?

clientesfinales

distribuidores

catalogominoristas

productominoristas

ordendecompraclientes

productominoristas

tarjetacreditoclientes

dineroelectronico

buscarIdTarjeta1

catalogominoristas

ordendecompraclientes

catalogominoristas

productominoristas 1

ISC-2002-2-41

100

En el modelo de estructura de navegación de la figura 23 se utiliza el modelo conceptual

del minorista, el cual incluye las clases clientefinal y distribuidor. La elección de éste

modelo se debe a que ejemplifica mejor la parte relacionada con el modelo de

presentación estática y dinámica. En la estructura de navegación se recurre a la

utilización de índices, guías y menús como elementos de acceso más comunes debido a

las características de los atributos de las clases y de la cardinalidad de las asociaciones

de navegación.. En el anterior modelo de estructura de navegación se especifica por

medio de elementos de acceso, cómo será realizada la navegación dentro del modelo

conceptual del minorista para que los requerimientos funcionales estipulados con

anterioridad.

La clase de navegación del minorista esta asociada por medio de una agregación a un

menú que lleva el mismo nombre y contiene una colección de objetos menú, donde cada

objeto menú tiene un nombre fijo y un enlace a una instancia de una clase de

navegación o a un elemento de acceso; en éste caso el menú se llama MENU

MINORISTA, y los objetos menú se enlazan principalmente a elementos de acceso de

tipo guía o índices. Con estos elementos de acceso se permite hacer un link a una clase

de navegación por medio de un índice, como por ejemplo, el acceso a los clientesfinales

o al distribuidor, o por medio de acceso secuencial como por ejemplo, el acceso a

producto del minorista (productominorista), las ordenes de compra de los clientes

finales (ordendecompracliente) o el catalogo del minorista (catalogominorista).

ISC-2002-2-41

101

Estas clase de navegación también tienen agregados menús que funcionan igual a lo

explicado anteriormente, pero además, se encuentra en el modelo un ejemplo sobre

cómo se puede representar una consulta para obtener información del negocio. Dicha

consulta se construye de manera tal, que pueda ser realizada por medio de una búsqueda

secuencial mediante el empleo de un elemento guía, o pueda ser llevada a cabo de forma

directa sobre la clase de navegación correspondiente, en este caso,

tarjetadecreditocliente.

3. MODELO DE PRESENTACIÓN ESTÁTICA

El anterior modelo muestra cómo navegar a través del espacio de navegación por medio

de elementos de acceso. Ahora en la guía propuesta como metodología, se continua con

el manejo de la información que es presentada al usuario, y que se encuentra en el

espacio de navegación y la estructura de acceso. Para esto, se utiliza un modelo de

presentación estático que representa una interfaz abstracta, diseñada en forma parecida a

un bosquejo de la interfaz del usuario.

El modelo de presentación se enfoca en la organización estructural de la presentación y

no en la apariencia física en términos de colores, formatos de presentación, etc. Estos

detalles son tenidos en cuenta en la fase de implementación, la cual no se trata en este

documento. Sin embargo, la disposición de modelar elementos en el modelo de

presentación da pistas acerca de posición y tamaño de estos elementos relativa con

otros.

ISC-2002-2-41

102

Pueden existir varios tipos de modelos de presentación, pero se hace énfasis

especialmente en dos alternativas:

• Presentación basada en un menú.

• Presentación basada en un mapa.

3.1 Elementos de modelaje. En la construcción de un modelo de presentación se debe decidir qué elementos deben

ser usados para la presentación de las instancias de las clases de navegación, y cuáles

para la presentación de los elementos de accesos.

• Frameset : Es un contenedor de objetos de presentación o de otros framesets.

Esta es una instancia de una clase frameset con estereotipo “frameset” con su

correspondiente ícono. Se representa como se muestra en la figura 24.

Figura 24. Frameset

En la figura 24, se observa la estructura de composición de la clase MyFrameset, con

estereotipo “frameset”.

ISC-2002-2-41

103

• Clase de presentación: Modela la presentación de una clase de navegación o un

acceso primitivo, tal como un índice, guía, consulta y menú. Las instancias de

una clase de presentación son los contenedores de elementos de modelaje como

texto, imágenes, secuencias de audio, secuencia de video, ancoras, colecciones

(listas de texto, imágenes, etc.), colecciones de ancoras (listas de ancoras), etc.

Está estereotipado como “presentational class”, con su correspondiente icono

como se muestra en la figura 25.

Figura 25. Clase de presentación.

En la figura 25, se observa la clase de presentación MyPresentationalClass, la cual tiene

el estereotipo “clase de presentación” y contiene elementos de modelaje que se

describen a continuación.

• Texto : Es una secuencia de caracteres.

ISC-2002-2-41

104

• Ancora : Es un texto marcado sobre el cual se puede hacer click para establecer

una relación de navegación con otros nodos.

• Botón : Es un área para hacer click, la cual tiene asociada una acción. Estos

también pueden ser triggers de navegación.

• Imagen, audio y video: Son objetos multimedia, en donde las imágenes son

desplegadas, mientras que el audio y video puede ser iniciado, detenido,

retrocedido y avanzado.

• Forma : Es usada por el usuario para ingresar información, ya sea llenando cajas

o seleccionando opciones desde un browser o checkbox.

• Colección y colección de ancoras: Son elementos de modelaje, tales como

listas de elementos de texto, listas de ancoras que permiten una representación

de composición.

En la figura 26 se muestra como los elementos se usan para construir una plantilla de

presentación para los clientes finales, igualmente se podría construir una para los

minoristas como se observa en la figura 27. En la clase de presentación para el

clientefinal se pueden añadir los elementos de modelaje necesarios para describir los

atributos pertenecientes a la clase de navegación que se desea representar, tales como la

imagen de la foto, listas de elementos de textos para los productos que ha solicitado ,

texto para la información personal, además podría agregar efectos sonoros o visuales

según las características de la aplicación.

ISC-2002-2-41

105

Figura 26. Clase de presentación para los clientes finales.

En la anterior figura, se muestra cómo se puede ordenar una plantilla o formato, por

medio de elementos de modelaje descritos anteriormente, creando la clase de

presentación para los clientes finales.

3.2 Modelo de presentación basado en un menú. El modelo de presentación consiste en un conjunto de clases de presentación (Web

page). Las siguientes reglas deben ser usadas como guías:

• Construir una presentación por cada clase de navegación encontrada en el

modelo de estructura de navegación, esto con el fin de proveer una plantilla para

las instancias de la clase, con sus respectivos atributos. Las clases con

estereotipo “texto”, “imagen”, “audio” y “video” son usados como atributos de

tipos primitivos y las “colecciones” son usados para las listas. La figura 26,

muestra la presentación construida para la clase de navegación clientefinal.

<<clase de presentación>> Clientefinal

<<imagen>> Fotografía

<<texto>> Nombre

<<texto>> Identificación

<<colección>> Productos solicitados

<<clase de presentación>> Clientefinal

ISC-2002-2-41

106

Figura 27. Clase de presentación para los minoristas • Seleccione una clase de navegación como una raíz para navegar y construya una

clase de presentación para el menú de esta clase de navegación (menú principal).

Añadir un ancora Home para volver a la raíz, es buena practica. Por ejemplo, en

la figura 28 se muestra la clase minorista cuyo menú principal es

minoristaMenu.

<<imagen>> Logo

<<texto>> Nombre

<<texto>> NIT

<<colección>> Productos solicitados al

distribuidor

<<clase de presentación>> minorista

ISC-2002-2-41

107

Figura 28. Frameset para minorista.

• Construya una clase de presentación para cada índice y menú que se encuentre

en el modelo de estructura de navegación. Para la presentación de un índice o

una clase menú se usan elementos de modelado con estereotipo <<colección de

ancoras>> o <<ancoras>> Como ejemplo de menús e índices, se muestra

clientefinalMenu, distribuidorIndex, distribuidorMenu y

ordedecompraclienteMenu en las figuras 29, 30, 31 y 32.

<<frameset>> MinoristaFrameset

<<clase de presentación>> minoristaMenu

clientesfinales

distribuidores

catalogominoristas

productosminoristas

ordendecompraclientes

<<clase de presentación>> minorista

HOME

ISC-2002-2-41

108

Figura 29. Frameset para clientefinal

<<frameset>> ClientefinalFrameset

<<clase de presentación>> minoristaMenu

clientesfinales

distribuidores

catalogominoristas

productosminoristas

ordendecompraclientes

<<clase de presentación>> clientefinal

HOME

<<clase de presentación>> clientefinalMenu

ordendecompraclientes

catalogominoristas

ISC-2002-2-41

109

Figura 30. Frameset para distribuidorIndex

<<frameset>> DistribuidorIndexFrameset

<<clase de presentación>> minoristaMenu

clientesfinales

distribuidores

catalogominoristas

productosminoristas

ordendecompraclientes

<<clase de presentación>> distribuidorIndex

HOME

<<colección de ancoras>> DistribIndex

ISC-2002-2-41

110

Figura 31, Frameset para distribuidor

<<frameset>> DistribuidorFrameset

<<clase de presentación>> minoristaMenu

clientesfinales

distribuidores

catalogominoristas

productosminoristas

ordendecompraclientes

<<clase de presentación>> distribuidor

<<clase de presentación>> distribuidorMenu

catalogominoristas

HOME

ISC-2002-2-41

111

Figura 32. Frameset para ordendecompraclientes

• Construya una clase de presentación para cada consulta y guía. Usando las

formas para representar consultas y guías introduciendo menú ítems adicionales

(“next”, “prev”) los cuales permiten avanzar o retroceder sobre los objetos en un

tour guiado, como se observa en la figura 33.

<<frameset>> OrdendecompraclientesFrameset

<<clase de presentación>> minoristaMenu

clientesfinales

distribuidores

catalogominoristas

productosminoristas

ordendecompraclientes

<<clase de presentación>> ordendecompraclientes

HOME

<<clase de presentación>> ordendecompraclientesMenu

Productominoristas

Tarjetacreditocliente

Productominoristas

ISC-2002-2-41

• Combine cad

presentación del menú princ

<<frameset>> OrdendecompraclientesFrameset

<<clase de presentación>> minoristaMenu

clientesfinales

distribuidores

catalogominoristas

productosminoristas

ordendecompraclientes

<<clase de presentación>> ordendecompraclientes

<<clase de presentación>> ordendecompraclientesMenu

Productominoristas

Tarjetacreditocliente

Productominoristas

<

Prev <

Next >>

112

Figura 33. Frameset para ordendecompraclientes

a clase de presentación (hechas en el paso 1) con la clase de e su menú ( hecho en el paso 3 ) en un frameset. Luego, adicione

ipal al frameset. Las figuras 30 y 31 son buenos ejemplos.

HOME

ISC-2002-2-41

113

3.3 Método de presentación basado en mapa Este tipo de presentación está basado en el uso de framesets los cuales permiten

visualizar la estructura de navegación. La idea es por tanto, dividir la presentación en

dos partes básicas:

• Proveer una presentación del árbol de navegación, mostrando la navegación

actual del usuario y el contexto.

• Mostrar el correspondiente contenido.

El procedimiento para realizar el modelo de presentación a partir del modelo de

estructura de navegación, se describe como sigue:

• Construir una presentación para cada clase de navegación y modelar cada clase

índice que aparezca en la estructura de navegación.

• Escoger una clase de navegación como raíz de la navegación. En el ejemplo se

ha seleccionado la clase minorista.

• Para cada clase de navegación y para cada clase índice considere todos los

posibles caminos ( en el modelo de estructura de navegación) desde la clase raíz

hasta la clase actual. Para cada camino construya una presentación del

correspondiente árbol de navegación.

ISC-2002-2-41

114

En la figura 34, se observa la clase minorista, cuyo árbol de navegación correspondiente

es representado por la clase de presentación NavigationalTreeMinorista, aquí minorista

es la raíz de la navegación y se muestra sólo el menú asociado con minorista.

La figura 35, es la clase de presentación NavigationalTreeDistribuidorIndex, muestra el

árbol de navegación cuando alguien se mueve desde minorista hasta el índice

distribuidor y la clase de presentación de la figura 36, muestra el árbol de navegación

cuando alguien navega hacia un distribuidor en particular. En este caso, la ancora

catalogominorista está ubicada a profundidad tres en el árbol, para representar el menú

asociado con un distribuidor.

Figura 34, Frameset para minorista

<<frameset>> MinoristaFrameset

<<clase de presentación>> minoristaMenu

clientesfinales

distribuidores

catalogominoristas

productosminoristas

ordendecompraclientes

<<clase de presentación>> minorista

HOME

ISC-2002-2-41

115

Figura 35, Frameset para distribuidorIndex

<<frameset>> DistribuidorIndexFrameset

<<clase de presentación>> navigationalTree DistribuidorIndex

Home

clientesfinales

distribuidores

catalogominoristas

productosminoristas

<<clase de presentación>> distribuidorIndex

Ordendecompracliente

<<colección de ancoras>> DistribIndex

ISC-2002-2-41

116

Figura 36, Frameset para distribuidor

• Combinar los resultados de los pasos uno y tres de acuerdo a los framesets.

Cualquier frameset tiene dos partes, donde el frame derecho contiene la

presentación de la clase de navegación o clase índice (hechas en el paso 1) y el

<<frameset>> DistribuidorFrameset

<<clase de presentación>> NavigationalTree

Distribuidor..i

Home

Clientesfinales

Distribuidores

Productosminorista

Productosminorista

<<clase de presentación>> distribuidor

ordendecompraclientes

catalogomnorista

Distri...i

ISC-2002-2-41

117

frame izquierdo representa el árbol de navegación ( paso 3) correspondiente a

una posible navegación de esta clase.

4. MODELO DE PRESENTACIÓN DINÁMICO.20

En el modelo estático de presentación se modela aspectos dinámicos de la presentación

con un modelo de ventana de flujo, que describen la conducta de los objetos de

presentación, por ejemplo, los cambios realizados en la interfaz del usuario cuando el

usuario interactúa con el sistema.

El control de flujo entre ventanas puede ser representado por modelos de interacción

que muestren qué ventanas están abiertas y cuál frameset está disponible en cada

ventana en un determinado momento. Para este propósito se usa los diagramas de

secuencia de UML.

4.1 Elemento de modelaje Este es usado para describir la interacción del usuario con la interfaz de la aplicación

Web.

• Window : es el área de la interface del usuario donde los frameset u objetos de

presentación son desplegados. Una ventana puede ser movida, redimensionada o

reducida a icono. Este incluye por lo menos dos botones, uno para transformar la

20 Rolf Hennicker y Nora Koch, Systematic Design of Web Applications with UML.

ISC-2002-2-41

118

ventana en un icono y otro para cerrar la ventana. En la figura 35 se muestra la

clase de estereotipo << window >>

Figura 37. Clase Window.

4.2 Método Los pasos para construir un modelo de ventana de flujo no pueden ser automatizados,

debido a que los desarrolladores deben decidir sobre los comportamientos de diferentes

ventanas.

• Establecer el contexto para el modelo de interacción. Por ejemplo, decidir qué

camino de navegación del diagrama de estructura de navegación debe ser

modelado. Un camino de navegación está siempre relacionado con un caso de

uso. En la figura 38, se muestra el caso de uso buscarTarjetaCredito por

compracliente que hace parte de la administración financiera.

• Decidir cuántas ventanas son necesarias en este contexto. Representa al usuario

y el objeto ventana en una dimensión horizontal. En la figura 36, se observan

tres ventanas.

• Especificar un mensaje de despliegue para cada objeto de presentación y los

framesets que puedan ser presentados al usuario en una ventana.

ISC-2002-2-41

119

• Incluir el mensaje de selección para cada acción del usuario que seleccione un

ancora o un botón. Los nombres del ancora o del botón son los parámetros de los

mensajes.

• Especificar mensajes de filled (llenado) y submit (registrar), para cada acción

del usuario que consista en ingresar datos en una plantilla de consulta. Esta

plantilla es el parámetro del mensaje.

• Incluir un mensaje para cada ventana abierta o cerrada.

• Usar delimitadores (balking) para especificar el periodo de tiempo en que una

ventana es visible.

Como ejemplo del modelo de ventanas de flujo, se muestra la figura 38.

Figura 38. Modelo de ventanas de flujo.

ISC-2002-2-41

120

CAPITULO 3

1. APLICACIÓN DE LA GUIA A CASOS REALES

En este capítulo se realiza la aplicación de la guía metodológica expuesta en casos

reales, para lograr la validación de la misma. Dado que en el capítulo anterior se utilizó

el ejemplo ficticio de una cadena de suministros para la elaboración y comercialización

de muebles, ahora se emplean casos reales pero que igualmente basen sus procesos en

una cadena de suministros. Como ayuda para obtener la información de empresas reales

que hayan incorporado a su modelo de negocio B2B, se utilizó como referencia el libro

“La clave del comercio electrónico, guía para pequeños y medianos exportadores”

desarrollado por el Centro de Comercio Internacional, en el cual se ilustran casos reales

acerca de la utilización de comercio electrónico.

Las aplicaciones Web para comercio electrónico han demostrado mejoras sustanciales

en las operaciones y procesos de la cadena de suministro. Por lo general, las compañías

multinacionales prefieren la realización de los negocios por medios electrónicos, debido

a que ha reducido el personal empleado en adquisiciones hasta en un 60% y los costos

de materiales en un 20%; igualmente reduce el tiempo de selección de proveedores a la

mitad del empleado anteriormente21. Estas multinacionales utilizan las plataformas de

compra electrónicas para reunir por medio de éstas a todos sus proveedores, como por

ejemplo el caso de General Motors, quien está colaborando con Ford, Daimler Chrysler

21 La clave del comercio electrónico, guía para pequeños y medianos exportadores, Centro de comercio internacional

ISC-2002-2-41

121

e I2, un especialista en software de cadenas de suministro, en la construcción de dicha

plataforma.

A nivel internacional existen muchas empresas que utilizan aplicaciones Web para

comercio electrónico. Las aplicaciones varían en su funcionalidad dependiendo del

modelo de negocio de cada empresa, por ejemplo, www.ironmall.com utiliza

aplicaciones electrónicas encargadas de manejar comunidades o portales de comercio en

línea, subastas del vendedor, donde se encuentran buenas ofertas sin restricciones de

sistemas específicos. Otras aplicaciones electrónicas son usadas para el manejo de

catálogos de Internet, catálogos de Intranet o sistemas del comprador, para solicitudes

electrónicas de propuestas (RFP), como búsqueda electrónica de proveedores y

benchmarking electrónico, etc. Aunque el empleo de plataformas de compra en

comercio electrónico se vincula a las grandes multinacionales debido a los grandes

costos que se requieren para su implementación, existe una serie de operaciones de

compra que se pueden realizar por medio de la red, como por ejemplo, obtención de

cotizaciones de varios proveedores, búsqueda de información técnica sobre partes o

artículos, verificación y comparación de precios, disponibilidad de inventarios de un

proveedor, realización de pedidos y seguimiento de su progreso, etc. Estas aplicaciones

electrónicas están siendo colocadas al alcance de las PYME´s en países en desarrollo.

Como primer caso real para el análisis de validez de la guía metodológica para el diseño

de aplicaciones Web, se utiliza el caso internacional de un ensamblador británico de

bicicletas, quien tiene una línea de montaje en el Reino Unido, pero sus proveedores se

encuentran en Vietnam. Anteriormente, las partes eran despachadas por el fabricante

vietnamita conforme iban saliendo de la línea de producción, pero salían recubiertas de

ISC-2002-2-41

122

papel engrasado y partículas de suciedad, cada caja contenía 10 partes y se etiquetaban

con la dirección del ensamblador británico y el número de parte del fabricante. Luego,

en la planta de montaje del Reino Unido los operarios desempacaban las partes, las

limpiaban de partículas de suciedad y las volvían a engrasar y empacar para luego

clasificarlas en bandejas según las listas de materiales de cada modelo de bicicleta, antes

de enviarlas a la línea de montaje, la planta ensambladora usaba entre 200 y 250

bandejas por día.

Actualmente los planos de diseño, la cantidad de cajas por entregar, las etiquetas de

código de barra y la información sobre la línea de suministro se transmiten por Internet

a través de un vínculo establecido por el comprador británico. El mayor fabricante

vietnamita reúne todas las partes de los demás fabricantes locales, y las engrasa y

preensambla antes de empacarlas en bandejas separadas para su envío en cajas de hasta

250 partes, dependiendo de los requisitos de la línea de montaje en el Reino Unido. Las

bandejas se etiquetan con el número del modelo de bicicleta y con el código de barras

del ensamblador británico (enviados por Internet), y las cajas se entregan directamente a

la línea de montaje en el Reino Unido sin necesidad de manipulación adicional .

Este es un claro ejemplo, en donde tanto el comprador como el proveedor se benefician.

Los proveedores obtienen un precio mucho mejor por sus partes y atraen más clientes

internacionales y por otro lado, el ensamblador de bicicletas resolvió un problema

logístico, debido a que el tiempo de ejecución disminuyo y las quejas y devoluciones

por productos mas elaborados bajo considerablemente.

ISC-2002-2-41

123

Los beneficios de la implementación de tecnología de Internet podrían ser mejores en el

caso de la utilización de aplicaciones Web, que permitieran no sólo el envío de

información básica para el negocio, sino también la automatización de los procesos de

pago de las partes de las bicicletas, y de revisión de inventarios por parte del proveedor

para realizar estimaciones de producción. Por esto, una aplicación Web diseñada con la

metodología descrita en éste trabajo, puede proporcionar desde el modelo conceptual el

aseguramiento de dichas funcionalidades, por medio de clases y asociaciones que

permitan representar las órdenes de compra de la fábrica de ensamblaje de bicicletas y

la cantidad de inventario disponible por los proveedores. Luego, fácilmente se podrá

diseñar el modelo de navegación que permitirá establecer formalmente como será la

navegación por medio de la aplicación, y quizás pueda servir como un replanteamiento

acerca de nuevas necesidades del negocio o por el contrario de la eliminación de algún

proceso que no genere valor agregado. Por ejemplo, la utilización de correo electrónico

para enviar información podría ser remplazado por aplicaciones que permitan

establecer conexiones seguras para el intercambio de información importante para la

empresa.

Los elementos de acceso utilizados en el modelo de navegación permiten realizar

búsquedas complejas y rápidas por medio de los índices y guías, de esta manera, las

etiquetas de los códigos de barras pueden ser ubicados más fácilmente sí estuvieran

diseñados bajo una estructura de menús e índices.

En cuanto al modelo de presentación es importante tener en cuenta que la

representación de los productos por medio de una interfaz agradable y fácil de navegar

ISC-2002-2-41

124

permite mejor interacción entre los negociantes. Sí el fabricante de partes en Vietnam

percibe una aplicación Web fácil de asimilar, quizá sirva como promoción para la

integración de nuevos socios en la utilización del comercio electrónico. Respecto a las

desventajas se puede pensar en que la forma de pago por las órdenes realizadas deben

contar con un infomediario, que autorice el pago y valide la transacción para evitar

fraudes, luego en el diseño de la aplicación Web se debe tener en cuenta las

características y necesidades de rapidez de los desembolsos, lo cual es difícil de

controlar en la metodología.

En el caso real del ensamblador británico de bicicletas, se describen sólo dos actores

principales en la cadena de suministro, pero igualmente, los proveedores tendrán que

entablar relaciones comerciales con productores de materia prima y el ensamblador

mantendrá vínculos comerciales con distribuidores mayorista o directamente con

minoristas, en realidad lo importante es que todos participen en la automatización de los

procesos básicos para el funcionamiento correcto del negocio. Entonces la factibilidad

de aplicar el diseño al modelo B2B, es muy grande si entramos a analizar las ventajas

que se generan al involucrar en una aplicación Web, a todos los participantes de la

cadena de suministro.

A continuación se expone otro caso real, pero en esta ocasión en el panorama

colombiano. Dentro de un plan estratégico para el aprovechamiento de las nuevas

oportunidades de negocio en Internet, la compañía de galletas Noel una importante

empresa colombiana cuyo centro administrativo de negocio se encuentra en Medellín,

emprendió el estudio, diseño e implementación de aplicaciones Web para el soporte de

ISC-2002-2-41

125

procesos del negocio y como una iniciativa de B2B en cuanto uno de los objetivos es

integrar a los clientes minoristas a sus plataforma de compras. Se podría decir que Noel

no esta interesado en vender galletas por Internet, sino fortalecer sus procesos de ventas,

compra y logística, estrechando sus relaciones con clientes y proveedores. La compañía

lanzó cuatro portales dirigidos a ofrecer información de sus productos al consumidor

final y sigue desarrollando sus dos portales de negocios B2B.

El primer portal fue Novaventa, que sirvió como experimento para determinar los

alcances de Internet en la relación con sus consumidores y proveedores, pero este portal

se fijaba a un modelo de negocio B2C, el cual es muy pobre en el contexto nacional,

principalmente por el tema de la seguridad, debido a que las entidades financieras no se

han preocupado por generar confianza en la gente para que utilice los servicios del pago

electrónico. No obstante, el proyecto ha servido como base para realizar cambios en los

procesos de ventas, por ejemplo, los vendedores ahora están trabajando con

computadores portátiles desde los cuales ingresan la información del pedido y por

medio asincrónico lo depositan en un software centralizado, con esto los vendedores

tiene más información acerca del estado del negocio que antes.

Por otro lado, el desarrollo de aplicaciones B2B se trabaja en un portal de negocios

llamado Noelenlinea.com donde los participantes en el negocio pueden interactuar

directamente con la empresa y consultar información personalizada. Los proveedores,

por ejemplo, pueden consultar pagos, ver sus consumos y revisar el desarrollo de su

historia comercial con Noel; los clientes en su rol de comerciantes minoristas, pueden

realizar pedidos y modificarlos, al igual que revisar catálogos, estados de cuenta, etc.

Otro proyecto, paralelo al anterior es el desarrollo de EDI por Internet realizado en un

ISC-2002-2-41

126

Centro Electrónico de Negocios, con el objetivo de automatizar procesos que repercuten

directamente en la obtención de beneficios como disminución de devoluciones y el

mejoramiento en la calidad del servicio. Actualmente, Noel cuenta con una comunidad

de aproximadamente 200 clientes que utilizan el CEN, donde la compañía les ofrece

acceso a Internet, capacitación y otras aplicaciones como el correo electrónico.

Actualmente Noel cuenta con los portales www.noel.com.co, www.zenu.com.co,

www.dragus.com.co, y www.tosh.com.co.

En la página www.cenlat.com se encuentra toda la información referente a los

proveedores y clientes, según la categoría de productos que ofrecen y el país de origen.

Por ejemplo, en el caso del sector alimenticio en Colombia aparecen los siguientes:

A.F. Trost Hansen Productos DANCALIABC Distribuciones - Carlos Andre Barrera

Alimentos Bonfiglio Ltda

Alimentos Copelia Ltda

Alimentos Don Magolo Ltda

Alimentos Toning. S.A. Aliños el Sabrosito y Cia Ltda

Alival Ltda

Alpina Productos Alimenticios S.A. Apicolmena Martha Ltda

Are Peto Ltda. Avicola Nacional S.A. Avicola Napoles Mejia Villegas Bavaria S.A. Casa Luker S.A. Cecilia Payan de Dominguez E Hijos- Dulces del Valle Ltda

Chicle Adams

Cidimpro S.A. Colombiana de Comercio S.A. Colombina S.A. Colpromesa

Comercial Allan S.A. Comercializadora de Soto Ltda

Comercializadora Nacional S.A.S. Ltda. y/o Productos Alimenticios Margarita

Comestibles Alfa Ltda. Comestibles Dan S.A. Comestibles Italo S.A. Compañía Colombiana de Jugos Coljugos S.A. Compañía Industrial de Cereales S.A. - Cocereales S.A. Compañia Nacional de Chocolates

Concentrados S.A. Conservas California S.A. Consorcio Nápoles Santa Anita

Cooperativa Colanta Ltda. Cooperativa de Productos Lacteos de Nariño

ISC-2002-2-41

127

Cunit Damy Ltda. Del Alba S.A. Del Pilar Ltda. Disa S.A

Don Maiz S.A. Duran y Tascón Granja Santa Anita

Effem Colombia Ltda. Fabrica de Especias y Productos El Rey S.A. Ferrero del Ecuador S.A. Friesland Colombia S.A. Gaseosas Lux

Gaseosas Postobon S.A. General Mills de Colombia S.A. Generoso Mancini y Cia. Ltda. Gher Asociados Ltda. Girones S.A. Harinera del Valle S.A. Hernando Rojas

INCAUCA Alimentos y Refrescos S.A. y/o ALIRESA

INCAUCA Refineria de Colombia S.A. Incauca S.A. Indupan Ltda. Industria Colombiana de Lacteos Incolacteos Ltda

Industria Colombiana de Productos Fritos INCODEPF LTDA

Industrias Alimenticias Aretama S.A. Industrias Alimenticias Embajador Ltda.Ingenio Providencia S.A. John Restrepo A. Cía S.A. Kelloggs de Colombia S.A. Klik S.A. Laboratorio Wyeth

Laboratorios Ecar Ltda

Lacteos el Establo Ltda

Levapan

Light de Colombia S.A. Lista Alimenticia S.A. Manitoba Ltda. Mantovani Ltda

Manuelita S.A. Masapan S.A. Matiz Davila y Cia. S. en C. Meals De Colombia

Mercalimento S.A. Molinos del Cauca

Nabisco Royal Nestlé de Colombia S.A. Noel Panamericana de Alimentos S.A. Parmalat Colombia Ltda. Pastas Alfredo S.A. Pastas Firenze Ltda. Pastificio S.A. Pollos El Bucanero S.A. Procter & Gamble Colombia S.A. Productos Alimenticios Doria S.A. Productos Kibonny

Productos Lacteos Pasco S.A. Productos Maniyun Ltda. Productos Quaker S.A. Pronut Provyser Refisal Reytex Ltda

Rica Rondo S.A. Samal LTDA. Signa Grain Ltda. Suizo

Team S.A. Tisanas Orquidea Ltda

Top Brands S.A. Unilever Andina S.A. Vinagres Finos Ltda

ISC-2002-2-41

128

Zenu

Figura 39. Lista de Proveedores y clientes en el sector alimenticio que reúne el CEN de

la compañía Noel22 Igualmente aparece la lista de proveedores para los sectores de aseo, confecciones

cosméticos, electrónica, juguetería, licores, variedades para el hogar y otros. El Centro

Electrónico de Negocios (CEN) es un servicio de comercio electrónico que agrupa en

un mismo lugar en Internet a todas las empresas de consumo masivo de Latino

América para que realicen transacciones electrónicas como compra, venta, pagos y

cobros con sus principales clientes: autoservicios, supermercados, papelerías,

droguerías…etc; facilitando de esta manera, la realización de pedidos por parte de los

clientes en un mismo tipo de formato con todos sus proveedores de una forma ágil y

confiable, reduciendo gastos de operación.

Con el contexto de la compañía ya expuesto, es destacable el interés que demuestra la

empresa hacia tecnologías de Internet, por esto, es posible que más adelante se pretenda

amplia su CEN a más participantes para ofrecer servicios adicionales, lo cual podría

significar la necesidad de robustecer la capacidad de las aplicaciones Web que

actualmente se utilizan. Con respecto a este punto, se concluye la necesidad de

formalizar el de desarrollo de software para las aplicaciones Web, para tener mayor

control de los cambios realizados en las aplicaciones cuando estas se escalen. En la guía

metodológica descrita, se plantean pasos para realizar la navegación más eficientemente

como ya se mencionado por medio de los elementos de acceso, que permiten ahorrar

pasos innecesarios en la navegación como el caso de los índices y menús; por otra parte,

la validez de la guía tendría que verse necesariamente ligada a aspectos no sólo

22 www.cenlat.com

ISC-2002-2-41

129

funcionales sino también a los no funcionales, para que no interfieran con el desempeño

de los procesos de los que se encargan las aplicaciones Web, es decir, sí el diseño

contiene elementos que optimicen la utilización de recursos del sistema, es probable que

la metodología también se pueda optimizar su beneficio para el desarrollo mismo de la

aplicación.

Otros aspectos, como el manejo de la personalización de productos también pueden ser

desarrollados por medio de la guía, debido a que existe el modelo de presentación que

permite desplegar por medio de los framesets la información correspondiente a cada

usuario, incluso se puede optar por la clásica presentación en menú o por la que se basa

en mapas para llevar un control mas esquemático de la navegación. Respecto a las

desventajas, que se podrían presentar en la aplicación de la guía al caso de Noel, se

pueden suponer retrasos en la integración de la nueva metodología con las ya existentes,

aunque sí las aplicaciones actuales soportan por medio de sus diagramas de clases o

modelos conceptuales la mayoría de las funcionalidades, es factible el ahorro de tiempo

en está etapa y dedicar mayor tiempo al modelo de estructura de navegación que

requiere igual o mayor cuidado.

Un caso real que merece ser mencionado es el de un intermediario. Li & Fung es una

empresa exportadora China, que actúa como intermediaria entre minoristas de Estado

Unidos y de Europa, ésta empresa no tiene instalaciones físicas, sólo cuenta con la red

para realizar sus operaciones. Aplicó las posibilidades que brinda el comercio

electrónico en la red de productores de prendas de vestir y bienes de consumo, para

reorganizar la cadena de suministro alrededor de la información. El funcionamiento de

esta empresa es bastante sencillo, cuando los comerciantes minoristas realizan un

ISC-2002-2-41

130

pedido, ágilmente se elabora un programa de producción y lo comunica a los

productores con disponibilidad.

Las mercancías producidas se empacan en un contenedor para enviarlas directamente a

los minoristas, eliminando la necesidad de bodegas, lo cual elimina cualquier

posibilidad de existencias en inventario. Después de exponer el caso, el análisis de

confrontación con la guía metodológica puede sugerir que aunque no existe ningún tipo

de mercancía material por almacenar, el hecho de manipular información, también

puede ser modelado por medio de la guía descrita en éste trabajo. Por ejemplo, la

posibilidad de utilizar elementos de acceso en la búsqueda de los productores

disponibles, facilita la elección de éstos pues se puede navegar fácilmente hasta los

framesets correspondientes y obtener toda información del productor.

Por otra parte, la metodología es lo suficientemente flexible como por ejemplo, para

omitir clases de navegación encargadas de representar los catálogos e inventarios de

productos, que en este modelo conceptual para el infomediario no existirían, pero igual,

sin perder la funcionalidad propia de éste estilo de negocio. Las desventajas en un caso

real de este tipo, suelen presentarse cuando la navegación se concentra en aspectos muy

específicos de información, con lo cual se puede pensar que un sistema diseñado por

medio de aplicaciones convencionales podría ser suficiente para realizar los procesos

básicos de la compañía.

Con estos ejemplos de casos reales, se desea dejar más claro cómo la utilización de la

guía metodológica para el diseño de aplicaciones Web en comercio electrónico,

ISC-2002-2-41

131

expuesta como resultado de la investigación es aplicable o no a modelos de negocios en

comercio electrónico, pero en especial al modelo B2B. Sin embargo, sólo la práctica y

la experiencia con los diferentes tipos de empresa podrán dar el veredicto final acerca de

las reales ventajas o desventajas de la aplicación de la guía, con esto se quiere dejar en

claro que aunque esta metodología pretender agregar formalismo al diseño de las

aplicaciones Web, no es la única manera de construir un diseño y que posiblemente en

todos los casos no se requiera la utilización total y al pie de la letra de la guía, puesto

que los negocios que son la base u origen de las aplicaciones de comercio electrónico

cambian rápidamente y sus requerimientos funcionales y no funcionales también. Claro

está, que la posibilidad de realizar cambios sobre la guía es posible en cuanto la

flexibilidad no altera su condición formal en una construcción de diseño bien elaborada.

Dichos cambios, hacen referencia a la incorporación o eliminación de elementos de

acceso y presentación, por ejemplo, se podría anexar elementos de acceso que

representen una navegación aleatoria sobre un determinado conjunto de objetos, o por el

contrario eliminar elementos de acceso como los índices cuando toda la navegación se

quiere hacer en orden secuencial.

Debido a que la ingeniería Web esta en continuo desarrollo y evolución, la guía

metodología expuesta no se encuentra exenta de ser modificada en trabajos futuros,

incluso por las razones mencionadas en el párrafo anterior. Además, existen aspectos

que deben ser integrados a corto plazo como por ejemplo, las bases de datos y los

sistemas distribuidos, así mismo, se debe abrir espacio a futuros desarrollos de sistemas

hypermedia para la personalización de aplicaciones, es decir, adaptar la presentación o

navegación de acuerdo al interés, preferencias o conocimientos del usuario. Estas

ISC-2002-2-41

132

adaptaciones pueden estar basadas en la información capturada por agentes que

observan la conducta del usuario. Por otro lado, las herramientas de diseño UML son

buenas en cuanto a la realización del diseño, pero no en cuanto al incremento de la

capacidad para generar verificación automatiza de los modelos, para soportar el uso de

patrones. Por tanto, aún hay mucho trabajo por realizar en la disciplina de ingeniería

Web

ISC-2002-2-41

133

CONCLUSIONES GENERALES

En la primera parte de éste trabajo se expone tecnologías Web y las arquitecturas que

facilitan las operaciones de comercio electrónico. Con esto, se pretende describir el

soporte actual o la infraestructura general sobre la cual se trabaja en comercio

electrónico, y sus modelos de negocio, además de los aspectos implícitos que genera

una transacción comercial en el mundo Internet. Dichos aspectos como los protocolos

de seguridad, los mecanismos básicos de encripción, y los medios de pago, son

analizados desde un punto de vista general, con lo cual se desea dejar a libre disposición

de elección el uso de cada una, dependiendo de las necesidades del negocio. Igualmente,

se proponen consejos acerca del uso del contenido en los sitios Web de comercio

electrónico, a través de la búsqueda de valor agregado en la etapa inicial, transaccional y

relacional.

En el contexto Colombiano, muchas de las tecnologías, especialmente las que se

refieren al manejo de integración de aplicaciones se encuentran al alcance de la mayoría

de los desarrolladores de software, por tanto, el desarrollo de aplicaciones por

componentes generan grandes expectativas, en cuanto que la posibilidad de interacción

con otros sistemas es más fácil. No obstante, la cultura de comercio electrónico en el

país aún es muy inmadura respecto a su entorno, por lo cual es imperante que las

empresas colombianas comiencen a integrar y desarrollar aplicaciones que permitan

ISC-2002-2-41

134

incrementar el uso de tecnología de información para la realización de transacciones

comerciales o para el intercambio de información necesaria para los negocios. De la

misma manera, las entidades financieras deben preocuparse por generar confianza en los

usuarios que deseen utilizar los medios electrónicos de pago.

Durante el desarrollo de la guía metodológica para el desarrollo sistémico de

aplicaciones, se utiliza un ejemplo del modelo de negocio B2B concerniente a la

industria del mueble. Con el ejemplo, se mostró la aplicación de la guía a un caso

hipotético, pero muy semejante a como funciona en la vida real, utilizando los modelos,

elementos de navegación, de acceso, de presentación y sus composiciones propuestas

para llevar a cabo el diseño de las aplicaciones Web, cuya validez fue analizada último

capitulo de éste trabajo.

Al momento de iniciar un proyecto de diseño de aplicaciones Web para comercio

electrónico, se valoran aspectos tecnológicos y económicos, que pueden aportar pero no

sustentar el éxito de la empresa, debido a la imperante necesidad de usar todos éstos

aspectos en la correcta administración del negocio. La definición adecuada de los

alcances del negocio, así como la determinación del mercado objetivo influyen en el

diseño y desarrollo de la aplicación Web. En el caso concreto del modelo de negocio

B2B, el diseño genera las bases sólidas para su posterior implementación, muy parecido

con lo que sucede en el desarrollo de aplicaciones no Web, pero con requerimientos no

funcionales más estrictos debido a que Internet aún es un medio hostil para desarrollar

proyectos de comercio electrónico. La funcionalidad del sistema se liga lógicamente a

los modelos conceptuales, de navegación, de presentación estática y dinámica que

ISC-2002-2-41

135

sistemáticamente y en un proceso bien definido, permiten alcanzar los beneficios

requeridos por la empresa y los usuarios.

El diseño debe proveer fortalezas para que los procesos sean eficientes y la información

generada por cada uno de los participantes en un proyecto B2B, sea fácil de manejar

desde el principio cuando se plantean los casos de uso y los requerimientos funcionales.

Con éstas bases es posible desarrollar con mayor rapidez los modelos siguientes, no

obstante, la versatilidad que brinda el uso de elementos de acceso y presentación pueden

ayudar a mejorar algunas inconsistencias en aquellas primeras etapas.

La guía metodología planteada está vinculada a procesos de modelos de negocios que

requieren ser automatizados con el objetivo común de minimizar los costos

operacionales y de aumentar la productividad de los mismos, por eso, el estudio de los

procesos, su medición y en general la optimización es la clave para que posteriormente

la aplicación de la guía metodológica genere los resultados deseados. Otro aspecto

importante es la duración del desarrollo de proyectos, puesto que la tecnología en

Internet avanza rápidamente, según estimaciones un año normal equivale a tres meses

en tiempo de tecnología Internet, y es posible que en muy corto tiempo después de

haber terminado el proyecto sea necesario realizar una migración hacia nuevas

tecnologías, de ahí, la importancia de definir formalmente los requerimientos

funcionales y no funcionales, así como todo el ciclo de desarrollo para que a futuro la

migración sea factible en términos de tiempo y costos, evitando comenzar desde cero en

el proceso de desarrollo de las aplicaciones Web.

ISC-2002-2-41

136

También es necesario reconocer que en Colombia sólo hasta ahora está empezando a

otorgarse importancia al trabajo planificado, es decir, la realización de cronogramas y

en general la administración de proyectos de desarrollo de aplicaciones. Con todos estos

factores en mente, es vital resaltar que las metodologías rígidas utilizadas en el

desarrollo de aplicaciones encargadas de automatizar los procesos de los negocios, no

son muy útiles en cuanto, no permiten realizar ajustes rápidos y efectivos en el

momento que cambien las condiciones de los negocios. La guía metodológica planteada

no pretende cubrir todos los casos posibles, puesto que la idea es adaptar la metodología

a las necesidades del negocio, de esta manera, no es imperante seguir paso a paso toda

la guía, para permitir alteraciones según la conveniencia y la experiencia del diseñador.

El equipo de trabajo de diseño y desarrollo debe crecer y experimentar con la

metodología, es decir, es importante realizar evaluaciones constantes acerca del

funcionamiento y eficacia de la implementación de la guía, para reforzar las fallas o

emplear ajustes necesarios para permitir la adecuación de la misma a la misión de la

empresa. Respecto al diseño, no es necesario reinventar todo de nuevo, es decir, puede

resultar buena práctica reutilizar las ideas de problemas ya resueltos y adaptarlos a las

necesidades que aparezcan, con esto, se destaca la importancia de usar patrones para

abstraer escenarios de aplicación.

Durante la experiencia de investigación para la realización de este trabajo, se encontró

que la necesidad de utilizar metodologías para las aplicaciones Web, es una necesidad

creciente, en cuanto el avance de las tecnologías Internet es acelerado y en la etapa de

diseño de la aplicación se requiere mantener un ritmo de crecimiento muy parecido al de

ISC-2002-2-41

137

las tecnologías, por eso, se mantiene la expectativa de que la guía metodológica

funcione eficazmente en el objetivo de sostener con eficiencia la etapa del diseño de

aplicaciones Web.

REFERENCIAS

[1] Mauricio Ruiz Valdivieso, Internet en las organizaciones modernas, Editorial AlfaOmega, primera edición de (2002). [2] Maria Luisa Solé Moro, Comercio Electrónico: Un mercado en expansión, Escuela superior de gestión comercial y marketing. Madrid (2000). [3] Jacobson I., Booch G., & Rumbaugh J. (1999). The Unified Software Development Process. Addison Wesley (1999). [4] Karl E.Wiegers, Software Requirements. Microsoft (1999). [5] Douglas F. Aldrich, Mastering the Digital Marketplace (Practical strategies for competitiveness in the new economy). John Wiley & Son (2002). [6] Rolf Hennicker, Systematic Design of Web Applications with UML. Institute of Computer Science. Ludwig-Maximilians University of Munich. [7] Nora Koch, Systematic Design of Web Applications with UML. F.A.S.T. Applied Software Technology GmbH.

[8] Jacobson I., Booch G., & Rumbaugh J. (1999). The Unified Software Development Process. Addison Wesley (1999). [9] Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modeling Language User Guide. Addison-Wesley (1999) [10] Sistemas extranets y comercio electrónico B2B, Juan Carlos Cardenas, John Romero [11] María José Ortín, Jesús García Molina, Begoña Moros, Joaquín Nicolás Grupo de Investigación de Ingeniería del Software, El Modelo De Negocio Como Base Para El Modelo De Requisitos [12] www.xmlglobal.com [13] www-3.ibm.com/software/webservers/commerce/wcs_pro/ [14] www.tornadostore.com

ISC-2002-2-41

138

[15] www.intershop.com [16] www.infor.uva.es/~jvegas/cursos/buendia/pordocente/node23.html [17] http://www.bredemeyer.com/use_cases.htm [18] http://www.korson-mcgregor.com/publications/korson/usecase3/index.html