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: Components -Based Development, Collaborative Systems, Development Methodologies, Artifacts, Case
Study.

1
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 2. SISTEMAS COLABORATIVOS Y
DESARROLLO BASADO EN
Cuando se revisa el conjunto de aplicaciones que se
COMPONENTES
encuentran disponibles dentro de una organización,
nunca falta el e-mail, las intranets, las agendas
Para destacarse en el mercado actual las
electrónicas, entre otros; es decir, software que soporta
y mejora la comunicación, la coordinación y la organizaciones se aseguran de que todos los grupos de
trabajo de la compañía colaboren entre sí
colaboración entre equipos y grupos de trabajos
interconectados (7), pero a veces las mismas no están oportunamente (1). Compartir información permite
organizar y administrar proyectos o tareas de forma
integradas de tal manera que logren la conformación
más eficiente e incrementar la productividad. Por esto,
de un Sistema Colaborativo (SC) que beneficie el
las empresas buscan, a través de la integración de las
negocio. Bajo esta realidad, la integración de
nuevas tecnologías con las ya existentes en la
aplicaciones a través de la reutilización de
organización, mantener al alcance de sus empleados
componentes, ha venido a ser una respuesta a esta
información precisa, útil y actualizada (10). Además,
problemática, ya que los diseños de nuevos sistemas se
los SC no sólo aumentan los niveles de productividad
basan en componentes implementados y probados en
y competitividad de una empresa, sino que también
otros sistemas (8). El Desarrollo Basado en
ayudan a eliminar ciertos procesos del negocio que a
Componentes (DBC) es un enfoque en donde los
corto plazo conllevan a una gran reducción de costos y
sistemas son un activo para las organizaciones y la
a una mejora significativa en el desempeño de los
reutilización de estos activos es esencial para
trabajadores (7,11).
incrementar el retorno de los costos de desarrollo (9).
“Un sistema colaborativo es una aplicación que hace
Ahora bien, por lo complejo que puede resultar el
más fácil la tarea de compartir información entre
desarrollo de un SC, se precisan metodologías
usuarios y dentro de los equipos de trabajo,
sistemáticas que conduzcan a la construcción de un
producto eficaz y permitan la incorporación del DBC ayudándolos a comunicarse y a trabajar unidos de
manera más efectiva y eficiente” (2). Por su parte,
como parte del proceso de desarrollo, ya que este
último tiene la ventaja de adaptarse fácilmente a O’Brien indica que estos sistemas “proveen
herramientas que nos ayudan a colaborar -comunicar
distintos modelos de desarrollo (9), así como permitir
ideas, compartir recursos y coordinar nuestro esfuerzo
la construcción y el mantenimiento de sistemas a bajo
de trabajo cooperativo- como miembros de muchos
costo, de entrega más rápida y de calidad (8,9). En este
sentido, Microsoft® Solution Framework (MSF) es procesos formales e informales, de equipos de
proyectos y de grupos de trabajo que están surgiendo
una metodología abierta que permite su
especialización para cada desarrollo en particular, lo en las organizaciones de hoy día” (7).
cual puede posteriormente extenderse para desarrollos
similares (5). 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
Sobre la base de las ideas expuestas anteriormente, en
beneficios de las inversiones en Tecnologías de la
este artículo se presenta la especialización de esta
Información (TI) (4). En otras palabras, los SC
metodología para el DBC de un SC. En primer lugar,
integran las aplicaciones de groupware (7) (e-mail,
se discutirá lo que engloba un SC y el DBC, algunas
grupos de discusión, bases de datos, gerencia de
características de la tecnología utilizada para los SC y
tareas, agendas electrónicas, videoconferencias, entre
las especificaciones generales de MSF.
otros) existentes en una organización a fin de
Posteriormente, se mostrará la especialización hecha a
compartir e intercambiar información, para maximizar
MSF, a través de la elaboración de todos los artefactos
los beneficios de las inversiones en TI. Sin embargo, a
propuestos para uno de los componentes del SC
veces las mismas no están integradas de tal manera
desarrollado: los componentes tipo Smart Tags.
que logren la conformación de un SC que beneficie el
Seguidamente, se muestran brevemente los otros
negocio. Partiendo del hecho de que a veces se cuenta
componentes del SC construidos con la misma
con aplicaciones implantadas dentro de las
especialización de MSF, con la finalidad de que el
lector tenga una idea completa de la magnitud y las organizaciones, pero éstas no responden cabalmente a
las necesidades del negocio, la integración de
funcionalidades del SC desarrollado. Finalmente, se
plantean las conclusiones del trabajo realizado. 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
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).
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.1. Modelo de Proceso de Desarrollo de
Aplicaciones MSF
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):

Ahora bien, desarrollar un SC no es tarea fácil, ya que a) Fase 1: Visión. En esta fase el equipo y el cliente
se deben integrar muy bien los requerimientos de definen los requerimientos del negocio y los
información de los usuarios con las fuentes de objetivos generales del proyecto. La fase culmina
información disponibles a lo largo de una con el hito Visión y Alcance aprobados.
organización, las cuales en la mayoría de las ocasiones
están en plataformas, formatos y tecnologías diferentes
Implantación
(7,11). Es por ello que es necesario contar con una completa
metodología de desarrollo que tome en cuenta esta de
Fa
s
se ión Vis e de
realidad y facilite la integración, la documentación y la Fa ntac ión
pla
Im
satisfacción de los requerimientos de los usuarios, de
Release Visión/
la organización y tecnológicos, de la mejor manera Readiness Alcance
aprobado aprobado
posible y a través de los beneficios del DBC, el cual
permite integrar con mayor facilidad las TI existentes
Est
Fas ización

dentro de una organización. Bajo estas premisas es que

abil

Plan e de
n
eació
e de

este artículo propone una serie de artefactos a ser

Fas
incorporados a MSF, con la finalidad de refinarl a y
soportar el enfoque de DBC de SC. Cabe destacar Plan del
Alcance
que aunque MSF es muy utilizada, es poco precisa, completo Fase de
Proyecto
aprobado
por lo que permite fácilmente la incorporación el Desarrollo

enfoque de DBC y de artefactos que la refinen con Figura 1. Modelo de Proceso de Desarrollo de
vista a soportar el desarrollo de este tipo particular de Aplicaciones MSF (6).
sistema.
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
3. MICROSOFT® SOLUTION FRAMEWORK
de la especificación funcional del proyecto. Esta
fase culmina con el hito Plan del proyecto
Microsoft® Solution Framework (MSF) es
aprobado.
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 c) Fase 3: Desarrollo. Esta fase involucra una serie
de releases internos del producto, desarrollados por
y necesidades particulares de una organización (5,6).
partes para medir su progreso y para asegurarse
MSF está compuesto por 6 modelos que promueven
que todos sus módulos o partes están sincronizados
principios como la planificación orientada a riesgos,
y pueden integrarse. La fase culmina con el hito
lanzamiento de versiones, hitos (“milestones”)
Alcance completo .
visibles, etc. Estos modelos son (5): (1) Arquitectura
Empresarial; (2) Equipo; (3) Proceso; (4) Gestión de
d) Fase 4: Estabilización. Esta fase se centra en
Riesgo; (5) Diseño de Componentes ; y (6) Aplicación.
probar el producto. El proceso de prueba hace
Para efectos de los intereses de este artículo, se
énfasis en el uso y el funcionamiento del producto
presentan con más detalle los modelos que serán
en la s condiciones del ambiente real. La fase
especializados : el Modelo de Proceso y el Modelo de
culmina con el hito Release Readiness aprobado.
Diseño de Componentes .
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
Línea base del
Plan del Proyecto Diseño Conceptual
Aprobado
Diseño Conceptual Línea base del
Diseño Lógico
Diseño Lógico
Diseño Físico 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 Indica el problema u oportunidad del
Problema negocio.
Visión de la Solución Describe la propuesta de solución.
Presenta los objetivos específicos a
Metas del Proyecto ser alcanzados con la solución.
Presenta el balance adecuado entre
Matriz de Tradeoffs
recursos, cronograma y
del Proyecto
requerimientos.
Roles y Equipo de Indica el personal responsable de la
Trabajo ejecución del proyecto.
Establece las funciones que realizará
Alcance el sistema.
Identifica los eventos inesperados y la
Lista de Riesgos
planificación de contingencias.
Esquema de la Describe el escenario de uso de la
solución 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
Restricción Restricción
por negociable aceptada
optimizar
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ó Tabla 4. Actividades propuestas para realizar el
su Probabilidad, su Impacto y su Prioridad. MSF Modelo de Componentes dentro de la Fase 2 –
propone que los riesgos de mayor prioridad deben ser Planeación.
atendidos antes que los otros. Actividad Descripción
Diseño Establece los conceptos que especifican las
Conceptual necesidades de los usuarios.
Tabla 3. Posibles Riesgos durante el desarrollo de los Diseño
componentes tipo Smart Tags. Organiza los componentes de la solución.
Lógico
No se tiene acceso oportuno a la información y al Especifica las restricciones tecnológicas de
Condición / Diseño Físico la solución.
diseño de los repositorios de datos de los que se
Descripción
necesita hacer uso.

Retraso en la entrega del producto final y/o

Consecuencia
entrega incompleta del producto.
a) Diseño Conceptual: El objetivo de esta actividad es
Probabilidad 0 (Bajo)
comenzar a originar el concepto de la solución
propuesta en el documento de Visión Aprobada. Se
Impacto 3 (Alto)
propone que el diseño conceptual esté compuesto
por los artefactos indicados en la Tabla 5.
Prioridad 0

El líder del proyecto debe identificar a la(s)

Tabla 5. Artefactos propuestos para el Diseño
Mitigación personas encargadas de proveer esta información Conceptual.
y solicitar su pronta atención . Artefacto Descripción
Especifica la ubicación, las
Perfil de los
capacidades y las expectativas, de los
Usuarios
usuarios.
Esquema de la solución: La Figura 3 muestra de Describen qué sucede en la ejecución
Escenarios de de una tarea en particular; especifican
manera esquemática los componentes propuestos; en Uso cómo son los procesos, las funciones
ella se destaca que los componentes se orientan a que y los procedimientos.
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 Ejemplos de estos artefactos para el caso de los
Microsoft® Word y/o Excel en Microsoft® Office XP, componentes tipo Smart Tags se presentan a
a través del uso de un conjunto de componentes tipo continuación.
Smart Tags.
a.1) Perfil de los Usuarios: Del documento de Visión
Aprobada se desprende que en este sistema existe
SEsAR .
SETrack .
AD
un usuario, cuyo perfil se describe a
continuación:
Smart Tags

• Ubicación: Cualquier lugar con acceso a la

Usuario Otras aplicaciones
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.
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 campo “Para:”.
2. El usuario inserta el
efectos de este artículo se describen sólo las titulo del mensaje y
acciones del Smart Tag GC de SETrack y se redacta el e- mail.
3. El usuario hace click
especifican todos los escenarios de uso que se sobre el botón de
derivan de él (ver Tabla 6). “Enviar” de la
ventana.
4. Se envía el e-mail al
Tabla 6. Descripción, Acciones y Escenarios de uso GC.
del Smart Tag GC SETrack. Post-condición: El e-mail es enviado.
Descripción Acciones

Reconoce el alias de Mostrar las cuentas del GC.

cada uno de los GC Reemplazar con el nombre completo del GC.
que figuran en la Mostrar el nombre completo del GC. b) Diseño Lógico: Para esta activ idad de diseño se
tabla GC de Enviar un e-mail al GC. establece la estructura y la comunicación de los
SETrack.
Escenarios de uso Especificación
elementos de la solución. El conjunto de artefactos
Mostrar las cuentas Intención: Poder visualizar el propuestos para esta actividad son descritos en la
del GC número de identificación Tabla 7. En esta etapa no interesan los detalles de
(ID) y el nombre de cada
cuenta que maneja el GC. implementación física, lo importante es entender
Actor: Usuario. las partes que van a conformar el sistema y la
Pre-condición: Se reconoció una palabra
como un alias y se señaló interacción entre ellas (5).
como Smart Tag.
Descripción: 1. Se presenta la
información en una
Tabla 7. Artefactos propuestos para el Diseño Lógico.
caja de mensaje. Artefacto Descripción
2. El usuario cierra la Diseño de la Presenta los elementos y lineamientos
caja de mensaje luego Interfaz de que conforman el diseño de la interfaz de
de leer la usuario.
Usuario
información.
Post-condición: La información se le Componentes de Establece los elementos involucrados en
muestra al actor desde la Solución la solución, así como sus relaciones.
una caja de mensajes. Especificación lógica de las Bases de
Bases de Datos
Reemplazar con el Intención: Poder intercambiar el Lógica Datos que conforman o con las que
nombre completo alias por el nombre interactúa la solución.
del GC completo del GC tal
como apare ce en el
Microsoft® Active Ejemplos de estos artefactos para los componentes
DirectoryT M.
Actor: Usuario.
tipo Smart Tags del SC desarrollado, se presentan
Pre-condición: Se reconoció una palabra a continuación.
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.
Mostrar el nombre Intención: Poder visualizar el
completo del GC nombre completo del GC
tal como aparece en el
Microsoft® Active Figura 4. Muestra de los reconocedores de un Smart
DirectoryT M.
Actor: Usuario. Tag.
Pre-condición: Se reconoció una palabra
como un alias y se señaló b.1) Interfaz de Usuario: Todos los componentes tipo
como Smart Tag. Smart Tags que conforman la solución propuesta
Descripción: 1. Se presenta la
información en una presentarán la misma interfaz que ofrece la
caja de mensaje. tecnología de los componentes tipo Smart Tags
2. El usuario cierra la
caja de mensaje luego
(3). Es necesario que los componentes tipo
de leer la Smart Tags y todas sus funciones (en este caso,
información.
Post-condición: La información se le
las descritas en la Tabla 6) puedan ser empleadas
muestra al actor desde desde documentos de Microsoft® Word y/o
una caja de mensajes. Excel. En la Figura 4 se muestra la interfaz que
Enviar un e-mail al Intención: Poder redactar y enviar
GC un e-mail al GC. presentan los componentes tipo Smart Tags
Actor: Usuario. cuando detectan la presencia de un término.
Pre-condición: Se reconoció una palabra
como un alias y se señaló
como Smart Tag. b.2) Componentes de la solución: El diagrama de los
Descripción: 1. Se presenta una
ventana de “Mensaje
elementos que conforman la solución
nuevo” de Outlook, nuevamente depende de las acciones ofrecidas
con la dirección de e- por cada componente tipo Smart Tag. En la
mail del GC en el
 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:
Acciones del
Documento Word
Smart Tags
“La actividad realizada MicrosoftSchemaURN
por lchacon” GC SETrack
“Mostrar las
cuentas del GC”
Reconocedores “Reemplazar con el
Smart Tags nombre completo del GC”
Otros “Mostrar el nombre
Reconocedores
completo del GC”
Reconocedor “Enviar un e-mail
GC SETrack al GC”
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.
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 Descripción
Restricciones de Especifica la tecnología
Tecnología utilizada.
SETrack
Implementación de la Muestra la apariencia de la
Interfaz del Usuario solución.
Active
Directory
Arquitectura de la Presenta la vista de
solución implantación de la solución.
Microsoft®
Outlook
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)
SEsAR
Microsoft® Office XP
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
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
SETrack del SC desarrollado: e l Planteamiento del Problema,
intranet
/ la Visión de la Solución y el Esquema de la Solución.
Internet
La presentación de estos artefactos permite visualizar
fácilmente la potencialidad completa del SC.
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.
 metodología Microsoft® Solution Framework
empleados en esta investigación, por utilizar un
Formulario enfoque iterativo, ofrecieron la flexibilidad necesaria
SE para manejar exitosamente los cambios de
requerimientos que surgieron a lo largo del todo el
SEsAR período del desarrollo y la incorporación del enfoque
Formulario
del DBC. Sin embargo, por ser una metodología tan
AM
abierta, fue necesaria la definición de artefactos
específicos que permitiesen precisar las necesidades
de los usuarios y las funcionalidades de los
Reviewer Formulario
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 Model v. 3.1. Microsoft Corporation”, Disponible en:
http://www.microsoft.com/msf/. June 2002.

[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.