Willydev Especializacion Msf

ESPECIALIZACIÓN DE MSF PARA EL DESARROLLO BASADO EN COMPONENTES DE UN SISTEMA COLABORATIVO Luis E. Mendoza1 , Anna Grimán 1 , María Pérez 1

RESUMEN El Desarrollo Basado en Componentes permite la construcción y el mantenimiento de sistemas a bajo costo, de entrega más rápida y de calidad, ya que el diseño de nuevos sistemas se basa en componentes implementados y probados en otros sistemas. El objetivo de este artículo es proponer una especialización de la metodología Microsoft® Solution Framework (MSF) para el Desarrollo Basado en Componentes de un Sistema Colaborativo. Esta especialización consiste en la definición de una serie de artefactos que sirven para documentar por completo el desarrollo de los componentes que conforman este tipo de sistemas. Además, se presenta el desarrollo del tipo de componente Smart Tags, y la elaboración de los artefactos pautados por la especialización de MSF para construir el Sistema Colaborativo que se desarrolló como Estudio de Caso de la investigación. Palabras Claves: Desarrollo basado en componentes, Sistemas colaborativos , Metodologías de desarrollo, Artefactos, Estudio de Caso.

ABSTRACT The Component-Based Development allows the construction and maintenance of systems at low cost, of quicker delivery and of quality, since the design of new systems is based on implemented and proven components in other systems. The objective of this article is to propose a specialization of the methodology Microsoft® Solution Framework (MSF) for the Components-Based Development of a Collaborati ve System. This specialization consists on the definition of a set of artifacts that serves to document completely the development of the components that conform this type of systems. Also, the Smart Tags component development, as well as the elaboration of the artifact averaged by the specialization of MSF to build the Collaborative System that was developed like case study of this research. Keywords: Study.

1

Components -Based Development, Collaborative Systems, Development Methodologies, Artifacts, Case

Laboratorio de Investigación en Sistemas de Información (LISI). Departamento de Procesos y Sistemas, Universidad Simón Bolívar. Apartado Postal 89000, Caracas 1080-A. Caracas - Venezuela. Telef.: +58 (212) 906.4017 / 3328 / 3314 / 3304. Fax: +58 (212) 906.4017 / 3303. E-mail: {lmendoza, agriman, movalles} @usb.ve

1. INTRODUCCIÓN Cuando se revisa el conjunto de aplicaciones que se encuentran disponibles dentro de una organización, nunca falta el e-mail, las intranets, las agendas electrónicas, entre otros; es decir, software que soporta y mejora la comunicación, la coordinación y la colaboración entre equipos y grupos de trabajos interconectados (7), pero a veces las mismas no están integradas de tal manera que logren la conformación de un Sistema Colaborativo (SC) que beneficie el negocio. Bajo esta realidad, la integración de aplicaciones a través de la reutilización de componentes, ha venido a ser una respuesta a esta problemática, ya que los diseños de nuevos sistemas se basan en componentes implementados y probados en otros sistemas (8). El Desarrollo Basado en Componentes (DBC) es un enfoque en donde los sistemas son un activo para las organizaciones y la reutilización de estos activos es esencial para incrementar el retorno de los costos de desarrollo (9). Ahora bien, por lo complejo que puede resultar el desarrollo de un SC, se precisan metodologías sistemáticas que conduzcan a la construcción de un producto eficaz y permitan la incorporación del DBC como parte del proceso de desarrollo, ya que este último tiene la ventaja de adaptarse fácilmente a distintos modelos de desarrollo (9), así como permitir la construcción y el mantenimiento de sistemas a bajo costo, de entrega más rápida y de calidad (8,9). En este sentido, Microsoft® Solution Framework (MSF) es una metodología abierta que permite su especialización para cada desarrollo en particular, lo cual puede posteriormente extenderse para desarrollos similares (5). Sobre la base de las ideas expuestas anteriormente, en este artículo se presenta la especialización de esta metodología para el DBC de un SC. En primer lugar, se discutirá lo que engloba un SC y el DBC, algunas características de la tecnología utilizada para los SC y las especificaciones generales de MSF. Posteriormente, se mostrará la especialización hecha a MSF, a través de la elaboración de todos los artefactos propuestos para uno de los componentes del SC desarrollado: los componentes tipo Smart Tags. Seguidamente, se muestran brevemente los otros componentes del SC construidos con la misma especialización de MSF, con la finalidad de que el lector tenga una idea completa de la magnitud y las funcionalidades del SC desarrollado. Finalmente, se plantean las conclusiones del trabajo realizado.

2. SISTEMAS COLABORATIVOS Y DESARROLLO BASADO EN COMPONENTES Para destacarse en el mercado actual las organizaciones se aseguran de que todos los grupos de trabajo de la compañía colaboren entre sí oportunamente (1). Compartir información permite organizar y administrar proyectos o tareas de forma más eficiente e incrementar la productividad. Por esto, las empresas buscan, a través de la integración de las nuevas tecnologías con las ya existentes en la organización, mantener al alcance de sus empleados información precisa, útil y actualizada (10). Además, los SC no sólo aumentan los niveles de productividad y competitividad de una empresa, sino que también ayudan a eliminar ciertos procesos del negocio que a corto plazo conllevan a una gran reducción de costos y a una mejora significativa en el desempeño de los trabajadores (7,11). “Un sistema colaborativo es una aplicación que hace más fácil la tarea de compartir información entre usuarios y dentro de los equipos de trabajo, ayudándolos a comunicarse y a trabajar unidos de manera más efectiva y eficiente” (2). Por su parte, O’Brien indica que estos sistemas “proveen herramientas que nos ayudan a colaborar -comunicar ideas, compartir recursos y coordinar nuestro esfuerzo de trabajo cooperativo- como miembros de muchos procesos formales e informales, de equipos de proyectos y de grupos de trabajo que están surgiendo en las organizaciones de hoy día” (7). Los SC son también la integración de las aplicaciones existentes en la organización, a fin de compartir e intercambiar información para maximizar los beneficios de las inversiones en Tecnologías de la Información (TI) (4). En otras palabras, los SC integran las aplicaciones de groupware (7) (e-mail, grupos de discusión, bases de datos, gerencia de tareas, agendas electrónicas, videoconferencias, entre otros) existentes en una organización a fin de compartir e intercambiar información, para maximizar los beneficios de las inversiones en TI. Sin embargo, a veces las mismas no están integradas de tal manera que logren la conformación de un SC que beneficie el negocio. Partiendo del hecho de que a veces se cuenta con aplicaciones implantadas dentro de las organizaciones, pero éstas no responden cabalmente a las necesidades del negocio, la integración de aplicaciones a través de la reutilización de componentes ha venido a ser una respuesta a esta problemática, ya que el diseño de nuevos sistemas se basa en componentes implementados y probados en otros sistemas (8). El Desarrollo Basado en Componentes (DBC) es un enfoque en donde los sistemas son un activo para las organizaciones y la

Partir del enfoque de DBC para construir SC permite que éstos sean óptimo s, donde el intercambio de información esté integrado al máximo y, además, se disponga de las herramientas adecuadas para visualizar y distribuir esta información rápidamente con la mayor eficacia y coherencia posible (2,4,7,11).

3. MICROSOFT® SOLUTION FRAMEWORK Microsoft® Solution Framework (MSF) es considerado más un marco de trabajo que una metodología, debido a que es flexible y abierto que puede ser adaptado para ajustarse a los requerimientos y necesidades particulares de una organización (5,6). MSF está compuesto por 6 modelos que promueven principios como la planificación orientada a riesgos, lanzamiento de versiones, hitos (“milestones”) visibles, etc. Estos modelos son (5): (1) Arquitectura Empresarial; (2) Equipo; (3) Proceso; (4) Gestión de Riesgo; (5) Diseño de Componentes ; y (6) Aplicación. Para efectos de los intereses de este artículo, se presentan con más detalle los modelos que serán especializados : el Modelo de Proceso y el Modelo de Diseño de Componentes .

El Modelo de Proceso de Desarrollo de MSF describe un ciclo de vida que puede ser usado para desarrollar software de manera exitosa, estableciendo el orden en el cual se deben realizar las actividades (6). Como puede verse en la Figura 1, este modelo consiste en cinco fases distintas, cuyos nombres dependen del tipo del proyecto en el que se aplica. Cada fase del proceso de desarrollo culmina con un hito visible, tal como se describe a continuación (6): a) Fase 1: Visión. En esta fase el equipo y el cliente definen los requerimientos del negocio y los objetivos generales del proyecto. La fase culmina con el hito Visión y Alcance aprobados. Implantación completa Fa s Vis e de ión

de se ión Fa ntac la p Im

Release Readiness aprobado

Visión/ Alcance aprobado

e de Fas ización abil Est

Ahora bien, desarrollar un SC no es tarea fácil, ya que se deben integrar muy bien los requerimientos de información de los usuarios con las fuentes de información disponibles a lo largo de una organización, las cuales en la mayoría de las ocasiones están en plataformas, formatos y tecnologías diferentes (7,11). Es por ello que es necesario contar con una metodología de desarrollo que tome en cuenta esta realidad y facilite la integración, la documentación y la satisfacción de los requerimientos de los usuarios, de la organización y tecnológicos, de la mejor manera posible y a través de los beneficios del DBC, el cual permite integrar con mayor facilidad las TI existentes dentro de una organización. Bajo estas premisas es que este artículo propone una serie de artefactos a ser incorporados a MSF, con la finalidad de refinarl a y soportar el enfoque de DBC de SC. Cabe destacar que aunque MSF es muy utilizada, es poco precisa, por lo que permite fácilmente la incorporación el enfoque de DBC y de artefactos que la refinen con vista a soportar el desarrollo de este tipo particular de sistema.

3.1. Modelo de Proceso de Desarrollo de Aplicaciones MSF

Alcance completo

Fas Plan e de eació n

reutilización de estos activos es es encial para incrementar el retorno de los costos de desarrollo. El DBC permite la construcción y el mantenimiento de sistemas a bajo costo, de entrega más rápida y de calidad (8,9).

Fase de Desarrollo

Plan del Proyecto aprobado

Figura 1. Modelo de Proceso de Desarrollo de Aplicaciones MSF (6).

b) Fase 2: Planeación. Durante la fase de planeación el equipo crea un borrador del plan maestro del proyecto, además de un cronograma del proyecto y de la especificación funcional del proyecto. Esta fase culmina con el hito Plan del proyecto aprobado. c) Fase 3: Desarrollo. Esta fase involucra una serie de releases internos del producto, desarrollados por partes para medir su progreso y para asegurarse que todos sus módulos o partes están sincronizados y pueden integrarse. La fase culmina con el hito Alcance completo . d) Fase 4: Estabilización. Esta fase se centra en probar el producto. El proceso de prueba hace énfasis en el uso y el funcionamiento del producto en la s condiciones del ambiente real. La fase culmina con el hito Release Readiness aprobado. e) Fase 5: Implantación: En esta fase el equipo implanta la tecnología y los componentes utilizados por la solución, estabiliza la

implantación, apoya el funcionamiento y la transición del proyecto, y obtiene la aprobación final del cliente. La fase termina con el hito Implantación completa.

3.2. Implantación del Modelo de Desarrollo de Componentes MSF La estructura de este modelo provee un continuo para las actividades del proyecto relacionadas con el diseño, a través del diseño conceptual, el diseño lógico y el diseño físico, de la aplicación que se está construyendo (5). Las fases y los documentos del diseño conceptual, lógico y físico, proveen tres perspectivas diferentes para cada una de las 3 audiencias: los usuarios, el equipo y los desarrolladores. Por lo tanto, el uso de este modelo ayuda a garantizar que una aplicación no se desarrolle sólo para satisfacer una necesidad tecnológica sino también para cubrir las necesidades del negocio y de los usuarios (5). Este modelo se relaciona con el Modelo de Proceso MSF en la Fase 2 - Planeación, ya que las fases del diseño de componentes ocurren en la Planeación como parte del desarrollo de la especificación funcional de la aplicación (5) . De esta manera, este modelo provee la base para el cronograma y el plan de la Fase 3 – Desarrollo, del Modelo de Proceso MSF. La Figura 2 muestra la relación entre ambos modelos; es decir, cómo se van ejecutando las actividades de diseño conceptual, lógico y físico, del Modelo de Desarrollo de Componentes, dentro del Modelo de Proceso. Visión Aprobada

Plan del Proyecto Aprobado

Diseño Conceptual Diseño Lógico Diseño Físico

Línea base del Diseño Conceptual

Línea base del Diseño Lógico Línea base del Diseño Físico

Figura 2. Las líneas base del diseño en la Fase de Planeación MSF (5). Sobre la base de los modelos descritos anteriormente, el presente artículo propone una especialización de MSF para la construcción de componentes soportado por el enfoque DBC de un SC, a través de la definición y la presentación de una serie de artefactos, específicamente para las Fases 1 y 2 del Modelo de Procesos y para las actividades del Modelo de Desarrollo de Componentes. Se hace énfasis en las Fases 1 y 2 del Modelo de Procesos, debido a que ellas son las etapas tempranas del Ciclo de Vida de

desarrollo, permitiendo así documentar los componentes del SC desde un principio, aplicando todos los conceptos asociados al enfoque DBC, y tomar decisiones oportunas a bajo costo y con poco riesgo.

4. ESPECIALIZACIÓN DE MSF PARA LA CONSTRUCCIÓN DEL SC A continuación se presentan para cada una de las fases del Modelo de Proceso y del Modelo de Desarrollo de Componentes, los artefactos propuestos a través de la construcción del SC utilizado como estudio de caso. Para efectos de este artículo, sólo se mostrará la construcción de un componente central del SC desarrollado: los Smart Tags. Un Smart Tag es un componente que reconoce de manera dinámica cierto tipo de informa ción en Microsoft® Office XP (3). Este tipo de componente trabaja en background (segundo plano) para detectar la presencia de términos en el documento de Microsoft® Word o en la hoja de cálculo de Microsoft® Excel . Un término es un dato que coincide con alguno de los patrones que han sido predefinidos por los programadores. Cuando un término es reconocido, se marca con un indicador que le brinda al usuario una forma rápida y fácil de acceder a las acciones correspondientes a ese patrón de datos (3). Para ilustrar la especialización realizada, sólo se incluirán los artefactos que se desarrollaron y que se considera n claves para el desarrollo de este componente del SC; y a su vez, sirvieron de base para la validación del mismo por parte de los usuarios.

4.1. Fase 1 - Visión Para determinar cuáles eran los objetivos de esta etapa, fue preciso especificar la Visión y el Alcance del proyecto y definir los roles que componen el Modelo de Equipos del MSF. Los artefactos propuestos que conforman el documento de Visión Aprobada, así como sus descripciones, se sintetizan en la Tabla 1. Posteriormente, se presentan los aspectos más importantes de los mismos para el caso de los componentes tipo Smart Tags. Planteamiento del Problema : Los Ingenieros de Sistemas (IS) de la unidad de Soporte Pre-Venta de la empresa X de Venezuela consideran que es posible mejorar la manera en que generan reportes y documentos, al hacer más accesible la información que manejan diversos repositorios de datos ya existentes en la organización. Actualmente, cada vez

que una persona escribe algún documento en Microsoft® Word y/o Excel y requiere consultar información almacenada en SETrack (base de datos de la aplicación que maneja las actividades realizadas por los IS en los proyectos), SEsAR (base de datos de la aplicación que maneja los Requerimientos de Actividades a los IS) o en el Microsoft® Active Directory TM , debe invertir tiempo en cambiar de aplicación y hacer la búsqueda. Una vez obtenida la información deseada, el usuario regresa a Word o Excel para continuar elaborando el documento. Esta tarea se torna especialmente tediosa cuando se necesita preparar reportes como “Historial de Proyectos” de una cuenta o cliente en particular o de un Ingeniero de Sistema. Tabla 1. Artefactos propuestos para la Fase 1 – Visión. Artefacto

Descripción

Planteamiento del Problema

Indica el problema u oportunidad del negocio.

Visión de la Solución

Describe la propuesta de solución.

Metas del Proyecto

Presenta los objetivos específicos a ser alcanzados con la solución.

Matriz de Tradeoffs del Proyecto

Presenta el balance adecuado entre recursos, cronograma y requerimientos.

Roles y Equipo de Trabajo

Indica el personal responsable de la ejecución del proyecto.

Alcance

Establece las funciones que realizará el sistema.

Lista de Riesgos

Identifica los eventos inesperados y la planificación de contingencias.

Esquema de la solución

Describe el escenario de uso de la solución propuesta.

Visión de la Solución: Incluir algunos componentes tipo Smart Tags en Microsoft® Office XP permitirá hacer más eficiente y productiva la manera en que el personal de diversas unidades de la empresa X de Venezuela elabora documentos y trabaja con Microsoft® Word o Microsoft® Excel; especialmente cuando requieren hacer uso de información almacenada en SETrack, SEsAR e incluso en el Microsoft® Active Directory TM de la empresa. Metas del Proyecto: Se espera que la inclusión de los nuevos componentes tipo Smart Tags en Microsoft® Office XP logre: (1) reducir el tiempo de elaboración de reportes, (2) minimizar el número de aplicaciones a consultar para obtener información específica o para realizar ciertas actividades , y (3) unificar el formato básico de los reportes. Matriz de Tradeoffs del Proyecto: La Tabla 2 muestra

la Matriz de Tradeoffs de los componentes tipo Smart Tags que forma parte del Documento de Visión Aprobada de esta etapa. Un Tradeoff es un cambio en alguno de los elementos -recursos, cronograma o requerimientos- que requiere que el equipo de trabajo haga ajustes en los otros elementos para mantener el balance del proyecto, incluso, potencialmente podría modificarse el mismo elemento al cual se le hizo el primer cambio (5,6). Tabla 2. Matriz de Tradeoffs propuesta y aplicada a los componentes tipo Smart Tags. Restricción por optimizar

Restricción negociable

Restricción aceptada

Recursos Cronograma Requerimientos

En la Tabla 2 se indica que durante esta Fase, el Equipo de Desarrollo aceptó los recursos con los que disponía para llevar a cabo el proyecto, mientras que el cronograma propuesto quedó abierto a posibles cambios junto con el conjunto de requerimientos finales del producto, que pueden aparecer durante las siguientes fases. Roles y Equipo de Trabajo: Se asignó el personal que cumpliría los siguientes roles: Líder del Proyecto, Líder del Producto, Desarrollo, Programa y Logística, Prueba y Educación al Usuario. Alcance: Los componentes tipo Smart Tags deben: (1) ser fáciles de instalar y de usar; (2) reconocer los distintos estados de las actividades de SEsAR y generar automáticamente reportes; (3) reconocer el alias de los distintos Gerentes de Cuenta (GC) de SETrack y ofrecer acciones como: ver las cuentas que maneja y obtener el nombre del GC desde el Microsoft® Active Directory TM; (4) reconocer el alias de los distintos GC de SEsAR y ofrecer la posibilidad de generar el Historial de Actividades Aprobadas; (5) reconocer el alias de los distintos IS de SETrack y ofrecer acciones como: generar historial de actividades, obtener nombre desde el Microsoft® Active Directory TM , etc.; y (6) reconocer el nombre de las distintas cuentas o clientes que se manejan en SETrack y ofrecer acciones como: generar historial de actividades en un cliente, ver productos Microsoft® en un cliente, etc. Lista de Riesgos: En la Tabla 3 se muestra, a manera de ejemplo, la descripción de uno de los posibles riesgos que pueden interferir con la culminación

exitosa del proyecto. Para cada uno de ellos se definió su Probabilidad, su Impacto y su Prioridad. MSF propone que los riesgos de mayor prioridad deben ser atendidos antes que los otros. Tabla 3. Posibles Riesgos durante el desarrollo de los componentes tipo Smart Tags. Condición / Descripción

No se tiene acceso oportuno a la información y al diseño de los repositorios de datos de los que se necesita hacer uso.

Consecuencia

Retraso en la entrega del producto final y/o entrega incompleta del producto.

Probabilidad

0 (Bajo)

Impacto

3 (Alto)

Prioridad

0

Mitigación

El líder del proyecto debe identificar a la(s) personas encargadas de proveer esta información y solicitar su pronta atención .

Tabla 4. Actividades propuestas para realizar el Modelo de Componentes dentro de la Fase 2 – Planeación. Actividad Diseño Conceptual Diseño Lógico Diseño Físico

Artefacto

AD

Smart Tags

Otras aplicaciones

Usuario

Especifica las restricciones tecnológicas de la solución.

Tabla 5. Artefactos propuestos para el Diseño Conceptual.

Esquema de la solución: La Figura 3 muestra de manera esquemática los componentes propuestos; en ella se destaca que los componentes se orientan a que el usuario pueda interactuar con distintos repositorios de datos (SEsAR, SETrack y el Microsoft® Active Directory TM de la corporación) y diversas aplicaciones, directamente desde un documento de Microsoft® Word y/o Excel en Microsoft® Office XP, a través del uso de un conjunto de componentes tipo Smart Tags.

SETrack .

Organiza los componentes de la solución.

a) Diseño Conceptual: El objetivo de esta actividad es comenzar a originar el concepto de la solución propuesta en el documento de Visión Aprobada. Se propone que el diseño conceptual esté compuesto por los artefactos indicados en la Tabla 5.

Perfil de los Usuarios

SEsAR .

Descripción Establece los conceptos que especifican las necesidades de los usuarios.

Figura 3. Esquema de los componentes tipo Smart Tags.

4.2. Fase 2 – Planeación Luego de establecer y definir la Visión de los componentes y el Alcance del proyecto, el siguiente paso fue elaborar la especificación funcional, para lo cual se llevaron a cabo las actividades descritas en la Tabla 4. A continuación se presentan los puntos más importantes de la especificación funcional de esta etapa, indicando los artefactos propuestos para cada documento, así como su descripción.

Escenarios de Uso

Descripción Especifica la ubicación, las capacidades y las expectativas, de los usuarios. Describen qué sucede en la ejecución de una tarea en particular; especifican cómo son los procesos, las funciones y los procedimientos.

Ejemplos de estos artefactos para el caso de los componentes tipo Smart Tags se presentan a continuación. a.1) Perfil de los Usuarios: Del documento de Visión Aprobada se desprende que en este sistema existe un usuario, cuyo perfil se describe a continuación: • Ubicación: Cualquier lugar con acceso a la intranet de la corporación. • Capacitación: Habilidad y experiencia media en el uso y manipulación de documentos elaborados en Microsoft Office, especialmente de la versión XP. Habilidad para usar un programa navegador para Internet. • Expectativas: Contar con componentes tipo Smart Tags que faciliten elaborar reportes y obtener información de las Bases de Datos (SEsAR y SETrack). Además, poder interactuar con otras aplicaciones desde un documento de Microsoft® Word y/o Excel. a.2) Escenarios de Uso: Los escenarios de uso de este componente del SC dependen de las acciones ofrecidas por cada componente tipo Smart Tags. Por lo tanto, es necesario definir todos los escenarios de cada uno de los componentes tipo

Smart Tags que formarán parte del SC. Para efectos de este artículo se describen sólo las acciones del Smart Tag GC de SETrack y se especifican todos los escenarios de uso que se derivan de él (ver Tabla 6). Tabla 6. Descripción, Acciones y Escenarios de uso del Smart Tag GC SETrack. Descripción Reconoce el alias de cada uno de los GC que figuran en la tabla GC de SETrack. Escenarios de uso Mostrar las cuentas del GC

Reemplazar con el nombre completo del GC

Mostrar el nombre completo del GC

Enviar un e-mail al GC

Post-condición:

campo “Para:”. 2. El usuario inserta el titulo del mensaje y redacta el e- mail. 3. El usuario hace click sobre el botón de “Enviar” de la ventana. 4. Se envía el e-mail al GC. El e-mail es enviado.

Acciones Mostrar las cuentas del GC. Reemplazar con el nombre completo del GC. Mostrar el nombre completo del GC. Enviar un e-mail al GC. Especificación Poder visualizar el número de identificación (ID) y el nombre de cada cuenta que maneja el GC. Actor: Usuario. Pre-condición: Se reconoció una palabra como un alias y se señaló como Smart Tag. Descripción: 1. Se presenta la información en una caja de mensaje. 2. El usuario cierra la caja de mensaje luego de leer la información. Post-condición: La información se le muestra al actor desde una caja de mensajes. Intención: Poder intercambiar el alias por el nombre completo del GC tal como apare ce en el Microsoft® Active DirectoryT M. Actor: Usuario. Pre-condición: Se reconoció una palabra como un alias y se señaló como Smart Tag. Descripción: 1. Se inserta el nombre del GC justo donde estaba escrito el alias, sobrescribiéndolo. Post-condición: El nombre completo del GC. Intención: Poder visualizar el nombre completo del GC tal como aparece en el Microsoft® Active DirectoryT M. Actor: Usuario. Pre-condición: Se reconoció una palabra como un alias y se señaló como Smart Tag. Descripción: 1. Se presenta la información en una caja de mensaje. 2. El usuario cierra la caja de mensaje luego de leer la información. Post-condición: La información se le muestra al actor desde una caja de mensajes. Intención: Poder redactar y enviar un e-mail al GC. Actor: Usuario. Pre-condición: Se reconoció una palabra como un alias y se señaló como Smart Tag. Descripción: 1. Se presenta una ventana de “Mensaje nuevo” de Outlook, con la dirección de email del GC en el Intención:

b) Diseño Lógico: Para esta activ idad de diseño se establece la estructura y la comunicación de los elementos de la solución. El conjunto de artefactos propuestos para esta actividad son descritos en la Tabla 7. En esta etapa no interesan los detalles de implementación física, lo importante es entender las partes que van a conformar el sistema y la interacción entre ellas (5). Tabla 7. Artefactos propuestos para el Diseño Lógico. Artefacto Diseño de la Interfaz de Usuario Componentes de la Solución Bases de Datos Lógica

Descripción Presenta los elementos y lineamientos que conforman el diseño de la interfaz de usuario. Establece los elementos involucrados en la solución, así como sus relaciones. Especificación lógica de las Bases de Datos que conforman o con las que interactúa la solución.

Ejemplos de estos artefactos para los componentes tipo Smart Tags del SC desarrollado, se presentan a continuación.

Figura 4. Muestra de los reconocedores de un Smart Tag. b.1) Interfaz de Usuario: Todos los componentes tipo Smart Tags que conforman la solución propuesta presentarán la misma interfaz que ofrece la tecnología de los componentes tipo Smart Tags (3). Es necesario que los componentes tipo Smart Tags y todas sus funciones (en este caso, las descritas en la Tabla 6) puedan ser empleadas desde documentos de Microsoft® Word y/o Excel. En la Figura 4 se muestra la interfaz que presentan los componentes tipo Smart Tags cuando detectan la presencia de un término. b.2) Componentes de la solución: El diagrama de los elementos que conforman la solución nuevamente depende de las acciones ofrecidas por cada componente tipo Smart Tag. En la

Figura 5 sólo se presenta y se explica el diagrama referente a las acciones y los escenarios de uso del Smart Tag GC SETrack (ver Tabla 6). En la Figura 5 se observan los elementos que conforman al Smart Tag GC SETrack y la relación entre ellos. Los elementos que deben desarrollarse son los siguientes:

Documento Word

Acciones del Smart Tags

“La actividad realizada por lchacon”

MicrosoftSchemaURN GC SETrack “Mostrar las cuentas del GC”

Reconocedores Smart Tags

“Reemplazar con el nombre completo del GC”

Otros Reconocedores

“Mostrar el nombre completo del GC”

Reconocedor GC SETrack

“Enviar un e-mail al GC”

c) Diseño Físico: En esta actividad de diseño se aplicaron las restricciones de la tecnología al Diseño Lógico de la solución. El conjunto de artefactos propuestos para esta actividad son des critos en la Tabla 8. Tabla 8. Artefactos propuestos para el Diseño Físico. Artefacto Restricciones de Tecnología

SETrack

Active Directory

Microsoft® Outlook

Descripción Especifica utilizada.

la

tecnología

Implementación de la Interfaz del Usuario

Muestra la apariencia de la solución.

Arquitectura de la solución

Presenta la vista de implantación de la solución.

Smart Tag GC SETrack

Figura 5. Diagrama de los elementos de la solución del componente tipo Smart Tag GC SETrack. • Reconocedor de GC SETrack: La rutina de reconocimiento de este elemento estará programada para que reconozca cadenas de caracteres (strings) que coincidan con los alias de los GC que figuran en la tabla GC de la base de datos SETrack. Por ejemplo de la siguiente oración “La actividad realizada por lchacon”, la palabra ‘lchacon’ será reconocida. • Acciones de GC SETrack: El reconocedor de GC SETrack (MicrosoftSchemaURNsetrackAM) tiene asociado 4 acciones que funcionan de manera similar desde Microsoft® Word y/o Excel. La Figura 5 muestra la interacción de cada acción con los otros elementos; por ejemplo, la primera acción Mostrar las cuentas del GC hace uso de la Base de Datos SETrack y devuelve la información al documento. b.3) Bases de Datos Lógica: Como se aprecia en al Figura 3, existen otros componentes de la solución de los que se harán uso como la Base de Datos SETrack, el Microsoft® Active DirectoryTM de la empresa y la aplicación Microsoft® Outlook. En este documento se plasma, entre otras cosas, el Diagrama E-R de las Bases de Datos (BD) que forman parte o interactúan con los componentes que se están diseñando; además, se establece claramente cómo son las relaciones entre las BD y todos los componentes del SC. Dadas las limitaciones de espacio y los compromisos de confidencialidad, no se realizará la descripción de estos elementos.

Ejemplos de estos artefactos para el caso de los componentes tipo Smart Tags se presentan a continuación.

Figura 6. Interfaz de usuario de los componentes tipo Smart Tags

c.1) Restricciones de Tecnología: (1) Todos los componentes tipo Smart Tags propuestos deberán ser desarrollados en Visual Basic 6.0; (2) en caso de que algunos de los elementos (acciones o reconocedor) de los componentes tipo Smart Tags, requiera conectarse a una Base de Datos, dicha conexión se hará usando ActiveX Data Object (ADO) 2.5; (3) las Bases de Datos SEsAR y SETrack se encuentran localizadas en un servidor SQL Server 2000 car-ts-01 (codificación interna de la empresa para los servidores ); y (4) los instaladores de los componentes tipo Smart Tags serán desarrollados en Visual Studio Installer. c.2) Interfaz de Usuario: Todos los componentes tipo Smart Tags que conforman la solución propuesta implementarán las interfaces ISmartTagAction y ISmartTagRecognizer (o frecida por la tecnología de los componentes tipo Smart Tags) (3), las cuales le permiten a las aplicaciones clientes

como Microsoft® Word y Microsoft® Excel, obtener toda la información necesaria para dar soporte y permitir visualizar los componentes tipo Smart Tags. La Figura 6 muestra la interfaz de usuario del Smart Tag. c.3) Arquitectura de la solución: La Figura 7 muestra la vista arquitectónica de implantación de la solución.

ActiveX Data Objects (ADO)

SETrack SEsAR

intranet / Internet

Microsoft® Office XP

que forman parte del SC desarrollado.

5. OTROS COMPONENTES DEL SC El objeto de esta sección es mostrar los otros componentes que se construyeron para lograr el SC deseado, con la finalidad de dar una idea más completa de todas las funcionales logradas con el SC desarrollado. Sólo se mostrarán 3 de los artefactos propuestos, para cada uno de los otros componentes del SC desarrollado: e l Planteamiento del Problema, la Visión de la Solución y el Esquema de la Solución. La presentación de estos artefactos permite visualizar fácilmente la potencialidad completa del SC.

car-ts-01

Figura 7. Vista arquitectónica de implantación de la solución de los componentes tipo Smart Tags.

in

“ n” productos en la Cuenta

Figura 8. Resultado de algunos componentes tipo Smart Tags.

4.3. Fase 3 – Desarrollo Para esta fase no se proponen artefactos ya que ésta abarca la implementación de la solución, la cual está condicionada por el documento de Diseño Físico. A lo largo de esta fase se realizaron una serie de releases internos que correspondían con cada uno de los componentes tipo Smart Tags desarrollados.

4.4. Fases 4 y 5 – Estabilización e Implantación Al igual que para la fase anterior, en estas fases tampoco se proponen artefactos ya que éstas abarcan las pruebas y la implantación de la solución; es decir, el lanzamiento completo de la solución; en este caso, los componentes tipo Smart Tags del SC. Con el objetivo de ilustrar el resultado logrado a lo largo del proyecto, en la Figura 8 se muestran algunas de las respuestas de dos de los componentes tipo Smart Tags

5.1. Workflow Planteamiento del Problema : Parte de la labor que realizan los IS en la unidad de Soporte Pre-Venta de la empresa X de Venezuela es apoyar a los GC en actividades que deben realizarse en los clientes, como: presentaciones, demostraciones, entrenamientos e instalación de productos. Actualmente los GC no siguen un proceso formal al momento de solicitar a los IS que realicen alguna actividad. Generalmente un GC se comunica con cualquiera de los IS personalmente, por teléfono o vía e-mail, a fin de explicar su necesidad de apoyo, luego dependiendo de lo acordado entre el IS y el GC se planifica la visita al cliente. Visión de la Solución: Los IS desean formalizar y automatizar el proceso de solicitud de actividades por parte de los GC, debido a que la manera en que se está llevando a cabo actualmente esta tarea genera inconvenientes, tales como: • escaso control sobre las actividades que realizan los IS. • no siempre se selecciona al IS ideal para la actividad propuesta. Esquema de la solución: En la Figura 9 se muestra de manera gráfica el esquema de la solución propuesta para la aplicación workflow.

Formulario

SE

SEsAR

Formulario

Reviewer

AM

Formulario

metodología Microsoft® Solution Framework empleados en esta investigación, por utilizar un enfoque iterativo, ofrecieron la flexibilidad necesaria para manejar exitosamente los cambios de requerimientos que surgieron a lo largo del todo el período del desarrollo y la incorporación del enfoque del DBC. Sin embargo, por ser una metodología tan abierta, fue necesaria la definición de artefactos específicos que permitiesen precisar las necesidades de los usuarios y las funcionalidades de los componentes del SC, bajo el enfoque del DBC.

Figura 9. Esquema de la solución de la aplicación de Workflow del SC desarrollado.

5.2. Portal Planteamiento del Problema: La unidad de Soporte Pre-Ventas de la empresa X de Venezuela crea, maneja y recopila un gran número de documentos e información cuya administración se ha tornado complicada. Realizar la búsqueda de un documento en específico es una tarea en la que se invierte un tiempo considerable, la colaboración entre IS para elaborar y revis ar documentos se lleva a cabo manualmente y no existe un sitio web unificado donde se organice, publique y comparta información entre todos los empleados de la unidad. Visión de la solución: Se requiere implantar un portal corporativo para dar solución a esta situación y garantizar una fácil integración de las aplicaciones que normalmente se emplean en el entorno laboral, como por ejemplo, Microsoft® Office. Esquema de la solución: En la Figura 10 se muestra el esquema de la solución propuesta. La idea principal es tener un servidor SharePoint Portal Server que hospede el portal corporativo y desde el cual se administren los archivos, documentos y demás orígenes de contenidos.

6. CONCLUSIONES Los modelos de procesos y de componentes de la

Figura 10. Esquema de la solución del Portal Corporativo del SC desarrollado.

Como resultado del SC desarrollado en esta investigación, se pudo corroborar que el DBC es un enfoque en donde los sistemas implantados dentro de una organización, que son un activo para éstas, pueden ser reutilizados fácilmente, incrementando el retorno de los costos de desarrollo. Además, el DBC permite la construcción y el mantenimiento de sistemas a bajo costo, de entrega más rápida y de calidad. Los artefactos propuestos y utilizadas para el desarrollo del SC, permitieron una definición completa y precisa de las funcionalidades y la documentación del sistema. El SC desarrollado logra mejorar el desempeño de los usuarios haciéndolos más competitivos, ya que estos tienen disponibilidad permanente de la información relacionada con las labores que usualmente necesitan realizar, integrando así las islas de información que anteriormente hacían más lento el trabajo.

AGRADECIMIENTOS Esta investigación fue financiada por el Fondo Nacional de Ciencia, Tecnología e Innovación (FONACIT) de la República Bolivariana de Venezuela, a través del proyecto S1-2001000792. Los autores desean agradecer a la Ing. J. Portillo por su colaboración y valioso aporte para la culminación de esta investigación.

REFERENCIAS [1] R. Hamman; “Introduction to Virtual Communities Research and Issue Two of Cybersociology”. Cybersociology Magazine, Vol. 2, Disponible en: http://www.cybersociology.com. Noviembre 1997. [2] Microsoft Corporation; “Collaboration Evaluation Guide Whitepaper”, Microsoft Corporation, Mayo 2001. [3] Microsoft Corporation; “Microsoft Office XP Smart Tag SDK 1.1.”, Microsoft Corporation, Available in: http://msdn.microsoft.com/msdn-files/027/001/652/Search.asp. May 2001. [4] Microsoft Corporation; “Microsoft Solutions: The Collaboration in Corporative World”, Microsoft Corporation, Marzo 1999. [5] Microsoft Corporation; “Microsoft Solution Framework White Paper”, Microsoft Corporation, Dic iembre 1999. [6] Microsoft Corporation; “MSF Process http://www.microsoft.com/msf/. June 2002.

Model

v.

3.1.

Microsoft

Corporation”,

Disponible

en:

[7] J.A. O’Brien; “Management Information Systems: Managing Information Technology in the E-Business Enterprise”, Fifth Edition. McGraw-Hill/Irwin, New York, 2001. [8] R. Pressman; “Ingeniería del Software: Un Enfoque Práctico”, Quinta Edición. McGraw-Hill/Interamericana de España, S.A., Madrid, 2002. [9] I. Sommerville; “Ingeniería de Software”, Sexta Edición. Addison Wesley Publishers Limited, México DF, 2002. [10] TechTarget, Inc; “whatis?com”, Disponible en: http://whatis.techtarget.com. Noviembre 2002. [11] E. Turban, J. Lee, D. King and M. Chung; “Electronic Commerce: a Managerial Perspective”, Prentice-Hall, Englewood Cliffs, New Jersey, 2000.